From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 1 07:27:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19969 for ; Thu, 1 Jun 2000 07:27:28 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.938B06A0@standards.nortelnetworks.com>; Thu, 1 Jun 2000 7:18:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1019 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 1 Jun 2000 07:16:41 -0400 Received: from ns.infoweb.co.cr (206.153.34.34) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EECA5180@standards.nortelnetworks.com>; Thu, 1 Jun 2000 7:06:39 -0400 Received: from host (ip156.providence11.ri.pub-ip.psi.net [38.26.242.156]) by ns.infoweb.co.cr (8.9.1/8.9.1) with ESMTP id FAA18959; Thu, 1 Jun 2000 05:24:28 -0600 X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <200006011124.FAA18959@ns.infoweb.co.cr> Date: Thu, 1 Jun 2000 06:07:22 -0500 Reply-To: Eddy West Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Eddy West Subject: [MOBILE-IP] Your Payments #634A X-To: easy2w@ns.infoweb.co.cr To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA19969 HOW TO SUBSTANTIALLY INCREASE SALES: Easily accept major credit cards right away! ******Act now and all App. & Processing fees waived***** call our (888) 363-7881 now! Our courteous customer care reps. are anxious to help you get your merchant account today. Merchant Status will help you increase sales by an incredible 50% to 400%. Stop losing valuable sales! With one phone call you can be: Accepting all major credit cards! Accepting checks over the net or by Fax! Accepting real time processing for member sites! Gaining customer loyalty and trust! Close the sale now. No more wondering if "The check is in the mail" We specialize in helping those entrepreneurs whom are just starting out: no credit, poor credit, or even if you have great credit. Almost everyone is approved! For the next 5 days we will waive all app. and processing fees! (Other companies charge $200 to $500 to set up) In Business since 1992 Call us today @ 1 (888) 363-7881 and ask for extension FBK for free setup! **************************************************** If you have received this message in error, please remove at: mailto:qp88k@netscape.net?subject=remove **************************************************** From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 1 14:22:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29255 for ; Thu, 1 Jun 2000 14:22:24 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8EEA7010@standards.nortelnetworks.com>; Thu, 1 Jun 2000 14:13:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1445 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 1 Jun 2000 14:12:03 -0400 Received: from opera (168.191.24.145) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F64EB560@standards.nortelnetworks.com>; Thu, 1 Jun 2000 14:02:03 -0400 X-Sender: Opera5@veriomail.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Message-ID: Date: Thu, 1 Jun 2000 14:03:32 -0500 Reply-To: Opera5@VERIOMAIL.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Opera5@VERIOMAIL.COM Subject: [MOBILE-IP] Best New Trade Show Display by Opera Portables, Inc. adv To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Opera Portables, Inc. is offering "by invitation" visits to our web site. Packed full of exciting projects and news, Opera is leading the industry with displays that are as much eye-popping as they are eye catching. Winner of numerous industry awards, including Ernst & Young's Crescendo Award, Exhibitor Magazine's Best New Product, Forty Under 40 and Emerging 30, Opera Portables is a progressive young company with imagination and vision. If you use displays, you really owe it to yourself to check out our stuff! Go to http://3637331613/ Opera Portables, Inc. All removes honored at http://3637331613/removes.htm From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 2 04:25:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26314 for ; Fri, 2 Jun 2000 04:25:10 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.443B0220@standards.nortelnetworks.com>; Fri, 2 Jun 2000 4:16:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1941 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 04:14:41 -0400 Received: from ms.hansol.co.kr (203.235.136.4) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.12416DE0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 4:14:40 -0400 Received: from ns ([210.112.7.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id RAA17196 for ; Fri, 2 Jun 2000 17:22:22 +0900 References: 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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <007601bfcc6b$cf3cd2a0$d012060a@hansol.co.kr> Date: Fri, 2 Jun 2000 17:22:46 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: [MOBILE-IP] RFC2344bis Reverse Tunneling To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi There is a part which describes the usage of reverse tunneling for private ip network. In Figure A1 of A.1, MN has its IP address, Mc. I recommend the fact that IP address Mc belongs to address space C, in lieu of address space A. Figure A1 itself can lead readers to confusion from the viewpoint that each of Fa, Fb, Hb, Hc, and Yc follows the corresponding address space. Jiwoong Lee From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 2 06:54:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27717 for ; Fri, 2 Jun 2000 06:54:22 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.261FBEB0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 6:45:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2066 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 06:44:22 -0400 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9604D5A0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 6:34:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27445; Fri, 2 Jun 2000 06:42:29 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200006021042.GAA27445@ietf.org> Date: Fri, 2 Jun 2000 06:42:29 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-10.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobile IP Challenge/Response Extensions Author(s) : C. Perkins, P. Calhoun Filename : draft-ietf-mobileip-challenge-10.txt Pages : 16 Date : 01-Jun-00 Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-10.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-challenge-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000601103531.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-challenge-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000601103531.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 2 12:44:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07078 for ; Fri, 2 Jun 2000 12:44:29 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0E0AED50@standards.nortelnetworks.com>; Fri, 2 Jun 2000 12:35:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3088 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 12:34:19 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DF5168E0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 12:34:19 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08537; Fri, 2 Jun 2000 09:42:25 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id JAA01597; Fri, 2 Jun 2000 09:42:24 -0700 (PDT) Received: (from samita@localhost) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) id e52GgNI481184; Fri, 2 Jun 2000 09:42:23 -0700 (PDT) X-Sun-Charset: US-ASCII Message-ID: <200006021642.e52GgNI481184@jurassic.eng.sun.com> Date: Fri, 2 Jun 2000 09:42:23 -0700 Reply-To: Samita Chakrabarti Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Samita Chakrabarti Subject: Re: [MOBILE-IP] RFC2344bis Reverse Tunneling X-To: porce@KAIST.AC.KR To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Jiwoong: Section A1 in the current draft puts Mc into address space A to provide an example of a visiting mobile node ( which has home address in address space C) in the foregin network. BTW, I am working with Gabriel to provide a section for the simplest case of private address support through reverse tunneling draft. Hopefully that will clarify the issues vs. possible implementation requirement for private address. Thanks, -Samita ----- Begin Included Message ----- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 2 01:26:18 2000 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Date: Fri, 2 Jun 2000 17:22:46 +0900 From: "Lee, Jiwoong" Subject: [MOBILE-IP] RFC2344bis Reverse Tunneling To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi There is a part which describes the usage of reverse tunneling for private ip network. In Figure A1 of A.1, MN has its IP address, Mc. I recommend the fact that IP address Mc belongs to address space C, in lieu of address space A. Figure A1 itself can lead readers to confusion from the viewpoint that each of Fa, Fb, Hb, Hc, and Yc follows the corresponding address space. Jiwoong Lee ----- End Included Message ----- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 2 14:03:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08681 for ; Fri, 2 Jun 2000 14:03:40 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1B04C2F0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 13:54:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3173 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 13:54:22 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A79924B0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 13:44:20 -0400 Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA09315; Fri, 2 Jun 2000 10:52:35 -0700 (PDT) Received: from rabhalla-nt-l (dhcp-171-70-57-27.cisco.com [171.70.57.27]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ32688; Fri, 2 Jun 2000 10:52:25 -0700 (PDT) X-Sender: rabhalla@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Mime-Version: 1.0 Content-Type: multipart/alternative; types="text/plain,text/html"; boundary="=====================_8022095==_.ALT" Message-ID: <200006021752.AAZ32688@airborne.cisco.com> Date: Fri, 2 Jun 2000 10:53:56 -0700 Reply-To: Rajesh Bhalla Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rajesh Bhalla Subject: Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-10.txt X-To: Internet-Drafts@ietf.org, tagp@3gpp2.org To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200006021042.GAA27445@ietf.org> --=====================_8022095==_.ALT Content-Type: text/plain; charset="us-ascii" Pat, Thanks for clarifications on the use of MN-AAA AE in section 6 of the updated draft. However I have concern about another change in section 3.2 (Foreign Agent Processing for Registration Requests). Para 6 of the updated version states: "the foreign agent MUST NOT remove the MN-AAA AE from the RRQ". I do not think that we want to mandate such behaviour at the FA. In fact, the text in following paras 7 and 9 ( section 3.2) describs the actions at the FA, if it were to remove the MN-AAA AE. Could you please help clarify. Thanks Rajesh Bhalla At 06:42 AM 6/2/00 -0400, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. > > Title : Mobile IP Challenge/Response Extensions > Author(s) : C. Perkins, P. Calhoun > Filename : draft-ietf-mobileip-challenge-10.txt > Pages : 16 > Date : 01-Jun-00 > >Mobile IP, as originally specified, defines an authentication >extension (the Mobile-Foreign Authentication extension) by >which a mobile node can authenticate itself to a foreign agent. >Unfortunately, this extension does not provide ironclad replay >protection for the foreign agent, and does not allow for the use >of existing techniques (such as CHAP) for authenticating portable >computer devices. In this specification, we define extensions for >the Mobile IP Agent Advertisements and the Registration Request >that allow a foreign agent to use a challenge/response mechanism to >authenticate the mobile node. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-10.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-mobileip-challenge-10.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20000601103531.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt > > > --=====================_8022095==_.ALT Content-Type: text/html; charset="us-ascii" Pat,

  Thanks for clarifications on the use of MN-AAA AE  in
  section 6 of the updated draft.
  
  However I have concern about another change in section 3.2
  (Foreign Agent Processing for Registration Requests). Para 6
  of the updated version states: "the foreign agent MUST NOT
  remove the MN-AAA AE from the RRQ".  I do not think that
  we want to mandate such behaviour at the FA. In fact, the text
  in following paras 7 and 9 ( section 3.2) describs the actions
  at the FA,  if it were to remove the MN-AAA AE.

  Could you please help clarify.

Thanks
Rajesh Bhalla


At 06:42 AM 6/2/00 -0400, Internet-Drafts@ietf.org wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.
>
>        Title           : Mobile IP Challenge/Response Extensions
>        Author(s)       : C. Perkins, P. Calhoun
>        Filename        : draft-ietf-mobileip-challenge-10.txt
>        Pages           : 16
>        Date            : 01-Jun-00
>
>Mobile IP, as originally specified, defines an authentication
>extension (the Mobile-Foreign Authentication extension) by
>which a mobile node can authenticate itself to a foreign agent.
>Unfortunately, this extension does not provide ironclad replay
>protection for the foreign agent, and does not allow for the use
>of existing techniques (such as CHAP) for authenticating portable
>computer devices.  In this specification, we define extensions for
>the Mobile IP Agent Advertisements and the Registration Request
>that allow a foreign agent to use a challenge/response mechanism to
>authenticate the mobile node.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-10.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>        "get draft-ietf-mobileip-challenge-10.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>        mailserv@ietf.org.
>In the body type:
>        "FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>        MIME-encoded form by using the "mpack" utility.  To use this
>        feature, insert the command "ENCODING mime" before the "FILE"
>        command.  To decode the response(s), you will need "munpack" or
>        a MIME-compliant mail reader.  Different MIME-compliant mail readers
>        exhibit different behavior, especially when dealing with
>        "multipart" MIME messages (i.e. documents which have been split
>        up into multiple messages), so check your local documentation on
>        how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <20000601103531.I-D@ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-10.txt>
>
--=====================_8022095==_.ALT-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 2 14:30:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09172 for ; Fri, 2 Jun 2000 14:30:50 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E1951980@standards.nortelnetworks.com>; Fri, 2 Jun 2000 14:21:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3324 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 14:20:59 -0400 Received: from mw.3com.com (149.112.20.3) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C622E290@standards.nortelnetworks.com>; Fri, 2 Jun 2000 14:20:59 -0400 Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id NAA00853; Fri, 2 Jun 2000 13:29:12 -0500 (CDT) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 862568F2.0065C9B2 ; Fri, 2 Jun 2000 13:31:47 -0500 X-Lotus-FromDomain: 3COM@3COM-MWGATE Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=l3wDnDf5bVpnpDoSajZ2wVPn60htsWeJy036K1o3KxEQa09CkXkmDRBN" Content-Disposition: inline Message-ID: <862568F2.0065C81D.00@mwgate02.mw.3com.com> Date: Fri, 2 Jun 2000 13:31:25 -0500 Reply-To: Yingchun Xu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yingchun Xu Subject: Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-10.txt X-To: Rajesh Bhalla To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --0__=l3wDnDf5bVpnpDoSajZ2wVPn60htsWeJy036K1o3KxEQa09CkXkmDRBN Content-type: text/plain; charset=us-ascii Content-Disposition: inline Mandating the behaviour of not removing MN-AAA AE is necessary for FA. Otherwise, it will create an interoperability issue. if one FA removes it and another don't and the MN and HA wants to use MN-AAA AE for mobile node authentication, it will work on one visited network and break on another. On the other hand, if FA s keeps MN-AAA AE in RRQ, it's upto HA to decide whether to use it or not. ---Yingchun. Rajesh Bhalla on 06/02/2000 12:53:56 PM Please respond to Rajesh Bhalla Sent by: Rajesh Bhalla To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM cc: (Yingchun Xu/MW/US/3Com) Subject: Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-10.txt Pat, Thanks for clarifications on the use of MN-AAA AE in section 6 of the updated draft. However I have concern about another change in section 3.2 (Foreign Agent Processing for Registration Requests). Para 6 of the updated version states: "the foreign agent MUST NOT remove the MN-AAA AE from the RRQ". I do not think that we want to mandate such behaviour at the FA. In fact, the text in following paras 7 and 9 ( section 3.2) describs the actions at the FA, if it were to remove the MN-AAA AE. Could you please help clarify. Thanks Rajesh Bhalla At 06:42 AM 6/2/00 -0400, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. > > Title : Mobile IP Challenge/Response Extensions > Author(s) : C. Perkins, P. Calhoun > Filename : draft-ietf-mobileip-challenge-10.txt > Pages : 16 > Date : 01-Jun-00 > >Mobile IP, as originally specified, defines an authentication >extension (the Mobile-Foreign Authentication extension) by >which a mobile node can authenticate itself to a foreign agent. >Unfortunately, this extension does not provide ironclad replay >protection for the foreign agent, and does not allow for the use >of existing techniques (such as CHAP) for authenticating portable >computer devices. In this specification, we define extensions for >the Mobile IP Agent Advertisements and the Registration Request >that allow a foreign agent to use a challenge/response mechanism to >authenticate the mobile node. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-10.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-mobileip-challenge-10.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20000601103531.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt > > > --0__=l3wDnDf5bVpnpDoSajZ2wVPn60htsWeJy036K1o3KxEQa09CkXkmDRBN Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PGh0bWw+DQpQYXQsPGJyPg0KPGJyPg0KJm5ic3A7IFRoYW5rcyBmb3IgY2xhcmlmaWNhdGlvbnMg b24gdGhlIHVzZSBvZiBNTi1BQUEgQUUmbmJzcDsgaW48YnI+DQombmJzcDsgc2VjdGlvbiA2IG9m IHRoZSB1cGRhdGVkIGRyYWZ0Ljxicj4NCiZuYnNwOyZuYnNwOyA8YnI+DQombmJzcDsgSG93ZXZl ciBJIGhhdmUgY29uY2VybiBhYm91dCBhbm90aGVyIGNoYW5nZSBpbiBzZWN0aW9uIDMuMiA8YnI+ DQombmJzcDsgKEZvcmVpZ24gQWdlbnQgUHJvY2Vzc2luZyBmb3IgUmVnaXN0cmF0aW9uIFJlcXVl c3RzKS4gUGFyYSA2DQo8YnI+DQombmJzcDsgb2YgdGhlIHVwZGF0ZWQgdmVyc2lvbiBzdGF0ZXM6 ICZxdW90OzxiPnRoZSBmb3JlaWduIGFnZW50IE1VU1QgTk9UDQo8YnI+DQombmJzcDsgcmVtb3Zl IHRoZSBNTi1BQUEgQUUgZnJvbSB0aGUgUlJRJnF1b3Q7LjwvYj4mbmJzcDsgSSBkbyBub3QgdGhp bmsNCnRoYXQgPGJyPg0KJm5ic3A7IHdlIHdhbnQgdG8gbWFuZGF0ZSBzdWNoIGJlaGF2aW91ciBh dCB0aGUgRkEuIEluIGZhY3QsIHRoZSB0ZXh0DQo8YnI+DQombmJzcDsgaW4gZm9sbG93aW5nIHBh cmFzIDcgYW5kIDkgKCBzZWN0aW9uIDMuMikgZGVzY3JpYnMgdGhlIGFjdGlvbnMNCjxicj4NCiZu YnNwOyBhdCB0aGUgRkEsJm5ic3A7IGlmIGl0IHdlcmUgdG8gcmVtb3ZlIHRoZSBNTi1BQUEgQUUu PGJyPg0KPGJyPg0KJm5ic3A7IENvdWxkIHlvdSBwbGVhc2UgaGVscCBjbGFyaWZ5Ljxicj4NCjxi cj4NClRoYW5rczxicj4NClJhamVzaCBCaGFsbGEgPGJyPg0KPGJyPg0KPGJyPg0KQXQgMDY6NDIg QU0gNi8yLzAwIC0wNDAwLCBJbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmcgd3JvdGU6PGJyPg0KJmd0 O0EgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cw0KZGlyZWN0b3JpZXMuPGJyPg0KJmd0O1RoaXMgZHJhZnQgaXMgYSB3b3JrIGl0 ZW0gb2YgdGhlIElQIFJvdXRpbmcgZm9yIFdpcmVsZXNzL01vYmlsZSBIb3N0cw0KV29ya2luZyBH cm91cCBvZiB0aGUgSUVURi48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KVGl0bGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOg0KTW9iaWxlIElQIENoYWxsZW5nZS9S ZXNwb25zZSBFeHRlbnNpb25zPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KQXV0aG9yKHMpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDogQy4gUGVya2lucywgUC4NCkNhbGhvdW48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpGaWxlbmFtZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA6DQpkcmFmdC1pZXRmLW1vYmlsZWlwLWNoYWxsZW5nZS0xMC50 eHQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpQ YWdlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA6DQoxNjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCkRhdGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOg0KMDEtSnVuLTAwPGJyPg0KJmd0Ozxicj4NCiZndDtN b2JpbGUgSVAsIGFzIG9yaWdpbmFsbHkgc3BlY2lmaWVkLCBkZWZpbmVzIGFuIGF1dGhlbnRpY2F0 aW9uPGJyPg0KJmd0O2V4dGVuc2lvbiAodGhlIE1vYmlsZS1Gb3JlaWduIEF1dGhlbnRpY2F0aW9u IGV4dGVuc2lvbikgYnk8YnI+DQomZ3Q7d2hpY2ggYSBtb2JpbGUgbm9kZSBjYW4gYXV0aGVudGlj YXRlIGl0c2VsZiB0byBhIGZvcmVpZ24gYWdlbnQuPGJyPg0KJmd0O1VuZm9ydHVuYXRlbHksIHRo aXMgZXh0ZW5zaW9uIGRvZXMgbm90IHByb3ZpZGUgaXJvbmNsYWQgcmVwbGF5PGJyPg0KJmd0O3By b3RlY3Rpb24gZm9yIHRoZSBmb3JlaWduIGFnZW50LCBhbmQgZG9lcyBub3QgYWxsb3cgZm9yIHRo ZQ0KdXNlPGJyPg0KJmd0O29mIGV4aXN0aW5nIHRlY2huaXF1ZXMgKHN1Y2ggYXMgQ0hBUCkgZm9y IGF1dGhlbnRpY2F0aW5nDQpwb3J0YWJsZTxicj4NCiZndDtjb21wdXRlciBkZXZpY2VzLiZuYnNw OyBJbiB0aGlzIHNwZWNpZmljYXRpb24sIHdlIGRlZmluZSBleHRlbnNpb25zDQpmb3I8YnI+DQom Z3Q7dGhlIE1vYmlsZSBJUCBBZ2VudCBBZHZlcnRpc2VtZW50cyBhbmQgdGhlIFJlZ2lzdHJhdGlv biBSZXF1ZXN0PGJyPg0KJmd0O3RoYXQgYWxsb3cgYSBmb3JlaWduIGFnZW50IHRvIHVzZSBhIGNo YWxsZW5nZS9yZXNwb25zZSBtZWNoYW5pc20NCnRvPGJyPg0KJmd0O2F1dGhlbnRpY2F0ZSB0aGUg bW9iaWxlIG5vZGUuPGJyPg0KJmd0Ozxicj4NCiZndDtBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1E cmFmdCBpczo8YnI+DQomZ3Q7PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtaWV0Zi1tb2JpbGVpcC1jaGFsbGVuZ2UtMTAudHh0IiBldWRvcmE9ImF1dG91 cmwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbW9iaWxl aXAtY2hhbGxlbmdlLTEwLnR4dDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0O0ludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzDQo8YSBocmVmPSJmdHA6Ly9mdHAvIiBl dWRvcmE9ImF1dG91cmwiPkZUUDwvYT4uIExvZ2luIHdpdGggdGhlDQp1c2VybmFtZTxicj4NCiZn dDsmcXVvdDthbm9ueW1vdXMmcXVvdDsgYW5kIGEgcGFzc3dvcmQgb2YgeW91ciBlLW1haWwgYWRk cmVzcy4gQWZ0ZXINCmxvZ2dpbmcgaW4sPGJyPg0KJmd0O3R5cGUgJnF1b3Q7Y2QgaW50ZXJuZXQt ZHJhZnRzJnF1b3Q7IGFuZCB0aGVuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtnZXQNCmRyYWZ0LWlldGYtbW9iaWxlaXAtY2hhbGxlbmdl LTEwLnR4dCZxdW90Oy48YnI+DQomZ3Q7PGJyPg0KJmd0O0EgbGlzdCBvZiBJbnRlcm5ldC1EcmFm dHMgZGlyZWN0b3JpZXMgY2FuIGJlIGZvdW5kIGluPGJyPg0KJmd0OzxhIGhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwiIGV1ZG9yYT0iYXV0b3VybCI+aHR0cDovL3d3dy5pZXRm Lm9yZy9zaGFkb3cuaHRtbDwvYT48YnI+DQomZ3Q7b3INCjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRm Lm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0IiBldWRvcmE9ImF1dG91cmwiPmZ0cDovL2Z0cC5p ZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0PC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0O0ludGVybmV0LURyYWZ0cyBjYW4gYWxzbyBiZSBvYnRhaW5lZCBieSBlLW1haWwuPGJy Pg0KJmd0Ozxicj4NCiZndDtTZW5kIGEgbWVzc2FnZSB0bzo8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1haWxzZXJ2QGlldGYub3JnLjxicj4NCiZn dDtJbiB0aGUgYm9keSB0eXBlOjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJnF1b3Q7RklMRQ0KL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1v YmlsZWlwLWNoYWxsZW5nZS0xMC50eHQmcXVvdDsuPGJyPg0KJmd0Ozxicj4NCiZndDtOT1RFOiZu YnNwOyZuYnNwOyBUaGUgbWFpbCBzZXJ2ZXIgYXQgaWV0Zi5vcmcgY2FuIHJldHVybiB0aGUgZG9j dW1lbnQNCmluPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBNSU1FLWVuY29kZWQgZm9ybSBieSB1c2luZw0KdGhlICZxdW90O21wYWNrJnF1b3Q7IHV0 aWxpdHkuJm5ic3A7IFRvIHVzZSB0aGlzPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBmZWF0dXJlLCBpbnNlcnQgdGhlDQpjb21tYW5kICZxdW90O0VO Q09ESU5HIG1pbWUmcXVvdDsgYmVmb3JlIHRoZSAmcXVvdDtGSUxFJnF1b3Q7PGJyPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb21tYW5kLiZuYnNwOyBU byBkZWNvZGUNCnRoZSByZXNwb25zZShzKSwgeW91IHdpbGwgbmVlZCAmcXVvdDttdW5wYWNrJnF1 b3Q7IG9yPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBhIE1JTUUtY29tcGxpYW50IG1haWwNCnJlYWRlci4mbmJzcDsgRGlmZmVyZW50IE1JTUUtY29t cGxpYW50IG1haWwgcmVhZGVyczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZXhoaWJpdCBkaWZmZXJlbnQNCmJlaGF2aW9yLCBlc3BlY2lhbGx5IHdo ZW4gZGVhbGluZyB3aXRoPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmcXVvdDttdWx0aXBhcnQmcXVvdDsgTUlNRQ0KbWVzc2FnZXMgKGkuZS4gZG9j dW1lbnRzIHdoaWNoIGhhdmUgYmVlbiBzcGxpdDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXAgaW50byBtdWx0aXBsZQ0KbWVzc2FnZXMpLCBzbyBj aGVjayB5b3VyIGxvY2FsIGRvY3VtZW50YXRpb24gb248YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhvdyB0byBtYW5pcHVsYXRlIHRoZXNlDQptZXNz YWdlcy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDtCZWxvdyBpcyB0aGUgZGF0YSB3aGlj aCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwNCnJlYWRlcjxicj4NCiZndDtpbXBs ZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9m DQp0aGU8YnI+DQomZ3Q7SW50ZXJuZXQtRHJhZnQuPGJyPg0KJmd0O0NvbnRlbnQtVHlwZTogdGV4 dC9wbGFpbjxicj4NCiZndDtDb250ZW50LUlEOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJmx0 OzIwMDAwNjAxMTAzNTMxLkktREBpZXRmLm9yZyZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0O0VOQ09E SU5HIG1pbWU8YnI+DQomZ3Q7RklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbW9iaWxl aXAtY2hhbGxlbmdlLTEwLnR4dDxicj4NCiZndDs8YnI+DQomZ3Q7Jmx0OzxhIGhyZWY9ImZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tb2JpbGVpcC1jaGFsbGVu Z2UtMTAudHh0IiBldWRvcmE9ImF1dG91cmwiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtaWV0Zi1tb2JpbGVpcC1jaGFsbGVuZ2UtMTAudHh0PC9hPiZndDs8YnI+DQom Z3Q7IDxicj4NCjwvaHRtbD4NCg0K --0__=l3wDnDf5bVpnpDoSajZ2wVPn60htsWeJy036K1o3KxEQa09CkXkmDRBN-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 2 14:38:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09401 for ; Fri, 2 Jun 2000 14:38:01 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DFE61480@standards.nortelnetworks.com>; Fri, 2 Jun 2000 14:28:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3430 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 14:27:51 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BBA476C0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 14:27:51 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05561; Fri, 2 Jun 2000 12:35:59 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA03589; Fri, 2 Jun 2000 11:35:57 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA12084; Fri, 2 Jun 2000 11:35:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 2 Jun 2000 11:35:44 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-10.txt X-To: Yingchun Xu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <862568F2.0065C81D.00@mwgate02.mw.3com.com> Precisely. It comes down to a policy decision on the Home Agent on whether or not the MN-AAA needs to be authenticated. Ensuring that the FA never strips the extension allows the HA to make such a decision. PatC ---- > > > Mandating the behaviour of not removing MN-AAA AE is necessary for FA. > Otherwise, it will create an interoperability issue. > if one FA removes it and another don't and the MN and HA wants to use MN-AAA > AE for mobile node authentication, it will work on one visited network and > break on another. > On the other hand, if FA s keeps MN-AAA AE in RRQ, it's upto HA to decide > whether to use it or not. > > ---Yingchun. > > > > > > Rajesh Bhalla on 06/02/2000 12:53:56 PM > > Please respond to Rajesh Bhalla > > Sent by: Rajesh Bhalla > > > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > cc: (Yingchun Xu/MW/US/3Com) > Subject: Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-10.txt > > > > Pat, > > Thanks for clarifications on the use of MN-AAA AE in > section 6 of the updated draft. > > However I have concern about another change in section 3.2 > (Foreign Agent Processing for Registration Requests). Para 6 > of the updated version states: "the foreign agent MUST NOT > remove the MN-AAA AE from the RRQ". I do not think that > we want to mandate such behaviour at the FA. In fact, the text > in following paras 7 and 9 ( section 3.2) describs the actions > at the FA, if it were to remove the MN-AAA AE. > > Could you please help clarify. > > Thanks > Rajesh Bhalla > > > At 06:42 AM 6/2/00 -0400, Internet-Drafts@ietf.org wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >This draft is a work item of the IP Routing for Wireless/Mobile Hosts > Working Group of the IETF. > > > > Title : Mobile IP Challenge/Response Extensions > > Author(s) : C. Perkins, P. Calhoun > > Filename : draft-ietf-mobileip-challenge-10.txt > > Pages : 16 > > Date : 01-Jun-00 > > > >Mobile IP, as originally specified, defines an authentication > >extension (the Mobile-Foreign Authentication extension) by > >which a mobile node can authenticate itself to a foreign agent. > >Unfortunately, this extension does not provide ironclad replay > >protection for the foreign agent, and does not allow for the use > >of existing techniques (such as CHAP) for authenticating portable > >computer devices. In this specification, we define extensions for > >the Mobile IP Agent Advertisements and the Registration Request > >that allow a foreign agent to use a challenge/response mechanism to > >authenticate the mobile node. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-10.txt > > > >Internet-Drafts are also available by anonymous FTP. Login with the username > >"anonymous" and a password of your e-mail address. After logging in, >type > "cd internet-drafts" and then > "get > draft-ietf-mobileip-challenge-10.txt". > > >A list of Internet-Drafts directories can be found in > >http://www.ietf.org/shadow.html > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > >Internet-Drafts can also be obtained by e-mail. > > > >Send a message to: > > mailserv@ietf.org. > >In the body type: > > "FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt". > > > >NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > >Below is the data which will enable a MIME compliant mail reader > >implementation to automatically retrieve the ASCII version of the > >Internet-Draft. > >Content-Type: text/plain > >Content-ID: <20000601103531.I-D@ietf.org> > > > >ENCODING mime > >FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt > > > > > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 2 14:58:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09830 for ; Fri, 2 Jun 2000 14:58:39 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CF7EAE10@standards.nortelnetworks.com>; Fri, 2 Jun 2000 14:49:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3531 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 14:49:21 -0400 Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BC2DEAB0@standards.nortelnetworks.com>; Fri, 2 Jun 2000 14:49:20 -0400 Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA08829; Fri, 2 Jun 2000 11:57:39 -0700 (PDT) Received: from rabhalla-nt-l (dhcp-171-70-57-27.cisco.com [171.70.57.27]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ33859; Fri, 2 Jun 2000 11:57:29 -0700 (PDT) X-Sender: rabhalla@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <200006021857.AAZ33859@airborne.cisco.com> Date: Fri, 2 Jun 2000 11:59:01 -0700 Reply-To: Rajesh Bhalla Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rajesh Bhalla Subject: Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-10.txt X-To: Yingchun_Xu@3com.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <882568F2.006568C3.00@hqoutbound.ops.3com.com> To remove the ambiguity, text in paras 7 and 9 (section 3.2) should then be changed. These paras talk about the possibility of FA removing MN-AAA AE. -- Rajesh At 01:31 PM 6/2/00 -0500, Yingchun_Xu@3com.com wrote: > > >Mandating the behaviour of not removing MN-AAA AE is necessary for FA. >Otherwise, it will create an interoperability issue. >if one FA removes it and another don't and the MN and HA wants to use MN-AAA AE >for mobile node authentication, it will work on one visited network and break on >another. >On the other hand, if FA s keeps MN-AAA AE in RRQ, it's upto HA to decide >whether to use it or not. > >---Yingchun. > > > > > >Rajesh Bhalla on 06/02/2000 12:53:56 PM > >Please respond to Rajesh Bhalla > >Sent by: Rajesh Bhalla > > >To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >cc: (Yingchun Xu/MW/US/3Com) >Subject: Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-10.txt > > > >Pat, > > Thanks for clarifications on the use of MN-AAA AE in > section 6 of the updated draft. > > However I have concern about another change in section 3.2 > (Foreign Agent Processing for Registration Requests). Para 6 > of the updated version states: "the foreign agent MUST NOT > remove the MN-AAA AE from the RRQ". I do not think that > we want to mandate such behaviour at the FA. In fact, the text > in following paras 7 and 9 ( section 3.2) describs the actions > at the FA, if it were to remove the MN-AAA AE. > > Could you please help clarify. > >Thanks >Rajesh Bhalla > > >At 06:42 AM 6/2/00 -0400, Internet-Drafts@ietf.org wrote: >>A New Internet-Draft is available from the on-line Internet-Drafts >directories. >>This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working >Group of the IETF. >> >> Title : Mobile IP Challenge/Response Extensions >> Author(s) : C. Perkins, P. Calhoun >> Filename : draft-ietf-mobileip-challenge-10.txt >> Pages : 16 >> Date : 01-Jun-00 >> >>Mobile IP, as originally specified, defines an authentication >>extension (the Mobile-Foreign Authentication extension) by >>which a mobile node can authenticate itself to a foreign agent. >>Unfortunately, this extension does not provide ironclad replay >>protection for the foreign agent, and does not allow for the use >>of existing techniques (such as CHAP) for authenticating portable >>computer devices. In this specification, we define extensions for >>the Mobile IP Agent Advertisements and the Registration Request >>that allow a foreign agent to use a challenge/response mechanism to >>authenticate the mobile node. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-10.txt >> >>Internet-Drafts are also available by anonymous FTP. Login with the username >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-ietf-mobileip-challenge-10.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >>Content-Type: text/plain >>Content-ID: <20000601103531.I-D@ietf.org> >> >>ENCODING mime >>FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt >> >> >> > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 2 16:37:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12853 for ; Fri, 2 Jun 2000 16:37:00 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8D495640@standards.nortelnetworks.com>; Fri, 2 Jun 2000 16:28:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3949 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 16:26:35 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.51A76050@standards.nortelnetworks.com>; Fri, 2 Jun 2000 16:26:35 -0400 Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA04303; Fri, 2 Jun 2000 13:34:55 -0700 (PDT) Received: from rabhalla-nt-l (dhcp-171-70-57-27.cisco.com [171.70.57.27]) by airborne.cisco.com (Mirapoint) with SMTP id AAZ35182; Fri, 2 Jun 2000 13:34:45 -0700 (PDT) X-Sender: rabhalla@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 References: <"Your message with ID" <862568F2.0065C81D.00@mwgate02.mw.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <200006022034.AAZ35182@airborne.cisco.com> Date: Fri, 2 Jun 2000 13:36:16 -0700 Reply-To: Rajesh Bhalla Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rajesh Bhalla Subject: Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-10.txt X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Pat, Alright. Do you then plan to update the draft to remove ambiguity at other places [paras 7 and 9 (section 3.2)]. There the draft talks about the possibility of FA removing MN-AAA AE. --- Rajesh At 11:35 AM 6/2/00 -0700, pcalhoun@eng.sun.com wrote: >Precisely. It comes down to a policy decision on the Home Agent on whether or >not the MN-AAA needs to be authenticated. Ensuring that the FA never strips >the extension allows the HA to make such a decision. > >PatC >---- >> >> >> Mandating the behaviour of not removing MN-AAA AE is necessary for FA. >> Otherwise, it will create an interoperability issue. >> if one FA removes it and another don't and the MN and HA wants to use MN-AAA >> AE for mobile node authentication, it will work on one visited network and >> break on another. >> On the other hand, if FA s keeps MN-AAA AE in RRQ, it's upto HA to decide >> whether to use it or not. >> >> ---Yingchun. >> >> >> >> >> >> Rajesh Bhalla on 06/02/2000 12:53:56 PM >> >> Please respond to Rajesh Bhalla >> >> Sent by: Rajesh Bhalla >> >> >> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >> cc: (Yingchun Xu/MW/US/3Com) >> Subject: Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-10.txt >> >> >> >> Pat, >> >> Thanks for clarifications on the use of MN-AAA AE in >> section 6 of the updated draft. >> >> However I have concern about another change in section 3.2 >> (Foreign Agent Processing for Registration Requests). Para 6 >> of the updated version states: "the foreign agent MUST NOT >> remove the MN-AAA AE from the RRQ". I do not think that >> we want to mandate such behaviour at the FA. In fact, the text >> in following paras 7 and 9 ( section 3.2) describs the actions >> at the FA, if it were to remove the MN-AAA AE. >> >> Could you please help clarify. >> >> Thanks >> Rajesh Bhalla >> >> >> At 06:42 AM 6/2/00 -0400, Internet-Drafts@ietf.org wrote: >> >A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >This draft is a work item of the IP Routing for Wireless/Mobile Hosts >> Working Group of the IETF. >> > >> > Title : Mobile IP Challenge/Response Extensions >> > Author(s) : C. Perkins, P. Calhoun >> > Filename : draft-ietf-mobileip-challenge-10.txt >> > Pages : 16 >> > Date : 01-Jun-00 >> > >> >Mobile IP, as originally specified, defines an authentication >> >extension (the Mobile-Foreign Authentication extension) by >> >which a mobile node can authenticate itself to a foreign agent. >> >Unfortunately, this extension does not provide ironclad replay >> >protection for the foreign agent, and does not allow for the use >> >of existing techniques (such as CHAP) for authenticating portable >> >computer devices. In this specification, we define extensions for >> >the Mobile IP Agent Advertisements and the Registration Request >> >that allow a foreign agent to use a challenge/response mechanism to >> >authenticate the mobile node. >> > >> >A URL for this Internet-Draft is: >> >http://www.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-10.txt >> > >> >Internet-Drafts are also available by anonymous FTP. Login with the username >> >"anonymous" and a password of your e-mail address. After logging in, >type >> "cd internet-drafts" and then > "get >> draft-ietf-mobileip-challenge-10.txt". > >> >A list of Internet-Drafts directories can be found in >> >http://www.ietf.org/shadow.html >> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > >> > >> >Internet-Drafts can also be obtained by e-mail. >> > >> >Send a message to: >> > mailserv@ietf.org. >> >In the body type: >> > "FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt". >> > >> >NOTE: The mail server at ietf.org can return the document in >> > MIME-encoded form by using the "mpack" utility. To use this >> > feature, insert the command "ENCODING mime" before the "FILE" >> > command. To decode the response(s), you will need "munpack" or >> > a MIME-compliant mail reader. Different MIME-compliant mail readers >> > exhibit different behavior, especially when dealing with >> > "multipart" MIME messages (i.e. documents which have been split >> > up into multiple messages), so check your local documentation on >> > how to manipulate these messages. >> > >> > >> >Below is the data which will enable a MIME compliant mail reader >> >implementation to automatically retrieve the ASCII version of the >> >Internet-Draft. >> >Content-Type: text/plain >> >Content-ID: <20000601103531.I-D@ietf.org> >> > >> >ENCODING mime >> >FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt >> > >> > >> > >> > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 2 18:02:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15854 for ; Fri, 2 Jun 2000 18:02:48 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8B538340@standards.nortelnetworks.com>; Fri, 2 Jun 2000 17:54:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4065 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 17:52:06 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.44311040@standards.nortelnetworks.com>; Fri, 2 Jun 2000 17:52:06 -0400 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA08535; Fri, 2 Jun 2000 16:00:14 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA22335; Fri, 2 Jun 2000 15:00:10 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA15835; Fri, 2 Jun 2000 15:00:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 2 Jun 2000 14:59:58 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-10.txt X-To: Rajesh Bhalla To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <200006022034.AAZ35182@airborne.cisco.com> > Pat, > > Alright. Do you then plan to update the draft to remove ambiguity > at other places [paras 7 and 9 (section 3.2)]. There the draft > talks about the possibility of FA removing MN-AAA AE. Paragraph 7 discusses the removal of the MN-AAA extension, while Paragraph 9 discusses the removal of the Challenge extension. There is no inconsistency, as far as I can tell. PatC > > --- Rajesh > > At 11:35 AM 6/2/00 -0700, pcalhoun@eng.sun.com wrote: > >Precisely. It comes down to a policy decision on the Home Agent on whether > or >not the MN-AAA needs to be authenticated. Ensuring that the FA never > strips >the extension allows the HA to make such a decision. > > > >PatC > >---- > >> > >> > >> Mandating the behaviour of not removing MN-AAA AE is necessary for FA. > >> Otherwise, it will create an interoperability issue. > >> if one FA removes it and another don't and the MN and HA wants to use > MN-AAA >> AE for mobile node authentication, it will work on one visited > network and >> break on another. > >> On the other hand, if FA s keeps MN-AAA AE in RRQ, it's upto HA to decide > >> whether to use it or not. > >> > >> ---Yingchun. > >> > >> > >> > >> > >> > >> Rajesh Bhalla on 06/02/2000 12:53:56 PM > >> > >> Please respond to Rajesh Bhalla > >> > >> Sent by: Rajesh Bhalla > >> > >> > >> To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > >> cc: (Yingchun Xu/MW/US/3Com) > >> Subject: Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-10.txt > >> > >> > >> > >> Pat, > >> > >> Thanks for clarifications on the use of MN-AAA AE in > >> section 6 of the updated draft. > >> > >> However I have concern about another change in section 3.2 > >> (Foreign Agent Processing for Registration Requests). Para 6 > >> of the updated version states: "the foreign agent MUST NOT > >> remove the MN-AAA AE from the RRQ". I do not think that > >> we want to mandate such behaviour at the FA. In fact, the text > >> in following paras 7 and 9 ( section 3.2) describs the actions > >> at the FA, if it were to remove the MN-AAA AE. > >> > >> Could you please help clarify. > >> > >> Thanks > >> Rajesh Bhalla > >> > >> > >> At 06:42 AM 6/2/00 -0400, Internet-Drafts@ietf.org wrote: > >> >A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> >This draft is a work item of the IP Routing for Wireless/Mobile Hosts > >> Working Group of the IETF. > >> > > >> > Title : Mobile IP Challenge/Response Extensions > >> > Author(s) : C. Perkins, P. Calhoun > >> > Filename : draft-ietf-mobileip-challenge-10.txt > >> > Pages : 16 > >> > Date : 01-Jun-00 > >> > > >> >Mobile IP, as originally specified, defines an authentication > >> >extension (the Mobile-Foreign Authentication extension) by > >> >which a mobile node can authenticate itself to a foreign agent. > >> >Unfortunately, this extension does not provide ironclad replay > >> >protection for the foreign agent, and does not allow for the use > >> >of existing techniques (such as CHAP) for authenticating portable > >> >computer devices. In this specification, we define extensions for > >> >the Mobile IP Agent Advertisements and the Registration Request > >> >that allow a foreign agent to use a challenge/response mechanism to > >> >authenticate the mobile node. > >> > > >> >A URL for this Internet-Draft is: > >> >http://www.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-10.txt > >> > > >> >Internet-Drafts are also available by anonymous FTP. Login with the > username >> >"anonymous" and a password of your e-mail address. After > logging in, >type >> "cd internet-drafts" and then > "get > >> draft-ietf-mobileip-challenge-10.txt". > > >> >A list of Internet-Drafts directories can be found in > >> >http://www.ietf.org/shadow.html > >> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > > >> > > >> >Internet-Drafts can also be obtained by e-mail. > >> > > >> >Send a message to: > >> > mailserv@ietf.org. > >> >In the body type: > >> > "FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt". > >> > > >> >NOTE: The mail server at ietf.org can return the document in > >> > MIME-encoded form by using the "mpack" utility. To use this > >> > feature, insert the command "ENCODING mime" before the "FILE" > >> > command. To decode the response(s), you will need "munpack" or > >> > a MIME-compliant mail reader. Different MIME-compliant mail > readers >> > exhibit different behavior, especially when dealing with > >> > "multipart" MIME messages (i.e. documents which have been split > >> > up into multiple messages), so check your local documentation on > >> > how to manipulate these messages. > >> > > >> > > >> >Below is the data which will enable a MIME compliant mail reader > >> >implementation to automatically retrieve the ASCII version of the > >> >Internet-Draft. > >> >Content-Type: text/plain > >> >Content-ID: <20000601103531.I-D@ietf.org> > >> > > >> >ENCODING mime > >> >FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt > >> > > >> > > >> > >> > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 2 21:48:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19335 for ; Fri, 2 Jun 2000 21:48:43 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1C26C430@standards.nortelnetworks.com>; Fri, 2 Jun 2000 21:40:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4338 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 2 Jun 2000 21:38:50 -0400 Received: from ms.hansol.co.kr (203.235.136.4) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F052D380@standards.nortelnetworks.com>; Fri, 2 Jun 2000 21:38:49 -0400 Received: from ns ([210.112.7.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id KAA18938; Sat, 3 Jun 2000 10:46:30 +0900 References: <200006021642.e52GgNI481184@jurassic.eng.sun.com> 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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <004601bfccfd$ac7675e0$d012060a@hansol.co.kr> Date: Sat, 3 Jun 2000 10:46:56 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: Re: [MOBILE-IP] RFC2344bis Reverse Tunneling X-To: Samita Chakrabarti To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear Samita, Please notice the statement in pp.20, RFC2344bis-01 Figure A1: NON-ROUTABLE PACKETS IN DISPARATE ADDRESS SPACES Mc Fa Fb Hb Hc Yc [MN]-----------------[FA]----------------[HA]---------------[Y] Addr space A Addr space B Addr space C In this diagram, there are three disparate address spaces: A, B and C. The home agent (HA) has one address each on address spaces B and C, and the foreign agent (FA), on address spaces A and B. The mobile node's (MN) has a permanent address, Mc, within address space C. Mc belongs to Addr Space C, but not A. If Mc belongs to Addr Space A, Mc is a local address and cannot send [Mc->Yc] IP diagram since they are disparate. Besides, if Mc belongs to Addr Space A, is it possible a MN aquires a co-located COA and find an FA again to use it as a local mobile agent ? ==> For this, I've not precisely verified yet. Regards, Jiwoong Lee ----- Original Message ----- From: Samita Chakrabarti To: Cc: Sent: Saturday, June 03, 2000 1:42 AM Subject: Re: [MOBILE-IP] RFC2344bis Reverse Tunneling > Hi Jiwoong: > > Section A1 in the current draft puts Mc into address space A to > provide an example of a visiting mobile node ( which has home > address in address space C) in the foregin network. > > BTW, I am working with Gabriel to provide a section for the simplest > case of private address support through reverse tunneling draft. > Hopefully that will clarify the issues vs. possible implementation > requirement for private address. > > Thanks, > -Samita > > ----- Begin Included Message ----- > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 2 01:26:18 2000 > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > X-Priority: 3 > X-MSMail-Priority: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 > Date: Fri, 2 Jun 2000 17:22:46 +0900 > From: "Lee, Jiwoong" > Subject: [MOBILE-IP] RFC2344bis Reverse Tunneling > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > > Hi > > There is a part which describes the usage of reverse tunneling for > private ip network. > > In Figure A1 of A.1, MN has its IP address, Mc. > > I recommend the fact that IP address Mc belongs to address space C, > in lieu of address space A. > > Figure A1 itself can lead readers to confusion from the viewpoint that each > of Fa, Fb, Hb, Hc, and Yc follows the corresponding address space. > > > Jiwoong Lee > > > ----- End Included Message ----- > > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jun 3 04:41:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04847 for ; Sat, 3 Jun 2000 04:41:32 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BAB09D40@standards.nortelnetworks.com>; Sat, 3 Jun 2000 4:32:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4559 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 3 Jun 2000 04:31:02 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.20463D10@standards.nortelnetworks.com>; Sat, 3 Jun 2000 4:21:01 -0400 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA13309 for ; Sat, 3 Jun 2000 02:29:13 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.53.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id BAA29755; Sat, 3 Jun 2000 01:29:12 -0700 (PDT) Received: from ha1mpk-mail.Eng.Sun.COM by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA26241; Sat, 3 Jun 2000 01:29:07 -0700 X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200006030829.BAA26241@ha1mpk-mail.eng.sun.com> Date: Sat, 3 Jun 2000 01:32:15 -0700 Reply-To: gab@sun.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gabriel Montenegro Subject: Re: [MOBILE-IP] RFC2344bis Reverse Tunneling X-To: "Lee, Jiwoong" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit hi, i'm sorry, i don't understand your question. i believe it started with this a few messages back : >> In Figure A1 of A.1, MN has its IP address, Mc. >> >> I recommend the fact that IP address Mc belongs to address space C... but you yourself cite the text under figure A1 in 2344bis: > and B. The mobile node's (MN) has a permanent address, Mc, > within address space C. aren't these two statements equivalent? if so, what is your objective in 'recommending' that which is already explicitly stated in 2344bis? -gabriel From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jun 3 09:33:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06242 for ; Sat, 3 Jun 2000 09:33:27 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8B0C6E10@standards.nortelnetworks.com>; Sat, 3 Jun 2000 9:24:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4894 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 3 Jun 2000 09:23:30 -0400 Received: from webmail2.hansolm.com (210.112.10.141) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.617E27A0@standards.nortelnetworks.com>; Sat, 3 Jun 2000 9:23:30 -0400 Received: from ns ([210.112.125.193]) by webmail2.hansolm.com with Microsoft SMTPSVC(5.5.1877.197.19); Sat, 3 Jun 2000 22:26:41 +0900 References: <200006030829.BAA26241@ha1mpk-mail.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <007001bfcd60$2319a160$5c12060a@hansol.co.kr> Date: Sat, 3 Jun 2000 22:32:12 +0900 Reply-To: Jiwoong Lee Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jiwoong Lee Subject: Re: [MOBILE-IP] RFC2344bis Reverse Tunneling X-To: gab@sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA06242 Dear Gabriel I think I misunderstood the denotation at first. It was my mistake. I'm sorry for that. I overlooked the meaning of "c" in "Mc." BTW, figure A1 itself might mislead readers to confusion, since the position of "Mc" is between [MN] and [FA] - belonging address space A. Thank you for your comment. Jiwoong Lee ----- Original Message ----- From: Gabriel Montenegro To: Sent: Saturday, June 03, 2000 5:32 PM Subject: Re: [MOBILE-IP] RFC2344bis Reverse Tunneling > hi, i'm sorry, i don't understand your question. > > i believe it started with this a few messages back : > > >> In Figure A1 of A.1, MN has its IP address, Mc. > >> > >> I recommend the fact that IP address Mc belongs to address space C... > > but you yourself cite the text under figure A1 in 2344bis: > > > and B. The mobile node's (MN) has a permanent address, Mc, > > within address space C. > > aren't these two statements equivalent? if so, what is your > objective in 'recommending' that which is already explicitly > stated in 2344bis? > > -gabriel > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jun 4 22:00:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11928 for ; Sun, 4 Jun 2000 22:00:06 -0400 (EDT) Received: from standards (47.234.32.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F62AFCC0@standards.nortelnetworks.com>; 4 Jun 2000 21:50:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5549 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 4 Jun 2000 21:49:15 -0400 Received: from ms.hansol.co.kr (203.235.136.4) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B9AB5100@standards.nortelnetworks.com>; 4 Jun 2000 21:49:14 -0400 Received: from ns ([210.112.7.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id KAA21842; Mon, 5 Jun 2000 10:56:50 +0900 References: <200006021642.e52GgNI481184@jurassic.eng.sun.com> 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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <001501bfce91$71fc4080$d012060a@hansol.co.kr> Date: Mon, 5 Jun 2000 10:57:15 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: Re: [MOBILE-IP] RFC2344bis Reverse Tunneling X-To: Samita Chakrabarti To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, In order to support communications between Mobile node( who has a private home address and is located at a private IP network) and a correspondent host (who has a public ip address and is located in a public ip network), how's designing of HA-NAT combination topology ? With this, HA MAY discern home ip address and private ip address. Hope to listen to your comments Regards, Jiwoong Lee From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 5 18:41:48 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12074 for ; Mon, 5 Jun 2000 18:41:47 -0400 (EDT) Received: from standards (47.234.32.16:2732) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73333@standards.nortelnetworks.com>; Mon, 5 Jun 2000 18:32:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0260 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Jun 2000 18:32:55 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73332@standards.nortelnetworks.com>; Mon, 5 Jun 2000 18:32:54 -0400 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA00741 for ; Mon, 5 Jun 2000 16:41:13 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA26232; Mon, 5 Jun 2000 15:41:12 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA15838; Mon, 5 Jun 2000 15:41:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 5 Jun 2000 15:40:48 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: [MOBILE-IP] Fast Hand-off Internet Draft X-cc: james.kempf@eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <001501bfce91$71fc4080$d012060a@hansol.co.kr> For all of you that care about fast hand-off, our latest Internet Draft was sent to the secretariat and will be shortly available. The name of the draft is draft-calhoun-mobileip-proactive-fa-01.txt, and this version is drastically different from the previous (-00) version. We believe that this contribution contains the required extensions necessary for Mobile IP to provide fast hand-off. Note that this draft does rely on portions of the Route Optimization and the Regional Registration drafts, in addition to RFC 2002. This draft *could* be adapted to IPv6 in the event that the Mobile Attendant (as proposed in Charlie's draft) is present. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 5 21:56:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14374 for ; Mon, 5 Jun 2000 21:56:43 -0400 (EDT) Received: from standards (47.234.32.16:2711) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7341E@standards.nortelnetworks.com>; Mon, 5 Jun 2000 21:47:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0515 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 5 Jun 2000 21:47:55 -0400 Received: from ns.ict.ac.cn (159.226.39.1:4488) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB733F8@standards.nortelnetworks.com>; Mon, 5 Jun 2000 21:37:50 -0400 Received: (qmail 22860 invoked from network); 6 Jun 2000 01:42:07 -0000 Received: from unknown (HELO JunT) (159.226.39.72) by ns.ict.ac.cn with SMTP; 6 Jun 2000 01:42:07 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009E_01BFCF9B.7F362A80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Message-ID: <00a101bfcf58$71a9fa60$4827e29f@ict.ac.cn> Date: Tue, 6 Jun 2000 09:42:15 +0800 Reply-To: Junt Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Junt Subject: [MOBILE-IP] SUBSCRIBE MOBILE-IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_009E_01BFCF9B.7F362A80 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U1VCU0NSSUJFIE1PQklMRS1JUA0K ------=_NextPart_000_009E_01BFCF9B.7F362A80 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yMDE0LjIxMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+U1VCU0NSSUJFIE1PQklMRS1JUDwvRElWPjwvQk9E WT48L0hUTUw+DQo= ------=_NextPart_000_009E_01BFCF9B.7F362A80-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 6 11:42:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10520 for ; Tue, 6 Jun 2000 11:42:05 -0400 (EDT) Received: from standards (47.234.32.16:3778) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73825@standards.nortelnetworks.com>; Tue, 6 Jun 2000 11:32:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1810 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 11:32:40 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73807@standards.nortelnetworks.com>; Tue, 6 Jun 2000 11:22:40 -0400 Received: from 130.128.225.134.210.in-addr.arpa (apple.sigeki.co.jp [210.134.225.130] (may be forged)) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id KAA12883 for ; Tue, 6 Jun 2000 10:30:59 -0500 (CDT) Received: from q80A2U73Y by 130.128.225.134.210.in-addr.arpa (AppleShare IP Mail Server 5.0.3) id 83621 via TCP with SMTP; Wed, 07 Jun 2000 00:29:12 +0900 Message-ID: Date: Tue, 6 Jun 2000 08:24:06 AM Reply-To: 524FKQko6@PUBLIC1.BTA.NET.CN Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: 524FKQko6@PUBLIC1.BTA.NET.CN Subject: Re: [MOBILE-IP] your decision To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Look, we don't want to waste your time...or ours You must be determined to earn a bare minimum of $10,000 in the next 30 - 45 days and to develop a net worth of over 1 Million Dollars Cash in the next 24-36 months. My mission is to help other people develop their life long dreams. Part of what I'm looking for are those people who are committed to that BIG of a picture and are not afraid to work for it. We can help you: REGARDLESS OF YOUR CURRENT AGE OR YOUR DEBT LOAD! NOT MLM or FRANCHISE Don't bother to call unless you are serious. Learn the Facts CALL 1-800-879-5841 (24 hrs) $10,000 IN 30 - 45 DAYS RETIREMENT IN 3-5 YEARS *************************************************************************************** All REMOVE requests AUTOMATICALLY honored upon receipt. mailto:lori1969@altavistausa.como?subject=Remove PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received. **************************************************************************************** From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 6 14:28:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16380 for ; Tue, 6 Jun 2000 14:28:59 -0400 (EDT) Received: from standards (47.234.32.16:3912) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73933@standards.nortelnetworks.com>; Tue, 6 Jun 2000 14:19:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2188 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 14:19:54 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73926@standards.nortelnetworks.com>; Tue, 6 Jun 2000 14:09:54 -0400 Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id NAA13937 for ; Tue, 6 Jun 2000 13:18:16 -0500 (CDT) Received: from apache.utdallas.edu (apache.utdallas.edu [129.110.16.9]) by ns0.utdallas.edu (Postfix) with ESMTP id 48D171A02B4; Tue, 6 Jun 2000 13:16:44 -0500 (CDT) Received: (from jcobb@localhost) by apache.utdallas.edu (8.9.1/8.9.1) id NAA00913; Tue, 6 Jun 2000 13:17:33 -0500 (CDT) Message-ID: <200006061817.NAA00913@apache.utdallas.edu> Date: Tue, 6 Jun 2000 13:17:33 -0500 Reply-To: jcobb@UTDALLAS.EDU Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: jcobb@UTDALLAS.EDU Subject: [MOBILE-IP] CFP ISADS 2001, August 15 Deadline X-To: mobile-ip@SMALLWORKS.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ** my apologies if you receive multiple copies *** ** feel free to forward this CFP to your colleagues *** ISADS 2001 CALL FOR PAPERS The Fifth International Symposium on Autonomous Decentralized Systems Monday March 26 - Wednesday March 28, 2001 Dallas, Texas, USA Sponsored by: IEEE Computer Society Information Processing Society of Japan The Society of Instrument and Control Engineers of Japan The Institute of Electronics, Infor. and Communication Engineers, Japan In Cooperation with: International Federation for Information Processing International Federation of Automatic Control OMG TINA-C Manufacturing Science and Technology Center, Japan Scope: Driven by the continuous growth in the power, intelligence and openness of computer, communication and control technologies, possibilities and opportunities for realizing highly efficient and dependable business and control systems have been steadily increasing. Dynamically changing social and economic situations demand next-generation systems based on emerging technologies and applications. Such systems are expected to have the characteristics of living systems composed of largely autonomous and decentralized components. Such systems are called Autonomous Decentralized Systems (ADS). After the successful first, second, third, and fourth International Symposium on Autonomous Decentralized Systems (ISADS) held in 1993 in Japan, in 1995 in the USA , in 1997 in Germany, and in 1999 in Japan, the fifth ISADS will be held in Dallas, Texas, USA during March 26-28, 2001. While ISADS 2001 will primarily focus on advancements and innovation in ADS concept, technologies, and applications related to the increasingly important topic of *Electronic Commerce*, other themes such as telecommunications and heterogeneous system and application integration will also be included. The ISADS 2001 committee invites papers and panel proposals on the topics of the symposium that will foster interactions among researchers and practitioners in computer, communication, management, control as applied to electronic commerce and other related fields from academia, industry, and government. The scope of discussions on ADS shall include, but not be limited to: * Computer and communication architectures / intelligent network /Internet; * Heterogeneous distributed information / control systems; * Mobile agent /computer-supported cooperative works; * Distributed software development and maintenance; * Assurance, fault tolerance and on-line expansion; * Object management architecture /design pattern / application frameworks; * Emergent control and robotic systems; * Novel applications: electronic commerce, telecommunications, information service systems, manufacturing systems, real-time event management, office automation, traffic and transportation control, logistics systems. Plant tour is scheduled on March 29, 2001. Delegates are encour- aged to participate. Information for Authors Papers should describe original work (not submitted or published elsewhere) and be 20 double-spaced pages (5,000 words) or less in length. Papers should include: title, authors, affiliations, 150-word abstract and list of keywords. Identify the author responsible for correspondence, including the author's name, position, mailing address, telephone and fax numbers, and email address. One of the authors of each accepted paper must present the paper at ISADS 2001. Information for Panel Organizers Panel proposals should include: title, organizer's affiliations, position, mailing address, telephone and fax numbers, email address, and 150-word statement on the scope, proposed chair and panelists. Submission Address Authors and panel organizers are requested to submit their manuscripts electrically in the Microsoft WORD document file format, the PDF format, or the Postscript format, and also email the abstract and the full addresses of the author(s) to the following address: thura@mitre.org Note The program committee of ISADS2001 highly encourage electronic submissions. Otherwise, papers should be sent to the program chair: Dr. Bhavani Thuraisingham Mail Stop A270 The MITRE Corporation 202 Burlington Road Bedford, MA 01730 Phone: 781-271-8873 Fax: 781-271-8752 Email: thura@mitre.org General Information For general information, see our World-Wide Web Page at: http://isads.utdallas.edu The proceedings of the symposium will be published by IEEE Computer Society Press. Important Deadlines August 15, 2000: All papers and panel proposals are due November 15, 2000: Authors and panel organizers notified of acceptance. December 15, 2000: Camera-ready copies of accepted papers and panelists' position papers General Chair William Osborne, U. of Texas, Dallas, USA Program Committee Chair: Bhavani Thuraisingham, The MITRE Corp., USA Co-Chair: Makoto Imase, NTT Labs, Japan Co-Chair: Linda Strick, GMD Fokus, Berlin, Germany Co-Chair: Jeffrey Tsai, U. of Illinois, Chicago, USA Members G. Agha, U. of IL, Urbana, USA R. Arai, U. of Tokyo, Japan D. Bae, KAIST, Korea F. Bastani, U. of TX, Dallas, USA E. Bertino, U. of Milano, Italy M. Ceruti, SPAWAR, USA I. Chen, Virginia, Tech, USA Y. Chen, U. of the Witwatersrand, South Africa R. Chow, U. of FL, USA J. Chung, IBM T.J. Watson Research Center, USA P. Chuang, Tamkang U., Taiwan P. Ciancarini, U. of Bologna. B. Cukic, West Virginia U., USA K. Eckert, GMD FOKUS Germany S. Eisenbach, Imperial College, UK D. Ferrari, U. of Catoloca, Italy M. Fisher, Manchester Metropolitan U., UK M. Fujita, Sony, Japan A. Fukuda, Nara Inst. of Science and Technology, Japan V. Garg, Univ. of TX, Austin, USA S. Ghosh, Arizona State U., USA A. Ghafoor, Purdue U., USA A. Ghose, U. of Wollongong, Australia M. Gien, Sun, France V. Gobel, U. of Oslo, Norway T. Higashino Osaka U., Japan D. Hislop, ARO, USA I. Iida, Fujitsu, Japan Y. Ishiguro, NEC, Japan K. Ito, TITECH, Japan Y. Kakuda, Hiroshima City U., Japan K. Kim, U.C. Irvine, USA H. Kopetz, TU Wien, Austria J. Kramer, Imperial College, UK L. LeLann, INRIA, France C. Liu, Chung Yuan Christian U., Taiwan M. Lyu, The Chinese U. of Hong Kong, Hong Kong Y. Masunaga, Ochanomizu U., Japan W. Meng , State U. of New York at Binghamton, USA R. Montenari, U. of Bologna, Italy W. Ng, Nanyang Technological U., Singapore A. Prakash, U. of Michigan, USA J. Putman, MITRE, USA Q. Qingquan, Southwest Jiatong U., China N. Raynal, INRIA, France W. Ruh, Concept-V, USA D. Serpanos, Inst. of Comuter Science, Technology-Hellas, Greece S. Shekhar, U. of MN, Mpls, USA L. Simoncini, CNUCE-CNR, Italy R. Stroud, U. of New Castle, UK V. Subrahmanian, U. of MD, College Park, USA K. Tsuchiya, Kyoto Uv, Japan B. Wah, U. of IL, Urbana, USA Y. Wakahara, U. of Tokyo, Japan F. Wang, National Chao Tung U., Taiwan M. Wooldridge, U. of Liverpool, UK H. Yokota, TITECH, Japan M. Yano, Tohoku U., Japan S. Yongqiang, Shanghai Jiao Tong U, China P. Yu, IBM T.J. Watson Research Center S. Zubairy, Quaid-e-Azam U., Pakistan Steering Committee Chair: Stephen S. Yau, Arizona State U., USA Hiroshi Kuwahara, Hitachi, Japan Kinji Mori, Tokyo Inst. of Technology, Japan Radu Popescu-Zeletin, GMD, Germany Publicity Chair Jorge Cobb, U. of Texas, Dallas, USA From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 6 20:27:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21112 for ; Tue, 6 Jun 2000 20:27:35 -0400 (EDT) Received: from standards (47.234.32.16:2803) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73A41@standards.nortelnetworks.com>; Tue, 6 Jun 2000 20:18:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2548 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 6 Jun 2000 20:18:39 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73A40@standards.nortelnetworks.com>; Tue, 6 Jun 2000 20:18:39 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA20540; Tue, 6 Jun 2000 17:26:56 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id RAA29376; Tue, 6 Jun 2000 17:26:57 -0700 (PDT) Received: (from samita@localhost) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) id e570Qtp299077; Tue, 6 Jun 2000 17:26:55 -0700 (PDT) X-Sun-Charset: US-ASCII Message-ID: <200006070026.e570Qtp299077@jurassic.eng.sun.com> Date: Tue, 6 Jun 2000 17:26:55 -0700 Reply-To: Samita Chakrabarti Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Samita Chakrabarti Subject: Re: [MOBILE-IP] RFC2344bis Reverse Tunneling X-To: porce@kaist.ac.kr To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Jiwoong : > In order to support communications between Mobile node( who has a private > home address and is located at a private IP network) and a correspondent > host (who has a public ip address and is located in a public ip network), > > how's designing of HA-NAT combination topology ? With this, HA MAY discern > home ip address and private ip address. > As I understand, HA-NAT combination topology design consideration is outside the scope of mobileip draft. It will be very tricky to specify private address support for home agent and foreign agent private networks with NATs. This could be implementation dependent. We can consider simple scenario for using mobile node with private addresses and where the COA and HAA are public addresses and the mobile node visits the foreign agent in a publicly routable network. Another case is mentioned in the rfc2344-bis, which is MN has private address and it is always one hop away from the home agent while at home or one hop away from FA while visiting. Figure A1: NON-ROUTABLE PACKETS IN DISPARATE ADDRESS SPACES Mc Fa Fb Hb Hc Yc [MN]-----------------[FA]----------------[HA]---------------[Y] Addr space A Addr space B Addr space C Figure A2: IP IN IP REVERSE TUNNELED PACKET FROM FA TO HA +-----------------+ | +-------+| | Fb->Hb | Mc->Yc|| | +-------+| +--------+--------+ -Samita From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 7 05:25:53 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08154 for ; Wed, 7 Jun 2000 05:25:53 -0400 (EDT) Received: from standards (47.234.32.16:1716) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73AF5@standards.nortelnetworks.com>; Wed, 7 Jun 2000 5:16:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2783 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 05:16:28 -0400 Received: from ms.hansol.co.kr (203.235.136.4:4953) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73AF4@standards.nortelnetworks.com>; Wed, 7 Jun 2000 5:16:27 -0400 Received: from ns ([210.112.7.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id SAA28145 for ; Wed, 7 Jun 2000 18:24:17 +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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <00cf01bfd062$478c1b40$d012060a@hansol.co.kr> Date: Wed, 7 Jun 2000 18:24:40 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: [MOBILE-IP] Comment on RFC2290: Mobile-IPv4 Option for PPP IPCP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear All, A statement in section 2.1 of RFC2290: Mobile-IPv4 Option for PPP IPCP should be updated. Section 2.1 of RFC2290: Mobile Node's Home Address ... the specification. This field MUST NOT be zero. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Since section 4 of RFC2794: Mobile IPv4 NAI Extension is saying that: 4. Interactions with Mobile-IPv4 Configuration Option to IPCP In the Mobile-IPv4 Configuration Option to IPCP [8], the Mobile Node's Home Address field may be zero. .... Regards, Jiwoong Lee PS BTW, Does mobileip WG deal with RFC2290? or who does ? There is no list of RFC2290 in mobileip wg home page in IETF. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 7 09:33:32 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10330 for ; Wed, 7 Jun 2000 09:33:31 -0400 (EDT) Received: from standards (47.234.32.16:4395) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73C59@standards.nortelnetworks.com>; Wed, 7 Jun 2000 9:24:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3237 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 09:24:19 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73C58@standards.nortelnetworks.com>; Wed, 7 Jun 2000 9:24:19 -0400 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id QAA28992; Wed, 7 Jun 2000 16:32:23 +0300 (EETDST) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id QAA00468; Wed, 7 Jun 2000 16:32:20 +0300 (EETDST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Wed, 7 Jun 2000 08:30:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="KS_C_5601-1987" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2BCD50D3@daeis07nok> Date: Wed, 7 Jun 2000 08:30:14 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] Comment on RFC2290: Mobile-IPv4 Option for PPP IP CP X-cc: porce@KAIST.AC.KR To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Comment below: >Dear All, > >A statement in section 2.1 of RFC2290: Mobile-IPv4 Option for PPP IPCP >should be updated. > > Section 2.1 of RFC2290: > Mobile Node's Home Address > ... > the specification. This field MUST NOT be zero. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >Since section 4 of RFC2794: Mobile IPv4 NAI Extension is saying that: > > 4. Interactions with Mobile-IPv4 Configuration Option to IPCP > > In the Mobile-IPv4 Configuration Option to IPCP [8], the Mobile > Node's Home Address field may be zero. > .... Abstract section of RFC2794: This memo also updates RFC2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero. -Basavaraj > > >Regards, > >Jiwoong Lee From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 7 10:17:42 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11147 for ; Wed, 7 Jun 2000 10:17:40 -0400 (EDT) Received: from standards (47.234.32.16:4395) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73CA6@standards.nortelnetworks.com>; Wed, 7 Jun 2000 10:08:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3329 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 10:08:28 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73CA1@standards.nortelnetworks.com>; Wed, 7 Jun 2000 9:58:27 -0400 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00854 for ; Wed, 7 Jun 2000 08:06:02 -0600 (MDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA11164; Wed, 7 Jun 2000 10:06:00 -0400 (EDT) Received: from atlantic.East.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by atlantic.East.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id KAA18567; Wed, 7 Jun 2000 10:06:24 -0400 (EDT) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-ID: <200006071406.KAA18567@atlantic.East.Sun.COM> Date: Wed, 7 Jun 2000 10:07:51 -0400 Reply-To: steven.glass@Sun.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] Comment on RFC2290: Mobile-IPv4 Option for PPP IPCP X-To: "Lee, Jiwoong" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Lee, Jiwoong" wrote: >Date: Wed, 7 Jun 2000 18:24:40 +0900 >Dear All, > >A statement in section 2.1 of RFC2290: Mobile-IPv4 Option for PPP IPCP >should be updated. > > Section 2.1 of RFC2290: > Mobile Node's Home Address > ... > the specification. This field MUST NOT be zero. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >Since section 4 of RFC2794: Mobile IPv4 NAI Extension is saying that: > > 4. Interactions with Mobile-IPv4 Configuration Option to IPCP > > In the Mobile-IPv4 Configuration Option to IPCP [8], the Mobile > Node's Home Address field may be zero. > .... This is why RFC2794 *updates* RFC2290. >PS BTW, Does mobileip WG deal with RFC2290? or who does ? There is no list >of RFC2290 in mobileip wg home page in IETF. We submitted it through the PPPEXT working group. Sincerely, Steven M. Glass From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 7 10:26:07 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11437 for ; Wed, 7 Jun 2000 10:26:07 -0400 (EDT) Received: from standards (47.234.32.16:4395) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73CD8@standards.nortelnetworks.com>; Wed, 7 Jun 2000 10:16:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3332 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 10:16:47 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73CA4@standards.nortelnetworks.com>; Wed, 7 Jun 2000 10:06:46 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10922; Wed, 7 Jun 2000 10:15:10 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200006071415.KAA10922@ietf.org> Date: Wed, 7 Jun 2000 10:15:10 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-11.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobile IP Challenge/Response Extensions Author(s) : C. Perkins, P. Calhoun Filename : draft-ietf-mobileip-challenge-11.txt Pages : 16 Date : 06-Jun-00 Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-11.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-challenge-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-challenge-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000606122717.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-challenge-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-challenge-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000606122717.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 7 20:11:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23037 for ; Wed, 7 Jun 2000 20:11:35 -0400 (EDT) Received: from standards (47.234.32.16:2542) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73FCB@standards.nortelnetworks.com>; Wed, 7 Jun 2000 20:02:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4412 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 20:02:03 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB73FCA@standards.nortelnetworks.com>; Wed, 7 Jun 2000 19:52:03 -0400 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA00721 for ; Wed, 7 Jun 2000 18:00:28 -0600 (MDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA17116 for ; Wed, 7 Jun 2000 20:00:27 -0400 (EDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by atlantic.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id UAA20627 for ; Wed, 7 Jun 2000 20:00:55 -0400 (EDT) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-LA_F2159613915R-2A-960422424=:578NCE.IlHAFeR" Message-ID: Date: Wed, 7 Jun 2000 20:00:24 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: [MOBILE-IP] Use of DHCP in Mobile IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ---LA_F2159613915R-2A-960422424=:578NCE.IlHAFeR Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I have (*finaly*) submitted my id to the id editor. My appologies for the added delay (amazing how bogged down in other things you sometime have to become). For your perusal, I'm attaching it below with the caveat that the editor may not accept it, and I may have to change it for resubmittal. It may be best to strip out the options, and put them in a separate document. I've also included "think:" sections where I think working group feedback would be useful. This is also going to be announced on the dhc mailing list. Cheers, Steve ---LA_F2159613915R-2A-960422424=:578NCE.IlHAFeR Content-Type: TEXT/plain; name="draft-glass-mobileip-agent-dhcp-proxy-00.txt"; charset=us-ascii Content-Description: default Internet Engineering Task Force S. Glass INTERNET DRAFT Sun Microsystems Mobile IP Working Group 7 June 2000 Mobile IP Agents as DHCP Proxies draft-glass-mobileip-agent-dhcp-proxy-00.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is a submission to the Mobile IP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract Since the inclusion of the Network Access Identifier (NAIs) into the mobile ip fabric, home agents have had a way to identify mobile nodes which do not have home IP addresses. After authenticating the registration request from such a mobile node, the home agent is then expected to assign a home addresses to the mobile node in the registration reply to be used on a semi-permanent basis. Unfortunately, no specific mechanism has yet been proposed. Ideally, as DHCP centralizes address management, a home agent should contact a DHCP server to allocate an address for the mobile node, thereby preserving DHCP as the central address maintainer. The technology does exist for a Home Agent to use DHCP controlled addresses, namely for the Home Agent to behave as a DHCP proxy agent. This document specifies the procedure for a Home Agent to follow when contacting a DHCP server to obtain home addresses for mobile nodes that require them. It does so in the spirit of the design goals of [1], and [2] (section 1.6). Moreover, it specifies the responsibilities of the home agent with regard to defending this S. Glass Expires 7 December, 2000 [page i] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 address, and maintaining it as appropriate. Obviously, support must be added to the home agent to provide for this functionality, so the most desireable case is to limit changes to just the home agent. This document enhances the behaviour of the home agent in a way so that no enhancements to the behaviour of a mobile node which is compliant with [1] and [3] is required. As a result, a clearer picture is also obtained as to what needs to be addressed when a mobile node is not assigned a home address before it roams, and the complications that can result in various mobile ip situations. As always, optimizations and enhancements can be made, in this case proposing changes to both home agent and mobile node. These changes are specified as optional extension support. The exchange of extensions is defined in such a way that if one side understands these extensions, and the other side does not, interoperability is still acheived. 1. Introduction Mobile IP was designed to give nodes the ability to leave the confines of their home subnet, allowing them to not only initiate new connections from their roamed location, but to keep their current connections active while receiving new connection requests through an agent on their home subnet, known as the home agent. Recent enhancements to mobile ip have even allowed nodes which do not yet have an IP address to connect to their home subnets, and receive an address through their home agent. No mechanism describing how the home agent is to obtain such addresses has been officially proposed, however, which may default home agents into have their own address-pools from which they can hand out addresses. The ideal method would be to have the mobile node receive an address from the same address pool as it would if it were at home, most likely the DHCP address pool on it's home network. Obtaining an address directly would be difficult since any concept of a home network to DHCP is the network on which the node is currenly residing. Special enhancements to DHCP would have to be devised to get the DHCP messages to, and from the home subnet, and it is likely such enhancements would immitate functionality already designed for mobile ip. The mechanism used to get a mobile node's request for a home address already exists in the NAI extension of the mobile ip registration process [3]. When the home agent receives a registration request containing a zero home ip address, and an NAI extension, it uses the NAI to associate the shared secret between the mobile node and itself, and uses the MN-HA authenticator to identify the registration as comming from the mobile node (if a MN-AAA authenticator appears instead, authentication is done using that at the AAA server). The HA then finds an address to assign to the mobile node. The home agent, by definition, has an interface on the mobile node's home link. Using this interface and the mobile node's NAI, it can generate the necessary DHCP messages as a DHCP proxy in an attempt to obtain an address which it can assign to the mobile node. S. Glass Expires 7 December, 2000 [page 1] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 2. Overview A mobile node which is away from home without a home address follows the proceedures detailed in [3], specifically sending a registration request containing a zero home address to it's home agent, includes an NAI extention, and appends a MN-HA identifier as detailed in [1] to authenticate itself to the home agent (or a MN-AAA authenticator to identify itself to the home AAA server if that method of authentication is used). Upon receiving such a registration, the home agent must get an address to pass back to the mobile node in the home address field of the registration reply. The home agent can now play a role similar to that of a DHCP proxy agent generating DHCP messages as described in [2] on behalf of the mobile node, as detailed below, in hopes of ultmately obtaining a suitable address for use as the mobile node's home address. It is important to understand the exact role the home agent is playing in this scenario. The home agent is not playing the roll of a DHCP relay, as it is not relaying any DHCP messages on behalf of the mobile node. From one perspective it is behaving as a DHCP proxy, generating DHCP mssages on behalf of a mobile node. In another perspective, it is simply obtaining an address it will be using on one of its own interfaces, namely an interface attached to the mobile node's home link. In this regard, the home agent is purely DHCP client. Should the mobile node return home, it will likely want to assume ownership of this IP address, so in this light we will consider the home agent as performing the job of a DHCP proxy, and will refer to it as such for consistency. 2.1 Mobile IPv4 with DHCP, and Mobile IPv6 with DHCPv6 As the relationship of the mobile node and the home agent doesn't change in regard to the home agent obtaining an address for a mobile node in mobile IPv6, it would be nice if it were possible to use the same mechanism in mobile IPv6 for a node to obtain a DHCPv6 address in the analogous way. In this case, mobile ip registration requests should be sent as in [10] with the NAI extension appearing after the registration request, and before the MN-HA or MN-AAA authenticator as described in [3]. The home agent would then generate DHCP messages as described in [11], obtaining an IPv6 address for use as the mobile node's home address. This document attempts to treat the IPv4 and IPv6 cases together, providing a mechanism to be used in either situation. As the majority of documents referenced here are works in progress, however, this document may need to be updated upon their completion. 3. Operation of a Home Agent as a DHCP Proxy Agent This section describes the proceedure a home agent should follow upon receiving an authenticated registration request from a mobile node requiring a home address in order to behave as a DHCP proxy agent, and the responsibilities imposed on the home agent as a result. S. Glass Expires 7 December, 2000 [page 2] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 3.1 The Initial Registration Request 1. The HA receives an authenticated registration request as defined in [1] for a mobile node which it is willing to service, and for which it does not have a current binding, and for which a home address needs to be assigned. This appears in the form of a mobile ip registration request containing a zero mobile node home address, an NAI extension, and MN-HA authenticator as described in [3] (or MN-AAA authenticator if that security model is in use). If the regisration request is unacceptable, the appropriate error code as defined in [1] or [3] MUST be returned to the mobile node's care-of address. 2. If the registration request has been authenticated as coming from the mobile node identified by the NAI contained in the registration request, the Home Agent builds a DHCPDISCOVER as defined in [2] exactly as it would to obtain a[nother] IP address for one of its links defined as being on the mobile node's home link (htype, hlen, chaddr, etc), with the following difference. The client identifier option (type 61) as defined in [4] MUST be included, wherein the type field MUST be set to 0, and the identifier MUST be set to the NAI as sent by the mobile node in the NAI extension. As the Client ID option (type 51) allows for up to one octet for length, a client id of up to 255 characters allows more than enough space for the up-to 128 character NAI [5]. Furthermore, an IP Address Lease Time option (type 51) SHOULD be included. The lifetime requested in the IP Address Lease Time option of the DHCP request SHOULD be the shorter value of the of either the lifetime appearing in the registration request, or the lifetime the home agent is willing to grant in a registration reply to this mobile node [1]. In addition, sname, giaddr, and yiaddr MUST be NULL, and hops is set to 0. The home agent MAY also include the DHCP Mobile IP Home Agent option [4]. If the home agent includes this extension, it MUST set the home agent address to the address apearing in the home agent field of the registration request, or the address belonging to the home agent on the link that will be servicing the mobile node. Note: this DHCP message may go through a DHCP relay agent. The home agent behaves no differently than as described above. 3. The home agent waits a configured amount of time for a DHCPOFFER from the DHCP server. It is recommended that the Home Agent wait no less than DHCPDISCOVER_TIMEOUT seconds for such a reply [2]. If no reply is received within that time period, and the home agent has no other pool from which it can assign addresses to the mobile node, it MUST return error 99 "Missing Home Address" as described in [3]. If the DHCPOFFER is received, it is processed, specifically for an acceptable home IP address, and lifetime. If the data in any field of the DHCPOFFER, specifically these two, are unacceptable, the home agent SHOULD attempt to negotiate these with the DHCP server. S. Glass Expires 7 December, 2000 [page 3] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 If the DHCPOFFER includes the Mobile IP Home Agent option (type 68), the home agent SHOULD compare the address contained in this option with its own, specifically the address identified as the home agent address in the registration request, or the address on the link that will be servicing the mobile node. If the address is NOT the same as the address being identified as the home agent address, the home agent MUST generate a registration reply with error 136 "Unknown Home Agent Address". As with home agent discovery [1], this should prompt the mobile node to choose a different home agent with which to register. (Think: the home agent SHOULD also put the address of the home agent returned in the Home Agent Option in the home agent field of the registration reply). (Think: Furthermore, this home agent SHOULD not reply to further home agent discovery packets from this mobile node for the duration of the lifetime appearing in the registration request). Upon receiving an acceptable DHCPOFFER, the home agent MUST transmit a DHCPREQUEST for the IP address being offered to the unicast address of the DHCP server as described by [2], and awaits a configured amount of time for a DHCPACK. It is recommended that the home agent wait at least DHCPREQUEST_TIMEOUT seconds for the DHCPACK from the DHCP server. If no reply is received to the DHCPREQUEST, the home agent MUST generate another DHCPREQUEST for an address apearing in another DHCPOFFER from a DHCP Server, or MAY transmit another DHCPDISCOVER as in (1) above, or, if no other address assignment mechanism is available, the home agent MUST send a registration response to the mobile node with error 99 "Missing Home Address" as described in [3]. 4. Upon recieving a DHCPACK with a suitable IP address and lifetime for the mobile node, the home agent MUST query the network for the address, as in the usual duplicate IP address detection mechanisms as is described in [2]. If the address is in use, the home agent SHOULD transmit another DHCPREQUEST for an address appearing in another DHCPOFFER from a DHCP Server, or transmit another DHCPDISCOVER message. If a DHCPNAK is received instead, the home agent MUST do one of the following: either renegotiate with the DHCP server, send out another DHCPREQUEST for an address appearing in another DHCPOFFER from a DHCP Server, send out another DHCPDISCOVER as described in (1) above, or if no other address assignment mechanism is available, send a registration response to the mobile node with error 99 "Missing Home Address" [3]. Think: what about the other possible responses to the DHCPREQUEST? 5. If the address in the DHCPACK is deemed suitable for use as an IP address for this interface, and as a home ip address for the mobile node, the home agent puts this address into the home address field of the registration reply. The home agent MUST also fill in the lifetime of the registration reply with the shortest value of either the lifetime appearing in the registration request, the lifetime normally granted by the home agent, or the lifetime granted by the DHCP server. S. Glass Expires 7 December, 2000 [page 4] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 The home agent MUST also include the NAI option as per [3], and append the usual HA-MN authenticator as described in [1], or the HA-AAA authenticator if that security mechanism is in use. The home agent MUST also claim, and defend the address as described in [3]. If no suitable address can be obtained from a DHCP agent, and no other method of obtaining an address is available, the home agent MUST send a registration reply to the mobile node with error 99 "Missing Home Address" [3]. 3.2 Re-registration Requests This sections details the behaviour of a home agent upon receiving a registration request from a mobile node for which it already has a binding. 1. The mobile node sends a registration request to a home agent with which it already has a binding. It MUST include either the IP Address assigned to it by the home agent, or the 0 address in the home address field of the registration request, and it MUST include the NAI that it originally used to obtain the binding and address. 2. The home agent receives an authenticated registration request, it MUST check to see if already has a binding, and is providing home agent services for this mobile node. This determination can be based on NAI, or (non-zero) home address. Before sending a registration reply to the mobile node's care-of address, the home agent MUST use the NAI, or (non-zero) home address to check to see if this mobile node was assigned a DHCP administered home address, and, if the home address appearing in the current registration request is non-zero, make sure the mobile node is using the same home address it was assigned in the previous registration using the NAI. If the registration request contains the zero address, the home agent MUST associate the address which was assigned to the mobile node's NAI by DHCP. 3. If the address the mobile node is using was assigned by DHCP, the home agent builds a DHCPREQUEST message exactly as it would for any DHCP address it were renewing as in [2] with the same exceptions as described in section 3.1 above. The message is unicast to the DHCP server that assigned the mobile node's current home address, the IP address being renewed (appearing in the yiaddr and ciaddr fields) MUST be set to the mobile node's home address, and the Client ID option (type 51) MUST be included with the type field set to 0, and the client-id set to the mobile node's NAI appearing in the registration request. The home agent SHOULD include the IP Address Lease Time option, where the lifetime is the shorter of either the lifetime appearing in the registration request, or the lifetime the home agent is willing to grant is placed in the IP Address Lease Time option. The home agent MAY also include the Mobile IP Home Agent option (type 68) with the address set to the home agent address appearing in the registration request, or the address of the home agent on the interface that will be servicing the mobile node. S. Glass Expires 7 December, 2000 [page 5] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 4. The home agent waits a configured amount of time for the DHCPACK. It is recommended that the home agent wait at least DHCPREQUEST_TIMEOUT seconds for the reply from the DHCP server. If a DHCPACK is received within this time, the home agent checks the IP address, and lifetime. If they are acceptable, meaing the IP address is identical to what the mobile node is using as appears in the home address field of the registration request, the home agent generates a registration reply to be sent to the care-of address appearing in the registrtion request, includes the IP address returned by the DHCP server, and the shorter lifetime of either that appearing in the reregistration request, what it is configured to approve, or that of the address lease granted by the DHCP server and appearing in the DHCPACK. Note: due to the nature of mobile ip, an IP address returned by the DHCP server that is different from that which is already granted is not acceptable. Should it be impossible, for some unknown reason, for the home agent to get the address currently being used by the mobile node as its home address, the home agent MUST reply with error 99, "Missing Home Address". 3.3 De-registration Requests Upon returning home the mobile node will deregister with the home agent as described in [1]. The moblile node generates a registration request with a lifetime of 0, and MUST use either the address assigned to it most recent registration reply from this home agent, or the 0 address and the NAI it used in its most recent registration request. The home agent MUST authenticate the [de]registration request, and if a non-zero address appears as the mobile node's home address MAY verify the mobile node is using the address it was assigned. If not, the home agent MAY return error 99, "Missing Home Address". Otherwise, the home agent behaves as descrbed in [1] pertaining to deregistering mobile nodes. The home agent MUST NOT transmit a DHCP release message for the mobile node's home address; the mobile node may still need it. Once the mobile node has been successfully deregistered, the responsibility for renewing, and defending this address belongs to it. It SHOULD immediately send out a DHCPDISCOVER message as described by [2] even though it knows the lease is otherwise good for the unused balance of the previous registration. The mobile node MUST include the Client ID option (type 51) with the type set to 0, and the client-id set to the NAI which was originally used to obtain the lease via the home agent, and MAY include a requested IP Address option (code 50) with the address set to the home address it is using. The mobile node MAY also include the IP Address Lease Time option (code 51), and any other option it wishes, including the Mobile IP Home Agent option for future reference. S. Glass Expires 7 December, 2000 [page 6] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 In response to this DHCPDISCOVER message, the mobile node should receive one or more DHCPOFFER messages. The mobile node SHOULD parse these messages looking for the address it is using as its home address, then identify and remember the DHCP server assigning this address. At this time the mobile node generates a DHCPREQUEST for the address received in the DHCPOFFER, and awaits the DHCPACK from the DHCP server. The mobile node SHOULD also cache the DHCPACK received from the DHCP server for future reference [2]. Note: A DHCPDISCOVER message is generated, and NOT a DHCPREQUEST for two reasons. Firstly, the mobile node is not likely to know the unicast address of the DHCP server assigning its home address. Secondly, some parameters in the DHCPDISCOVER may be different such as htype, chaddr, and hlen (e.g. bridged networks of different hardware-level topology). These MUST now be set to those that are appropriate for the mobile nodes home interface. ------------ Think: for minimal mobile node implementations ------------- If the mobile node wishes the home agent to continue to renew its address lease, it MUST deregister using the DHCP aquired address as its home address, and 0 as the care-of address, setting the lifetime to 0. As this is not a legal deregistration request as described by [1], the home agent can assume the mobile node is aware of it's DHCP aquired address, and is asking the home agent to continue renewing its address lease. If a home agent receives such a deregistration request, it MUST check that the mobile node issuing the deregistration request did indeed obtain its home address through DHCP, matching the address with the NAI. The home agent, upon approving the deregistration, renews the mobile node's home address with the DHCP server using the NAI in the Client ID option, and MAY include the IP Address Lease Time option (code 51). If the renewal is not successful, the home agent MUST send a registration reply to the mobile node with error 99, "Missing Home Address". Alternatively, if the home agent does not support lease maintenence while the mobile node is deregistered, it MUST return error XX, "DHCP lease maintenance not allowed." In this scenario, if the mobile node wishes to continue to use the address assigned to it, it MUST send out DHCPDISCOVER message as described above, and attempt to renew the lease immediately upon successfully deregistering. If the renewal is successful, the home agent sends a successful registration reply to the mobile node, setting the lifetime to the value it wishes the mobile node to contact it in precisely the same way as described here so the home agent can renew the DHCP lease for the mobile node. Note: the lifetime included in the registration reply MAY be the lifetime returned by the DHCP Server, or it MAY be some other value. The mobile node should use the same registration renewal algorithm it uses to renew its mobile ip binding while away from home. The mobile node MUST also claim the address on the link, and defend it as it would any other address it is using. ------------- Fin: for minimal mobile node implementations ------------- S. Glass Expires 7 December, 2000 [page 7] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 3.4 Address Responsibilities The home agent, in negotiating for a home address for the mobile node, has been given an (additional) IP address for one of its interfaces. It is also acting on behalf of the mobile node that it is providing home agent services for. As a result, the home agent MUST defend this address as it would any other home address registered by a mobile node [1]. Furthermore, the home agent MUST remember this address, that the address was obtained through DHCP, the address of the DHCP server that granted it, and the mobile node's NAI. The home agent MAY cache the DHCPACK for future reference. The mobile node uses this address as it would any address assigned to it (by the home agent) including the exceptions described by [1] in relation to what it MUST and MUST NOT do while on the foriegn subnet. When using this address on its home subnet, it MUST defend this address itself as it would any address it is using. 4.0 New DHCP-Specific Mobile IP Options For optimizations, and enhancements, this document defines the following OPTIONAL extensions. In each case, what is required for the home agent and mobile node to support is detailed. The extensions for the mobile node to use are in the range 128-255, which as specified by [1] are ignored (by the home agent) upon receipt if not understood. In this way, a home agent which does not understand these extensions will ignore them, the registration request will NOT be silently discarded, and the mobile node's registration will be processed. Conversely, the home agent reply extentions are in the range 0-127. In this way, if a mobile node receives a registration reply which contains an extension giving it some special information which it does NOT understand it will silently discard the entire registration reply, and attempt to reregister (with a different home agent). A home agent MUST NOT insert any DHCP-related mobile IP extensions in a registration reply to a mobile node from which it did not receive a DHCP-related mobile IP extension. As these are optional extensions, and support is not required to be compliant with this specification, the appropriate assumptions which can be made by either side is specified depending on the level of support provided by each end. In addition, allowable responses by home agents and mobile nodes when using these extensions is detailed in the appropriate sections. All DHCP options conform to the requirements laid out in [7]. S. Glass Expires 7 December, 2000 [page 8] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 4.1 Mobile IP DHCP Address Extension A mobile node wishing to obtain a DHCP address lease SHOULD include the following extension in its registration request. This extension MUST appear before the MN-HA or MN-AAA authenticator, and SHOULD appear after the NAI extension. The "Mobile IP DHCP Address" extension is defined 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 0 9 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type | Length |A|L|S| reserved ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 200(TBA) "Mobile IP DHCP Address" extension Length The number of bytes of the whole extension (MUST be word aligned). Currently 4 (may be extended) A 0 or 1 Set to 1 if the mobile node wishes to get the address of the DHCP Server. L 0 or 1 Set to 1 if the mobile node wishes to get the DHCP lease lifetime of the address. S 0 or 1 Set to 1 if the mobile node wishes to get the subnet mask of its home link. Note: it is not necessary for any of the bits to be set. The presence of the "Mobile IP DHCP Address" extension is sufficient to imply the mobile node wishes to be assiged a DHCP administered address. If the mobile node doesn't care to be informed of any of this information, it MAY opt to leave each of the A, L, and S bits unset. If a home agent receives a registration request containing a Mobile IP DHCP Address Request extension, it SHOULD first attempt to obtain an address through DHCP. If it is able to obtain the address through DHCP, it MUST include this extension in the reply before the HA-MN or HA-AAA authenticator, and after the NAI extension. The home agent SHOULD also set the bits corresponding to the information it is returning to the mobile node. If the home agent is unable to obtain an address through DHCP, it MAY try another mechanism to obtain an address, in which case it MUST NOT include the "Mobile IP DHCP Address" extension in the registration reply. If the home agent can not obtain a home address for the mobile node through any means available to it, the home agent MUST return error 99 "Missing Home Address". Mobile nodes which include this extension in their registration requests SHOULD NOT expect notification from the home agent that the address they are getting is DHCP administered. The mobile node MUST assume in the absense of DHCP related extensions that any home address it receives in the registration reply is maintained by the home agent. If a mobile node includes this extension with the A bit set to 1, it MUST be prepared to perform its own lease maintenance (see section 4.2) as a home agent returning this extension, and a Mobile IP DHCP Server IP Address extension (defined below) will not be maintaining a DHCP lease for the mobile node. S. Glass Expires 7 December, 2000 [page 9] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 4.2 Mobile Node's Maintaining Their Own DHCP Leases It would be useful for a mobile node to manage it's own DHCP administered address from the foreign domain. This can only happen in situations where a reverse tunnel exists, either through a foreign agent, or with a colocated care-of address. Lease renewal requires DHCPREQUEST messages be unicast to the DHCP server, and therefore requires knowledge of the DHCP Server IP addrss. In this way a mobile node can have DHCP messages delivered to (and from) the home domain, and can immediately continue to maintain its DHCP lease, possibly without the need to broadcase a DHCPDISCOVER message, upon returning to the home link. 4.2.1 Mobile IP DHCP Server IP Address Extension In order to maintain their own leases, the mobile node must minimally know the IP address of the DHCP server. The "Mobile IP DHCP Server Address" extension is defined 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type | IP version no.| DHCP Server IP Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 54(TBA) "DHCP Server IP Address" extension IP version number 4 or 6 The IP version of the address DHCP Server IP Address The IP address of the DHCP server If the DHCP server address is an IPv4 address, the IP version number MUST be set to 4, and there MUST be 4 octets of address in the DHCP Server IP Address portion of the extension. If the DHCP server address is an IPv6 address, the IP version number MUST be set to 6, and there MUST be 16 octets of address in the DHCP Server IP Address portion of the extension. In either case, the extension is word-aligned. Note: This mechanism makes it possible for a mobile node to obtain an IPv6 address via DHCPv6 from its home link by using a mobile IPv4 registration request. It may then use the usual mobile IPv6 mechanisms to inform correspondent nodes of its location, etc. [10] S. Glass Expires 7 December, 2000 [page 10] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 4.2.2 Mobile IP DHCP Lease Lifetime Extension Knowing the lifetime granted by the DHCP server may also be useful for mobile nodes maintaining their own leases who do not wish to renew on every mobile ip reregistration. If a mobile node were to have to do this, it may opt instead to have the home agent renew its DHCP lease. It also allows mobile nodes to determine if immediate lease renewal is necessary upon returning to their home network. The "Mobile IP DHCP Lease Lifetime" extension is defined 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Lifetime ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (lifetime continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 51(TBA) "Mobile IP DHCP Lease Lifetime" extension Length 4 (Same as IP address lease time option (51)[4]) Lifetime The lifetime of the lease for the address appearing in the home address field of this registration reply. This value MUST be copied from the DHCPACK message as sent by the DHCP Server. If the mobile node is renewing its own DHCP leases, it MAY renew the lease any time it wishes. If it has no knowledge of it DHCP lease lifetime, the mobile node SHOULD attempt renew its DHCP lease immediately prior to renewing its mobile ip registaration. S. Glass Expires 7 December, 2000 [page 11] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 4.3 Mobile IP Home Subnet Prefix Length Extension A home subnet prefix is useful to the mobile node to do move detection to the home subnet. Without it, the mobile node must hear becons specifically from its home agent to know that it is home. Though requestable by the mobile node itself (through DHCPINFORM, see below), a home subnet mask extension is useful enough that it is defined here so the information can be delivered to the mobile node in the initial registration reply. The "Mobile IP Home Subnet Prefix Length" extension is defined as follows: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1(TBA) "Mobile IP Home Subnet Prefix Length" extension Prefix The number of bits of prefix as indicated by either the subnet mask option in the DHCPACK (converted to "bits of subnet"), or the prefix- len returned for an IPv6 link, and which MUST be applicable to the home address returned in the mobile ip registration reply. Note: the DHCP server will return the prefix of the address being leased in dotted-decimal notation for IPv4 addresses. The home agent MUST convert this into the above format by counting the number of leading bits in the subnet mask option of the DHCPACK. This "dualism" of dotted-decimal mask and prefix-length already exists in mobile IP as "Prefix Length" extensions in mobility agent becons and will not cause confusion if treated in the analogous fashion. If for some reason the DHCP server returns a subnet mask which, in its dotted-decimal format is not convertable to the above format, the "Mobile IP Home Subnet Prefix Length" extension MUST NOT be included in registration replies returned to the mobile node. 4.4 Requesting Other DHCP Information by use of DHCPINFORM Once the mobile node has the IP address of its DHCP Server, the mobile node MAY build a DHCPINFORM message, and unicast it to its DHCP Server as defined in [2]. Such a message can request any information listed in [2], or [4]. If, for example, the home agent did not include a "Mobile IP Home Link Prefix Length" extension, the mobile node may itself request to be informed of the prefix lengh (subnet mask) associated with its address. It is not known how DHCP Servers will respond to a DHCPINFORM message from a node looking for the lifetime of it's lease. It is advised that a mobile node that does not receive a Mobile IP DHCP Lease Lifetime extension renew their leases upon each successful mobile IP registration renewal. S. Glass Expires 7 December, 2000 [page 12] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 4.5 Using Home Agents that don't Support Mobile IP DHCP Extensions It is recommended that if a mobile node does not recieve any DHCP extensions from the home agent, particularly in response to a registration request containing a "Mobile IP DHCP Address" extension, assume its address was obtained in some generic way by the home agent, and is maintained by the home agent (either through DHCP, or some other means). The method described below is not recommended as it is not known how all DHCP server implementations will react to DHCPDISCOVER messages coming from a non-zero IP source address. Moreover, it means the home agent is unaware that the mobile node is maintaining its own lease for this address, and may already be maintaining the lease on the mobile node's behalf. In general this shouldn't be a problem, but it means more work for mobile node, home agent, DHCP server, and more bandwidth utilization on the home link, and all links comprising the forward and reverse tunnels. If a mobile node is registered with a home agent which does not support these extensions, it MAY transmit a DHCPDISCOVER message containing the NAI it used to register with the home agent in the client ID option (see section 3 above) back to its home link using the mechanisms to reverse tunnel broadcast datagrams as described by [6]. This means the DHCP assigned address will be the source address of the DHCPDISCOVER message eminating from the home agent, and NOT the usual 0 address. In response, the mobile node may then receive multiple DHPCOFFERS, from which it chooses the server offering the lease to the address it is now using as the destination of subsequent DHCPREQUESTs used in lease maintenence. If no such DHCP Server can be identified, the mobile node MUST assume the address will be maintained by the home agent. 5.0 Other Considerations This section covers considerations relating to the interaction of mobile ip, and DHCP. 5.1 Additional Error Codes As this document primarily concentrates on the use of DHCP in a mobile IP environment, there are no additional error codes defined for basic operation. ------------ Think: for minimal mobile node implementations ------------- There are, however, additional error codes defined for lease maintenence in section 3.3. ------------ Fin: for minimal mobile node implementations ------------- S. Glass Expires 7 December, 2000 [page 13] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 5.2 Returning Information from Other DHCP-Specific Options/Codes Without supporting optional DHCP extensions in mobile IP, there is no way to proxy information other than the home address, and perhaps a hint as to the DHCP lease time, to a MN. Therefore, there is little to be gained from the home agent including any other options in the DHCPDISCOVER or DHCPREQUEST other than those mentioned in section 3: Client ID option (code 61), IP address Lease Time option (code 51), Requested IP Address option (code 50), and possibly Mobile IP Home Agent option (code 68). Using the method outlined in section 4.4, however, a mobile node can use a DHCPINFORM message to obtain any information about its home subnet it desires, and through mobile IP, by a mechanism as if it were at home. As a result, there is only a limited need for DHCP extensions to mobile IP to help optimize the use of DHCP by the mobile node and home agent. 6.0 Caveats and Cautions The use of DHCP with mobile ip, while allowing address management to be centralized, comes with some caveats, and cautions which site administrators should be aware of. 6.1 Home Address Availability There is no guarantee that DHCP administered addresses will be available to a node, even in non-mobile ip situations. A way around this, however, which is not available to non-mobile IP aware nodes is for a mobile node to be configured with multiple home agents on different links, or multiple link prefixes in the home domain for home agent discovery. In this way, if one home agent is unable to obtain an address lease for the mobile node, the mobile node may send a registration request to a home agent on a different link (using the same NAI) in hopes of obtaining a home address there. Moreover, a mobile node may obtain home addresses on different links using the same NAI. 6.2 Home Address Consistency As with any address assignment mechanism, there is a chance a mobile node will not be able to obtain the same IP address it had been using in the past. This refers, of course, to an IP addresses for which the mobile node's binding is no longer valid, or certainly for which the DHCP lease has expired. The mobile node should take care to never allow a binding to expire for an IP address it may be dependant on. This applies not only to IP addresses obtained through DHCP, but any address allocated by the home agent. Although a DHCP server SHOULD return the IP address used in a previous binding by the same node [2], there is no guarantee the address will be available. This is exactly the same as in the case where the home agent is itself handing out addresses from its own pool. Should the home agent be itself administering addresses, and such an address is implicity returned to the address pool because a mobile node allowed its registration to expire, there is no guarantee that address will be available to the same mobile node in a subsequent session unless the S. Glass Expires 7 December, 2000 [page 14] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 home agent is reserving one IP address per potential mobile node, and is therefore reserving specific IP addresses for individual mobile nodes. The idea of providing IP addresses from an address pool, however, is to reuse addresses, if not allow the number of addresses needed to be minimized, so such a home agent configuration seems to defy the intent of dynamic IP address configuration. In the case of PPP assigned addresses, common practice seems to be to permanently assign one IP address per dial-in line, but this situation is not analogous as only one host can be connected to a dial-in line at a time, and thereby there is no risk of multiple nodes needing this address simultaneously, nor needing to obtain the same address across different PPP sessions. 6.3 Multiple DHCP Addresses If for some reason the mobile node wishes to obtain additional addresses on the home link, while it seems possible for it to reverse tunnel DHCPDISCOVER messages as described in [1] and [6] to its home link, DHCPOFFERS arriving at the interface of the home agent on the mobile node's home link will not contain enough information for the home agent to know where to deliver them. While it may be possible for home agents to examine the contents of the decapsulated reverse tunnel traffic, and note that it is sending a DHCPDISCOVER on behalf of the mobile node, this is not recommended, and can lead to problems when more than one mobile node is doing so simultaneously. Instead, mobile node's requiring multiple addresses MUST have one NAI per required address on each of the required links. Therefore, if a mobile node has two interfaces each requiring a different address on the same home link, it MUST have two NAIs, but if these interfaces are on separate home links, only one NAI is required. If a mobile node has simultaneous DHCP leases, the way DHCP does lease renewal requires each lease to be renewed independantly. This is the case if the mobile node is maintaining its own leases, or if the home agent is doing lease renewal on behalf of the mobile node. 6.4 Selecting an NAI Of concern are allowable characters that can be placed both in NAIs, and the Client ID option. [4] specifies the Client ID option, and [5] specifies the character set and format restrictions for the NAI. At this time, there do not appear to be any conflicts with the requirements laid out in [5] on NAI character restrictions, and those restrictions placed on the Client ID option in [2]. System Administrators are advised, however, to limit their assigned NAIs to the intersection of the requirements as they may change over time. S. Glass Expires 7 December, 2000 [page 15] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 6.5 DHCPINFORM Caveat It is not known how DHCP Servers will respond to a DHCPINFORM message from a node looking for the lifetime of it's address lease. It is advised that a mobile node that does not receive a Mobile IP DHCP Lease Lifetime extension not attempt to query the DHCP Server for this information, and allow the home agent to renew its lease. 7.0 Security Considerations The Mobile IP protocol requires the use of MN-HA or MN-AAA authenticators to provide authentication of the MN to the HA/home subnet. Whenever a registration request is received by a home agent it MUST be authenticated as having been sent by the MN identified by either the home address, or if the home address is set to the 0 address, the NAI option appended to the registration request, but appearing before, and thereby protected by, the MN-HA or MN-AAA authenticator. As a result, the DHCP address being requested by home agents on behalf of mobile nodes they are servicing are being assigned to machines which have been authenticated as belonging to the home domain, and more specifically, are part of the subnet the assigned address belongs to. Moreover, as there is a one-to-one mapping between NAI and Client ID, only one address per NAI will be assigned per link, thereby preventing a situation where subnet addresses would be more exhausted than if the mobile nodes were making the DHCP requests on their own. 8.0 Compliance Statements 8.1 Mobile IP Compliance Statement Whereas this document follows mobile node and home agent proceedures and requirements described in the mobile IP document draft-ietf-mobileip-rfc2002-bis-LATEST.txt, which, upon obtaining RFC status, will obsolete [1], mobile nodes complying with [1] (and [2], and [3]) should function properly when interacting with home agents complying with [1] (and [2], and [3]) and this specification. 8.2 DHCP Compliance Statement Whereas this document details RFC2131, which obsoletes RFC1541, all that is required is for a home agent and the DHCP server to follow DHCP Client and Proxy requirements in RFC1541. 9.0 Acknoledgements The author wishes to greatfully acknowledge the help provided by David Miner, Carl Smith, and Michael Carney, all of Sun Microsystems. Their knowledge of DHCP far surpasses mine, and were able to help fill in many of the DHCP implementation details I was not clear on. S. Glass Expires 7 December, 2000 [page 16] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 10.0 Author's Name and Address Comments should be sent to the mobileip mailing list: mobile-ip@standards.nortelnetworks.com or to the author: Steven M. Glass Steven.Glass@sun.com Sun Microsystems 1 Network Drive Burlington, MA. 01803 Office: 1.888.555.9SUN Fax: 1.781.442.1677 11.0 References [1] RFC2002, "IP Mobility Support", C. Perkins, October 1996 [2] RFC2131, "Dynamic Host Configuration Protocol", R. Droms, March 1997 [3] RFC2794, "Mobile IP Network Access Identifier Extension for IPv4", P. Calhoun and C. Perkins. March 2000. [4] RFC2132, "DHCP Options and BOOTP Vendor Extensions", Alexander & Droms, March 1997. [5] RFC2486, "The Network Access Identifier", B. Aboba, M. Beadles, January 1999. [6] RFC2344, "Reverse Tunneling for Mobile IP", G. Montenegro, May 1998 [7] RFC2489 "Procedure for Defining New DHCP Options", Droms, January 1999 [9] Glass, S. "Mobile IP Registration Revocation", Work In Progress. [10] D. Johnson and C. Perkins, "Mobility Support in IPv6", Work In Progress. [11] J. Bound, M. Carney, and C. Perkins, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work In Progress. S. Glass Expires 7 December, 2000 [page 17] Internet Draft Mobile IP Agents as DHCP Proxies 1 June, 2000 12.0 Full Copyright Statement "Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13.0 Chair's Address The Working Group can be contacted via its current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola M/S M8-540 6000 Connection Drive 1501 West Shure Drive Irving, TX 75039 Arlington Heights, IL 60004 USA USA Phone: +1 972-894-6709 Phone: +1 847-632-3148 EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com Fax : +1 972-894-5349 S. Glass Expires 7 December, 2000 [page 18] ---LA_F2159613915R-2A-960422424=:578NCE.IlHAFeR-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 7 23:13:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25969 for ; Wed, 7 Jun 2000 23:13:08 -0400 (EDT) Received: from standards (47.234.32.16:3973) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7409A@standards.nortelnetworks.com>; Wed, 7 Jun 2000 23:04:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4683 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 7 Jun 2000 23:04:06 -0400 Received: from ms.hansol.co.kr (203.235.136.4:1437) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74099@standards.nortelnetworks.com>; Wed, 7 Jun 2000 23:04:06 -0400 Received: from ns ([210.112.7.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id LAA30384 for ; Thu, 8 Jun 2000 11:38:12 +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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <00e501bfd0f2$b9617c20$d012060a@hansol.co.kr> Date: Thu, 8 Jun 2000 11:38:36 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: [MOBILE-IP] Simple Q. on Mobile-IPv4 Option for PPP IPCP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear All Item no.7 in section 2.5 of RFC2290: Mobile-IPv4 Configuration Option for PPP IPCP .... a. Ack() .... Otherwise, the mobile node MAY attempt to obtain a topologically routable address through any of its supported means (e.g., DHCP, manual configuration, etc.) for use as a co-located care-of address. If the mobile node is successful in obtaining such an address then it SHOULD register this address with its home agent. => Nak(IP=0) MUST NOT be sent. Goto 6. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Legal response from peer is defined as only (a). Now then, it's not clear to understand "Goto 6" in the underscored statement. May I ask dilation to this ? Regards, Jiwoong Lee From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 8 11:04:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09220 for ; Thu, 8 Jun 2000 11:04:48 -0400 (EDT) Received: from standards (47.234.32.16:3808) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB742D0@standards.nortelnetworks.com>; Thu, 8 Jun 2000 10:55:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5408 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 10:55:22 -0400 Received: from MYPC (208.238.46.160:2555) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB742C7@standards.nortelnetworks.com>; Thu, 8 Jun 2000 10:45:16 -0400 X-Sender: griffin@exotic.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Message-ID: Date: Thu, 8 Jun 2000 09:55:48 -0400 Reply-To: griffin@EXOTIC.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: griffin@EXOTIC.COM Subject: [MOBILE-IP] GET $3MIL VALUE FROM $25 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Few people get chances they take... Rockefella' US$25.00 FOR US$3MIL VALUE RESERVED ... SEND US$25 YOU CAN OWN (in beautiful Jamaica) 7 Acre COFFEE FARM (BLUE MOUNTAIN COFFEE) * your own coffee to grind * coffee price is going up - you can operate at the retail end * export to Japan, etc *you can setup local management and watch the $$ come as more people start to drink 5 or more cups per day as a cure or preventative to ALZImers ALSO in the chance is 50 Acres BEACH FRONT PROPERTY (North Coast) * ready for RESORT development * international GOLF course operation * establish a NUDITY beach colony on the white sands * watch the income flow SEND US$25. IN AN EVELOPE WITH YOUR NAME AND ADDRESS WRITTEN ON & put this smaller envelop into a larger envelop ( we will return info to you here) & write a note saying: please enter me in this DRAW & put this note into the larger envelop THAT'S SIMPLY IT BUT YOUR CHANCE GOES UP : FOR EACH NAME YOU WRITE ONTO THE NOTE GIVES YOU ONE MORE ENTRY TO THE DRAW if we find the referred person applied for the same DRAW you are in. IF you write peter smith and a peter smith send in $25. you get one more entry. 1. draw date is that date the applicants fee reach the reserve value indicated 2. you will be sent your title of ownership (and conditions) or the information of who got it. 3. you will be automatically re-entered into the next DRAW if you had referred over ten applicants SEND YOUR ENVELOPE TO EXOCTIC INVESTMENTS P.O. BOX 8776 KINGSTON CSO JAMAICA W.I From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 8 12:44:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11610 for ; Thu, 8 Jun 2000 12:44:57 -0400 (EDT) Received: from standards (47.234.32.16:3443) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB743A5@standards.nortelnetworks.com>; Thu, 8 Jun 2000 12:35:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5649 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 12:35:30 -0400 Received: from mta5.rcsntx.swbell.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74389@standards.nortelnetworks.com>; Thu, 8 Jun 2000 12:25:29 -0400 Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00DRVF4T39@mta5.rcsntx.swbell.net> for mobile-ip@standards.nortelnetworks.com; Thu, 8 Jun 2000 11:05:48 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Message-ID: <0FVU00DSRFDM39@mta5.rcsntx.swbell.net> Date: Thu, 8 Jun 2000 11:05:48 -0500 Reply-To: zainprov@SWBELL.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: zainprov@SWBELL.NET Subject: [MOBILE-IP] Shocking LOSE 10-100lbs. DESTINY To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 8 13:59:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13085 for ; Thu, 8 Jun 2000 13:59:28 -0400 (EDT) Received: from standards (47.234.32.16:4591) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74403@standards.nortelnetworks.com>; Thu, 8 Jun 2000 13:50:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0055 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 13:50:21 -0400 Received: from shuttle.wide.toshiba.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB743FD@standards.nortelnetworks.com>; Thu, 8 Jun 2000 13:40:20 -0400 Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA24025; Fri, 9 Jun 2000 02:35:34 +0900 (JST) User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 64 Message-ID: Date: Fri, 9 Jun 2000 02:42:45 +0900 Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. Subject: [MOBILE-IP] a comment of draft-ietf-mobileip-ipv6-12.txt X-To: iesg@ietf.org X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Before finishing the last call for the mobile IPv6 draft, I'd like to comment on the draft. I hope this is not too late, and apologize in advance if this has already been discussed. Section 10.2 of the draft says as follows: - Since the mobile node is away from home, the mobile node inserts a Home Address option into the packet, replacing the Source Address in the packet's IP header with a care-of address suitable for the link on which the packet is being sent, as described in Section 10.1. The Destination Options header in which the Home Address option is inserted MUST appear in the packet before the AH [11] (or ESP [12]) header, so that the Home Address option is processed by the destination node before the AH or ESP header is processed. It seems to me that the order of the destination options header including the home address option is not conformant to the recommended order of extension headers specified in RFC 2460: When more than one extension header is used in the same packet, it is recommended that those headers appear in the following order: IPv6 header Hop-by-Hop Options header Destination Options header (note 1) Routing header Fragment header Authentication header (note 2) Encapsulating Security Payload header (note 2) Destination Options header (note 3) upper-layer header note 1: for options to be processed by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the Routing header. note 2: additional recommendations regarding the relative order of the Authentication and Encapsulating Security Payload headers are given in [RFC-2406]. note 3: for options to be processed only by the final destination of the packet. At least for me, the above order assumes that a destination options header placed before an authentication header (or an ESP) should also be accompanied with a routing header. However, the mobile IPv6 draft does not mention a routing header at all (I guess the draft does not care about a routing header). Is my concern about the order correct? If so, at least I want the draft to describe the intention of the unrecommended order and possible effects on implementation. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 8 16:18:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15805 for ; Thu, 8 Jun 2000 16:17:59 -0400 (EDT) Received: from standards (47.234.32.16:3400) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74442@standards.nortelnetworks.com>; Thu, 8 Jun 2000 16:08:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0145 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 8 Jun 2000 16:08:51 -0400 Received: from taurus.cs.albany.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74441@standards.nortelnetworks.com>; Thu, 8 Jun 2000 15:58:51 -0400 Received: from euler.cs.albany.edu (euler.cs.albany.edu [169.226.2.43]) by taurus.cs.albany.edu (8.9.3+Sun/8.9.1) with ESMTP id QAA19639; Thu, 8 Jun 2000 16:04:40 -0400 (EDT) Received: (from ravi@localhost) by euler.cs.albany.edu (SMI-8.6/CLI2) id QAA27918; Thu, 8 Jun 2000 16:04:38 -0400 Message-ID: <200006082004.QAA27918@euler.cs.albany.edu> Date: Thu, 8 Jun 2000 16:04:38 -0400 Reply-To: "S.S.Ravi" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "S.S.Ravi" Subject: [MOBILE-IP] DIAL M Workshop -- Call for Participation X-To: dmanet@zpr.uni-koeln.de, im-net-digest@iwr.uni-heidelberg.de, itc@ieee.org, manet@itd.nrl.navy.mil, mobility@media.mit.edu, opt-net@zib.de, orcs-l@listserv.okstate.edu, podc-post@research.telcordia.com, tccc@ieee.org, theorynt@listserv.nodak.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM CALL FOR PARTICIPATION 4th International Workshop on Discrete Algorithms and Methods for Mobile Computing & Communications (DIALM for Mobility) August 11, 2000 Boston, Massachusetts, USA In conjunction with ACM MobiCom 2000 Workshop URL : http://www.eecis.udel.edu/~elloyd/dialm.d/home.html SPONSORS: (a) National Science Foundation. (b) ACM SIGMOBILE (in cooperation with ACM SIGACT) (c) Basic and Applied Simulation Science Group (TSA-2) of Los Alamos National Laboratory. SCOPE: Mobile computing and communications devices such as portable phones, laptops and palmtops will have an enormous impact on our lifestyle over the next several decades. The introduction of mobility raises a number of new research issues. This workshop is devoted to discrete algorithms and methods in the context of mobile and wireless computing and communications. The workshop is intended to serve as a forum for open discussions and lively debate, and to foster cooperation among practitioners and theoreticians. The conference program includes three invited talks and 11 contributed papers. (The schedule of talks appears below.) REGISTRATION and HOTEL INFORMATION: DIAL M Workshop registration is being conducted in conjunction with the MobiCom 2000 conference registration. Please see the Mobicom 2000 home page (http://www.argreenhouse.com/mobicom2000) for registration, conference location and hotel information. STUDENT TRAVEL GRANTS: Students attending DIAL M may apply for Student Grants to defray a part of the cost of attending the workshop. Any student may apply (presenting a paper is NOT a prerequisite). For further information, please contact the DIAL M Program Chair Professor Errol Lloyd (elloyd@udel.edu). Funding for these grants is provided by the National Science Foundation. CONFERENCE PROGRAM: 7 AM - Noon Registration 7 AM - 8 AM Continental Breakfast 8 AM Welcome by the Program Chair: Errol Lloyd (Univ. of Delaware) 8:05 AM Remarks by the Steering Committee Chair: Maurizio Bonuccelli (Univ. of Pisa) SESSION ONE 8:10 - 8:30 AM Online Algorithms for Channel Assignment Problems in Cellular Networks P. Crescenzi (Universita di Firenza); G. Gambosi and P. Penna (Universita di Roma) 8:30 - 8:50 AM Worst-case Analysis of a Dynamic Channel Assignment Strategy L. Narayanan and Y. Tang (Concordia University) 8:50 - 9:10 AM Efficient Use of Radio Spectrum in Wireless Networks with Channel Separation between Close Stations A. Bertosi (Univ. of Trento); M. C. Pinotti (National Research Council, Italy); R. Tan (Univ. of Science and Arts of Oklahoma) 9:10 - 9:30 AM Blocking Probability Estimates in a Partitioned Sector TDMA System C. Chekuri, K. Ramanan, P. Whiting and L. Zhang (Bell Laboratories) 9:30 - 9:50 AM Energy-Efficient Routing in Radio Networks K. Nagoya (Nagoya Institute of Technology); S. Olariu (Old Dominion University) 9:50 - 10:20 AM Refreshment Break an Discussion Time SESSION TWO 10:20 - 11:20 AM INVITED TALK: Data Structures for Mobile Data Leonidas Guibas (Stanford University) 11:20 - 11:40 AM Mobile Facility Location S. Bespamyatnikh (Univ. of British Columbia); B. Bhattacharya (Simon Fraser University); D. Kirkpatrick and M. Segal (Univ. of British Columbia) 11:40 - Noon A. Aggarwal, M. Kapoor, L. Ramachandran and A. Sarkar (IBM India Research Laboratory) Noon - 1:10 PM Workshop Luncheon SESSION THREE 1:10 - 2:10 PM INVITED TALK: The Post-PC Era: It's about the New Services-Enabled Internet Randy Katz (Univ. of California, Berkeley) 2:10 - 2:30 PM Dynamic Session Management for Static and Mobile Users: A Competitive On-Line Algorithmic Approach Y. Bejarno, I. Cidon (Technion - Israel Institute of Technology); J. (Seffi) Naor (Bell Laboratories) 2:30 - 2:50 PM Efficient Memoryless Protocol for Tag Identification C. Law, K. Lee and K. Y. Siu (Massachusetts Institute of Technology) 2:50 - 3:20 PM Refreshment Break and Discussion Time SESSION FOUR 3:20 - 4:20 PM INVITED TALK: Application of a Theory of Simulation to Models of Mobile Communication Systems Christopher Barrett (Los Alamos National Laboratory) 4:20 - 4:40 PM A Decision-Theoretic Approach to Resource Allocation in Wireless Multimedia Networks Z. Haas, J. Halpern, L. Li and S. Wicker (Cornell Univ.) 4:40 - 5:00 PM Leader Election Algorithms for Mobile Ad Hoc Networks N. Malpani, J. Welch and N. Vaidya (Texas A&M Univ.) PROGRAM CHAIR: Errol L. Lloyd Department of Computer and Information Sciences University of Delaware Newark, DE, USA Email: elloyd@udel.edu PROGRAM COMMITTEE Amotz Bar-Noy, AT&T Labs and Tel Aviv University, Israel Anthony Ephremides, University of Maryland, USA Aura Ganz, University of Massachusetts, USA Juraj Hromkovic, RWTH Aachen, Germany Bo Li, Hong Kong University of Science and Technology, Hong Kong Jason Yi-Bing Lin, National Chiao-Tung University, ROC Errol Lloyd, University of Delaware,USA -- Program Chair Madhav Marathe, Los Alamos National Lab Marina Papatriantafilou, Chalmers Univ. of Technology, Sweden Stephane Perennes, INRIA, France Cynthia Phillips, Sandia National Laboratories, USA Balaji Raghavachari, University of Texas at Dallas, USA S. S. Ravi, SUNY Albany, USA -- Publicity Chair Andrea Richa, Arizona State University, USA Aravind Srinivasan, Bell Labs, USA Martha Steenstrup, BBN, USA Subhash Suri, Washington University, USA Eli Upfal, Brown University, USA Peter Widmayer, ETH Zurich, Switzerland STEERING COMMITTEE Ian Akyildiz, Georgia Tech, USA Maurizio Bonuccelli, University of Pisa, Italy (Chair) Afonso Ferreira, CNRS - I3S - INRIA - Sophia Antipolis, France Arunabha Sen, Arizona State University, USA. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 9 03:10:58 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06872 for ; Fri, 9 Jun 2000 03:10:58 -0400 (EDT) Received: from standards (47.234.32.16:3709) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7458A@standards.nortelnetworks.com>; Fri, 9 Jun 2000 3:01:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0561 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 03:01:30 -0400 Received: from odin2.bull.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74589@standards.nortelnetworks.com>; Fri, 9 Jun 2000 3:01:29 -0400 Received: from ecbull20.frec.bull.fr (ecbull20.frec.bull.fr [129.183.4.3]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA53332; Fri, 9 Jun 2000 09:13:01 +0200 Received: from isatis.frec.bull.fr (isatis.frec.bull.fr [129.183.144.1]) by ecbull20.frec.bull.fr (8.9.2/8.9.1) with ESMTP id JAA14040; Fri, 9 Jun 2000 09:09:20 +0200 Received: from bull.net (localhost [127.0.0.1]) by isatis.frec.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id JAA156998; Fri, 9 Jun 2000 09:09:19 +0200 (DFT) X-Mailer: Mozilla 4.06 [en] (X11; I; AIX 4.2) MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3940981E.FC64AD7C@bull.net> Date: Fri, 9 Jun 2000 09:09:18 +0200 Reply-To: Aime.Le-Rouzic@BULL.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: AIme Le-Rouzic Organization: Bull Subject: Re: [MOBILE-IP] a comment of draft-ietf-mobileip-ipv6-12.txt X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, In fact, the Home Address has to be also BEFORE the fragment header to allow firewalls to read it. Those firewalls can be on other destinations than those listed in the Routing Header. May be it needs to clarify to put a recommendation in RFC2460 or in the next RFC MobileIPv6 this special case. Best regards JINMEI Tatuya / $B?@L@C#:H (B wrote: > > Before finishing the last call for the mobile IPv6 draft, I'd like to > comment on the draft. > > I hope this is not too late, and apologize in advance if this has > already been discussed. > > Section 10.2 of the draft says as follows: > > - Since the mobile node is away from home, the mobile node inserts > a Home Address option into the packet, replacing the Source > Address in the packet's IP header with a care-of address suitable > for the link on which the packet is being sent, as described in > Section 10.1. The Destination Options header in which the Home > Address option is inserted MUST appear in the packet before the > AH [11] (or ESP [12]) header, so that the Home Address option is > processed by the destination node before the AH or ESP header is > processed. > > It seems to me that the order of the destination options header > including the home address option is not conformant to the recommended > order of extension headers specified in RFC 2460: > > When more than one extension header is used in the same packet, it is > recommended that those headers appear in the following order: > > IPv6 header > Hop-by-Hop Options header > Destination Options header (note 1) > Routing header > Fragment header > Authentication header (note 2) > Encapsulating Security Payload header (note 2) > Destination Options header (note 3) > upper-layer header > > note 1: for options to be processed by the first destination > that appears in the IPv6 Destination Address field > plus subsequent destinations listed in the Routing > header. > > note 2: additional recommendations regarding the relative > order of the Authentication and Encapsulating > Security Payload headers are given in [RFC-2406]. > > note 3: for options to be processed only by the final > destination of the packet. > > At least for me, the above order assumes that a destination options > header placed before an authentication header (or an ESP) should also > be accompanied with a routing header. However, the mobile IPv6 draft > does not mention a routing header at all (I guess the draft does not > care about a routing header). > > Is my concern about the order correct? If so, at least I want the > draft to describe the intention of the unrecommended order and > possible effects on implementation. > > Thanks, > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -- ________________________Aime LEROUZIC____________________________ BULL S.A ECHIROLLES FRANCE mailto:Aime.Lerouzic@frec.bull.fr http://www-frec.bull.com tel: +33 (0)4 76 29 75 51 Communications TCPIP http://intranet/lerouzic From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 9 07:20:09 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08625 for ; Fri, 9 Jun 2000 07:20:09 -0400 (EDT) Received: from standards (47.234.32.16:1475) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74628@standards.nortelnetworks.com>; Fri, 9 Jun 2000 7:10:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0753 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 07:10:52 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74624@standards.nortelnetworks.com>; Fri, 9 Jun 2000 7:00:51 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08511; Fri, 9 Jun 2000 07:09:22 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200006091109.HAA08511@ietf.org> Date: Fri, 9 Jun 2000 07:09:21 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-glass-mobileip-agent-dhcp-proxy-00.txt X-cc: dhcp-v4@bucknell.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IP Agents as DHCP Proxies Author(s) : S. Glass Filename : draft-glass-mobileip-agent-dhcp-proxy-00.txt Pages : 18 Date : 08-Jun-00 Since the inclusion of the Network Access Identifier (NAIs) into the mobile ip fabric, home agents have had a way to identify mobile nodes which do not have home IP addresses. After authenticating the registration request from such a mobile node, the home agent is then expected to assign a home addresses to the mobile node in the registration reply to be used on a semi-permanent basis. Unfortunately, no specific mechanism has yet been proposed. Ideally, as DHCP centralizes address management, a home agent should contact a DHCP server to allocate an address for the mobile node, thereby preserving DHCP as the central address maintainer. The technology does exist for a Home Agent to use DHCP controlled addresses, namely for the Home Agent to behave as a DHCP proxy agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-glass-mobileip-agent-dhcp-proxy-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-glass-mobileip-agent-dhcp-proxy-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-glass-mobileip-agent-dhcp-proxy-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000608093912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-glass-mobileip-agent-dhcp-proxy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-glass-mobileip-agent-dhcp-proxy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000608093912.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 9 07:28:06 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08710 for ; Fri, 9 Jun 2000 07:28:06 -0400 (EDT) Received: from standards (47.234.32.16:1475) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74647@standards.nortelnetworks.com>; Fri, 9 Jun 2000 7:18:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0757 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 07:18:42 -0400 Received: from tcm-gw.tcm.hut.fi (tcm.hut.fi) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74627@standards.nortelnetworks.com>; Fri, 9 Jun 2000 7:08:41 -0400 Received: (from smap@localhost) by tcm-gw.tcm.hut.fi (8.8.7/8.8.7) id OAA02100 for ; Fri, 9 Jun 2000 14:17:12 +0300 Received: from caffeine.tcm.hut.fi(130.233.45.27) by tcm-gw.tcm.hut.fi via smap (V2.0) id xma002098; Fri, 9 Jun 00 14:16:49 +0300 Received: from morphine.tcm.hut.fi (morphine.tcm.hut.fi [130.233.45.7]) by caffeine.tcm.hut.fi (8.9.2/8.9.2) with ESMTP id OAA03289 for ; Fri, 9 Jun 2000 14:16:53 +0300 (EET DST) Received: from localhost (lpetande@localhost) by morphine.tcm.hut.fi (8.9.2/8.7.1) with ESMTP id OAA07756 for ; Fri, 9 Jun 2000 14:16:41 +0300 (EET DST) X-Authentication-Warning: morphine.tcm.hut.fi: lpetande owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 9 Jun 2000 14:16:41 +0300 Reply-To: Lars Henrik Petander Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Lars Henrik Petander Subject: [MOBILE-IP] MIPL Mobile IPv6 for linux To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello! The MIPL project at the Helsinki University of Technology has implemented Mobile IPv6 as a kernel module for the Linux kernel version 2.4. The release 0.50 of MIPL is an alpha prototype, but it implements most of the functionality specified in the IETF draft version 12 of mobility support for IPv6, including route optimization. Authentication of binding updates and acknowledgements is not implemented yet, since currently there is no IPSec available for Linux that supports IPv6. The development work will continue in the GO research project at HUT. The release consists of a kernel module, some patches to the IPv6 module and configuration and installation tools, all under GPL. The release, source code and more information are available from: http://vesper.tky.hut.fi/mip Henrik Petander, MIPL / GO project From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 9 07:58:41 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09243 for ; Fri, 9 Jun 2000 07:58:41 -0400 (EDT) Received: from standards (47.234.32.16:1210) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7466D@standards.nortelnetworks.com>; Fri, 9 Jun 2000 7:49:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0847 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 07:49:41 -0400 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7466C@standards.nortelnetworks.com>; Fri, 9 Jun 2000 7:39:40 -0400 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e59Bm8r27582 for ; Fri, 9 Jun 2000 13:48:09 +0200 (MET DST) Received: from greymse1.lmf.ericsson.se (greymse1.lmf.ericsson.se [131.160.1.6]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA10325 for ; Fri, 9 Jun 2000 14:48:07 +0300 (EET DST) Received: from localhost (root@localhost) by greymse1.lmf.ericsson.se (8.9.3 (PHNE_18979)/8.8.6) with ESMTP id OAA22986 for ; Fri, 9 Jun 2000 14:48:06 +0300 (EETDST) X-OpenMail-Hops: 2 X-OpenMail-Autoreplied: TRUE MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Message-ID: <"AUTOANS-08a0c0a1.0960551284.greymse1.lmf.ericsson.se*"@MHS> Date: Fri, 9 Jun 2000 14:48:04 +0300 Reply-To: manuel.sanchez@LMF.ERICSSON.SE Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: manuel.sanchez@LMF.ERICSSON.SE Subject: [MOBILE-IP] Auto Reply Message To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200006091109.HAA08511@ietf.org> Content-Transfer-Encoding: 8bit I am out of office for a few days. I will be back the 19th of June. -- Manuel Sanchez Cabas Advance Signalling Research Laboratory Mobile:+358 40 562 3067 Telephone: +358 9 299 3018 Email: Manuel.Sanchez@lmf.ericsson.se Oy LM Ericsson Ab 02420 Jorvas FINLAND From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 9 14:06:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16448 for ; Fri, 9 Jun 2000 14:06:30 -0400 (EDT) Received: from standards (47.234.32.16:4685) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7480A@standards.nortelnetworks.com>; Fri, 9 Jun 2000 13:57:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1371 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 13:57:09 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74806@standards.nortelnetworks.com>; Fri, 9 Jun 2000 13:47:09 -0400 Received: from milena.par.univie.ac.at (milena.par.univie.ac.at [131.130.186.60]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id MAA00875 for ; Fri, 9 Jun 2000 12:55:39 -0500 (CDT) Received: from kirsty (kirsty [131.130.186.49]) by milena.par.univie.ac.at (8.9.3/8.9.3) with SMTP id OAA10392 for ; Thu, 8 Jun 2000 14:16:57 +0200 (MET DST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4733ZLumYv8QHq5gUrCDRg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Message-ID: <200006081216.OAA10392@milena.par.univie.ac.at> Date: Thu, 8 Jun 2000 14:16:57 +0200 Reply-To: Thomas Fahringer Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Thomas Fahringer Subject: [MOBILE-IP] Open Research Position: Execution-Driven Performance Analysis for Distr./Parallel Systems X-To: tfmisc@par.univie.ac.at To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM The Institute for Software Science at the University of Vienna is offering within a long-term research project a *********************************************************** *** Research Position in Execution-Driven Performance *** *** Analysis for Distributed and Parallel Systems *** *********************************************************** Applicants should have knowledge in one or more of the following areas: + distributed and parallel systems + performance measurement, monitoring, and tracing + on-line and post-execution performance analysis + performance visualization + programming skills + distributed programming (Java) + parallel programming (OpenMP, MPI, Threads, HPF ...) + databases and expert systems Position: Research position for a doctoral student. Starting Date: immediately Duration: until April 2003. Project Summary: The position is offered as part of a long-term research project about performance-oriented application development for distributed and parallel systems. The main task of this position requires to develop a performance analysis system that searches for performance problems in object-oriented multi-threaded distributed and parallel applications exploiting both data and task parallelism. These applications are executed on clusters of SMPs or on heterogeneous workstation networks. Various instrumentation systems are used to obtain raw performance data while executing a program. Performance data may be stored in a data repository (database or expert system) for post-execution analysis. The system to be developed tries to find performance problems based on collected and computed performance data, and information about the input program provided by a compiler. Performance problems will be associated with the input program. Based on detected performance problems further decisions may be taken, e.g. refinement of instrumentation, more detailed search for performance problems, application and system changes to improve performance, etc. For more information, please contact Thomas Fahringer (tf@par.univie.ac.at) ======================================================================= Thomas Fahringer, Ph.D. Tel: (office): +43 1 4277-38816 Associate Professor Tel: (sec): +43 1 4277-38801 University of Vienna Fax: +43 1 4277-9388 Institute for Software Science E-mail: tf@par.univie.ac.at Liechtensteinstr. 22 WWW: http://www.par.univie.ac.at/~tf A-1090 Vienna, Austria From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 9 14:10:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16546 for ; Fri, 9 Jun 2000 14:10:35 -0400 (EDT) Received: from standards (47.234.32.16:4685) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7481D@standards.nortelnetworks.com>; Fri, 9 Jun 2000 13:59:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1372 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 13:59:43 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74807@standards.nortelnetworks.com>; Fri, 9 Jun 2000 13:49:43 -0400 Received: from marjan.fesb.hr (root@marjan.fesb.hr [161.53.166.3]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id MAA00905 for ; Fri, 9 Jun 2000 12:57:57 -0500 (CDT) Received: from jurica (jurica.fesb.hr [161.53.166.43]) by marjan.fesb.hr (8.9.3/8.9.3) with SMTP id LAA01077; Thu, 8 Jun 2000 11:43:04 +0200 (MET DST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <03db01bfd132$0d136c90$2ba635a1@fesb.hr> Date: Thu, 8 Jun 2000 11:44:18 +0200 Reply-To: SoftCOM Secretary Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: SoftCOM Secretary Organization: FESB, University of Split Subject: [MOBILE-IP] SoftCOM 2000 Deadline Extension and Feature Topic CFP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear All, Due to the number of requests for deadline extension the SoftCOM 2000 Organizing Committee has extended the paper submission deadline to June 19, 2000. We use this opportunity to remind the potential contributors that the deadline for special session "The New Millennium Telecommunications in the Alps-Adria Countries" is approaching. From the papers presented at SoftCOM 2000, a set of the most representative papers (or their integrals) will be selected for publication in the August 2001 issue of the IEEE Communications Magazine. Deadline for the Feature Topic: Complete manuscript to be received by July 15, 2000 Notification of acceptance: July 31, 2000 The Feature Topic includes, but it is not limited to: -historical background, developments, -operation statistics and experiencies, user (universities, institutes, schools) opinions, -the newest technologies and services, -development of telelearning and videoconferencing, -Web applications and information systems, -security aspects, -plans for future,toward the new millennium, -the role of universities and institutes, -the role of the national and regional operators and companies, industry and institutions, -joint projects, joint institutes and laboratories between academic and operators and companies, industry and institutions, -participation of academic institutions in education of professionals from industry and vice versa, Participation in this FT is expected from institutions which cover academic networking (such as CARNet in Croatia, Arnes in Slovenia), as well as from universities, institutes and schools as users, particularly in the Alps-Adria region. In addition, contributions from national and regional institutions, companies, operators and industry who participate in development of academic networking, promotion of education and R&D investigations are particularly welcome. More details can be found at http://www.fesb.hr/SoftCOM Thank you for your interest in SoftCOM 2000. SoftCOM 2000 Organizing Committee From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 9 15:32:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17785 for ; Fri, 9 Jun 2000 15:32:38 -0400 (EDT) Received: from standards (47.234.32.16:4171) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74859@standards.nortelnetworks.com>; Fri, 9 Jun 2000 15:23:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1477 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 15:23:36 -0400 Received: from babbage.ececs.uc.edu (ececs.uc.edu) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74856@standards.nortelnetworks.com>; Fri, 9 Jun 2000 15:13:35 -0400 Received: from wayward.ececs.uc.edu (wayward.ececs.uc.edu [129.137.9.117]) by babbage.ececs.uc.edu (8.9.3+Sun/8.9.3) with ESMTP id PAA13310 for ; Fri, 9 Jun 2000 15:22:02 -0400 (EDT) Received: (from sdas@localhost) by wayward.ececs.uc.edu (8.9.3+Sun/8.9.1) id PAA29667 for mobile-ip@standards.nortelnetworks.com; Fri, 9 Jun 2000 15:21:45 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID: <200006091921.PAA29667@wayward.ececs.uc.edu> Date: Fri, 9 Jun 2000 15:21:45 -0400 Reply-To: Samir Das Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Samir Das Subject: [MOBILE-IP] MobiCom 2000: Call for Participation To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit ANNOUNCEMENT AND CALL FOR PARTICIPATION MobiCom 2000 The Sixth Annual International Conference on Mobile Computing and Networking August 6 - 11, 2000 Seaport Hotel at World Trade Center Boston Boston, Massachusetts, USA THE COMPLETE ADVANCE PROGRAM AND REGISTRATION INFORMATION ARE AVAILABLE AT ---------------------------------------------- http://www.research.telcordia.com/mobicom2000/ ---------------------------------------------- Sponsored by ACM SIGMOBILE In cooperation with ACM SIGCOMM and SIGMETRICS; IEEE Communications Society; the USENIX Association; the IEE (UK); the IEICE and IPSJ (Japan); the KICS (Korea); and the IFIP WG 6.3 With support from IBM Research (Platinum supporter), HP Laboratories (Platinum supporter), Nokia (Gold supporter) and AT&T Laboratories Cambridge (Gold supporter) CONFERENCE HIGHLIGHTS --------------------- o Keynote Address: "Sentient Computing: The Interface is Everywhere," by Andy Hopper, Professor, University of Cambridge, and Managing Director, AT&T Laboratories Cambridge. o Technical Sessions: Twenty-eight technical papers will be presented describing previously unpublished research on a wide variety of topics in mobile computing and wireless networking, including prototype systems and networks, location support and data dissemination, packet scheduling and channel allocation, mobile internetworking, data management in mobile systems, and routing for ad hoc networks. Papers in a special session will challenge the community with new technologies and visionary applications. This year's conference received the largest number of paper submissions ever, resulting in a highly selective technical program. o Panels: We have organized two panels on timely issues with panelists who are passionate about these topics. P1: Comm'n Sense: Wireless Sensor Networks (Moderator: Deborah Estrin, UCLA and USC/ISI) P2: The Future Wireless Internet: Gazing Into the Crystal Ball (Moderator: Armando Fox, Stanford University) o Tutorials: There will be eight tutorials on cutting-edge topics: T1: Mobile IP for Current and Future Internet (David B. Johnson, CMU and Rice University) T2: Database Management Systems and Mobile Computing (Wang-Chien Lee, GTE Labs, Sandeep K.S. Gupta and Pradeep Srimani, Colorado State University) T3: Personal Area Networking Over Bluetooth (Pravin Bhagwat, AT&T Labs Research) T4: Service Discovery and Device Cooperation (Golden Richard III, University of New Orleans) T5: Energy Efficiency in Mobile Computing and Networking (Mani Srivastava, UCLA) T6: Mobile Voice over IP (Prathima Agrawal, Telcordia, Parmesh Ramanathan, University of Wisconsin, and Cormac J. Sreenan, University College Cork) T7: Mobile Ad Hoc Networks: Routing, MAC and Transport Issues (Nitin Vaidya, Texas A&M University) T8: Shaping the User Experience for Handheld Computing (Phillip B. Shoemaker, Palm Inc.) o Research Demos and Exhibits: The conference will also feature research demos from academic and industry research groups as well as the newest cutting edge products and services from a wealth of companies. o Workshops: Tackling the dominant issues of the day, the following workshops will allow extended considerations of particular topics. - Dial-M: Discrete Algorithms and Methods for Mobile Computing and Communications - WoWMoM: Wireless Mobile Multimedia - MSWiM: Modeling Analysis and Simulation of Wireless and Mobile Systems - MobiHOC: Mobile Ad Hoc Networking and Computing REGISTRATION ------------ The MobiCom 2000 web pages have all the conference registration and hotel reservation specific information: http://www.research.telcordia.com/mobicom2000/ Important Dates: July 7, 2000 -- Discounted hotel reservation deadline. July 15, 2000 -- Early conference registration deadline. Don't delay -- register today for MobiCom 2000. Come, celebrate the wireless revolution and its convergence with the Internet, on Boston's historic waterfront. It is THE conference to attend. We look forward to seeing you in Boston. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 9 22:37:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23358 for ; Fri, 9 Jun 2000 22:37:29 -0400 (EDT) Received: from standards (47.234.32.16:4387) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74920@standards.nortelnetworks.com>; Fri, 9 Jun 2000 22:28:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1747 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 9 Jun 2000 22:28:12 -0400 Received: from mail.huawei.com.cn (202.96.135.132:55077) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7491F@standards.nortelnetworks.com>; Fri, 9 Jun 2000 22:18:06 -0400 Received: from j01788 ([10.11.50.199]) by mail.huawei.com.cn (Netscape Mail Server v2.02) with SMTP id AAA17792 for ; Sat, 10 Jun 2000 10:27:32 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0010_01BFD2C5.F58222C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Message-ID: <001201bfd282$e7a20640$c7320b0a@huawei.com.cn> Date: Sat, 10 Jun 2000 10:23:45 +0800 Reply-To: tovey Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: tovey Subject: [MOBILE-IP] To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0010_01BFD2C5.F58222C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksIGV2ZXJ5b25lDQoNCiAgIEluIHRoaXMgaW50ZXJuZXQtZHJhZnQgPGRyYWZ0LWlldGYtbW9i aWxlaXAtM2d3aXJlbGVzcy1leHQtMDMudHh0PiwgdGhlcmUgbWF5YmUgc29tZSBwcm9ibGVtIGlu IHNlY3Rpb24gNC4xLCBhcyBmb2xsb3dpbmc6DQogICAgICBBIFJOTiBNVVNUIHNlbmQgYSBSZWdp c3RyYXRpb24gUmVxdWVzdCB3aXRoIHRoZSBHUkUgZW5jYXBzdWxhdGlvbioNCiAgIGFuZCB0aGUg cmV2ZXJzZSB0dW5uZWxpbmcgYml0IHNldC4gVGhlIEhvbWUgQWRkcmVzcyBmaWVsZCBpcyBzZXQg dG8NCiAgIHplcm8uIFRoZSBIb21lIEFnZW50IGZpZWxkIHdpbGwgYmUgYXNzaWduZWQgdG8gdGhl IElQIGFkZHJlc3Mgb2YgdGhlDQogICBQRFNOIGFuZCB0aGUgQ2FyZS1vZiBBZGRyZXNzIGZpZWxk IHdpbGwgYmUgYXNzaWduZWQgdG8gdGhlIElQDQogICBhZGRyZXNzIG9mIFJOTi4NCkFjY29yZGlu ZyB0byBBMTEgaW50ZXJmYWNlIG9mIElPUyA0IG9mIENETUEyMDAwIHNwZWNpZmljYXRpb24sIHdl IHVzZSBVRFAgaW5zdGVhZCBvZiBHUkUgdG8gZXN0YWJsaXNoIHRoZSBSLVAgY29ubmVjdGlvbiBi ZXR3ZWVuIEJTQy9QQ0YgYW5kIFBEU04uDQoNClRvdmV5IEppYW5nDQoyMDAwLjYuMTANCg== ------=_NextPart_000_0010_01BFD2C5.F58222C0 Content-Type: text/plain; name="draft-ietf-mobileip-3gwireless-ext-03.txt" Content-Disposition: attachment; filename="draft-ietf-mobileip-3gwireless-ext-03.txt" Content-Transfer-Encoding: quoted-printable Mobile IP Working Group Yingchun Xu (editor) Internet Draft Rajesh Bhalla March 2000 Ed Campbell Karl Freter 3Com Corporation Eileen McGrath Hadwen Alcatel Gopal Dommety Kirit Joshi Cisco Systems Parviz Yegani Ericson Wireless Communication Inc. Takeo Matsumura FUJITSU Atsushi Teshima HITACHI Ltd. Lee Dong Hyun HYUNDAI Electronics Naoto Itoh IDO Corporation Kimihiro Ohki KDD Corporation Byung-Keun Lim LG Information & Communications, Ltd Peter J. McCann Thomas Towle Lucent Technologies Jay Jayapalan Motorola Inc. Peter W. Wenzel Carey B. Becker James Jiang Nortel Networks Shota Shikano Oki Electric Industry Co.,Ltd. Woojune Kim Yong Chang Samsung Electronics Ltd. Jun Mo Koo SK Telecom Bill Semper Samsung Telecommunications Mark A. Lipford Frederic Leroudier Sprint PCS Jim Gately USWest Advanced Technologies Mobile IP Based Micro Mobility Management Protocol in The Third Generation Wireless Network Xu et al. Expires September 2000 1 =0C Internet Draft 3G Wireless March 2000 Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at anytime. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines extensions to the Mobile IP protocol [1] to allow mobility management for the interface between a radio network and a packet data network in the third generation cdma2000 network. Mobile IP requires link layer connectivity between the Mobile Node and the Foreign Agent. This draft proposes a protocol for achieving this when the physical layer terminates at a point distant from the FA. In particular, this protocol applies to cdma2000 networks where the physical layer terminates at a Radio Network Node (RNN) and the FA resides inside a separate Packet Data Serving Node (PDSN). The PDSN is responsible for establishing, maintaining, and terminating the link layer to the Mobile Node. A RNN is responsible for relaying the link layer protocol between a Mobile Node and its corresponding PDSN. The interface between the RNN and the PDSN is called the RP interface. This interface requires mobility management for handling handoff from one RNN to another without interrupting end to end communication. It also requires the support of the link layer protocol encapsulation. 1. Introduction This document defines extensions to the Mobile IP protocol [1] to allow mobility management for the interface between a radio network and a packet data network in the third generation cdma2000 network. Mobile IP requires link layer connectivity between the Mobile Node and the Foreign Agent. This draft proposes a protocol for achieving this when the physical layer terminates at a point distant from the Xu et al. Expires September 2000 2 =0C Internet Draft 3G Wireless March 2000 FA. In particular, this protocol applies to cdma2000 networks where the physical layer terminates at a Radio Network Node (RNN) and the FA resides inside a separate Packet Data Serving Node (PDSN). The PDSN is responsible for establishing, maintaining, and terminating the link layer to the Mobile Node. A RNN is responsible for relaying the link layer protocol between a Mobile Node and its corresponding PDSN. The interface between the RNN and the PDSN is called the RP interface. This interface requires mobility management for handling handoff from one RNN to another without interrupting end to end communication. It also requires the support of the link layer protocol encapsulation. The messages used for mobility management across the RP interface include Registration Request, Registration Reply, Registration Update and Registration Acknowledge. These messages MUST be sent with UDP using well-known port number 451. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 2. Glossary CDMA Code Division Multiple Access FA Foreign Agent HA Home Agent MN Mobile Node PDSN Packet Data Serving Node RNN Radio Network Node RP Interface between the RNN and the PDSN 3. cdma2000 Network RP Interface Overview The high level architecture of a third generation cdma2000 network RP interface is shown in Figure 1. +---------+ +---------+ +---------+ | | | | | | | RNN |----RP------| PDSN |---------| HA | | | Interface | | | | +---------+ +---------+ +---------+ /|\ | Visited Access Home Network | Provider Network | | \|/ +--------+ | Mobile | | Node | Xu et al. Expires September 2000 3 =0C Internet Draft 3G Wireless March 2000 +--------+ Figure 1: The Third Generation cdma2000 Network RP Interface In above figure 1, the PDSN will be responsible for establishing, maintaining, and terminating the link layer to the Mobile Node. It initiates the authentication, authorization, and accounting for the Mobile Node and optionally, securely tunnels to the Home Agent. The RNN is responsible for mapping the Mobile Node identifier reference to a unique link layer identifier used to communicate with the PDSN. RNN validates the Mobile Station for access service and manages the physical layer connection to the Mobile Node. 4. Mobile IP Extensions This section describes extensions to the Mobile IP protocol for the RP interface within the third generation cdma2000 network. 4.1 Registration Request In a cdma2000 network, the mobile node initiates a connection by sending a call setup indication to the RNN across the radio network. When this indication is received by a RNN, a Registration Request will be sent from the RNN to the PDSN to setup a new RP session. A RNN MUST send a Registration Request with the GRE encapsulation and the reverse tunneling bit set. The Home Address field is set to zero. The Home Agent field will be assigned to the IP address of the PDSN and the Care-of Address field will be assigned to the IP address of RNN. When a Registration Request is received by a PDSN, the information from the Session Specific Extension (see next section) will be used to identify a RP session. When a registration is accepted, a GRE tunnel will be created for this Mobile Node. The message is sent with UDP using well-known port number 451. The fields of the Registration Request message are shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |S|B|D|M|G|V|T| | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Xu et al. Expires September 2000 4 =0C Internet Draft 3G Wireless March 2000 | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type 1 (Registration Request) G This bit MUST be set to 1 for GRE tunneling. T This bit MUST be set to 1 for reverse tunneling. Home Address The field is set to zero. Home Agent This field is assigned to the IP address of the PDSN. Care-of Address This field is assigned to the IP address of RNN. Extensions The Session Specific Extension as described in the next section MUST be included along with the ones described in RFC2002. Specifically, the MN-HA Authentication extension as described in RFC2002 MUST be included along with this extension. 4.2 Session Specific Extension This extension is defined to carry information related to the session between a Mobile Node and its serving PDSN. The detailed format of the extension is shown 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 | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | MN Connection ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN ID Type | MN ID Length | MN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN ID =E0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Xu et al. Expires September 2000 5 =0C Internet Draft 3G Wireless March 2000 Type 39 (not-skippable). Length This is a one octet field and it indicates the length (in bytes) of the extension, NOT including the Type and Length fields. Protocol Type This is a two octet field. It indicates the type of the protocol to be tunneled across the RP interface. It is same as the Protocol Type field in the GRE header. Key This is a four octet value assigned by the RNN and inserted in every GRE frame across the RP interface during user data tunneling. Reserved This is a two octet field. It is not used and is set to zero. MN Connection ID This is a two octet field and it is used to differentiate the multiple sessions from the same Mobile Node. It is locally unique to a Mobile Node. MN ID Type This is a two octet field and it indicates the type of the following Mobile Node ID value. Type value 1 will be reserved for International Mobile Station Identity (IMSI) encoded in ASCII format. For detailed description of the IMSI, see reference [8]. MN ID Length This is a one octet field and it indicates the length (in bytes) of the following Mobile Node ID field. For IMSI MN ID encoded in ASCII format, the length field value ranges from 10 to 15 bytes. MN ID This is the Mobile Node ID, which is globally unique. It is used to uniquely identify a Mobile Node. For Type 1 MN ID, the most significant digit of IMSI will be coded in ASCII and stored as the most significant byte of the MN ID. Xu et al. Expires September 2000 6 =0C Internet Draft 3G Wireless March 2000 This extension MUST be included in the Registration Request, Registration Reply, Registration Update and Registration Acknowledge (see section 4.5) messages. It will be included before the MN-HA Authentication extension in the Registration Request and Registration Reply messages and before the Registration Update Authentication Extension in the Registration Update and Registration Acknowledge messages. The MN ID and the MN Connection ID together will uniquely identify a Mobile Session. 4.3 Registration Reply The Registration Reply will be sent by a PDSN following the procedure as described in [1]. The Home Address field will be the same value as the Home Address field from the corresponding Registration Request message received by the PDSN. The message is sent with UDP using well-known port number 451. 4.4 Registration Update/Acknowledge Two new messages are defined to support PDSN initiated RP tunnel tear down and to speed up resource reclamation on the RNN. The Registration Update message is used for notification of the change of the registration associated with a call. It shall be sent by the PDSN to the previous RNN when a RNN to RNN handoff happens. Both messages are sent with UDP using well-known port number 451. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- The format of the Registration Update message is illustrated above, and contains the following fields: Type 20 Reserved Sent as 0; ignored on reception. Xu et al. Expires September 2000 7 =0C Internet Draft 3G Wireless March 2000 Home Address Sent as 0; =20 Home Agent Address The IP Address of the PDSN. Identification A 64-bit number assigned by the node sending the Registration Update message. It is used to assist in matching requests with replies, and in protecting against replay attacks. Extensions Both Registration Update Authentication Extension (see section 4.6) and Session Specific Extension (see section 4.2) SHALL be included. A Registration Update shall be sent by a PDSN to indicate the closure of a RP session. The RNN may reclaim the resource associated with that session. A Registration Acknowledge message is used to acknowledge receipt of a Registration Update message. It MUST be sent by a node receiving a Registration Update message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care Of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- The format of the Registration Acknowledge message is illustrated above, and contains the following fields: Type 21 Status If the Status is nonzero, this acknowledgment is negative. Reserved Sent as 0; ignored on reception. Xu et al. Expires September 2000 8 =0C Internet Draft 3G Wireless March 2000 Home Address Copied from the Registration Update message being acknowledged. Care of Address The IP address of the RNN. Identification Copied from the Registration Update message being acknowledged. Extensions Both Registration Update Authentication Extension (see section 4.6) and Session Specific Extension (see section 4.2) SHALL be included. Allowable values for the Status include: 0 successful acknowledgement 128 reason unspecified 129 administratively prohibited 131 sending node failed authentication 133 identification mismatch 134 poorly formed Registration Update 4.5 Registration Update Authentication Extension The Registration Update Authentication extension is used to authenticate the Registration Update and Registration Acknowledge messages. It has the same format and default algorithm support requirements as the authentication extension defined for Mobile IP protocol [1], but with a different type (40). The authenticator value is computed from the stream of bytes including the shared secret, the UDP payload all prior extensions in their entirety, and the type and length of this extension, but not including the authenticator field itself nor the UDP header. The secret used for computing the authenticator field is shared between the RN and PDSN. This extension is required in both Registration Update and Registration Acknowledge messages. 4.6 Summary The extensions to Mobile IP include enabling the GRE encapsulation and reverse tunneling during Registration. A new extension called Session Specific Extension is defined and is mandatory in the Registration Request, Registration Reply, Registration Update and Registration Acknowledge messages. The Home Address field MUST be set to zero in the Registration Request, Registration Reply, Registration Update and Registration Acknowledge messages. Xu et al. Expires September 2000 9 =0C Internet Draft 3G Wireless March 2000 Two new messages (Registration Update and Registration Acknowledge) are defined to support the RP session disconnection in order to speed up resource reclamation. 5.0 GRE Encapsulation GRE encapsulation as described in [3] shall be supported during user data transmission. A new protocol type might be required to support the link layer protocol defined for the third generation cdma2000 network. The Key field shall be required and its value shall be same as the one from the Session Specific Extension as described above. The sequence number may be required, depending on the requirement of the protocol encapsulated within the GRE frame. During traffic tunneling, the sender will insert the Key value from the Registration Request message into the Key field of the GRE header. The receiver will use the Key value from the GRE header to decide where to forward the user data. 6.0 IANA Considerations This document specifies two new messages and two new extensions to Mobile IP protocol [1]. The numbers to be assigned to these messages and extensions have been taken from the numbering space assigned to Mobile IP in RFC 2002 [1] and extended in RFC 2356 [4]. The Registration Request, Registration Reply, Registration Update and Registration Acknowledge messages MUST be sent with UDP using well-known port number 451. This port number is chosen from the unassigned port range as specified in RFC1700 [9]. The Registration Update and Registration Acknowledge messages defined in section 4.4 MUST be assigned the Type values of 20 and 21 respectively. The Session Specific Extension defined in section 4.2 MUST be assigned the Type value of 39, and the Registration Update Authentication Extension defined in section 4.5 MUST be assigned a value of 40. The Status values defined in section 4.4 are the error codes defined in RFC 2002 [1]. They correspond to the error values conventionally associated with a rejection by a home agent (i.e., the values from the range 128-255). The IANA MUST record the Status values as defined in section 4.4 of this document. With these assignments, the Type values assigned to the two new messages and to two new extensions, and the error values for the Status field, have been identified as not conflicting with any numbers defined for Mobile IP to date and documented at http://www.isi.edu/in-notes/iana/assignments/mobileip-numbers. 7.0 Security Considerations Xu et al. Expires September 2000 10 =0C Internet Draft 3G Wireless March 2000 The protocol presented in this draft is designed for use over a protected, private network between RNN and PDSN. Pre-arranged security associations in the style of Mobile IPv4 are assumed to exist among every (RNN, PDSN) pair that will form an RP connection. Also, it is assumed that the session specific information is authenticated by means outside the scope of this draft. Several potential vulnerabilities exist if these assumptions are not met. First, if the network connecting the RNN and PDSN is accessible to an attacker, user traffic may be intercepted and/or spoofed if there are no other end-to-end security mechanisms in place. Second, the Mobile IP control messages must be authenticated, to prevent tunnel setup and tear down by unauthorized parties. Mobile IP Authentication Extensions are used to provide this additional protection for control messages. Finally, if session specific information is not authenticated, a denial-of-service attack is possible if a RNN unknowingly sends a registration request to the PDSN with a spoofed session specific extension. The PDSN would then send an explicit tunnel tear down to the previous RNN, causing user traffic to be misdirected to the new RNN. This would cause a loss of service and possibly interception of traffic, depending on what other security measures are in place. 8.0 Acknowledgments The authors of this draft would like to thank Charles E. Perkins and David B. Johnson for the ideas presented in the Route Optimization draft [7]. References [1] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October 1996. [2] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC2344, May 1998. [3] Hanks, S., Li, R., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [4] G. Montenegro and V. Gupta. "Sun's SKIP Firewall Traversal for Mobile IP". RFC 2356, June 1998. [5] Pat R. Calhoun and Charles E. Perkins. "Mobile IP Network Address Identifier Extension". draft-ietf-mobileip-mn-nai- 05.txt, October 1999. (work in progress). [6] Charles E. Perkins and Pat R. Calhoun. "Mobile IP Challenge/ Response Extensions". draft-ietf-mobileip-challenge-06.txt, October 1999. (work in progress). Xu et al. Expires September 2000 11 =0C Internet Draft 3G Wireless March 2000 [7] Charles E. Perkins and David B. Johnson. "Route Optimization in Mobile IP". draft-ietf-mobileip-optim-08.txt, February 1999. (work in progress). [8] TIA/EIA/IS-95-B [9] J. Reynolds and J. Postel. =F4ASSIGNED NUMBERS=F6. RFC1700, = October 1994. Authors=C6 Addresses Yingchun Xu 3Com Corporation 1800 West Central Road Mount Prospect, USA 60056 Phone: (847) 342-6814 Email: Yingchun_Xu@3com.com Rajesh Bhalla 3Com Corporation 1800 West Central Road Mount Prospect, USA 60056 Phone: (847) 797-2618 Email: rajesh_bhalla@3com.com Karl Freter 3Com Corporation 1800 W. Central Road Mount Prospect, IL 60056 Phone: (847) 222-2268 Email: karl_freter@3com.com Ed Campbell 3Com Corporation Xu et al. Expires September 2000 12 =0C Internet Draft 3G Wireless March 2000 1800 W. Central Road Mount Prospect, IL 60056 Phone:(847) 342-6769 Email: ed_campbell@3com.com Eileen McGrath Hadwen Alcatel PO Box 4442, Boulder CO 80306 Phone: 303 499 1496 Email: mcgrath.hadwen@worldnet.att.net Gopal Dommety Cisco Systems 170 West Tasman Drive San Jose, CA 95134 Phone: (408) 525-1404 Email: gdommety@cisco.com Kirit Joshi Cisco Systems 170 West Tasman Drive San Jose, CA 95134 Phone: (408) 525 7367 Email: kjoshi@cisco.com Parviz Yegani Ericson Wireless Communication Inc. 6455 Lusk Blvd. San Diego, CA 92121 Phone: (858) 332-6017 Email: p.yeqani@ericsson.com Takeo Matsumura FUJITSU Kamiodanaka Nakahara-ku, Kawasaki-City Phone: +81-44-740-8109 Email: matumura@mcs.ts.fujitsu.co.jp Atsushi Teshima HITACHI Ltd. 216 Totsuka-cho, Totsuka-ku, Yokohama Japan 244-8567 Phone:+81-45-865-7003 Email: atsushi_teshima@cm.tcd.hitachi.co.jp Lee Dong Hyun HYUNDAI Electronics Industry KOREA Kyungkido Icheonsi 435-050 Phone: 82-336-630-2756 Email: jihs@hei.co.kr Naoto Itoh Xu et al. Expires September 2000 13 =0C Internet Draft 3G Wireless March 2000 IDO Corporation Gobancho YS building 12-3 Gobancho, Chiyoda-ku, Tokyo Japan 102-8361 Phone: +81-3-3263-9660 Email: nao-itoh@ido.co.jp Kimihiro Ohki KDD Corporation 3-2, Nishi-Shinjuku 2-chome, Shinjuku-ku, Tokyo 163-8003, Japan Phone: +81-3-3347-5477 Email: ki-ohki@kdd.co.jp Byung-Keun Lim, LG Information & Communications, Ltd. 533, Hogye-dong, Dongan-ku, Anyang-shi, Kyungki-do,431-080, Korea Phone: +82-343-450-7199 Email: bklim@lgic.co.kr Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566 Phone: (630) 713 9359 EMail: mccap@lucent.com Thomas Towle Lucent Technologies Rm. 2D-225 263 Shuman Blvd Naperville, IL 60566 Phone: 630-979-7303 Email: ttowle@lucent.com Jay Jayapalan Motorola Inc.=20 1501 W Shure Drive Arlington Heights,IL 60004 Phone: (847) 642-4031 Email: jayapal@cig.mot.com Peter W. Wenzel Nortel Networks 2201 Lakeside Blvd. Richardson, TX 75082, USA Phone: (972) 684-7134 Email: wenzel@nortelnetworks.com Carey B. Becker Nortel Networks 2201 Lakeside Blvd. Xu et al. Expires September 2000 14 =0C Internet Draft 3G Wireless March 2000 Richardson, TX 75082, USA Phone: (972) 685-0560 Email: becker@nortelnetworks.com James Jiang Nortel Networks 2201 Lakeside Blvd. Richardson, TX 75082, USA Phone: (972)684-5885 Email: jjiang@nortelnetworks.com Shota Shikano Oki Electric Industry Co., Ltd. Phone:+81-3-3454-2111 Email: shikano471@oki.co.jp Woojune Kim Samsung Electronics Ltd. 11th Fl, Samsung Plaza Bldg, 263, Seohyeon-dong, Pundang-gu, Sungnam-shi, Kyunggi-do, 463-050 Pundang P.O. Box 32, Korea Phone: +82-342-779-8526 Email: keg@telecom.samsung.co.kr Yong Chang Samsung Electronics Ltd. 11th Fl, Samsung Plaza Bldg, 263, Seohyeon-dong, Pundang-gu, Sungnam-shi, Kyunggi-do, 463-050 Pundang P.O. Box 32, Korea Phone: +82-342-779-6822 Email : yong@telecom.samsung.co.kr Bill Semper Samsung Telecommunications 1130 Arapaho Rd Richardson, TX 75082 Phone: 972-761-7996 Email: bsemper@telecom.samsung.com Jun Mo Koo SK Telecom Phone: 650-568-5762 Email: jmkoo@sktelecom.com Mark A. Lipford Sprint PCS 8001 College Blvd. Suite 210 KSOPKZ0101 Overland Park, KS 66210 Phone: 913-664-8335 Email: Mlipfo01@sprintspectrum.com Xu et al. Expires September 2000 15 =0C Internet Draft 3G Wireless March 2000 Frederic Leroudier Sprint PCS 8001 College Blvd. Suite 210 KSOPKZ0101 Overland Park, KS 66210 Phone: 913-664-8350 Email: FLerou01@sprintspectrum.com Jim Gately USWest Advanced Technologies 4001 Discovery Drive Boulder, CO 80303 Phone: 303-541-6415 Email: jgately@uswest.com Xu et al. Expires September 2000 16 =0C ------=_NextPart_000_0010_01BFD2C5.F58222C0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jun 10 09:00:57 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08346 for ; Sat, 10 Jun 2000 09:00:57 -0400 (EDT) Received: from standards (47.234.32.16:1898) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB749B7@standards.nortelnetworks.com>; Sat, 10 Jun 2000 8:51:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1948 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 10 Jun 2000 08:51:35 -0400 Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB749B6@standards.nortelnetworks.com>; Sat, 10 Jun 2000 8:51:35 -0400 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.69.63.148]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA25755; Sat, 10 Jun 2000 06:00:14 -0700 (PDT) Received: (fred@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA00384; Sat, 10 Jun 2000 06:00:05 -0700 (PDT) Message-ID: <200006101300.GAA00384@irp-view7.cisco.com> Date: Sat, 10 Jun 2000 06:00:05 -0700 Reply-To: fred@CISCO.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: fred@CISCO.COM Subject: [MOBILE-IP] draft-glass-mobileip-agent-dhcp-proxy-00.txt X-To: QA3445@email.mot.com, Raj.Patil@nokia.com, Steven.Glass@sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I notice that you recently posted a new internet draft. A document that might be worth reading is http://www.ietf.org/ID-nits.html This document was put together by members of the IESG to help the community know what are the most common problems that we see in documents, whether from working groups or individual submissions, and pro-actively avoid them. This is an automatic email; please don't conclude that I have discovered something awful about your draft, as I haven't even read it yet. Rather, I'm just letting you know that there is a list of common issues that get raised over and over again in IESG reviews, and I'd like to save you the hassle by letting you see for yourself whether any of them apply. Let me know if you have any questions I can answer. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jun 10 19:56:57 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11370 for ; Sat, 10 Jun 2000 19:56:56 -0400 (EDT) Received: from standards (47.234.32.16:3760) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74A55@standards.nortelnetworks.com>; Sat, 10 Jun 2000 19:47:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2158 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 10 Jun 2000 19:47:45 -0400 Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74A54@standards.nortelnetworks.com>; Sat, 10 Jun 2000 19:47:44 -0400 Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA21538; Sat, 10 Jun 2000 16:56:29 -0700 (PDT) Received: from rabhalla-nt-l ([10.19.210.58]) by airborne.cisco.com (Mirapoint) with SMTP id ABD09633; Sat, 10 Jun 2000 16:56:19 -0700 (PDT) X-Sender: rabhalla@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <200006102356.ABD09633@airborne.cisco.com> Date: Sat, 10 Jun 2000 16:57:40 -0700 Reply-To: Rajesh Bhalla Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Rajesh Bhalla Subject: Re: [MOBILE-IP] draft-ietf-mobileip-3gwireless-ext-03.txt X-To: tovey To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <001201bfd282$e7a20640$c7320b0a@huawei.com.cn> Tovey, Reference to the setting of 'G' and 'T' bits of RRQ in section 4.1 of the draft conforms to the requirements for GRE tunneling and reverse tunneling over the RP connection (IOS 4 CDMA2000 model). Transport for RRQ is UDP, as you mentioned. Setting of 'G' and 'T' bits ensure that (1) reverse tunnelling is enabled between the FA(RNC) and the HA(PDSN) and (2) that GRE is used for tunneling over the RP connection. >> Rajesh << At 10:23 AM 6/10/00 +0800, tovey wrote: >Hi, everyone > > In this internet-draft , there maybe some problem in section 4.1, as following: > A RNN MUST send a Registration Request with the GRE encapsulation* > and the reverse tunneling bit set. The Home Address field is set to > zero. The Home Agent field will be assigned to the IP address of the > PDSN and the Care-of Address field will be assigned to the IP > address of RNN. >According to A11 interface of IOS 4 of CDMA2000 specification, we use UDP instead of GRE to establish the R-P connection between BSC/PCF and PDSN. > >Tovey Jiang >2000.6.10 > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jun 11 16:02:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09288 for ; Sun, 11 Jun 2000 16:02:24 -0400 (EDT) Received: from standards (47.234.32.16:4790) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74C0C@standards.nortelnetworks.com>; 11 Jun 2000 15:52:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2763 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 11 Jun 2000 15:52:40 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74C0A@standards.nortelnetworks.com>; 11 Jun 2000 15:42:36 -0400 Received: from cse.uta.edu (cse.uta.edu [129.107.12.1]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id OAA15146 for ; Sun, 11 Jun 2000 14:51:09 -0500 (CDT) Received: from cse.uta.edu (IDENT:ramesh@[129.107.100.27]) by cse.uta.edu (8.9.0/8.9.0) with ESMTP id OAA06637; Sun, 11 Jun 2000 14:51:25 -0500 (CDT) X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3943A86B.521A267@cse.uta.edu> Date: Sun, 11 Jun 2000 09:55:39 -0500 Reply-To: ramesh@cse.uta.edu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ramesh Yerraballi Organization: UTA Computer Science and Engineering Subject: [MOBILE-IP] WoWMoM 2000: Call for Participation X-To: sigmobile@acm.org To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, This is an invitation to participate in this year's Wokshop on Wireless Mobile Multimedia to be held in conjunction with MobiCom-2000. The technical program and registration info. are below. My apologies if you receive multiple copies of this mail Ramesh Yerraballi ----------------------------------- Dr. Ramesh Yerraballi Assistant Professor, Dept. of CSE Univ. of Texas at Arlington e-mail: ramesh@cse.uta.edu ----------------------------------- --------------------------------------------------------------------- CALL FOR PARTICIPATION WoWMoM-2000 The Third ACM International Workshop on Wireless Mobile Multimedia (in conjunction with MobiCom-2000) August 11, 2000 (Friday) Seaport Hotel at the World Trade Center, Boston, Massachusetts, USA Sponsors: * ACM SigMobile * Nortel Networks * The University of California at Riverside * DIMACS - The Center for Discrete Mathematics & Theoretical Computer Science * CReWMaN at the University of Texas at Arlington --------------------------------------------------------------------- For uptodate technical program, registration information, and hotel information for the WoWMoM workshop are now available at http://www-cse.uta.edu/crewman/conferences/wowmom-2000/ If you are unable to access the above web page, please send e-mail to ramesh@cse.uta.edu -------------------------------------------------------------------------- WoWMoM 2000 Technical Program -------------------------------------------------------------------------- Welcome Address (8:00 am - 8:30 am) -------------------------------------------------------------------------- Session I ( 8:30 am - 10:00 am) Wireless QoS: Admission and Call Control * W2F2Q: Packet Fair Queuing in Wireless Packet Networks Yung Yi, Yongho Seok, Taekyoung Kwon and Yanghee Choi Seoul National University * A Wireless Fair Scheduling Algorithm for Error'Prone Wireless Channels Peng Lin, B. Bensaou, Q. L. Ding, and K.C. Chua National University of Singapore * A Novel Distributed Call Admission Control for Wireless Mobile Multimedia Networks Youssef Iraqi , University of Montreal Raouf Boutaba, University of Waterloo, Canada * Real-time Prioritized Call Admission Control in a Base Station Scheduler Jay R. Moorma, John W. Lockwood and Sung Mo Kang University of Illinois and Washington University, St. Louis -------------------------------------------------------------------------- Coffee Break (10:00 am - 10:30 am) -------------------------------------------------------------------------- Session II (10:30 am - 12:00 noon) Wireless Mobility: Support and Performance Analysis * An Integrated Mobility and Traffic Model for Resource Allocation in Wireless Networks Hisashi Kobayashi, Shum-Zheng Yu and Brian L. Mark Princeton University and George Mason University * Mobility Modeling of Rush Hour Traffic for Location Design Area in Cellular Networks Apurva Kumer, IBM - India Research Lab. M. N. Umesh, Silicon Automation Systems, India Rajesh Jha, Lucent Technologies, NJ * Multicast Support for Mobile IP with the Hierarchical Local Registration Approach H. Omar, T. Saadawi and M. Lee The City University of New York * Performance Evaluation of ATM/AAL2 as switching technology in 3G Mobile Access Networks Oscar Mezquita Baeza, GMD Fokus GmbH Berlin, Germany Enrico Scarrone, CSELT Turin, Italy -------------------------------------------------------------------------- Lunch Break (12:00 noon - 1:30 pm) -------------------------------------------------------------------------- Session III (1:30 pm - 3:00 pm) Resource Management in Mobile Systems * Managing the Storage and Battery Resources in an Image Capture Device (Digital Camera) using Dynamic Transcoding Surendar Chandra, Carla Schlatter Ellis and Amin Vahdat Duke University * Performance Modelling of Speculative Prefetching for Compound Requests in Low Bandwidth Networks N.J. Tuah, M. Kumar and S. Venkatesh Curtin University of Technology, Australia * A Modified CDMA/PRMA Medium Access Control Protocol for Integrated Services in LEO Satellite Systems Abbas Ibrahim and Samie Tohme Ecole Nationale Superieure des Telecommunications, Paris, France * Delay Jitter Performance of Video Traffic in a Cellular Wireless ATM Network T.C. Wong, J. W. Mark and K. C. Chua National University of Singapore and University of Waterloo, Canada -------------------------------------------------------------------------- Coffee Break (3:00 pm - 3:30 pm) -------------------------------------------------------------------------- Session IV (3:30 pm - 5:00 pm) Panel -- TBD -------------------------------------------------------------------------- END OF PROGRAM From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 12 04:25:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26905 for ; Mon, 12 Jun 2000 04:25:14 -0400 (EDT) Received: from standards (47.234.32.16:1982) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74D0E@standards.nortelnetworks.com>; Mon, 12 Jun 2000 4:15:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3089 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 12 Jun 2000 04:15:55 -0400 Received: from shuttle.wide.toshiba.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74D09@standards.nortelnetworks.com>; Mon, 12 Jun 2000 4:05:53 -0400 Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id RAA12085; Mon, 12 Jun 2000 17:01:12 +0900 (JST) References: <3940981E.FC64AD7C@bull.net> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 19 Message-ID: Date: Mon, 12 Jun 2000 17:10:50 +0900 Reply-To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. Subject: Re: [MOBILE-IP] a comment of draft-ietf-mobileip-ipv6-12.txt X-To: Aime.Le-Rouzic@bull.net X-cc: ipng@sunroof.eng.sun.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: In your message of "Fri, 09 Jun 2000 09:09:18 +0200" <3940981E.FC64AD7C@bull.net> >>>>> On Fri, 09 Jun 2000 09:09:18 +0200, >>>>> AIme Le-Rouzic said: > In fact, the Home Address has to be also BEFORE the fragment header to > allow firewalls to read it. Those firewalls > can be on other destinations than those listed in the Routing Header. > May be it needs to clarify to put a recommendation in RFC2460 or > in the next RFC MobileIPv6 this special case. Hmm, in any case, I hope the mobile IPv6 specification clarifies the ordering as long as it dares to break the recommendation in RFC2460 (which is already a draft-standard RFC), before the spec proceeds to an RFC status. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 12 11:57:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05073 for ; Mon, 12 Jun 2000 11:57:29 -0400 (EDT) Received: from standards (47.234.32.16:2111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74E72@standards.nortelnetworks.com>; Mon, 12 Jun 2000 11:48:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3575 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 12 Jun 2000 11:48:15 -0400 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74E71@standards.nortelnetworks.com>; Mon, 12 Jun 2000 11:48:14 -0400 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id SAA08782 for ; Mon, 12 Jun 2000 18:56:54 +0300 (EETDST) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id SAA29498 for ; Mon, 12 Jun 2000 18:56:52 +0300 (EETDST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Mon, 12 Jun 2000 10:56:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2BCD50F4@daeis07nok> Date: Mon, 12 Jun 2000 10:54:45 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: [MOBILE-IP] IETF48 - Timeslot requests To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, If you would like a timeslot for presenting to the Mobile IP WG at IETF48 (30 July - 4 August 2000), please send me or Phil a note including the following details by July 23rd, 2000: 1. Title of presentation and how this is related to the Mobile IP WG 2. Associated I-D (if applicable) 3. Amount of time requested -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 13 02:10:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29764 for ; Tue, 13 Jun 2000 02:10:27 -0400 (EDT) Received: from standards (47.234.32.16:3648) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74FC7@standards.nortelnetworks.com>; Tue, 13 Jun 2000 2:00:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4014 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 02:00:49 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB74FC6@standards.nortelnetworks.com>; Tue, 13 Jun 2000 1:50:48 -0400 Received: from uci.agh.edu.pl (root@galaxy.uci.agh.edu.pl [149.156.96.9]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id AAA24528 for ; Tue, 13 Jun 2000 00:59:25 -0500 (CDT) Received: from saturn.kt.agh.edu.pl (proms@saturn.kt.agh.edu.pl [149.156.114.3]) by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with SMTP id HAA18400 for ; Tue, 13 Jun 2000 07:59:13 +0200 (MET DST) Received: by saturn.kt.agh.edu.pl (AIX 3.2/UCB 5.64/5.1) for mobile-ip@smallworks.com id AA49030; Tue, 13 Jun 2000 07:58:21 +0200 Address: Mickiewicza 30, 30-059 Krakow, POLAND Message-ID: <10006130558.AA49030@saturn.kt.agh.edu.pl> Date: Tue, 13 Jun 2000 07:58:21 +0200 Reply-To: Piotr Pacyna Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Piotr Pacyna Organization: University of Mining and Metallurgy Subject: [MOBILE-IP] PROMS2000 - last Call for Papers X-To: mobile-ip@smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear Sir, Dear Madam, Please find enclosed the Protocols for Multimedia Systems conference CfP. We do apologise if you receive multiple copies of this. Thank you for your attention. With best regards, Piotr Pacyna OC Chair ++++++++++++++++++++++++++++++++++++++++++++++++++++++ (We do apologize, if you receive multiple copies of this CfP) Announcement and Call for Papers PROTOCOLS FOR MULTIMEDIA SYSTEMS - PROMS2000 Cracow, Poland, October 22-25, 2000 Sponsored by IEEE Poland Sect. and Cracow Communications Soc. Chap. Lucent Technologies, ZWUT a Siemens Company, http://PROMS2000.kt.agh.edu.pl/ After past successful PROMS conferences held in Berlin, Salzburg, Madrid, and Santiago de Chile now we cordially invite you to Cracow/Poland, a lovely university city, with a 1000 year history, today one of cultural capitals of Europe. Emerging broadband interactive applications along with a development of different networking technologies should draw telecom operators' and service providers' attention to protocols supporting multimedia systems as an interface between these two environments that has to be still investigated and modified. The PROMS2000 conference is intended to contribute to a scientific, strategical and practical cooperation between research institutes and industrial companies in the area of distributed multimedia applications, protocols, and intelligent management tools, with emphasis on their provision over broadband networks. PROMS2000 will cover papers and demonstrations on research and achievements related to the following topics: TOPICS * design and implementation of multimedia protocols for public switched telephony networks, mobile networks, data networks, and satellite networks using IP, ATM or other connectivity techniques; * application, media, and protocol integration: synchronization of media streams; * multiparty and group communication protocols; * mobile networking and routing: multimedia communication architectures for mobile networks; * multimedia applications: video-on-demand, digital video libraries, video games, virtual community, teleworking, teleteaching, e-commerce, telemeeting, virtual reality simulations; * content based searching and querying; * techniques for the specification of communication services required by multimedia applications; * methods for real-time testing and analysis of service implementations; * integration of media storage and communication mechanisms, operating system and high-performance issues; * experiences with service provisioning using distributed multimedia applications, eg. voice over IP; * performance of protocols, such as TCP, and applications: modeling, simulation and optimization in different networks; * definition, provisioning, and supervision of QoS parameters for networked applications and services, eg. in IntServ/DiffServ networks; * multimedia traffic engineering; * applications and platforms for service management and provisioning; * intelligent management tools pertaining to costs and quality of service, network access, accounting, security, and system resilience; * service access - security, authentication, privacy; * accounting and tariff policing for multimedia teleservices. IMPORTANT DATES * Full papers due June 26, 2000 * Authors notified July 24, 2000 * Full paper camera ready due September 25, 2000 CONFERENCE TIMETABLE * 1st day October 22 full-day sightseeing tour (optional) * 2nd day October 23 tutorials, welcome reception * 3rd day October 24 invited talks, sessions, panel, banquet * 4th day October 25 invited talks, sessions VENUE Its history rooted deep in the Middle Ages, Cracow, is the most celebrated city in Poland. UNESCO has added its architectural complex to the World Heritage List. Cracow's appeal today, however, is no longer attributable solely to the beauty of its medieval architecture, but to its strong scientific potential for applied research and development. The PROMS2000 Conference will be held on the modern premises of the Department of Telecommunications within walking distance of both the downtown area and hotels. Direct flights to Cracow are available to and from Chicago, Copenhagen, New York, Toronto, Frankfurt, London, Paris, Rome, Tel Aviv, Vienna and Zurich. SUBMISSION Submit a full manuscript to the PROMS chair in an electronic form (MSWord, Postscript or pdf file); editorial requirements can be found at http://PROMS2000.kt.agh.edu.pl/. PROCEEDINGS 1. Each participant will receive Proceedings from the conference. 2. Two best papers will be considered for publication in the IEEE Communications Magazine (March 2001 issue) in a feature topic "Protocols for Multimedia Systems". CONFERENCE CHAIR Zdzislaw PAPIR Department of Telecommunications University of Mining and Metallurgy Al. Mickiewicza 30 30-059 Cracow, Poland E-mail: papir@kt.agh.edu.pl Phone: +48 12 634 55 82 Fax: +48 12 634 23 72 PROGRAM COMMITTEE Koichi Asatani, Univ. Kogakuin, asatani@sin.cc.kogakuin.ac.jp William Atwood, Univ. Concordia, Bill@cs.Concordia.ca Arturo Azcorra, Univ. Carlos III de Madrid, azcorra@it.uc3m.es Stanislaw Budkowski, INT-Evry, stan@int-evry.fr Andrew Campbell, Univ. Columbia, campbell@ctr.columbia.edu Michel Diaz, LAAS-CNRS, diaz@laas.fr Wolfgang Effelsberg, Univ. Mannheim, effelsberg@informatik.uni-mannheim.de Paolo Fasano, CSELT, Paolo.Fasano@cselt.it Francisco Fontes, Portugal Telecom, fontes@ptinovacao.pt Nicolas D. Georganas, Univ. Ottawa, georgana@mcrlab.uottawa.ca Per Gunningberg, Univ. Uppsala, Per.Gunningberg@docs.uu.se Ibrahim Habib, Univ. New York Ulrich Hofmann, Univ. Salzburg, ulrich.hofmann@fh-sbg.ac.at David Hutchison, Univ. Lancaster, dh@comp.lancs.ac.uk Yuji Inoue, NTT, yuji@rd.nttdata.co.jp Andrzej Jajszczyk, Univ. Mining and Metallurgy, jajszcz@kt.agh.edu.pl Pedro Lizcano, Telefonica Labs, lizcano@tid.es John C. S. Lui, Chinese Univ. Hong Kong, cslui@cse.cuhk.edu.hk Andrzej R. Pach, Univ. Mining & Metallurgy, pach@kt.agh.edu.pl Sergio Palazzo, Univ. Catania, palazzo@iit.unict.it Thomas Plagemann, Center for Technology, plageman@unik.no Radia Perlman, SUN, radia.perlman@sun.com Radu Popescu-Zeletin, GMD, zeletin@fokus.gmd.de Marten J. van Sinderen, Univ. Twente, sinderen@cs.utwente.nl Kazem Sohraby, Lucent, sohraby@lucent.com Joan I. Solana, Nokia Telecom R & D, juan.solana@nokia.com Eduardo Vera, Univ. of Chile, evera@accessnova.cl Johan Zuidweg, Tecsidel, johan.zuidweg@ieee.org ORGANISING COMMITTEE Chair: Piotr PACYNA, proms@kt.agh.edu.pl K. Juszkiewicz, juszkiew@kt.agh.edu.pl J. Gozdecki, gozdecki@kt.agh.edu.pl J. Roman, roman@kt.agh.edu.pl From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 13 05:39:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01197 for ; Tue, 13 Jun 2000 05:39:02 -0400 (EDT) Received: from standards (47.234.32.16:3813) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75049@standards.nortelnetworks.com>; Tue, 13 Jun 2000 5:29:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4165 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 05:29:41 -0400 Received: from hotmail.com (law2-f17.hotmail.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75048@standards.nortelnetworks.com>; Tue, 13 Jun 2000 5:19:40 -0400 Received: (qmail 26340 invoked by uid 0); 13 Jun 2000 09:28:23 -0000 Received: from 210.228.222.236 by www.hotmail.com with HTTP; Tue, 13 Jun 2000 02:28:23 PDT X-Originating-IP: [210.228.222.236] Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: <20000613092823.26339.qmail@hotmail.com> Date: Tue, 13 Jun 2000 17:28:23 SGT Reply-To: Jonathan Khoo Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jonathan Khoo Subject: [MOBILE-IP] Query To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi there, Is there any archives on the past emails/discussions on Mobile IP? Thanks and have a nice day! Jonathan Khoo ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 13 07:14:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02933 for ; Tue, 13 Jun 2000 07:14:51 -0400 (EDT) Received: from standards (47.234.32.16:2072) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7507F@standards.nortelnetworks.com>; Tue, 13 Jun 2000 7:05:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4227 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 07:05:36 -0400 Received: from bfgbhome.inetint.com (tnt-dal-42-195.dallas.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75078@standards.nortelnetworks.com>; Tue, 13 Jun 2000 6:55:35 -0400 Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id GAA07420; Tue, 13 Jun 2000 06:04:12 -0500 Mail-Followup-To: Jonathan Khoo , MOBILE-IP@STANDARDS.NORTELNETWORKS.COM References: <20000613092823.26339.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i X-Operating-System: Linux bfgbhome 2.2.14-5.0 Precedence: special-delivery X-Sensitivity: Confidential X-Importance: High X-Priority: 1 (highest) Message-ID: <20000613060412.A7324@dallas.net> Date: Tue, 13 Jun 2000 06:04:12 -0500 Reply-To: bidulock@dallas.net Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Brian F. G. Bidulock" Organization: Brian F. G. Bidulock, P. Eng. Subject: Re: [MOBILE-IP] Query X-To: Jonathan Khoo To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <20000613092823.26339.qmail@hotmail.com>; from khoohuit@HOTMAIL.COM on Tue, Jun 13, 2000 at 05:28:23PM +0000 Content-Transfer-Encoding: 8bit Jonathan, The IETF WG mail archives are in: ftp://ftp.ietf.org/ietf-mail-archive/mobileip/ They are also available from the website at: http://www.ietf.org/ Jonathan Khoo wrote: (Tue, 13 Jun 2000 17:28:23) > Hi there, > > Is there any archives on the past emails/discussions on Mobile IP? > > Thanks and have a nice day! > > Jonathan Khoo > > > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@dallas.net ¦ world; the unreasonable one persists in ¦ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ M.O.A.M.O.N.N.T.O.M.E. ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 13 09:10:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06569 for ; Tue, 13 Jun 2000 09:10:37 -0400 (EDT) Received: from standards (47.234.32.16:2535) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75101@standards.nortelnetworks.com>; Tue, 13 Jun 2000 9:01:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4384 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 09:01:16 -0400 Received: from web618.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB750FB@standards.nortelnetworks.com>; Tue, 13 Jun 2000 8:51:15 -0400 Received: from [193.205.242.44] by web618.mail.yahoo.com; Tue, 13 Jun 2000 05:59:59 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <20000613125959.3493.qmail@web618.mail.yahoo.com> Date: Tue, 13 Jun 2000 05:59:59 -0700 Reply-To: =?iso-8859-1?q?rete=20rete?= Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: =?iso-8859-1?q?rete=20rete?= Subject: [MOBILE-IP] Information on handoff To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi, I am studying about mobile IP.So I'd like to know your opinion about the possibility to perform fast hand-off using 802.11 base stations. Is it possible? In particular, is it possible using 802.11 standard protocol to have interworking between L2 and L3 to detect that mobile node could be serviced better by another FA? Thanks in advance, Spillo __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 13 11:06:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10831 for ; Tue, 13 Jun 2000 11:06:59 -0400 (EDT) Received: from standards (47.234.32.16:4495) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB751BB@standards.nortelnetworks.com>; Tue, 13 Jun 2000 10:57:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0202 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 10:57:33 -0400 Received: from hotmail.com (law2-f303.hotmail.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB751BA@standards.nortelnetworks.com>; Tue, 13 Jun 2000 10:57:32 -0400 Received: (qmail 75584 invoked by uid 0); 13 Jun 2000 15:06:16 -0000 Received: from 210.228.222.189 by www.hotmail.com with HTTP; Tue, 13 Jun 2000 08:06:16 PDT X-Originating-IP: [210.228.222.189] Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: <20000613150616.75583.qmail@hotmail.com> Date: Tue, 13 Jun 2000 23:06:16 SGT Reply-To: Jonathan Khoo Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jonathan Khoo Subject: [MOBILE-IP] Deregistration question... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi there, A great thanks for all those who replied my previous mail! :) I was reading the latest draft revision of RFC2002 and I came across the part on the deregistration with HA. It was mentioned in the draft that the HA should transmit gratuitous ARP together with the (de)Registration Reply. The MN must transmit the gratuitous ARP before the HA begins the deregistration process. It was also mentioned later in the draft the if the HA rejects the (de)registration process, then no ARP processing is perform by the HA. Now, please correct me if I am wrong, if the MN sends the ARP packet before the deregistration process and the process fails, isn't there a possibility that some of the packets might be sent to this MN as their ARP tables might be updated with the gratutious ARP sent by the MN earlier? Thanks and have a nice day. Jonathan Khoo ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 13 12:28:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13858 for ; Tue, 13 Jun 2000 12:28:38 -0400 (EDT) Received: from standards (47.234.32.16:4495) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75251@standards.nortelnetworks.com>; Tue, 13 Jun 2000 12:19:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0381 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 12:19:16 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75246@standards.nortelnetworks.com>; Tue, 13 Jun 2000 12:09:16 -0400 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA07769; Tue, 13 Jun 2000 10:17:50 -0600 (MDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA27420; Tue, 13 Jun 2000 12:17:29 -0400 (EDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by atlantic.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id MAA06009; Tue, 13 Jun 2000 12:18:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 13 Jun 2000 12:17:25 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] Deregistration question... X-To: Jonathan Khoo To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <20000613150616.75583.qmail@hotmail.com> > I was reading the latest draft revision of RFC2002 and I came across the > part on the deregistration with HA. > > It was mentioned in the draft that the HA should transmit gratuitous ARP > together with the (de)Registration Reply. The MN must transmit the > gratuitous ARP before the HA begins the deregistration process. > > It was also mentioned later in the draft the if the HA rejects the > (de)registration process, then no ARP processing is perform by the HA. > > Now, please correct me if I am wrong, if the MN sends the ARP packet before > the deregistration process and the process fails, isn't there a possibility > that some of the packets might be sent to this MN as their ARP tables might > be updated with the gratutious ARP sent by the MN earlier? I suppose the ordering of most events is implimentation specific, but... The MN has to begins the deregistration process, as this is based on its move detection. The HA processes the deregistration requests, if it's acceptable, removes the MN's binding, and sends a deregistration reply. The MN processes the deregistration reply, and if it's acceptable, sends its address-claiming gratuitous arp. Yes, there is a non-zero amount of time between being removed from the HA's binding, and reclaiming your address, but that's not really relavent. One of the risks of roaming is not being where your traffic is going, and happens everytime a MN roams, and many drafts specify FA's caching packets, then delivering them to the new CoA upon getting binding updates. To get a clearer picture, try any that deal with fast handoff or route optimization. Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 13 12:50:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14712 for ; Tue, 13 Jun 2000 12:50:09 -0400 (EDT) Received: from standards (47.234.32.16:4495) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75284@standards.nortelnetworks.com>; Tue, 13 Jun 2000 12:40:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0435 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 12:40:51 -0400 Received: from seattle.3com.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75270@standards.nortelnetworks.com>; Tue, 13 Jun 2000 12:30:50 -0400 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id JAA07971 for ; Tue, 13 Jun 2000 09:39:34 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id JAA09282 for ; Tue, 13 Jun 2000 09:39:23 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882568FD.005B6027 ; Tue, 13 Jun 2000 09:38:03 -0700 X-Lotus-FromDomain: 3COM Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <882568FD.005B5C00.00@hqoutbound.ops.3com.com> Date: Tue, 13 Jun 2000 11:39:57 -0500 Reply-To: Umamaheswar_Achari_Kakinada@3COM.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Umamaheswar_Achari_Kakinada@3COM.COM Subject: Re: [MOBILE-IP] Deregistration question... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I think the question was what happens if the deregistration HA fails but the MN would have transmitted the gratuitous ARP before the HA begins the deregistration process. Should the MN send another gratuitous ARP or am I missing something ? Cheers Achari ---------------------- Forwarded by Umamaheswar Achari Kakinada/MW/US/3Com on 06/13/2000 05:44 PM --------------------------- Steven Glass - Solaris Software on 06/13/2000 11:17:25 AM Please respond to Steven Glass - Solaris Software Sent by: Steven Glass - Solaris Software To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM cc: (Umamaheswar Achari Kakinada/MW/US/3Com) Subject: Re: [MOBILE-IP] Deregistration question... > I was reading the latest draft revision of RFC2002 and I came across the > part on the deregistration with HA. > > It was mentioned in the draft that the HA should transmit gratuitous ARP > together with the (de)Registration Reply. The MN must transmit the > gratuitous ARP before the HA begins the deregistration process. > > It was also mentioned later in the draft the if the HA rejects the > (de)registration process, then no ARP processing is perform by the HA. > > Now, please correct me if I am wrong, if the MN sends the ARP packet before > the deregistration process and the process fails, isn't there a possibility > that some of the packets might be sent to this MN as their ARP tables might > be updated with the gratutious ARP sent by the MN earlier? I suppose the ordering of most events is implimentation specific, but... The MN has to begins the deregistration process, as this is based on its move detection. The HA processes the deregistration requests, if it's acceptable, removes the MN's binding, and sends a deregistration reply. The MN processes the deregistration reply, and if it's acceptable, sends its address-claiming gratuitous arp. Yes, there is a non-zero amount of time between being removed from the HA's binding, and reclaiming your address, but that's not really relavent. One of the risks of roaming is not being where your traffic is going, and happens everytime a MN roams, and many drafts specify FA's caching packets, then delivering them to the new CoA upon getting binding updates. To get a clearer picture, try any that deal with fast handoff or route optimization. Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 13 12:57:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14911 for ; Tue, 13 Jun 2000 12:57:03 -0400 (EDT) Received: from standards (47.234.32.16:4495) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB752B3@standards.nortelnetworks.com>; Tue, 13 Jun 2000 12:47:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0524 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 12:47:40 -0400 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB752B2@standards.nortelnetworks.com>; Tue, 13 Jun 2000 12:47:39 -0400 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA04455 for ; Tue, 13 Jun 2000 09:56:22 -0700 (MST)] Received: [from az33exi01.corp.mot.com ([199.2.84.10]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA26372 for ; Tue, 13 Jun 2000 09:56:21 -0700 (MST)] Received: by AZ33EXI01 with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 09:56:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 13 Jun 2000 09:56:15 -0700 Reply-To: Core Scott-P18750 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Core Scott-P18750 Subject: [MOBILE-IP] RFC 2290 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I have been reviewing the latest version of TR45.6 and noticed that the use of IPCP for Mobile IP (RFC 2290) was specifically prohibited. Can someone give me some background on why this RFC should not be used? Thanks Scott From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 13 13:24:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15917 for ; Tue, 13 Jun 2000 13:24:12 -0400 (EDT) Received: from standards (47.234.32.16:4495) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75314@standards.nortelnetworks.com>; Tue, 13 Jun 2000 13:14:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0616 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 13:14:54 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75300@standards.nortelnetworks.com>; Tue, 13 Jun 2000 13:04:54 -0400 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20989; Tue, 13 Jun 2000 11:13:10 -0600 (MDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA11706; Tue, 13 Jun 2000 13:12:59 -0400 (EDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by atlantic.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id NAA06137; Tue, 13 Jun 2000 13:13:32 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 13 Jun 2000 13:12:55 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] RFC 2290 X-To: Core Scott-P18750 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" > I have been reviewing the latest version of TR45.6 and noticed that the use > of IPCP for Mobile IP (RFC 2290) was specifically prohibited. Can someone > give me some background on why this RFC should not be used? > Scott, I believe the motivation was they feel it's unnecessary. The IP Address option is not mandatory in IPCP, so I think the idea is a node that understands mobile IP, by omiting it, implies it has an address, and the peer doesn't push to assign one. Then when IPCP completes, the [mobile] node does move detection on the becons. Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 13 13:30:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16147 for ; Tue, 13 Jun 2000 13:30:42 -0400 (EDT) Received: from standards (47.234.32.16:4495) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75339@standards.nortelnetworks.com>; Tue, 13 Jun 2000 13:21:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0626 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 13:21:26 -0400 Received: from vhaishhbexcd.med.va.gov (205.183.31.122:3523) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75308@standards.nortelnetworks.com>; Tue, 13 Jun 2000 13:11:26 -0400 Received: from 152.129.1.70 by vhaishhbexcd.med.va.gov (InterScan E-Mail VirusWall NT); Mon, 12 Jun 2000 12:18:06 -0500 (Central Daylight Time) Received: by VHAISHHBEXC4 with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 12:23:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2A5485D1C9C7D311816F0000F805ADB7696F61@vhapugexc1.med.va.gov> Date: Tue, 13 Jun 2000 12:21:42 -0500 Reply-To: "Kay, Rodney" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Kay, Rodney" Subject: [MOBILE-IP] FW: Mobile IP Agents as DHCP Proxies To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > -----Original Message----- > From: Kay, Rodney > Sent: Monday, June 12, 2000 11:13 AM > To: 'Steven.Glass@sun.com' > Subject: Mobile IP Agents as DHCP Proxies > > I am reviewing the subject document, and have encountered a situation > which doesn't make much sense to me. Please forgive me if my question > seems simplistic, but I am new to the IETF and chose your document due to > the new mobile computing requirements of my place of employment. > > In 3.1(3) you indicate that the HA should compare the IP address in the > DHCPOFFER with it's own when the DHCPOFFER includes the Mobile IP Home > Agent option (type 68); and if these are disparate, then an error 136 > "Unknown Home Agent Address" should be issued. My question - why would an > HA receive a DHCPOFFER for which it had not issued a DHCPDISCOVER request > as defined in [2]? > > Thank you for your time. > > Rodney H. Kay > Vista Systems Manager > Puget Sound Health Care System > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 13 13:53:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16904 for ; Tue, 13 Jun 2000 13:53:26 -0400 (EDT) Received: from standards (47.234.32.16:4495) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75392@standards.nortelnetworks.com>; Tue, 13 Jun 2000 13:44:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0769 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 13:44:07 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75380@standards.nortelnetworks.com>; Tue, 13 Jun 2000 13:34:06 -0400 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13287; Tue, 13 Jun 2000 10:42:39 -0700 (PDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA03135; Tue, 13 Jun 2000 13:42:37 -0400 (EDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by atlantic.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id NAA06243; Tue, 13 Jun 2000 13:43:10 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 13 Jun 2000 13:42:33 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] FW: Mobile IP Agents as DHCP Proxies X-To: "Kay, Rodney" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <2A5485D1C9C7D311816F0000F805ADB7696F61@vhapugexc1.med.va.gov> Rodney, Sorry for the delay in my response. I got a fairly lengthy feedback from someone yesterday, which combined with real work occupied more than the usual block of time... > In 3.1(3) you indicate that the HA should compare the IP address in the > DHCPOFFER with it's own when the DHCPOFFER includes the Mobile IP Home Agent > option (type 68); and if these are disparate, then an error 136 "Unknown > Home Agent Address" should be issued. My question - why would an HA receive > a DHCPOFFER for which it had not issued a DHCPDISCOVER request as defined in > [2]? 3.1(2) specifies the DHCP discover, so I assume you're asking why the DHCPOFFER would have a different value for the Mobile IP Home Agent Address option... The HA sends a DHCPDISCOVER with the Mobile IP Home Agent option set to either the address in the home agent field of the registration request, or the IP address of the interface on the mobile node's home link that will be servicing the mobile node. The DHCP Server then builds a DHCPOFFER based on several things, but specifically to the Mobile IP Home Agent option (see page 29-30 of 2131): Once the network address and lease have been determined, the server constructs a DHCPOFFER message with the offered configuration parameters. ... The configuration parameters MUST be selected by applying the following rules in the order given below. The network administrator is responsible for configuring multiple DHCP servers to ensure uniform responses from those servers. The server MUST return to the client: ... o Parameters requested by the client, according to the following rules: -- IF the server has been explicitly configured with a default value for the parameter, the server MUST include that value in an appropriate option in the 'option' field, ELSE -- IF the server recognizes the parameter as a parameter defined in the Host Requirements Document, the server MUST include the default value for that parameter as given in the Host Requirements Document in an appropriate option in the 'option' field, ELSE -- The server MUST NOT return a value for that parameter, The server MUST supply as many of the requested parameters as possible and MUST omit any parameters it cannot provide. The server MUST include each requested parameter only once unless explicitly allowed in the DHCP Options and BOOTP Vendor Extensions document. ... o Any parameters specific to this client (as identified by the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER or DHCPREQUEST message), e.g., as configured by the network administrator, ... o Parameters with non-default values on the client's subnet. So if the DHCP Server has a different value configured for the home agent address assigned to this client-id, it'll include the Mobile IP Home Agent Address option with the value it's configured to send. Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 13 14:19:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18201 for ; Tue, 13 Jun 2000 14:19:24 -0400 (EDT) Received: from standards (47.234.32.16:4495) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB753D0@standards.nortelnetworks.com>; Tue, 13 Jun 2000 14:10:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0847 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 14:10:05 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB753BB@standards.nortelnetworks.com>; Tue, 13 Jun 2000 14:00:03 -0400 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01261; Tue, 13 Jun 2000 12:08:33 -0600 (MDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA25988; Tue, 13 Jun 2000 14:04:31 -0400 (EDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by atlantic.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id OAA06354; Tue, 13 Jun 2000 14:05:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 13 Jun 2000 14:04:27 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] Deregistration question... X-To: Umamaheswar_Achari_Kakinada@3COM.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <882568FD.005B5C00.00@hqoutbound.ops.3com.com> > I think the question was what happens if the deregistration HA fails but > the MN would have > transmitted the gratuitous ARP before the HA begins the deregistration > process. Should the MN send another gratuitous ARP or am I missing > something ? Sorry - I've reread the relavent sections of d-i-m-rfc2002-bis-01.txt (section page 64 - 65 in particular) which does a lot to clarify and update what 2002 says (said), so part of the ordering I said below is actually wrong (!) Specific to your question (in hopefully a more successful attempt to get it right): Upon realizing it's on its home link: - The mobile node MUST reclaim it's address via gratuitous arp. This updates the arp cache on the machines on the home link. - The MN generates a [de]registration request, and sends it to the HA. - The HA processes the [de]registration request. - If the HA rejects it, it generates a [de]registration reply with the appropriate error, and sends it to the link address of the MN. The HA does NOT transmit any ARPs. In this way, the MN is receiving it's traffic despite the failed [de]registration attempt since it has intercepted the traffic that would otherwise have gone to the HA and into the tunnel. There's no need for the MN to retransmit that ARP, then again, there's no harm in it being retransmitting when the MN is successfully deregistered, either. Sorry about [my addition to] the confusion! This is also probably where the disclaimer normally goes that this use of ARP doesn't make the network less secure or chaotic than in the non-mobile case; anyone can gratuitous arp an address if they so choose. Cheers, Steve > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > cc: (Umamaheswar Achari Kakinada/MW/US/3Com) > Subject: Re: [MOBILE-IP] Deregistration question... > > > > > I was reading the latest draft revision of RFC2002 and I came across the > > part on the deregistration with HA. > > > > It was mentioned in the draft that the HA should transmit gratuitous ARP > > together with the (de)Registration Reply. The MN must transmit the > > gratuitous ARP before the HA begins the deregistration process. > > > > It was also mentioned later in the draft the if the HA rejects the > > (de)registration process, then no ARP processing is perform by the HA. > > > > Now, please correct me if I am wrong, if the MN sends the ARP packet before > > the deregistration process and the process fails, isn't there a possibility > > that some of the packets might be sent to this MN as their ARP tables might > > be updated with the gratutious ARP sent by the MN earlier? > > I suppose the ordering of most events is implimentation specific, but... > > The MN has to begins the deregistration process, as this is based on its > move detection. The HA processes the deregistration requests, if it's > acceptable, removes the MN's binding, and sends a deregistration reply. The > MN processes the deregistration reply, and if it's acceptable, sends its > address-claiming gratuitous arp. > > Yes, there is a non-zero amount of time between being removed from the > HA's binding, and reclaiming your address, but that's not really relavent. > One of the risks of roaming is not being where your traffic is going, and > happens everytime a MN roams, and many drafts specify FA's caching packets, > then delivering them to the new CoA upon getting binding updates. To get a > clearer picture, try any that deal with fast handoff or route optimization. > > Cheers, > Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 13 14:45:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18744 for ; Tue, 13 Jun 2000 14:45:31 -0400 (EDT) Received: from standards (47.234.32.16:4495) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75400@standards.nortelnetworks.com>; Tue, 13 Jun 2000 14:36:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0939 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 14:36:16 -0400 Received: from smtpgw1.sprintspectrum.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB753FF@standards.nortelnetworks.com>; Tue, 13 Jun 2000 14:34:55 -0400 Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw1.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id NAA22482 for ; Tue, 13 Jun 2000 13:43:07 -0500 (CDT) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 13:43:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC88011D5C67@pkcexv018.sprintspectrum.com> Date: Tue, 13 Jun 2000 13:43:00 -0500 Reply-To: "Lipford, Mark" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lipford, Mark" Subject: Re: [MOBILE-IP] X-To: tovey To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Tovey, I am guessing this is OK. The people that wrote this I-D are also the ones that work on 3GPP2 TSG-A that defined the A10 and A11 interfaces. I did forward this to Yingchun to confirm it. Thanks Mark A. Lipford -----Original Message----- From: tovey [mailto:toveyjiang@HUAWEI.COM.CN] Sent: Friday, June 09, 2000 9:24 PM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] << File: draft-ietf-mobileip-3gwireless-ext-03.txt >> Hi, everyone In this internet-draft , there maybe some problem in section 4.1, as following: A RNN MUST send a Registration Request with the GRE encapsulation* and the reverse tunneling bit set. The Home Address field is set to zero. The Home Agent field will be assigned to the IP address of the PDSN and the Care-of Address field will be assigned to the IP address of RNN. According to A11 interface of IOS 4 of CDMA2000 specification, we use UDP instead of GRE to establish the R-P connection between BSC/PCF and PDSN. Tovey Jiang 2000.6.10 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 13 19:33:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24933 for ; Tue, 13 Jun 2000 19:33:45 -0400 (EDT) Received: from standards (47.234.32.16:1517) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7553B@standards.nortelnetworks.com>; Tue, 13 Jun 2000 19:24:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1327 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 19:24:28 -0400 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75524@standards.nortelnetworks.com>; Tue, 13 Jun 2000 19:14:27 -0400 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 TAA00186 for ; Tue, 13 Jun 2000 19:23:12 -0400 (EDT) Received: from ihgp24.ih.lucent.com (h135-1-53-29.lucent.com [135.1.53.29]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA00182 for ; Tue, 13 Jun 2000 19:23:12 -0400 (EDT) Received: by ihgp24.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id SAA20497; Tue, 13 Jun 2000 18:23:11 -0500 (CDT) Received: from lucent.com by ihgp24.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id SAA20322; Tue, 13 Jun 2000 18:22:48 -0500 (CDT) X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3946C247.1308EB8D@lucent.com> Date: Tue, 13 Jun 2000 18:22:47 -0500 Reply-To: Tom Hiller Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Tom Hiller Organization: Lucent Technologies Subject: Re: [MOBILE-IP] RFC 2290 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Scott, We use the RRQ/RRP to tell the PDSN (which supports PPP and FA) the address the mobile will use. In this case the mobile does not request an address to be assigned in IPCP. This approach is more efficient than getting an address from PPP and then telling PPP in the next moment that the mobile wants to use a different address. Also we did not hear about a lot of RFC 2290 implementations and people said it was complex. So that was that. Thanks, Tom PS The PDSN supports both PPP and Mobile IP. Core Scott-P18750 wrote: > > I have been reviewing the latest version of TR45.6 and noticed that the use > of IPCP for Mobile IP (RFC 2290) was specifically prohibited. Can someone > give me some background on why this RFC should not be used? > > Thanks > > Scott From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 13 22:56:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28850 for ; Tue, 13 Jun 2000 22:56:15 -0400 (EDT) Received: from standards (47.234.32.16:1487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75595@standards.nortelnetworks.com>; Tue, 13 Jun 2000 22:46:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1476 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 22:46:58 -0400 Received: from hotmail.com (f133.law3.hotmail.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75594@standards.nortelnetworks.com>; Tue, 13 Jun 2000 22:36:57 -0400 Received: (qmail 785 invoked by uid 0); 14 Jun 2000 02:45:42 -0000 Received: from 209.254.217.37 by www.hotmail.com with HTTP; Tue, 13 Jun 2000 19:45:42 PDT X-Originating-IP: [209.254.217.37] Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: <20000614024542.784.qmail@hotmail.com> Date: Wed, 14 Jun 2000 02:45:42 GMT Reply-To: amarnath gudlavalleti Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: amarnath gudlavalleti Subject: [MOBILE-IP] Network Simulator To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, I am looking for projects that can be done on Mobile IP using Network Simulator. I have gone through the documentation to run wireless simulations and creating mobile IP simulations in ns of Marc Greis' tutorial. I have also read the relevant stuff from the ns manual. I am looking for some tests that can be done with ns on handoffs and buffering by writing tcl scripts or adding some classes to the source. So, if canyone who has worked/ is working on Mobile IP using ns can help me I will be very thankful. Thank you, Amarnath. ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 13 23:52:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29907 for ; Tue, 13 Jun 2000 23:52:05 -0400 (EDT) Received: from standards (47.234.32.16:3463) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB755CF@standards.nortelnetworks.com>; Tue, 13 Jun 2000 23:42:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1551 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 13 Jun 2000 23:42:55 -0400 Received: from mail0.u-aizu.ac.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB755CE@standards.nortelnetworks.com>; Tue, 13 Jun 2000 23:42:42 -0400 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 MAA29773; Wed, 14 Jun 2000 12:50:35 +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 MAA25351; Wed, 14 Jun 2000 12:50:34 +0900 (JST) X-Mailer: Mozilla 4.7 [en_jp] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <20000614024542.784.qmail@hotmail.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Message-ID: <3947010A.3DECAC53@u-aizu.ac.jp> Date: Wed, 14 Jun 2000 12:50:34 +0900 Reply-To: sarikaya@U-AIZU.AC.JP Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Behcet Sarikaya Organization: University of Aizu Subject: Re: [MOBILE-IP] Network Simulator X-To: amarnath gudlavalleti To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Why don't you try to extend the Mobile IP support to Mobile IPv6 support? If you are knowledgeable enough on ns, this would be a good contribution. -- Behcet From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 14 07:08:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15344 for ; Wed, 14 Jun 2000 07:08:10 -0400 (EDT) Received: from standards (47.234.32.16:4946) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7572F@standards.nortelnetworks.com>; Wed, 14 Jun 2000 6:58:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1996 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 14 Jun 2000 06:58:37 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7572D@standards.nortelnetworks.com>; Wed, 14 Jun 2000 6:48:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14960; Wed, 14 Jun 2000 06:57:22 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200006141057.GAA14960@ietf.org> Date: Wed, 14 Jun 2000 06:57:22 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-12.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobile IP Challenge/Response Extensions Author(s) : C. Perkins, P. Calhoun Filename : draft-ietf-mobileip-challenge-12.txt Pages : 16 Date : 13-Jun-00 Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-12.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-challenge-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-challenge-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000613121347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-challenge-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-challenge-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000613121347.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 14 16:59:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04134 for ; Wed, 14 Jun 2000 16:59:00 -0400 (EDT) Received: from standards (47.234.32.16:2613) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB759A7@standards.nortelnetworks.com>; Wed, 14 Jun 2000 16:49:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2810 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 14 Jun 2000 16:49:35 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB759A4@standards.nortelnetworks.com>; Wed, 14 Jun 2000 16:39:35 -0400 Received: from hefaistos.kastproduction.cz ([194.228.111.133]) by hosaka.smallworks.com (8.9.1/8.9.1) with SMTP id PAA05534 for ; Wed, 14 Jun 2000 15:48:20 -0500 (CDT) Received: from PSlREF727 (unverified [32.102.49.125]) by hefaistos.kastproduction.cz (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 14 Jun 2000 22:48:16 +0200 Message-ID: <6gHxg2f7P2ig> Date: Wed, 14 Jun 2000 03:40:51 PM Reply-To: UmEC068N5@INET22.KAJIMA.CO.JP Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: UmEC068N5@INET22.KAJIMA.CO.JP Subject: [MOBILE-IP] earn extra money online now To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM hello, You can build a residual income from time you spend on the Internet placing FREE advertisements like this. Successful Internet company wants you to help them market their products and services online. Place FREE pre-written ads and get paid commissions on any sales that you bring to the company. A FREE Web Site, and complete training and instructions will be provided to you. To Register with the program and to begin receiving instructions, simply mailto:intmall@china.com?subject=RegisterMe AND INSERT YOUR FIRST AND LAST NAME AS TEXT to be removed from this list mailto:21remo@england.com?subject=remove From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 14 21:51:20 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08290 for ; Wed, 14 Jun 2000 21:51:20 -0400 (EDT) Received: from standards (47.234.32.16:2149) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75AA4@standards.nortelnetworks.com>; Wed, 14 Jun 2000 21:41:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3145 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 14 Jun 2000 21:41:58 -0400 Received: from hotmail.com (law2-f38.hotmail.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75AA3@standards.nortelnetworks.com>; Wed, 14 Jun 2000 21:41:58 -0400 Received: (qmail 97640 invoked by uid 0); 15 Jun 2000 01:50:46 -0000 Received: from 203.181.29.95 by www.hotmail.com with HTTP; Wed, 14 Jun 2000 18:50:46 PDT X-Originating-IP: [203.181.29.95] Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: <20000615015046.97639.qmail@hotmail.com> Date: Thu, 15 Jun 2000 09:50:46 SGT Reply-To: Jonathan Khoo Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jonathan Khoo Subject: Re: [MOBILE-IP] Deregistration question... X-To: Steven.Glass@East.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi there, Thanks for the reply. Is there anyway to prevent traffic from going to a bogus MN after it has sent it's gratutious ARP and deregistration fails? Have a nice day! Cheers, Jonathan > This is also probably where the disclaimer normally goes that >this >use of ARP doesn't make the network less secure or chaotic than >in the >non-mobile case; anyone can gratuitous arp an address if they >so choose. > > Cheers, > Steve ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 15 04:00:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24810 for ; Thu, 15 Jun 2000 04:00:17 -0400 (EDT) Received: from standards (47.234.32.16:4969) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75B86@standards.nortelnetworks.com>; Thu, 15 Jun 2000 3:50:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3429 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 15 Jun 2000 03:50:56 -0400 Received: from q1u8b6 (abq133.cnsp.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75B85@standards.nortelnetworks.com>; Thu, 15 Jun 2000 3:40:55 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 15 Jun 2000 03:50:56 -0400 Reply-To: Steve Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steve Subject: [MOBILE-IP] On Oprah To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM May of 00 The lifestyle you have always wanted for ONLY $300.00 sml1@idunk.net We received your name as someone interested in receiving business opportunity information. If it was an error, and you wish to be removed from our list, please reply to smlr@idunk.net. All mailings are sent complying to the proposed United States Federal requirements for commercial e-mail (S1618 Section 301). Paragraph (a)(2)(c) of S. 1618 101 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 15 10:28:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03043 for ; Thu, 15 Jun 2000 10:28:50 -0400 (EDT) Received: from standards (47.234.32.16:1122) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75CB6@standards.nortelnetworks.com>; Thu, 15 Jun 2000 10:18:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0104 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 15 Jun 2000 10:18:17 -0400 Received: from fmweb02.unimessage.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75CB5@standards.nortelnetworks.com>; Thu, 15 Jun 2000 10:08:16 -0400 Received: from fmweb02.unimessage.net (localhost [127.0.0.1]) by fmweb02.unimessage.net (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA01369 for ; Thu, 15 Jun 2000 16:17:04 +0200 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="135593989.961078623903.JavaMail.nobody@fmweb02.unimessage.net" Message-ID: <135586993.961078624150.JavaMail.nobody@fmweb02.unimessage.net> Date: Thu, 15 Jun 2000 16:17:04 +0200 Reply-To: Joachim Koch Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Joachim Koch Subject: [MOBILE-IP] FW: IETF-Draft Cellular-IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --135593989.961078623903.JavaMail.nobody@fmweb02.unimessage.net Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, as you see, I have posted a comment to the authors of the draft . Yours sinceerly Joachim Koch ----- Original Message ----- Von: joachimkoch@redseven.de An: andras.valko@eth.ericsson.se Empfangen: 14.06.2000 22:56 Betreff: IETF-Draft Cellular-IP Dear Mr. Valko, as you see in the attachment, I have a comment to your IETF-Draft Cellular-IP. To make see changes easier, I have made as a header the diffs between the draft and my comment. Thanks for comments. Yours sinceerly -- ________________________________________________ redseven Community - Alleine war gestern http://www.redseven.de redseven freemail - der kostenlose eMail-Service http://mail.redseven.de Join us now! --135593989.961078623903.JavaMail.nobody@fmweb02.unimessage.net Content-Type: text/plain; name=Comment.txt Content-Disposition: attachment; filename=Comment.txt Content-Transfer-Encoding: 7bit INTERNET-DRAFT A. Campbell J. Gomez Expires July 2000 C-Y. Wan S. Kim Columbia University Z. Turanyi A. Valko Ericsson January 2000 ********************************************************************** diffs between the draft and my comment ( next 67 LINES): 717c717 < 3.3.2. Route-update packet --- > ***3.3.2. Route-update packet 735c735 < | CU |S| AType | Auth. Length | CU | --- > | CU |S| AType | Auth. Length | **see ch.4.2.***[CU] | 782a783,785 > * ***New IP-Address Contains the new IP-Address of the MH after > changing IP-address and gateway (see ch. 4.2.) > 805c808 < Currently the following type of control information is defined --- > *** Currently the following type of control information is defined 810,812c813,826 < < < --- > > * New Beacon Signal Structure > The Layer2 parameters related to the Base Station changed. > (==> new cell) (This control-Type for routing-update packets only) > > * New Paging Area > The ID of the Paging Area changed > > * Teardown > The Beacon Signal is missing through 3 Periods > > * New Gateway > The Gateway is changed, so the IP-Address of the Mobile Host is > to be changed (see ch. 4.2.) 1206c1220 < 4.2. Multiple Gateway Networks --- > ***4.2. Multiple Gateway Networks 1219a1234,1238 > * ***see ch 3.2.2. a change of the gateway results in a change of the > IP-Address of the mobile host. Therefore the second CU field in the > Route-update-packet could be used to transmit the new IP-Adress. In the > Control-information field the change of gateway and the change of > Ip-Address could be used as described in ch 3.2.2.**** 1310c1329,1330 < topology. An Uplink neighbor is identified by the interface through --- > topology. An Uplink neighbor is identified by the **non-air** interface > through 1332c1352,1353 < The Gateway broadcasts the packet on all of its interfaces except --- > The Gateway broadcasts the packet on all of its **non-air**interfaces > except 1341,1343c1362,1365 < 3) It stores the Cellular IP Network Identifier and the IP address of < the Gateway. < 3) It stores the interface through which the packet arrived together --- > [3) It stores the Cellular IP Network Identifier and the IP address of > the Gateway]. > 3) It stores the **non-air**interface through which the packet arrived > together ********************************************************************** Cellular IP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies a protocol that allows routing IP datagrams to a mobile host. The protocol is intended to provide local mobility and handoff support. It can interwork with Mobile IP [1] to provide wide area mobility support. Four fundamental design principles of the protocol are: (1) location information is stored in distributed data bases (2) location information referring to a mobile host is created and updated by regular IP datagrams originated by the said mobile host (3) location information is stored as soft state (4) location management for idle mobile hosts is separated from location management of hosts that are actively transmitting or receiving data. Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 1] INTERNET-DRAFT Cellular IP January 2000 Table of Contents 1. Introduction 3 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 1.2. New Architectural Entities . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 1.5. Location Management and Routing . . . . . . . . . . . . . 7 2. Cellular IP Functions 8 2.1. Location Management . . . . . . . . . . . . . . . . . . . 8 2.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Handoff . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4. Wide Area Mobility . . . . . . . . . . . . . . . . . . . 10 2.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Protocol Details 11 3.1. Protocol Parameters . . . . . . . . . . . . . . . . . . . 11 3.2. Beacon Signal Structure . . . . . . . . . . . . . . . . . 12 3.3. Packet Formats . . . . . . . . . . . . . . . . . . . . . 12 3.3.1. Data packet . . . . . . . . . . . . . . . . . . . 12 3.3.2. Route-update packet . . . . . . . . . . . . . . . 12 3.3.3. Paging-update packet . . . . . . . . . . . . . . . 14 3.3.4. Paging-teardown packet . . . . . . . . . . . . . . 14 3.4. Addressing . . . . . . . . . . . . . . . . . . . . . . . 14 3.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 14 3.6. Cellular IP Routing . . . . . . . . . . . . . . . . . . . 15 3.6.1. Topology . . . . . . . . . . . . . . . . . . . . . 15 3.6.2. Uplink Routing . . . . . . . . . . . . . . . . . . 15 3.6.3. Downlink Routing . . . . . . . . . . . . . . . . . 16 3.7. Cellular IP Gateway . . . . . . . . . . . . . . . . . . . 17 3.8. Cellular IP Mobile Host . . . . . . . . . . . . . . . . . 18 4. Extensions to Cellular IP 19 4.1. Semi-soft Handoff . . . . . . . . . . . . . . . . . . . . 19 4.2. Multiple Gateway Networks . . . . . . . . . . . . . . . . 20 4.3. Charging . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations 20 6. Intellectual Property Right Notice . . . . . . . . . . . . . . 20 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 APPENDIX A. Uplink Neighbor Selection . . . . . . . . . . . . . . 21 0. What's Changed The following major improvements have been made to the protocol compared to : - Security support for Cellular IP has been added. - Paging Areas have been introduced. As long as an idle mobile host is moving inside a Paging Area, it is not necessary to transmit any control packets. - Semi-soft handoff has been introduced to improve handoff performance. - Each node maintains only one valid Route Cache mapping and only one valid Paging Cache mapping for each mobile host. There is one exception to this in the case of semisoft handoff. Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 2] INTERNET-DRAFT Cellular IP January 2000 In addition, the following minor changes have been made: - Cache mappings can not be created or modified (but still can be refreshed) by data packets. - Paging-update packets remove Route Cache entries. - An optional paging-teardown packet has been introduced that explicitly removes Paging Cache mappings. - The Base Station's beacon signal has been extended to include Paging Area ID. - The example algorithm in Appendix A. has been extended to distribute Network ID, Gateway IP address and Paging Area IDs. - Control packet format has been changed to ICMP. - Control packets must contain timestamp and authentication information. - Cache mappings now contain timestamp information of the update packet that created the mapping. - Cache mappings also contain the MAC address of the downlink Cellular IP node to allow multiple Cellular IP nodes to reside a shared medium. The notion of Uplink and Downlink I/Fs has been replaced by Uplink and Downlink neighbors. 1. Introduction Hosts connecting to the Internet via a wireless interface are likely to change their point of access frequently. A mechanism is required that ensures that packets addressed to moving hosts are successfully delivered with high probability. A change of access point during active data transmission or reception is called a handoff. During or immediately after a handoff, packet losses may occur due to delayed propagation of new location information. These losses should be minimized in order to avoid a degradation of service quality as handoff become more frequent. This memo specifies Cellular IP, a protocol that provides mobility and handoff support for frequently moving hosts. It is intended to be used on a local level, for instance in a campus or metropolitan area network. Cellular IP can interwork with Mobile IP [1] to support wide area mobility, that is, mobility between Cellular IP Networks. 1.1. Applicability Cellular IP supports local mobility, that is, mobility inside an access network. To provide global mobility support, Mobile IP [1] should be used in conjunction with Cellular IP. Cellular IP is designed to support frequently migrating, rarely moving or static hosts as well. Cellular IP assumes that a random access L2 protocol covers the air interface. Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 3] INTERNET-DRAFT Cellular IP January 2000 1.2. New Architectural Entities Cellular IP Node A Cellular IP Network consists of interconnected Cellular IP nodes. The role of nodes is twofold. They route IP packets inside the Cellular IP Network and communicate with mobile hosts via a wireless interface. Referring to the latter role, a Cellular IP node that has a wireless interface is also called a Base Station. Cellular IP Base Station See Cellular IP node. Cellular IP Gateway A Cellular IP node that is connected to a regular IP network by at least one of its interfaces. Cellular IP Mobile Host A mobile host that implements the Cellular IP protocol. 1.3. Terminology Active Mobile Host A mobile host is in active state if it is transmitting or receiving IP packets. (Exact definition is given in Section 3.8.) Cellular IP Network Identifier A unique identifier assigned to Cellular IP Networks. Control packet Paging-update, paging-teardown and route-update packet. Data packet An IP packet that is not a control packet. Downlink Directed to a mobile host. Downlink neighbor All neighbors of a Cellular IP node except its Uplink neighbor are referred to as Downlink neighbors. Idle Mobile Host A mobile host is in idle state if it has not recently transmitted or received IP packets. (Exact definition is given in Section 3.8.) Internet A Cellular IP Network provides access to a regular IP network. This IP network in this memo is referred to as "Internet", but it can also be a corporate intranet, for example. Neighbor Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 4] INTERNET-DRAFT Cellular IP January 2000 One Cellular IP node is said to be the neighbor of another if they are connected directly. Neighbors are identified in a Cellular IP node by interface and MAC address. Paging Area A set of Base Stations. Idle mobile hosts crossing cell boundaries within a Paging Area do not need to transmit control packets to update their position. (Exact definition is given in Section 2.1.) Paging Cache A cache maintained by some Cellular IP nodes, used to route packets to mobile hosts. Paging-timeout Validity time of mappings in Paging Caches. Paging-update packet A control packet transmitted by Cellular IP mobile hosts in order to update Paging Cache. Paging-update-time Time between consecutive paging-update packets. Paging-teardown packet A control packet transmitted by Cellular IP mobile hosts in order to explicitly disconnect from the Cellular IP Network. Route-timeout Validity time of mappings in Route Cache. Route-update packet A control packet transmitted by Cellular IP mobile hosts in order to update Route Cache. Route-update-time Time between consecutive route-update packets. Route Cache A cache maintained by all Cellular IP nodes, used to route packets to mobile hosts. Update packet Paging-update and route-update packet. Uplink Originated by a mobile host. Uplink neighbor The neighbor of a Cellular IP node which is the next hop on the shortest path towards the Gateway. 1.4. Protocol Overview Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 5] INTERNET-DRAFT Cellular IP January 2000 The figure shown below presents a schematic view of multiple Cellular IP Networks providing access to the Internet. .............................................. . . . Internet Backbone with Mobile IP . . . .............................................. / | \ / | \ +--+ +--+ +--+ |GW| |GW| |GW| +--+ +--+ +--+ / | \ +-------------+ +--------------------+ +-------------+ | | | | | | | Cellular IP | | Cellular IP | | Cellular IP | | Network | | Network | | Network | | | | __ __ __ | | | +-------------+ +-|BS|---|BS|---|BS|-+ +-------------+ -- -- -- + ... + MH MH In what follows, we present an overview of the operation of Cellular IP, followed by a figure illustrating the functional entities that comprise Cellular IP. Base Stations periodically emit beacon signals. Mobile hosts use these beacon signals to locate the nearest Base Station. A mobile host can transmit a packet by relaying it to the nearest Base Station. All IP packets transmitted by a mobile host are routed from the Base Station to the Gateway by hop-by-hop shortest path routing, regardless of the destination address. Cellular IP nodes maintain Route Cache. Packets transmitted by the mobile host create and update entries in each node's Cache. An entry maps the mobile host's IP address to the neighbor from which the packet arrived to the node. The chain of cached mappings referring to a single mobile host constitutes a reverse path for downlink packets addressed to the same mobile host. As the mobile host migrates, the chain of mappings always points to its current location because its uplink packets create new and change old mappings. IP packets addressed to a mobile host are routed by the chain of cached mappings associated with the said mobile host. To prevent its mappings from timing out, a mobile host can Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 6] INTERNET-DRAFT Cellular IP January 2000 periodically transmit control packets. Control packets are ICMP packets with specific authentication payloads. Mobile hosts that are not actively transmitting or receiving data but want to be reachable for incoming packets, let their Route Cache mappings time out but maintain Paging Cache mappings. IP packets addressed to these mobile hosts will be routed by Paging Caches. Paging Caches have a longer timeout value than Route Caches and are not necessarily maintained in every node. +--------+ |host in | |Internet| +--------+ | Internet | -------------------------- +--------+ Cellular IP Network |Cell. IP| |Gateway | +--------+ | - : | : | :\___________ Uplink neighbor A network of | | (=shortest path | +--------+ toward Gateway) Cellular IP | |Cellular| | |IP node | nodes | +--------+ | | ___________ Downlink neighbors | :/ (=all other - : neighbors) : | +--------+ uplink |Cellular| ^ |IP node | | +--------+ | air | | interface| V +--------+ downlink | Mobile | | host | +--------+ 1.5. Location Management and Routing Cellular IP uses two parallel cache systems to store the information related to the location of mobile hosts. The two systems basically operate in the same way. This section is intended to clarify why we use two distinct caches. When a mobile host is in active state, the network must follow its movement from Base Station to Base Station to be able to deliver Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 7] INTERNET-DRAFT Cellular IP January 2000 packets without searching for the mobile host. As a consequence active mobile hosts must notify the network about each handoff. For idle mobile hosts exact location tracking is less important, instead mimizing communication to save battery is of higher priority. By deploying two caches, the granularity of location tracking can be different for idle and active mobile hosts. Separating the location tracking for idle and active mobile hosts also has a performance benefit. Supposing there is just one set of cache, for each downlink packet the entire cache must be searched to find the destination mobile host. It is expected, however, that only a portion of the hosts will be in active state at any given time and that most of the packets are destined for active mobile hosts. Thus by separating the caches for active and idle mobile hosts only a smaller cache needs to be searched for most of the packets. This results in faster lookups and better scalability [5]. 2. Cellular IP Functions 2.1. Location Management Cellular IP allows idle mobile hosts to roam large geographic areas without the need to transmit location update packets at cell borders. The network operator can group cells into Paging Areas, each comprising of an arbitrary number of (typically adjacent) cells. Each Paging Area has an identifier that is unique in the given Cellular IP Network. Each Base Station transmits its Paging Area Identifier in its periodic beacon signals, thus enabling mobile hosts to notice when they move into a new Paging Area. An idle mobile host that moves into a new Paging Area must transmit a paging-update packet. Paging-update packets are routed from the Base Station to the Gateway using hop-by-hop routing. Selected nodes of the Cellular IP network are equipped with Paging Cache. These nodes monitor passing paging-update packets and update Paging Cache mappings to point toward the new Paging Area. Paging-update packets reach the Gateway and are discarded there to isolate Cellular IP specific operations from the Internet. When the idle mobile host moves within a Paging Area, it transmits a paging-update packet only when the system specific time, paging- update-time expires. Outdated mappings of Paging Caches are cleared if no update arrives before paging-timeout expires. When an IP packet arrives at a Cellular IP node, addressed to a mobile host for which no up-to-date Route Cache mapping is available, the Paging Cache is used to route the packet. This is called "implicit paging". If the node has no Paging Cache, it forwards the packet to all Downlink neighbors. A node that has Paging Cache but has no mapping in it for the destination mobile host discards the packet. On the path from the gateway to the mobile host there may be Cellular IP nodes with and without Paging Cache. After the paging packet Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 8] INTERNET-DRAFT Cellular IP January 2000 leaves the last node which has a Paging Cache it is effectively downlink broadcast by all nodes it passes. The set of cells that are reached by the paging packet forms a Paging Area. The number, size and population of Paging Areas in a Cellular IP network are determined by the topology of the network and the placement of Paging Caches. Based on the configuration of a Paging Area each base station (with Paging Cache configured) could be considered an autonomous Paging Area. The other extreme case is when a Cellular IP Network has no Paging Cache configured in which case the complete network represents a Paging Area where paging devolves to broadcasting throughout the network. When the mobile host receives the paging packet, it moves to active state and creates its Route Cache mappings by sending a route-update packet. Subsequent IP packets addressed to the same host will be routed by Route Caches as long as the mobile host keeps the Route Caches updated. 2.2. Routing Packets transmitted by mobile hosts are routed to the Gateway using shortest path hop-by-hop routing. Cellular IP nodes monitor these passing data packets and use them to create and update Route Cache mappings. These map mobile host IP addresses to Downlink neighbors of the Cellular IP node. Packets addressed to the mobile host are routed along the reverse path, on a hop-by-hop basis, by these Route Cache mappings. The structure and basic operation of routing is similar to that of location management. To clarify the duality between the two, we summarize the operation of Paging Caches and Route Caches in the following table. For the reasons of separating the two functions, see Section 1.7. ---------------------------------------------------------------------- Paging Caches Route Caches ---------------------------------------------------------------------- refreshed by all uplink packets (data, data and paging-update, route-update) route-update packets updated by all update packets route-update packets (paging-update, route-update) updated when moving to a new Paging moving to a new Area, or after cell, or after paging-update-time route-update-time scope both idle and active MHs active mobile hosts purpose route downlink packets if route downlink there is no Route Cache entry packets ---------------------------------------------------------------------- The mobile host may keep receiving data packets without sending data Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 9] INTERNET-DRAFT Cellular IP January 2000 for possibly long durations. To keep its Route Cache mappings up to date and to avoid repeated paging, mobile hosts in active state that have no data to send must send periodic route-update packets. Like uplink data packets, route-update packets update Route Caches and ensure that the hop-by-hop route from the Gateway to the mobile host does not time out. In addition, active mobile hosts must transmit a route-update packet when they cross cell borders. This is required because the Route Cache mappings associated with the new Base Station can only be created by authenticated route-update packets. Data packets are not required to carry authentication information and hence can refresh, but not modify Route Cache mappings. For reliability and timeliness, Paging Caches also contain mobile hosts that are contained by Route Caches. For this reason, Paging Caches are updated by all uplink update packets and refreshed by all uplink packets including data packets as well. 2.3. Handoff Handoff is initiated by the mobile host. As an active host approaches a new Base Station, it transmits a route-update packet and redirects its packets from the old to the new Base Station. The route-update packet will configure Route Caches along the way from the new Base Station to the Gateway. (The paths leading to the old and new Base Stations may overlap. In nodes where the two paths coincide, the route-update packet simply refreshes the old mapping and the handoff remains unnoticed.) An idle mobile host, moving to a new Base Station, transmits a paging-update packet only if the new Base Station is in a new Paging Area. During handoffs between Base Stations within the same Paging Area idle mobile hosts may remain silent, as paging is performed within the entire Paging Area. 2.4. Wide Area Mobility Wide area mobility occurs when the mobile host moves between Cellular IP Networks. The mobile host can identify Cellular IP Networks by the Cellular IP Network Identifier contained in the Base Stations' beacon signals. The beacon signal also contains the IP address of the Gateway. For security and charging purposes, authentication and other user-related information may need to be provided by the mobile host, when it first contacts a Cellular IP Network. This information will be inserted in the payload of the first paging-update packet and may be repeated in a few subsequent paging-update packets for reliability. Upon receiving the first paging-update packet, the Gateway performs admission control that may involve technical and charging decisions. The Gateway's response is sent to the mobile host in regular IP packet(s). If the request was accepted, the response may also carry the required setting for protocol parameters. After successful authentication to the Cellular IP network the mobile host can send a Mobile IP registration message to its home agent, Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 10] INTERNET-DRAFT Cellular IP January 2000 specifying the Gateway's IP address as the care-of-address. (Alternatively, the Gateway can register at the Home Agent on behalf of the mobile host.) The mobile host may leave the service area at any time without prior notice. Mappings associated to the host will be cleared after the timeout. Alternatively, as a performance optimization the host may send a paging-teardown packet to clear Cache mappings from both Route and Paging Caches. 2.5. Security Cellular IP control packets (paging-update, route-update and paging- teardown packets) carry mandatory authentication information. This prevents malicious mobile hosts from changing location information related to other mobile hosts using a spoofed source address; details of the authentication mechanism can be found in Section 3.5. Data security issues are not discussed in this document. We note that any further authentication or encryption can be performed in addition to control packet authentication built into Cellular IP. 3. Protocol Details 3.1. Protocol Parameters The following parameters shall be set by network management. The values listed here are for information only. Note that in the most typical case a mobile host that is in active state will regularly transmit data packets and hence route-update packets will need to be transmitted at handoffs only. ------------------------------------------------------------------- Name Meaning Typical Value ------------------------------------------------------------------- route-update-time Maximal inter-arrival time 3 sec of packets updating the Route Cache route-timeout Validity of Route 9 sec Cache mappings paging-update-time Maximal inter-arrival time 3 min of packets updating the Paging Cache paging-timeout Validity of Paging 9 min Cache mappings ------------------------------------------------------------------- Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 11] INTERNET-DRAFT Cellular IP January 2000 3.2. Beacon Signal Structure Cellular IP Base Stations must periodically transmit beacon signals to allow for mobile hosts to identify an available Base Station. Information elements carried by the beacon signal include: - Layer2 parameters related to the Base Station; - the Cellular IP Network Identifier; - the IP address of the Gateway; and - the ID of the Paging Area. All parameters can be configured by network management. As an alternative, in Appendix A we present an example algorithm for automatically distributing the Cellular IP Network Identifier, the IP address of the Gateway and the Paging Area IDs to Base Stations. 3.3. Packet Formats 3.3.1. Data packet Cellular IP forwards regular IP packets without modification, segmentation, encapsulation or tunneling. ***3.3.2. Route-update packet A route-update packet is an ICMP packet where - the source address is the IP address of the sending mobile host; - the destination address is the Gateway; and - the type is Cellular IP Control Packet and the code is Route-update. The payload of the route-update packet carries authentication and control information in the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Timestamp (64 bits long) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CU |S| AType | Auth. Length | **see ch.4.2.***[CU] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authentication (variable length) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Control information (variable length) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Timestamp Contains a timestamp used to determine the order in which update packets are sent. The timestamp Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 12] INTERNET-DRAFT Cellular IP January 2000 field is formatted as specified by the Network Time Protocol [2]. The low-order 32 bits of the NTP format represent fractional seconds, and those bits which are not available from a time source should be generated from a good source of randomness. Mobile hosts must ensure that the 64 bit value of timestamps is strictly increasing in consecutive control packets. CU Currently Unused. Must be set to 0. S flag Set to 1 to indicate semi-soft handoff. Default value is 0. Any Cellular IP node that does not support semi-soft handoffs may ignore this bit. (See Section 4.1.) AType Denotes the authentication method used. The default authentication method is described in [4]. All authentication methods must utilize the timestamp field. Auth. Length Denotes the length of the authentication information in bytes. Authentication Contains the authentication information. * ***New IP-Address Contains the new IP-Address of the MH after changing IP-address and gateway (see ch. 4.2.) Alternatively the Authentication Header [3] could also be used for authenticating control packets. This issue is for further study. Control information is encoded in the following Type-Length-Value format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+- | Type | Length | Data ... | Type ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+- Type Indicates the particular type of control information. Length Indicates the length (in bytes) of the following data field within. The length does not include the Type and Length bytes. Data This field may be zero or more bytes in length. The meaning, format and length of the data field is determined by the Type and Length fields. *** Currently the following type of control information is defined (details are for further study): Registration request Used when a mobile host enters the Cellular IP Network. * New Beacon Signal Structure The Layer2 parameters related to the Base Station changed. (==> new cell) (This control-Type for routing-update packets only) * New Paging Area The ID of the Paging Area changed * Teardown The Beacon Signal is missing through 3 Periods * New Gateway The Gateway is changed, so the IP-Address of the Mobile Host is to be changed (see ch. 4.2.) Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 13] INTERNET-DRAFT Cellular IP January 2000 3.3.3. Paging-update packet A paging-update packet is an ICMP packet where - the source address is the IP address of the sending mobile host; - the destination address is the Gateway; and - the type is Cellular IP Control Packet and the code is Paging-update. The payload of the paging-update packet carries authentication and control information in the same format as the route-update packet. The S flag must be 0 for paging-update packets. 3.3.4. Paging-teardown packet A paging-teardown packet is a ICMP packet where - the source address is the IP address of the sending mobile host; - the destination address is the Gateway; and - the type is Cellular IP Control Packet and the code is Paging-teardown. The payload of the paging-teardown packet carries authentication and control information in the same format as the route-update packet. The S flag must be 0 for paging-teardown packets. 3.4. Addressing Cellular IP requires no address space allocation beyond what is present in IP. Mobile hosts are identified by their home IP addresses. 3.5. Security Each Cellular IP Network has a secret network key of arbitrary length known to all Cellular IP nodes. The network key is kept secret from mobile hosts and other nodes outside the Cellular IP Network, however. Upon initial registration the Gateway must authenticate and possibly authorize the mobile host. This initial authentication and authorization can be based on any known symmetric or asymmetric method. After authentication the Gateway concatenates the key of the network and the IP address of the mobile host and calculates the PID of the mobile host by an MD5 Hash similarly as in [4]: PID := MD5(network key, IP address of MH) Then it acquires the public key of the mobile host from a trusted party, encrypts the PID and sends it to the mobile host. This way the mobile host and the Cellular IP network have a shared secret. The PID remains the same during handoff and can be easily computed by each Base Station. The PID can be used to authenticate (and optionally to encrypt) IP packets over the air interface. Authentication is performed by creating a short hash from the (PID, timestamp, packet content) triple that is placed into the transmitted packets. The validity of Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 14] INTERNET-DRAFT Cellular IP January 2000 each packet can be easily checked by any Base Station even immediately after a handoff and without prior communication with the mobile host or with the old Base Station. In addition to authenticating control packets, PID can optionally also be used to provide security for data packets transmitted over the wireless link. To this avail, any known shared secret based security mechanism can be used where PID serve as the shared secret. 3.6. Cellular IP Routing Cellular IP nodes need only to implement the algorithm described in this section. They do not need regular IP routing capability. This section describes the routing algorithm in Cellular IP nodes other than the Gateway. The extra functions required only in the Cellular IP Gateway are described in Section 3.7. 3.6.1 Topology In uplink direction (toward the Gateway), packets are routed in the Cellular IP Network on a hop-by-hop basis. The neighbor to which a node will forward a packet toward the Gateway is referred to as the node's Uplink neighbor. The Uplink neighbor at each node may be designated by network management. Alternatively, a simplified shortest path algorithm can select Uplink neighbors instead of manual configuration. (A regular shortest path algorithm is also applicable but is more complex than required since it determines routes to all nodes in the network.) A simple algorithm that configures Uplink neighbors and automatically reconfigures them if necessary after a topology change is described in Appendix A. A node's neighbors other than the Uplink neighbor are called Downlink neighbors. 3.6.2 Uplink Routing A packet arriving at a node from one of its Downlink neighbors is assumed to be coming from a mobile host. The packet is first used to update the node's Route and Paging Caches and is then forwarded to the node's Uplink neighbor. To update the Caches, the node reads the packet type, port number and the source IP address. Paging-update packets update the Paging Cache only. Route-update packets update both Route and Paging Caches. Data packets only refresh the soft state of both caches, but do not change it. Both types of caches consist of { IP-address, interface, MAC address, expiration time, timestamp } 5-tuples, called mappings. The IP address is the address of the mobile host the mapping corresponds to. The interface and the MAC address denote the Downlink neighbor toward the mobile host. The timestamp field contains the timestamp of the control packet that has Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 15] INTERNET-DRAFT Cellular IP January 2000 established the mapping. When a data packet arrives from a Downlink neighbor, the Route Cache entry of the source IP address is searched first. If the data packet is coming from the same neighbor as indicated by the cache entry then it is sent from the direction where the mobile host was last seen. In that case the mapping is only refreshed: the expiration time is set to the current time + route-timeout. If the node has Paging Cache, then the expiration time of the mapping in the Paging Cache is set to current time + paging-timeout as well. Then the packet is forwarded to the uplink. If the data packet arrived from a different neighbor than that is in its mapping or no mapping exists for the IP address, then the packet is dropped. When an update packet arrives from a Downlink neighbor then the authentication is first validated. Packets with invalid authentication must be dropped and the event should be logged as a potential tampering attempt. For valid packets the node creates the following 5-tuple: { the newly arrived packet's source IP address, the interface through which it arrived, the source MAC address of the arrived packet, current time + route-timeout, the timestamp in the arrived update packet } This mapping is used to update Route Cache, if the incoming packet is a route-update packet. If a valid mapping for the source IP address already exists, then it is replaced by the new 5-tuple, if the timestamp is newer, otherwise the packet is dropped. If no mapping exists for the source IP address then the mapping is added to the Route Cache. The Paging Cache is updated in the same way, but using paging-timeout instead of route-timeout. If the node has no Paging Cache then only the Route Cache is updated. If the incoming packet is a paging-update, then only the Paging Cache is updated (if any). If the packet is a paging-teardown packet and the authentication information is valid, then mappings of the mobile host with timestamp earlier than the timestamp of the packet are removed from both the Route and the Paging Cache. After cache modifications the control packet is forwarded to the Uplink neighbor. 3.6.3 Downlink Routing A packet arriving to a Cellular IP node from the Uplink neighbor is assumed to be addressed to a mobile host. The node first checks if the destination IP address has a valid mapping in the Route Cache. If such a mapping exists, the packet is forwarded to the Downlink neighbor found in the mapping. Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 16] INTERNET-DRAFT Cellular IP January 2000 If the Route Cache contains no mapping for the destination IP address and the node has no Paging Cache, then the packet is broadcast on all interfaces of the node except the interface of the Uplink neighbor. If the node has Paging Cache and there is a mapping for the destination IP address, then the packet is forwarded to the neighbor found in that mapping. If the node has Paging Cache, but there is no mapping for the destination IP address, then the packet is dropped. 3.7. Cellular IP Gateway The following figure is a schematic view of a Cellular IP Gateway. The Gateway can logically be divided into three building blocks: a regular Cellular IP node, a Gateway Packet Filter and a Gateway Controller. IP network =================== | +------------------------------|--------+ | | | | +----------+ +-------------+ | | | Gateway |__________| Gateway | | | |Controller| |Packet Filter| | | +----------+ +-------------+ | | |\_______|___Uplink neighbor | | | | +-------------+ | | Cellular IP | Cellular IP | | | Gateway | node | | | +-------------+ | | | | | | +-------------------------|----|----|---+ <----Downlink neighbors Uplink packets update the Route and/or Paging Caches in the Cellular IP node block and are forwarded towards the Gateway filter. The Gateway filter reads the destination IP address. If this is the Gateway's address, the packet is forwarded to the Gateway controller. Most of these packets are control packets with empty control information field and are immediately dropped. If the packet carries control information, for instance a registration request, it is interpreted and processed by the Gateway controller. If the destination address is not the Gateway's, the packet is forwarded to the Internet. (This means that a packet sent from a mobile host to another mobile host in the same Cellular IP Network goes through the destination Home Agent. However, this is not the case if route optimization is used. To operate efficiently even without Mobile IP route optimization, the Gateway Packet Filter can also check if the destination address of an uplink packet has a valid mapping in any of the Gateway's caches. If a mapping is found, the Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 17] INTERNET-DRAFT Cellular IP January 2000 packet is "turned back" and is treated as a downlink packet.) Packets arriving from the Internet (using Mobile IP) to mobile hosts in the Cellular IP Network are decapsulated and forwarded to the Cellular IP node block. Arriving packets not using Mobile IP are assumed to be sent to mobile hosts of which this Cellular IP Network is the home network. If no foregin registration shows that the mobile host is away, these packets are forwarded to the Cellular IP node block unchanged. The Gateway's Cellular IP node block treats these packets as determined by the Cellular IP Routing algorithm (Section 3.5) according to the mappings in Route and Paging Cache. It is optional whether Cellular IP Nodes have Paging Cache configured or not. However, it is recommended that at least the Gateway's Cellular IP node has Route Cache configured. This ensures that packets addressed to hosts currently not connected to the Cellular IP Network do not enter the network and do not load it in vain but are immediately discarded in the Gateway when neither Route, nor Paging Cache mapping is found for the destination address. (It may be advantageous to also generate an ICMP message in this case and send it back to the packet's source address.) 3.8. Cellular IP Mobile Host While connected to a Cellular IP Network, a mobile host must be in one of two states: 'active' or 'idle'. The host moves from idle to active state when it receives or wishes to send a data packet. Active state is maintained as long as the host is transmitting or receiving data packets. When the host has not received or transmitted any data packets for some time (the value of this timer may be implementation-specific) then it returns to idle state. When the host moves from idle to active state, it must transmit a route-update packet. At the same time, a timer is initiated from a value equal to route-update-time. If the timer expires without any data packet being transmitted from the host, again a route-update packet is transmitted and the timer is re-initiated. Any IP packet transmitted before the timer expires, resets the timer to route- update-time. This ensures that while the mobile host is in active state, the largest interval between two transmitted packets is never longer than route-update-time. The mechanism also ensures that if data packets are transmitted with sufficient frequency, no route- update packets will be generated, which will probably be typical. If the host is in active state, it must immediately transmit a route-update packet whenever it connects to a new base station. This typically happens at migration, but is also the case after a wireless channel black-out or when the host enters the Cellular IP Network. A packet transmitted this way also resets the route-update packet timer. In idle state, the mobile host must transmit paging-update packets periodically, at intervals of paging-update-time. In addition, the Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 18] INTERNET-DRAFT Cellular IP January 2000 host must transmit a paging-update packet when it connects to a new Base Station which has a different Paging Area ID from the previous Base Station. (When connecting to a Base Station that belongs to the same Paging Area as the previous one, the host need not transmit paging-update packet.) Similarly to the route-update packet timer, the paging-update timer is reset if a data packet is transmitted. The mobile host must ensure that the 64 bit value of timestamps is strictly increasing in consecutive control packets. 4. Extensions to Cellular IP 4.1. Semi-soft Handoff When a mobile host switches to a new Base Station it sends a route- update packet to make the chain of cache bindings to point to the new Base Station. Packets that are traveling on the old path will be delivered to the old Base Station and will be lost. Although this loss may be small it can potentially degrade TCP throughput. This kind of handoff, when the mobile switches all at once to the new Base Station is called "hard" handoff. For performance details of hard handoff in a Cellular IP network see [5]. To improve the performance of loss sensitive applications, another type of handoff may be introduced, called "semi-soft" handoff. During semi-soft handoff a mobile host may be in contact with either of the old and new Base Stations and receive packets from them. Packets intended to the mobile host are sent to both Base Stations, so when the mobile host eventually moves to the new location it can continue to receive packets without interruption. To initiate semi-soft handoff, the moving mobile host transmits a route-update packet to the new Base Station and continues to listen to the old one. The S flag is set in this route-update packet to indicate semi-soft handoff. Semi-soft route-update packets create new mappings in the Route and Paging Cache similarly to regular route-update packets. When the semi-soft route-update packet reaches the cross-over node where the old and new path meet (note that the cross-over node already has a mapping for the mobile host), the new mapping is added to the cache instead of replacing the old one. Packets sent to the mobile host are transmitted to both Downlink neighbors. When the mobile host eventually makes the move then the packets will already be underway to the new Base Station and the handoff can be performed with minimal packet loss. After migration the mobile host sends a route-update packet to the new Base Station with the S bit cleared. This route-update packet will remove all mappings in Route Cache except for the ones pointing to the new Base Station. The semi-soft handoff is then complete. If the path to the new Base Station is longer than to the old Base Station or it takes non negligible time to switch to the new Base Station, then some packets may not reach the mobile host. To overcome the problem, packets sent to the new Base Station can be delayed during the semi-soft handoff. This way a few packets may be Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 19] INTERNET-DRAFT Cellular IP January 2000 delivered twice to the mobile host, but in many cases this results in better performance than a few packets lost. Introduction of packet delay can be best performed in the Cellular IP node that has multiple mappings for the mobile host as a result of a semi-soft route-update packet. Packets that belong to flows that require low delay but can tolerate occasional losses should not be delayed. For performance details of semi-soft handoff in a Cellular IP network see [5]. ***4.2. Multiple Gateway Networks Cellular IP requires that a mobile host be using exactly one Gateway at a time. This requirement comes from the fact that the Gateway serves as the mobile host's Foreign Agent and it relays its packets both up and downlink. It is also required to make uplink routing unambiguous. The Cellular IP Network can have multiple Gateways as long as a single host still uses just one Gateway at any time. (The host can change Gateway, involving a Mobile IP location updating.) In a Network with multiple Gateways, nodes must be able to determine which Gateway a given mobile host is using. Assignment of Gateways can, for instance, be based on geographical partitioning of the network, or on partitioning the mobile hosts' address space. This issue is for further study. * ***see ch 3.2.2. a change of the gateway results in a change of the IP-Address of the mobile host. Therefore the second CU field in the Route-update-packet could be used to transmit the new IP-Adress. In the Control-information field the change of gateway and the change of Ip-Address could be used as described in ch 3.2.2.**** 4.3. Charging Cellular IP Network providers can charge Cellular IP Mobile users for connectivity or for transmitted data or both. Charging information is best collected in the Gateway. The Gateway receives all control packets and can determine the time a mobile host was connected to the network. It can also measure through traffic in both directions. 5. Security Considerations A Cellular IP Network is a single administrative domain. It is connected to the Internet through a Gateway that may eventually also serve as a firewall. Hence security issues only need to be considered at the wireless interface. The security of a Cellular IP system will be determined by the wireless link. Security issues relating to wireless links are not specific to Cellular IP, and are out of the scope of Cellular IP, even though they must be dealt with in practical Cellular IP implementations. A security problem specific to Cellular IP is the security of the control packets, which can be solved by the authentication mechanism described in Section 3.5. 6. Intellectual Property Right Notice This is to affirm that Telefonaktiebolaget LM Ericsson and its subsidiaries, in accordance with corporate policy, will offer patent licensing for submissions rightfully made by its employees which are adopted or recommended as a standard by your organization as follows: Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 20] INTERNET-DRAFT Cellular IP January 2000 If part(s) of a submission by Ericsson employees is (are) included in a standard and Ericsson has patents and/or patent application(s) that are essential to implementation of such included part(s) in said standard, Ericsson is prepared to grant - on the basis of reciprocity (grantback) - a license on such included part(s) on reasonable, non- discriminatory terms and conditions. Ericsson has filed patent applications that might possibly become essential to the implementation of this contribution. References [1] "IP Mobility Support," C. Perkins, ed., IETF RFC 2002, October 1996. [2] "Network Time Protocol (Version 3): Specification, Implementation and Analysis," D. Mills, IETF RFC 1305, March 1992. [3] "IP Authentication Header," R. Atkinson, IETF RFC 1826, August 1995. [4] "IP Authentication using Keyed MD5," P. Metzger, W. Simpson, IETF RFC 1828, August 1995. [5] "Cellular IP Performance," A. T. Campbell, J. Gomez, S. Kim, Z. Turanyi, A. Valko, C-Y Wan, Work in Progress, , October 1999. Authors' Addresses Andrew T. Campbell, Javier Gomez, Sanghyo Kim, Chieh-Yih Wan Department of Electrical Engineering, Columbia University Rm. 801 Schapiro Research Building 530 W. 120th Street, New York, N.Y. 10027 phone: (212) 854 3109 fax : (212) 316 9068 email: {campbell,javierg,shkim2,wan}@comet.columbia.edu Zoltan R. Turanyi, Andras G. Valko Ericsson Traffic Analysis and Network Performance Laboratory H-1300 Bp.3.P.O.Box 197, Hungary phone: +36 1 437 7774 fax : +36 1 437 7219 email: {zoltan.turanyi,andras.valko}@eth.ericsson.se Appendix A. Uplink Neighbor Selection This algorithm selects the Uplink neighbor of all nodes of a Cellular IP Network and reconfigures them if necessary after a change of topology. An Uplink neighbor is identified by the **non-air** interface through which it is accessible from the node and its corresponding MAC address. The algorithm also distributes the Cellular IP Network Identifier, the IP address of the Gateway and the Paging Area IDs to the Base Stations. Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 21] INTERNET-DRAFT Cellular IP January 2000 The Gateway periodically creates a control packet called a "Gateway broadcast packet". The Gateway broadcast packet contains - the Cellular IP Network Identifier; - the IP address of the Gateway; - a sequence number increased each time by the Gateway; and - a Paging Area ID field initially set to the ID of the Gateway. The Gateway broadcasts the packet on all of its **non-air**interfaces except those connected to the Internet. A Cellular IP node receiving a Gateway broadcast packet follows the steps below. 1) It drops the packet if the sequence number is lower or equal to the sequence number of one of the previously received Gateway broadcast packets. In this case no further processing is needed. 2) It stores the sequence number of the Gateway broadcast packet for later comparison. [3) It stores the Cellular IP Network Identifier and the IP address of the Gateway]. 3) It stores the **non-air**interface through which the packet arrived together with source MAC address of the packet (if any) to identify the Uplink neighbor. All other interface/MAC address combinations will denote Downlink neighbors. 4) If the node has a Paging Cache, it overwrites the value of the Paging Area ID field in the packet by its own ID. 5) The value of the (possibly overwritten) Paging Area ID field is stored as the Paging Area ID of the node. This value will be used in beacon signals if the node is a Base Station. 6) It stores the Cellular IP Network Identifier and the IP address of the Gateway. These values will be used in beacon signals if the node is a Base Station. 7) After a short random delay, the node broadcasts the packet through all of its interfaces, except the air interface(s) and the interface of the Uplink neighbor. Campbell, Gomez, Kim, Wan, Turanyi, Valko [Page 22] --135593989.961078623903.JavaMail.nobody@fmweb02.unimessage.net-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 15 14:46:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11606 for ; Thu, 15 Jun 2000 14:46:14 -0400 (EDT) Received: from standards (47.234.32.16:2470) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75D7F@standards.nortelnetworks.com>; Thu, 15 Jun 2000 14:36:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0329 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 15 Jun 2000 14:36:48 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75D7A@standards.nortelnetworks.com>; Thu, 15 Jun 2000 14:26:48 -0400 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25987; Thu, 15 Jun 2000 11:35:31 -0700 (PDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA29070; Thu, 15 Jun 2000 14:35:30 -0400 (EDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by atlantic.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id OAA24917; Thu, 15 Jun 2000 14:36:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 15 Jun 2000 14:35:27 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] Deregistration question... X-To: Jonathan Khoo To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <20000615015046.97639.qmail@hotmail.com> > Hi there, > > Thanks for the reply. Is there anyway to prevent traffic from going to a > bogus MN after it has sent it's gratutious ARP and deregistration fails? > Jonathan According to the way 2002-bis is written, no. The HA would have to reclaim the address after the unsucessful dereg, which isn't allowed. This is done to make things no worse than they would be without mobile ip. Any other node can gratuitous arp for the mobile's IP address, thereby stealing the traffic. If *whomever* fails the dereg (bad nonce, whatever) it's better for the HA to not take the MN's IP address back, thereby potentially stealing the traffic from a legitimate mobile node (no different than a node stealing the address, but which wouldn't be likely to attempt to deregister), rather than taking the address back and stealing the traffic. If the HA gets another registration request from the mobile node, though, it should absolutely take the address (gratuitous ARP). Perhaps a better strategy may be if the MN fails authentication the HA should gratuitous arp the address back, but any other error the HA shouldn't. Anyone have a good reason why this isn't done? Cheers, Steve > > This is also probably where the disclaimer normally goes that >this > >use of ARP doesn't make the network less secure or chaotic than >in the > >non-mobile case; anyone can gratuitous arp an address if they >so choose. > > > > Cheers, > > Steve > > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 15 20:55:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18890 for ; Thu, 15 Jun 2000 20:55:13 -0400 (EDT) Received: from standards (47.234.32.16:3278) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75DFD@standards.nortelnetworks.com>; Thu, 15 Jun 2000 20:45:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0501 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 15 Jun 2000 20:45:42 -0400 Received: from hotmail.com (law2-f227.hotmail.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75DFC@standards.nortelnetworks.com>; Thu, 15 Jun 2000 20:45:41 -0400 Received: (qmail 85688 invoked by uid 0); 16 Jun 2000 00:54:32 -0000 Received: from 203.181.29.97 by www.hotmail.com with HTTP; Thu, 15 Jun 2000 17:54:32 PDT X-Originating-IP: [203.181.29.97] Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: <20000616005432.85687.qmail@hotmail.com> Date: Fri, 16 Jun 2000 08:54:32 SGT Reply-To: Jonathan Khoo Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jonathan Khoo Subject: Re: [MOBILE-IP] Deregistration question... X-To: Steven.Glass@East.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Steven, Thanks for your clarification. I think another way would be as what you have suggested earlier, that is to have a buffer to collect the packets at the FA when the MN moves away. In this case, there is absolutely no need for the MN to gratutious ARP first before the deregistration as the packets can be delivered after successful deregistration. Of course, this would then have an effect on delay sensitive data. Then again, anyone has any idea what's the timeframe of the deregistration process? 1 sec (max)? Probably it's not that important after all.... :P Cheers, Jonathan >From: Steven Glass - Solaris Software >Reply-To: Steven Glass - Solaris Software >To: Jonathan Khoo >CC: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM >Subject: Re: [MOBILE-IP] Deregistration question... >Date: Thu, 15 Jun 2000 14:35:27 -0400 (EDT) > > > Hi there, > > > > Thanks for the reply. Is there anyway to prevent traffic from going to a > > bogus MN after it has sent it's gratutious ARP and deregistration fails? > > > Jonathan > > According to the way 2002-bis is written, no. The HA would have to >reclaim the address after the unsucessful dereg, which isn't allowed. This >is >done to make things no worse than they would be without mobile ip. Any >other >node can gratuitous arp for the mobile's IP address, thereby stealing the >traffic. If *whomever* fails the dereg (bad nonce, whatever) it's better >for >the HA to not take the MN's IP address back, thereby potentially stealing >the >traffic from a legitimate mobile node (no different than a node stealing >the >address, but which wouldn't be likely to attempt to deregister), rather >than >taking the address back and stealing the traffic. If the HA gets another >registration request from the mobile node, though, it should absolutely >take >the address (gratuitous ARP). > > Perhaps a better strategy may be if the MN fails authentication the HA >should gratuitous arp the address back, but any other error the HA >shouldn't. >Anyone have a good reason why this isn't done? > > Cheers, > Steve > > > > > This is also probably where the disclaimer normally goes that > >this > > >use of ARP doesn't make the network less secure or chaotic than >in the > > >non-mobile case; anyone can gratuitous arp an address if they >so >choose. > > > > > > Cheers, > > > Steve > > > > ________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > > > ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 16 01:57:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29941 for ; Fri, 16 Jun 2000 01:57:00 -0400 (EDT) Received: from standards (47.234.32.16:2065) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75EA5@standards.nortelnetworks.com>; Fri, 16 Jun 2000 1:47:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0706 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 16 Jun 2000 01:47:29 -0400 Received: from q1u8b6 (abq145.cnsp.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB75EA0@standards.nortelnetworks.com>; Fri, 16 Jun 2000 1:37:28 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 16 Jun 2000 01:47:29 -0400 Reply-To: Gary Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Gary Subject: [MOBILE-IP] E-Malls To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Own an Internet Mall ONLY $99.50 per year. Become RICH from others buying at your mall. ie. Dell, Barnes & Noble, Ebay and 1,200 others. gc@usafan.net We received your name as someone interested in receiving business opportunity information. If was an error, and you wish from our list, please reply to gcr@usafan.net All mailings are sent complying to the proposed United States Federal requirements for commercial e-mail (S1618 Section 301). Paragraph (a)(2)(c) of S. 1618 102 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 16 13:15:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17526 for ; Fri, 16 Jun 2000 13:15:29 -0400 (EDT) Received: from standards (47.234.32.16:1839) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB760CF@standards.nortelnetworks.com>; Fri, 16 Jun 2000 13:05:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1423 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 16 Jun 2000 13:05:55 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB760CE@standards.nortelnetworks.com>; Fri, 16 Jun 2000 13:05:54 -0400 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17827 for ; Fri, 16 Jun 2000 11:14:47 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA10617 for ; Fri, 16 Jun 2000 10:14:46 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA27569 for ; Fri, 16 Jun 2000 10:14:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 16 Jun 2000 10:14:21 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: [MOBILE-IP] WG Internet Drafts to last call... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM All, I was wondering if the following Internet Drafts could be moved to WG last call, and sent to the IESG for publication: 1. draft-ietf-mobileip-mier-03.txt. This one has already received interoperability, and I believe it is ready. 2. draft-ietf-mobileip-aaa-key-01.txt. This one was also sucessfully tested at the last connectathon, and should be moved ahead. 3. draft-ietf-mobileip-gnaie-00.txt. This fairly non-controversial draft is a no-brainer and should be moved ahead as well. Thanks, PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 16 14:46:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20667 for ; Fri, 16 Jun 2000 14:46:05 -0400 (EDT) Received: from standards (47.234.32.16:1587) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7610B@standards.nortelnetworks.com>; Fri, 16 Jun 2000 14:36:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1506 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 16 Jun 2000 14:36:41 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7610A@standards.nortelnetworks.com>; Fri, 16 Jun 2000 14:36:40 -0400 Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id VAA06374; Fri, 16 Jun 2000 21:45:21 +0300 (EETDST) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id VAA09056; Fri, 16 Jun 2000 21:45:19 +0300 (EETDST) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id ; Fri, 16 Jun 2000 13:43:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2BCD5123@daeis07nok> Date: Fri, 16 Jun 2000 13:43:08 -0500 Reply-To: Basavaraj.Patil@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Basavaraj Patil Subject: Re: [MOBILE-IP] WG Internet Drafts to last call... X-cc: Pat.Calhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Pat, >All, > >I was wondering if the following Internet Drafts could be moved to WG >last call, and sent to the IESG for publication: >1.draft-ietf-mobileip-mier-03.txt. >This one has already received interoperability, and I believe it is >ready. This one has already completed WG last call and has been submitted to the IESG. >2.draft-ietf-mobileip-aaa-key-01.txt. This one was also sucessfully >tested at the last connectathon, and should be moved ahead. References to DIAMETER in this document need to be removed and also the use of MD5 as suggested in the draft needs to be updated to be more in-line with the FA challenge draft (ver.12). Maybe you should reissue a new draft and then we can do a WG last call. >3.draft-ietf-mobileip-gnaie-00.txt. This fairly non-controversial >draft is a no-brainer and should be moved ahead as well. Sounds reasonable. > >Thanks, > >PatC -Basavaraj From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sat Jun 17 02:04:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15075 for ; Sat, 17 Jun 2000 02:04:06 -0400 (EDT) Received: from standards (47.234.32.16:2649) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7623B@standards.nortelnetworks.com>; Sat, 17 Jun 2000 1:54:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1882 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sat, 17 Jun 2000 01:54:35 -0400 Received: from q1u8b6 (abq137.cnsp.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7623A@standards.nortelnetworks.com>; Sat, 17 Jun 2000 1:44:34 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sat, 17 Jun 2000 01:54:35 -0400 Reply-To: Greg Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Greg Subject: [MOBILE-IP] .com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello, It's So Simple To Earn thousands per week Nowadays... We're searching for only 10 elite individuals with the work ethic necessary to generate a cash-flow for themselves of $500 - 5,000 per week, and to increase that to over $20,000 per month, in as little as four to six months. If you really have a burning desire and commitment. Do you have the self-discipline to ignore the TV for a couple of hours per day? Are you looking for a legitimate home-based business opportunity, With one of the fastest growing companies in America. If you would like to build an amazing income that will grow lighting-fast then this is for you! You can build your business under our guidance and support. You have nothing to lose, there's no risk involved, nor is there any obligation whatsoever, and you may be qualified to earn thousands of extra dollars per month! So click on now! To find out more about this opportunity. P.S. You literally have a once-in-a-lifetime opportunity to GET INVOLVED NOW! Don't let this one go by. You have absolutely nothing to lose! This could be the most fascinating and profitable business of your life! Please, serious inquiries only. Don't waste my time. gs@dovecanyon.com We received your name as someone interested in receiving business opportunity information. If was an error, and you wish from our list, please reply to gsr@dovecanyon.com All mailings are sent complying to the proposed United States Federal requirements for commercial e-mail (S1618 Section 301). Paragraph (a)(2)(c) of S. 1618 103 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jun 18 02:08:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07469 for ; Sun, 18 Jun 2000 02:08:16 -0400 (EDT) Received: from standards (47.234.32.16:1537) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB763C7@standards.nortelnetworks.com>; 18 Jun 2000 1:58:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2391 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 18 Jun 2000 01:58:27 -0400 Received: from q1u8b6 (abq141.cnsp.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB763C6@standards.nortelnetworks.com>; 18 Jun 2000 1:48:24 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sun, 18 Jun 2000 01:58:27 -0400 Reply-To: John Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: John Subject: [MOBILE-IP] It's been a long time To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM WHY NOT WORK FOR YOUR SELF AND KEEP ALL THE PROFITS? It's a fact that 7 out of 10 millionaires became rich by being in business for themselves. If you want to succeed, the surest way to get there is to go with a proven successful role model. Statistics show that 92% of those that link up with a proven business DO SUCCEED. Our company is a debt free business that offers you the opportunity and direction to run your own home based business. Taxes take 35% of your income this is a big opportunity. There are 120 million people who actually would like to talk to you. You just need that burning desire. If you are serious about wanting to get out of the rat race, this could be your personal escape plan. We have a full information package waiting for you. Take the first step towards improving your lifestyle, enjoying financial freedom and tasting success. jk2@parsmail.com We received your name as someone interested in receiving business opportunity information. If was an error, and you wish to be removed from our list, please reply to jkr@parsmail.com All mailings are sent complying to the proposed United States Federal requirements for commercial e-mail (S1618 Section 301). Paragraph (a)(2)(c) of S. 1618 104 From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jun 18 23:32:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14361 for ; Sun, 18 Jun 2000 23:32:31 -0400 (EDT) Received: from standards (47.234.32.16:4476) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76552@standards.nortelnetworks.com>; 18 Jun 2000 23:22:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2942 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 18 Jun 2000 23:22:51 -0400 Received: from tsbgw.wide.toshiba.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76551@standards.nortelnetworks.com>; 18 Jun 2000 23:22:48 -0400 Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id MAA21867; Mon, 19 Jun 2000 12:31:30 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id MAA23574; Mon, 19 Jun 2000 12:31:30 +0900 (JST) Received: from tanuki (tanuki.isl.rdc.toshiba.co.jp [133.196.16.162]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with SMTP id MAA04128; Mon, 19 Jun 2000 12:31:30 +0900 (JST) References: <20000615015046.97639.qmail@hotmail.com> X-Mailer: Datula version 1.21.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200006190331.MAA04128@isl.rdc.toshiba.co.jp> Date: Mon, 19 Jun 2000 12:42:29 +0900 Reply-To: Yoshiyuki Tsuda Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yoshiyuki Tsuda Organization: Corporate R&D Center, Toshiba Corporation Subject: Re: [MOBILE-IP] Deregistration question... X-To: Steven Glass - Solaris Software To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Hi, Steve, I agree with you this isn't an MIP specific issue but a common issue. I have another related issue: an MN will often register its HA without B-bit. Then, if an erroneous node sends erroneous gratuitous ARPs, the HA can detect them, but not relay them to the MN. So, in this case, the MN cannot detect such erroneous ARPs. I think, it might be better an HA should relay such erroneous ARPs to an MN, whether the B-bit is set or not. Thanks. -Yoshi On Thu, 15 Jun 2000 14:35:27 -0400, Steven Glass - Solaris Software wrote: >> > Hi there, >> > >> > Thanks for the reply. Is there anyway to prevent traffic from going to a >> > bogus MN after it has sent it's gratutious ARP and deregistration fails? >> >> > Jonathan >> >> According to the way 2002-bis is written, no. The HA would have to >> reclaim the address after the unsucessful dereg, which isn't allowed. This is >> done to make things no worse than they would be without mobile ip. Any other >> node can gratuitous arp for the mobile's IP address, thereby stealing the >> traffic. If *whomever* fails the dereg (bad nonce, whatever) it's better for >> the HA to not take the MN's IP address back, thereby potentially stealing the >> traffic from a legitimate mobile node (no different than a node stealing the >> address, but which wouldn't be likely to attempt to deregister), rather than >> taking the address back and stealing the traffic. If the HA gets another >> registration request from the mobile node, though, it should absolutely take >> the address (gratuitous ARP). >> >> Perhaps a better strategy may be if the MN fails authentication the HA >> should gratuitous arp the address back, but any other error the HA shouldn't. >> Anyone have a good reason why this isn't done? >> >> Cheers, >> Steve >> >> >> > > This is also probably where the disclaimer normally goes that >this >> > >use of ARP doesn't make the network less secure or chaotic than >in the >> > >non-mobile case; anyone can gratuitous arp an address if they >so choose. >> > > >> > > Cheers, >> > > Steve >> > >> > ________________________________________________________________________ >> > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com >> > >> From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 19 07:47:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00192 for ; Mon, 19 Jun 2000 07:47:20 -0400 (EDT) Received: from standards (47.234.32.16:2518) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB766DE@standards.nortelnetworks.com>; Mon, 19 Jun 2000 7:37:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3393 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 19 Jun 2000 07:37:29 -0400 Received: from goliath.siemens.de (194.138.37.131:63102) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB766DD@standards.nortelnetworks.com>; Mon, 19 Jun 2000 7:37:28 -0400 X-Envelope-Sender-Is: jochen.grimminger@mchp.siemens.de (at relayer goliath.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.10.1/8.10.1) with ESMTP id e5JBkGB14626; Mon, 19 Jun 2000 13:46:16 +0200 (MET DST) Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.202.157]) by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e5JBkFP21291; Mon, 19 Jun 2000 13:46:16 +0200 (MET DST) Received: from mhpa2f1c (mhpa2s1c.mchp.siemens.de [139.23.200.185]) by mail-y.mchp.siemens.de (8.9.3/8.9.3) with SMTP id NAA10219; Mon, 19 Jun 2000 13:46:15 +0200 (MET DST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: Date: Mon, 19 Jun 2000 13:46:06 +0200 Reply-To: jochen.grimminger@mchp.siemens.de Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Grimminger Jochen Subject: [MOBILE-IP] Fast Handovers/offs X-To: "Charles E. Perkins" , Pat Calhoun , Karin ElMalki To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hallo Charlie, i'm just wondering, are you thinking about merging some ideas from Pat Calhoun or Karim El Malki for Fast Handoffs/overs into your RegTun Draft ? With one is prefered or are you three working allready together to produce a Draft-ietf document for Pittsburgh ;-) ... as RegTun seems to be a very promissing basis for improving latencies and packet loss Best Regards Jochen ******************************** Dipl. Phys. Jochen Grimminger Siemens AG Otto-Hahn Ring 6 81730 Munich +49 89 636 41740 +49 89 636 51115 ******************************** From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 19 14:56:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20306 for ; Mon, 19 Jun 2000 14:56:37 -0400 (EDT) Received: from standards (47.234.32.16:1487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB768E3@standards.nortelnetworks.com>; Mon, 19 Jun 2000 14:46:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0248 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 19 Jun 2000 14:46:58 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB768A3@standards.nortelnetworks.com>; Mon, 19 Jun 2000 14:36:55 -0400 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19351; Mon, 19 Jun 2000 11:45:48 -0700 (PDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA14599; Mon, 19 Jun 2000 14:45:46 -0400 (EDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by atlantic.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id OAA05691; Mon, 19 Jun 2000 14:46:22 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 19 Jun 2000 14:45:42 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] Deregistration question... X-To: Yoshiyuki Tsuda To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <200006190331.MAA04128@isl.rdc.toshiba.co.jp> > Hi, Steve, > > I agree with you this isn't an MIP specific issue but a common issue. > > I have another related issue: an MN will often register its HA without > B-bit. Then, if an erroneous node sends erroneous gratuitous ARPs, the > HA can detect them, but not relay them to the MN. So, in this case, > the MN cannot detect such erroneous ARPs. > I think, it might be better an HA should relay such erroneous ARPs to > an MN, whether the B-bit is set or not. Tsudasan, This is a nice feature! The HA lets the mobile node, if it's still on the other end of the tunnel, know that someone's captured its address. If it's still at the other end of the tunnel, it reregisters to allow the HA to resend a gratuitous arp and recapture the address. Sure, the MN can't compete with a bag-guy on the home subnet, but it could certainly let a user know what's happening... Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 19 17:36:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24047 for ; Mon, 19 Jun 2000 17:36:28 -0400 (EDT) Received: from standards (47.234.32.16:4018) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB769A2@standards.nortelnetworks.com>; Mon, 19 Jun 2000 17:26:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0566 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 19 Jun 2000 17:26:58 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76994@standards.nortelnetworks.com>; Mon, 19 Jun 2000 17:16:58 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Mon Jun 19 17:25:56 EDT 2000 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id RAA03870; Mon, 19 Jun 2000 17:26:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Message-ID: <001b01bfda34$d4ad6070$72f0b487@dnrc.belllabs.com> Date: Mon, 19 Jun 2000 17:25:03 -0400 Reply-To: Sandy Thuel Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sandy Thuel Subject: [MOBILE-IP] Use of DHCP and Mobile IP X-cc: "Tlp@Lucent. Com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I am pleased to announce that we have completed and submitted a draft proposing a solution for dynamic home addressing on mobile hosts that use Mobile IP for mobility and DHCP for configuration. The draft describes a procedure called "transient tunneling" that requires no changes to the Mobile IP nor DHCP standards, while enabling mobile hosts to dynamically acquire their home address and other configuration parameters when they power up in a foreign network. A recent I-D posted on this list by Steve Glass was targeted at addressing the same problem, though following a different approach from ours. (Nice job, Steve!) We are encouraged to see interest in this problem and hope to spur continued interest and progress on defining a solution. Sandy Thuel Bell Labs, Lucent Technologies From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 19 17:43:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24106 for ; Mon, 19 Jun 2000 17:43:03 -0400 (EDT) Received: from standards (47.234.32.16:4018) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB769CC@standards.nortelnetworks.com>; Mon, 19 Jun 2000 17:32:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0581 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 19 Jun 2000 17:32:59 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB769A1@standards.nortelnetworks.com>; Mon, 19 Jun 2000 17:22:59 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by crufty; Mon Jun 19 17:30:43 EDT 2000 Received: from blhothuelpc (thuelpc [135.180.240.114]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id RAA04261 for ; Mon, 19 Jun 2000 17:30:48 -0400 (EDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001E_01BFDA13.F841D140" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Message-ID: <001d01bfda35$7f537140$72f0b487@dnrc.belllabs.com> Date: Mon, 19 Jun 2000 17:29:49 -0400 Reply-To: Sandy Thuel Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sandy Thuel Subject: [MOBILE-IP] Use of DHCP and Mobile IP To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_001E_01BFDA13.F841D140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I am pleased to announce that we have completed and submitted a draft proposing a solution for dynamic home addressing on mobile hosts that use Mobile IP for mobility and DHCP for configuration. The draft describes a procedure called "transient tunneling" that requires no changes to the Mobile IP nor DHCP standards, while enabling mobile hosts to dynamically acquire their home address and other configuration parameters when they power up in a foreign network. A recent I-D posted on this list by Steve Glass was targeted at addressing the same problem, though following a different approach from ours. (Nice job, Steve!) We are encouraged to see interest in this problem and hope to spur continued interest and progress on defining a solution. Sandy Thuel Bell Labs, Lucent Technologies ------=_NextPart_000_001E_01BFDA13.F841D140 Content-Type: text/plain; name="draft-thuel-mobileip-tt-00.txt" Content-Disposition: attachment; filename="draft-thuel-mobileip-tt-00.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force S.Thuel / L.Salgarelli / R.Ramjee / INTERNET-DRAFT K.Varadhan / T.LaPorta draft-thuel-mobileip-tt-00.txt Bell Labs - Lucent Technologies Date: 19 June 2000 Expires: 19 December 2000 Dynamic Home Addressing in Mobile IP using Transient Tunnels Status of this memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract Dynamic home addressing has lately become a popular and viable approach for configuring mobile IP hosts. This draft introduces a method for these hosts to dynamically acquire a home address through DHCP when powering up in a foreign network, referred to as the Transient Tunneling (TT) procedure. Our procedure solves the problem that mobile hosts cannot rely on conventional broadcasting Thuel et al. Expires 12/00 [Page 1] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 procedures to properly discover an addressing server in their home network. While leveraging the growing DHCP code-base, our procedure requires no changes to protocol standards and only minor changes to server implementations. In addition, its impact on host power-up latency is acceptable in conventional wide-area networks scenarios. Alternative solutions are discussed along with other issues related to dynamic addressing on mobile hosts such as wireless bandwidth usage. Table Of Contents: 1 Introduction 3 2 Mobility and DHCP: The Broadcasting Problem 4 3 Transient Tunneling Solution 6 4 Implementation Issues 9 4.1 Registration Latency ..................................... 9 4.2 Mobile Client ............................................ 10 4.3 Home Agent ............................................... 10 4.4 DHCP Server .............................................. 10 4.5 Private Addressing Support ............................... 11 4.6 Network Administration ................................... 11 5 Alternative Solutions 12 6 Other Issues 16 6.1 Efficient Wireless Bandwidth Usage ....................... 16 6.2 External Foreign Agents .................................. 18 7 Security considerations 18 8 Acknowledgements 19 Thuel et al. Expires 12/00 [Page 2] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 1 Introduction While the Mobile IP (M-IP) protocol [1] relies on the ability to configure the home and care-of addresses (COAs) of mobile hosts for mobility management, it does not dictate how they are to be obtained. Traditionally, mobile hosts have had a fixed home address that is statically configured. Recently, the trend has shifted to a dynamic home addressing model, where a configuration protocol enables these hosts to dynamically acquire and install a home address on power-up. Dynamic home addressing enables efficient management of addresses, which is critical in supporting wide-area wireless data users with millions of devices using a limited IPv4 address space. It also provides ease of configurability by replacing the burdensome task of manually configuring hosts with a more effective mechanism for address allocation. There are similar arguments to support the dynamic allocation of co-located care-of addresses (CCOAs), which are required every time the host experiences a handoff. (Unless otherwise stated, we assume that the CCOA option of M-IP is used instead of external Foreign Agents, or FAs. Since the CCOA option is the the more general of the two options, most of the discussion will apply to the external FA option as well. Differences regarding the use of FAs are discussed in Section 6.) DHCP is the current dynamic addressing and configuration protocol in widespread use on the Internet [2]. It not only enables hosts to acquire addresses but also other configuration options associated with the access network (e.g., netmask for subnet, domain name servers, directory servers, email servers, etc. [3]). As emerging and future client applications increasingly rely on network services, the ability to dynamically configure these services through options becomes important. This protocol is a popular tool for today's service providers to manage their addressing needs. It is likewise a natural candidate to support dynamic addressing on mobile hosts. However, since it was designed for fixed hosts, its use on mobile hosts presents a number of challenges. Many of DHCP's limitations in supporting host mobility have been well documented in the literature [4, 5, 6, 7]. The main issues concern its configuration latency, effective use of wireless bandwidth, and security. These issues are well known and there is on-going work to address them. One problem, however, that has been overlooked is that procedures for dynamic home addressing Thuel et al. Expires 12/00 [Page 3] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 based on DHCP do not always work. Specifically, mobile hosts that power up in a foreign network cannot contact addressing servers in their home network through broadcasting. The thrust of this memo is to describe this broadcasting problem and to provide a solution referred to as the Transient Tunneling (TT) procedure. The solution comprises a two- stage addressing procedure for mobile hosts that power up in a foreign network. It introduces the notion of an addressing element referred to as a bootstrapping agent co-located with a M-IP Home Agent for the temporary creation of a tunnel over which standard DHCP transactions take place. We illustrate the set of transactions needed for a host power-up in its home or in a foreign network. We discuss implementation issues and argue that the impact of our procedure on host power-up latency is acceptable. Finally, we discuss alternative solutions and other related issues concerning Transient Tunneling such as wireless bandwidth usage and security. Although other solutions may result in lower power-up latency overheads, our procedure is simple to implement, avoids the problems that plague its alternatives, and exhibits acceptable performance. TT requires no changes to protocol standards and minor changes to server implementations. In addition, it leverages the growing DHCP code-base with its embedded support for important and often necessary host configuration options beyond addressing. Note that the procedure is not needed for hosts powering up in their home network. However, power-ups in a foreign network, where it is applicable, are expected to be the more frequent case (e.g., use of M-IP for corporate access). The procedure is defined for IPv4, where the management of a limited address space is important. Although there is no reason why it cannot be used in the context of IPv6 as well, dynamic home addressing is less of a concern. Details regarding the use of Transient Tunneling under IPv6 are not discussed in this memo. 2 Mobility and DHCP: The Broadcasting Problem Consider a model where mobile hosts rely on DHCP to dynamically configure both their home address and their co-located COA. This implies that clients running on the host must acquire and maintain leases on both addresses. Let us refer to the clients for the home address and for the COA as Hclient and Fclient, respectively. Assume a mobile host powers up in its home network with no knowledge of an unexpired home address lease. Since it needs to Thuel et al. Expires 12/00 [Page 4] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 MH HOME DHCP RELAY HOME DHCP SERVER | | | | DHCPDISCOVER (bcast) | DHCPDISCOVER (bcast/ucast) | |------------------------>|--------------------------->| | DHCPOFFER (bcast) | DHCPOFFER (ucast) | |<------------------------|<---------------------------| | DHCPREQUEST (bcast) | DHCPREQUEST (ucast/bcast) | |------------------------>|--------------------------->| | DHCPACK (bcast) | DHCPACK (ucast) | |<------------------------|<---------------------------| Figure 1: Procedures for Mobile Host Power-Up at its Home Network. acquire one, it initiates the execution of Hclient, which must go through a full initialization (rather than a speedier reboot). Figure 1 shows the standard addressing transactions. Hclient attempts to contact a server by broadcasting a DISCOVER message on its local subnet. This is actually a limited broadcast message since it is destined to address 255.255.255.255. The message is received by a server, or a relay on that subnet that is configured to forward the message to a server elsewhere on the home network (the scenario shown involves a relay). When the message reaches the server, it responds with an OFFER that it either broadcasts on its subnet or unicasts to the relay that had forwarded it. Whether through the relay or directly from the server, the mobile host receives the message as a limited broadcast. Hclient then broadcasts a REQUEST, reaching the server directly or via the relay, as before. The server responds with an ACK, confirming the granting of a lease. The ACK reaches the host once again as a limited broadcast and Hclient concludes its lease acquisition by installing acquired state on the host's interface. Though not shown in the figure, Hclient periodically enters the lease maintenance stage where it sends renewals to its home server. As per the standard, no M-IP registrations are needed while the host is in its home network. Now let us consider the case where a host powers up in a foreign network. Once again, assume, without loss of generality, that the host holds no unexpired home address leases. If Hclient attempts to send a limited broadcast message in the hope of contacting a server that can grant it a home address, it will fail. Any upstream broadcast messages will be received by a local server or Thuel et al. Expires 12/00 [Page 5] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 relay which may offer an address from its own lease pool, not that of the host's home network. Hclient needs a way to contact its remote home server, as standard broadcasting procedures will not enable a proper server discovery. In brief, standard DHCP broadcasting procedures do not work for dynamic home addressing on mobile hosts that power up in a foreign network. Note that the acquisition or renewal of a COA by Fclient works according to standard procedures because the appropriate DHCP servers are local and may be reached through broadcasting. 3 Transient Tunneling Solution While there are many possible ways to bridge the gap between a mobile host powering up in a foreign network and its remote home DHCP server, the notion of an addressing agent for home address allocation coupled with the assistance of M-IP is attractive and conducive to a viable solution. In this section, we describe our Transient Tunneling(TT) solution. The general idea is to use: a) M-IP as the signaling mechanism for reaching the home network and triggering the acquisition of a home address; b) an addressing agent in the home network to allocate a temporary home address for the host; and c) DHCP to allocate a permanent home address and any other configuration state for the host. Variations in the design of the addressing agent and its interaction with M-IP and DHCP leads to other possible solutions, as discussed in Section 5. Our approach is as follows. On power-up, we assume a host is capable of determining whether it is in its home or in a foreign network. This location inference may be based on knowledge of its NAI, similar in format to a user email address (as specified in [8], a wireless link-layer identifier such as the Mobile Identification Number (MIN) can be mapped to a NAI). For example, a M-IP client on the host may listen for periodic advertisements from a home or foreign agent containing the domain name which it can then compare against its own NAI. Let us examine the message flows associated with the power-up procedures for a host that is powering up in a foreign network using Transient Tunneling. As shown in Figure 2, the host first needs to acquire a co-located COA so it spawns a DHCP client (Fclient). Once it acquires the COA, it sends a unicast M-IP registration message to its Home Agent (HA), assumed to be known through static configuration or some other means such as dynamic home agent address resolution [1]. The registration message contains the host's COA Thuel et al. Expires 12/00 [Page 6] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 FOREIGN FOREIGN M-IP HOME DHCP DHCP HOME DHCP MH RELAY SERVER AGENT SERVER | | | | | / | DISCOVER | DISCOVER | | | | |---------->|----------->| | | Acquire | | . | . | | | COA | | . | . | | | | | ACK | ACK | | | \ |<----------|<-----------| | | / | | | | | M-IP | | M-IP REGISTRATION (wo/ home address) | | Client | |------------------------------------->| | Reg. | | M-IP REPLY (w/10.* home address) | | \ |<-------------------------------------| | / | | | | | | | DHCP DISCOVER | |DHCP DISCOVER | Acquire | = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|------------->| Public | | . | . | | | Home | | . | . | | | Address | | | DHCP ACK | DHCP ACK | | = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|<-------------| \ | | | | | / | M-IP DE-REGISTRATION (of 10.*) | | M-IP | |------------------------------------->| | Client | | | | M-IP REPLY | | De-reg. \ |<-------------------------------------| | / | | | | | M-IP | | M-IP REGISTRATION (of public address)| | Client | |------------------------------------->| | Reg. | | | | M-IP REPLY | | \ |<-------------------------------------| | Figure 2: Transient Tunneling procedure for a Mobile Host Power-Up in a Foreign Network. Thuel et al. Expires 12/00 [Page 7] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 and its NAI, but no home address. When the HA receives the registration message and notices that the home address is missing, it contacts a local addressing agent to acquire a home address on behalf of the host. We investigated several designs for the addressing agent, differing in implementation complexity. Due to its simplicity, we chose the design of a lightweight addressing agent referred to as a bootstrapping agent and placed it on the M-IP HA. This bootstrapping agent disburses temporary home addresses from a pool of private IP addresses in the class 10.*. Once a 10.* address is assigned, the HA uses it to set up a tunnel to the COA of the host. The HA unicasts a registration reply message containing the 10.* address back to the host. On receipt, the host sets up its end of the tunnel. Then Hclient is initialized on the host and launches a standard set of transactions needed to acquire a home address and other configuration options through the transient tunnel (highlighted with thicker arrows in the figure). All Hclient messages must be reverse tunneled through the HA to ensure that they are not received by any local DHCP servers or relays. Reverse tunneled messages are forwarded on the home subnet by the receiving HA, so that a home server or relay receives them. Similarly, replies sent by a home server or relay are tunneled to the remote host. Using this transient tunnel, Hclient successfully acquires an address (and other requested configuration state) from a home server without concerns about broadcasting. After this bootstrapping phase, the 10.* address should be released, and its associated tunnel is torn down and replaced with a tunnel terminating at the DHCP-granted home address. This entails sending a M-IP de-registration message from the host to the HA, followed by a registration containing the valid home address. Alternatively, the 10.* address could have a short lease (in the order of 10 seconds) and be allowed to time-out. Note that lease renewals may also be broadcast since they are reverse-tunneled to the home network. For this procedure to work, the broadcast bit options in DHCP and M-IP must be set. The broadcast "B" bit in the flags field of DHCP query messages must be set by the clients to ensure that the replies from the server or relay in the home network reach the client on the host while it is in the foreign network. Existing implementations of DHCP clients such as on Microsoft Windows and ISC's implementation for UNIX always set the broadcast bit by default. By setting this bit, the client informs the server or Thuel et al. Expires 12/00 [Page 8] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 relay to send any replies to the host as a broadcast using an IP broadcast address as the IP destination address and the link-layer broadcast address as the link-layer destination address. This ensures that the HA receives broadcast packets for subsequent forwarding to the host. The M-IP broadcast "B" bit in registration requests must also be set to ensure that the HA tunnels broadcast messages back to the host. A drawback in setting this bit is that the host may receive a flood of unwanted broadcast messages from its home network that are forwarded by its HA. This would result in a significant waste of wireless bandwidth. Strategies to address this issue are discussed in Section 6. To summarize, Transient Tunneling uses a bootstrapping addressing agent on the home agent to allocate private home addresses. This enables a temporary tunnel to be established to the host over which a standard, co-located DHCP client can acquire a lease from a pool of public (i.e., globally routable) home addresses. Once a home address is acquired, it is used to replace the temporary tunnel with a corresponding M-IP tunnel. 4 Implementation Issues 4.1 Registration Latency A key issue for the Transient Tunneling procedure to be effective is the latency that it introduces during a power-up in a foreign network. Five major terms contribute to this latency, namely: (1) the time required for the client to acquire a local IP address through DHCP; (2) the time to set up the transient-tunnel, by registering with the HA; (3) the time required to acquire a permanent home-address with DHCP through the transient-tunnel; (4) the time required to de-register the transient-tunnel; (5) the time to register with the HA using the newly acquired home-address. For term number 1, a typical DHCP procedure accounts for latencies in the order of 200ms (dominated by DHCP processing times at the server and the client). If we assume a round trip time (RTT) in the order of 100ms between the client and the home-network, term 2 should be in the order of 100ms (on a typical HA, processing time for a registration request is in the order of a few milliseconds). Thuel et al. Expires 12/00 [Page 9] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 Accounting for the RTT, term 3 should account for roughly 400ms, while terms 4 and 5 should be in the order of 100ms each. Therefore, the latency of typical power-ups in foreign-networks with transient tunneling should be in the order of 5 RTTs plus the latency of a local DHCP transaction (to acquire the COA), amounting to about 1 second. Considering that the TT procedure is carried out only during power-ups, and not during normal handoffs, this should be perfectly acceptable for a large spectrum of clients, from PDAs to laptop computers. 4.2 Mobile Client Current DHCP client implementations such as ISC's [9] allow a host with multiple network interfaces to dynamically configure each interface. Concurrently executing DHCP client state machines on the host acquire, install, and maintain configuration state for each interface without interfering with each other. However, the support of more than one DHCP client for a single interface requires that steps be taken to prevent or resolve any resource conflicts that may arise on the shared interface, such as during the installation of acquired configuration state. These potential conflicts raise implementation-dependent issues that must be addressed if mobile hosts are to dynamically configure their home and care-of address, typically on a single wireless interface. 4.3 Home Agent Since the mobile client uses the NAI to identify itself, the home-agent is required to be able to index all the Mobile IP requests using the NAI of the client, instead of its home-address. In any event, home-agents that conform to [10] are already required to support this modification of the basic operation as outlined in [1]. No other change to the home-agent is required to support the TT procedure. 4.4 DHCP Server The procedure described in this text has been specifically designed to work without requiring any change to current DHCP server implementations. Therefore, the TT procedure will be completely supported by existing DHCP server implementations conforming to [2]. Thuel et al. Expires 12/00 [Page 10] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 4.5 Private Addressing Support Transient Tunneling requires support for private addressing (10.*) only at the Mobile IP Home Agent and at the Foreign Agent (on the mobile host), which are the two ends of the transient tunnel. The temporary 10.* home address is never exposed to any correspondent host, so packets addressed to the mobile host with this private address could only originate at the Home Agent. The only packets that the Home Agent sends to the mobile host while the transient tunnel is set up are IP broadcast packets forwarded from the DHCP server. These packets are encapsulated with the mobile host's COA in the destination field of the outer IP header and contain the IP broadcast address in the destination field of the inner IP header. As a result, there is never a need for any routers between the Home Agent and the Foreign Agent nor in the Internet to support the routing of packets with private addresses. When the transient tunnel is set up, tunneled packets destined to the mobile host are routed based on its public COA. As soon as the transient tunnel is torn down, packets destined to the mobile host are sent to its public DHCP-acquired home address (and tunneled to the COA while in the host remains in a foreign network). If an external foreign agent is used rather than being on the mobile host, this agent must be able to forward packets destined to the private address for the mobile host, as discussed in Section 6.2. 4.6 Network Administration The transient tunneling procedure was designed to preserve DHCP as the sole entity controlling the management of public IP addresses within a network. The cost of achieving this is a configuration latency overhead due to extra control messages that must complete additional round trips. Although this configuration latency overhead should be an acceptable price to pay to maintain one administrative entity for IP address and configuration management, there may be cases where such a tradeoff may not be the preferred choice. For instance, some networks may need to serve many low-end, mobile IP hosts requiring only dynamic address assignment and no other configuration options. To configure these devices when they power up in a foreign network, it might be better to have the HA assign a public address in the initial registration message which the Thuel et al. Expires 12/00 [Page 11] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 host can keep without requiring the establishment of a transient tunnel. In this manner, the host configuration latency is kept to a single round trip. However, a number of challenges are introduced, including issues of renewing or releasing the address thus acquired and fragmentation of the IP address space between DHCP and the HA's. (These challenges are further elaborated in the following section.) In spite of its limitations, network administrators may opt to adopt this form of address assignment for such special hosts. If the temporary address assigned by the HA is drawn from a public address pool rather than from a pool of private addresses, the use of transient tunneling may be an optional choice made by the mobile host. A host with limited configuration needs may choose to keep the address offered by the HA as its permanent home address while other hosts may use the first offered address as a temporary one to setup the transient tunnel and acquire its permanent home address from DHCP. Support for this flexibility introduces challenges in the sizing of the address pools maintained by DHCP and by the HA that need to be further examined. 5 Alternative Solutions As stated earlier, there are several possible ways to design the addressing agent that is co-located with the Home Agent and for the mobile host to acquire other configuration parameters (i.e., options). Contrasting with the bootstrapping agent used in our transient tunneling procedure, we also examined the notions of an embedded agent and a proxy agent, leading to a set of four dynamic configuration solutions summarized in Table 1. Transient Tunneling corresponds to the first entry in the table while the other three solutions involve embedded and proxy agents, described as follows. As shown in Figure 3, in the embedded agent approach, the allocation of home addresses for hosts powering up away from home is completely up to an addressing agent embedded within a M-IP Home Agent (i.e., the embedded agent assumes the equivalent role of a DHCP server). The sophistication of this embedded agent may range from providing lightweight addressing support to a rich-featured DHCP-like server engine. In the case of a lightweight addressing agent, it differs from our bootstrapping agent because it manages a pool of addresses reserved from within the (limited) public address space of the Thuel et al. Expires 12/00 [Page 12] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 ---------------------- -------------------- ---------- | --> Embedded Agent | | --> Proxy Agent ----->| DHCP | | | | | | | | Server | | --> HA interface | | --> HA interface | ---------- ---------------------- -------------------- ^ ^ M-IP HOME ^ M-IP HOME | | AGENT | AGENT | | | / | | /--------------/ | | | v v v ( ~~~~~ ) ( ~~~~~ ) ( ) ( ) ( ACCESS ) ( ACCESS ) ( NETWORK ) ( NETWORK ) ( ) ( ) ~~~~~ ~~~~~ ^ ^ ^ | | | | | \ | MOBILE HOST | | MOBILE HOST ----------v-------------- ------v----|--------- | -> M-IP Client | | -- M-IP|Client | | | | | | v | | -> Addressing Client | | -> DHCP Client | ------------------------- --------------------- Figure 3: Architecture for an Embedded Agent (at left) versus a Proxy Agent (at right). Thuel et al. Expires 12/00 [Page 13] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 home network. A mobile host can acquire a home address from a HA equipped with this embedded agent, then acquire other configuration parameters from a DHCP server through a DHCPINFORM message. This is the third approach shown in Table 1. If, on the other hand, the HA has a rich-featured embedded agent, the mobile host may acquire all its configuration options through this agent, eliminating the need for DHCP services, as indicated in solution 4 of Table 1. Note that with embedded agents, the mobile host maintains all responsibility for processing equivalent to that of a typical DHCP client. SOURCE FOR SOURCE FOR HOME ADDRESS OTHER CONFIGURATION PARAMETERS -------------------------------------------------------------- 1) DHCP + HA_with_bootstrap DHCP (via DHCPREQUEST) 2) DHCP + HA_with_proxy DHCP (via DHCPREQUEST) 3) HA_with_embedded(light) DHCP (via DHCPINFORM) 4) HA_with_embedded(heavy) HA_with_embedded Table 1: Dynamic Configuration Solutions for a Mobile Host Power-Up in a Foreign Network. A major disadvantage of embedded agents is that they require substantial modifications to Home Agents, duplicating part or most of the functionality already provided by DHCP. In the case of a heavyweight embedded agent, the strong coupling between DHCP and M-IP also requires changes to the current M-IP specification to allow piggy-backing of configuration options in registration messages and creates the need for the M-IP Home Agent implementation to keep abreast of the changes in DHCP standards. Another challenging issue for any embedded agent is how to handle the configuration state it allocated to a mobile host after it returns to its home network. If the state is leased, the host client needs to indirectly trigger periodic renewals through Mobile IP registrations, although the standard specifies that no registrations should be sent while a host is at home. Procedures for address management for a scenario like this are described in [11]. If it is not leased, hard state created at the embedded agent must be explicitly removed when the mobile host no longer needs its home address (e.g., on shutdown). This suffers from typical rogue address problems. Finally, the lightweight embedded Thuel et al. Expires 12/00 [Page 14] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 agent suffers from limitations in the deployment of DHCPINFORM support in current DHCP server implementations. For example, both ISC's and Windows NT 4.0 DHCP servers do not support INFORM messages. In the proxy agent approach, the addressing agent acts like a surrogate DHCP client for the mobile host. It conducts a standard DHCP transaction in the home network to acquire a home address for the mobile (with no options) from a local server. Other configuration options are subsequently acquired through a DHCPREQUEST, as indicated in the second approach of Table 1. The proxy agent acquires an address on behalf of the mobile host by behaving like a co-located DHCP client and relay; appearing like a relay to servers residing on the home network while performing client processing. If the mobile host wishes to use its MAC address as its client identifier, then it must send this address in its registration request. The DHCP server uses the client identifier to create a lease entry in its database. Future lease renewals that are sent directly by the mobile host must use the same client identifier to ensure that the server finds the proper lease binding to renew for the host. With the DHCP client identifier option, the mobile host may opt to use its NAI as its client identifier. In this case, there is no need to extend the registration message to include the host's MAC address. Referring to Figure 3, the mobile host indirectly triggers proxy processing by sending a registration message on power-up. This message might be extended to contain its MAC (e.g., Ethernet) address, as discussed. On receipt of the registration message, the HA contacts the proxy agent with the proper client identifier for the mobile host. The proxy agent runs a client state machine modified to send and receive DHCP messages to and from servers as if they were passing through a relay. After the proxy acquires a home address, it halts the client state machine (i.e., aborts lease maintenance procedures) and forwards the address to the HA. The HA, in turn, creates a tunneling entry for the mobile using its known COA and acquired address, then forwards the home address to the host in its registration reply message. When the host receives the reply, it installs the home address on its interface, and sets up the tunnel endpoint managed by its co-located FA. With the tunnel in place, the host spawns a DHCP client and immediately renews its home address lease requesting (through a DHCPREQUEST) any other configuration options of interest. From then onwards, client messages go directly to the server without HA intervention. Thuel et al. Expires 12/00 [Page 15] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 In this manner, the proxy agent only manages home address acquisition while the client on the host carries out transactions for lease maintenance and the acquisition of configuration options. Unlike embedded agents, proxy agents rely on the use of DHCP for home addressing. They provide a loose coupling between M-IP and DHCP by strictly limiting the role of a HA to be that of a mediator between the host and the proxy for home address acquisition. Therefore, they are much less complex than embedded agents. In general, their shortcomings lie in having to implement the proxy, building an interface between the proxy and the HA, modifying the HA to perform its mediating role, and committing to future HA updates to reflect changes in the evolution of DHCP. Also, M-IP registration messages may have to be modified to include the MAC address of the client. Although the effort to implement proxy agents is not unreasonable, it is substantially greater than that required for bootstrapping agents. The solutions with proxy and embedded agents do have a performance advantage over transient tunneling with a bootstrapping agent; the configuration latency is lower. While all solutions include the overhead for the acquisition of a COA, solutions 2 and 3 have an additional overhead of approximately 2 RTTs (1 RTT for a M-IP registration and 1 RTT for a DHCP REQUEST or INFORM transaction). Solution 4, where the embedded agent returns the allocated home address and all other configuration parameters in one M-IP registration request, has an overhead of only 1 RTT. This contrasts with the 5 RTT overhead of transient tunneling, as described in Section 4.1. Given that this configuration latency overhead only affects mobile host power-ups, where latencies in the order of a couple of seconds are acceptable, we argue that the implementation simplicity of transient tunneling makes a more favorable tradeoff. 6 Other Issues 6.1 Efficient Wireless Bandwidth Usage Mobile hosts usually connect to an IP access network through a wireless air link, where bandwidth tends to be limited and costly due to physical and regulatory constraints. As a result, Thuel et al. Expires 12/00 [Page 16] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 practical mobility solutions should be concerned with the effective use of air bandwidth. Typical approaches to address this concern are packet compression techniques and the reduction of over-the-air traffic. We focus on the latter approach. Traffic over-the-air may be reduced through the prevention of bandwidth waste. One way to prevent bandwidth waste in the Transient Tunneling procedure is to stop unwanted broadcast packets originating in the home network from being tunneled to the mobile host by its HA. Recall from Section 3 that a broadcasting bit needs to be set in the HA so that DHCP packets broadcast by a server or relay in the home network reach the host in a foreign network. Unfortunately, all broadcast packets will be forwarded when the transient tunnel is present, not just the few desired DHCP packets. This introduces a costly traffic burden, especially over low bit-rate wireless links. We now outline approaches to eliminates this undesirable broadcast traffic overhead. In the ``co-located relay'' approach, the DHCP client is modified to mimic the operation of a joint client and relay. By sending messages to the server as if they were passing through a relay, the server is tricked into responding with IP unicast messages, thus eliminating the need for the HA to forward any broadcast packets downstream. The co-located relay would use the private home address of the host acquired through TT procedures as its IP address and advertise it to the server in DHCP requests (in the 'giaddr' field). It should be noted that address assignment rules used by the DHCP server to decide which address to assign to an incoming request are not standardized. Server implementations often select an address on the subnet where the relay resides, if the request was relayed, or on the subnet associated with the server's interface on which the request was received. This may yield to an undesirable address assignment for TT, entailing possible implementation-dependent changes to the server's subnet selection rules. Unicast server replies would likewise be processed through this virtual relay to eliminate relay state and hand it off to the client for normal processing. This approach hinges on the fact that TT assigns a private home address that can be used to simulate DHCP relay functionality for acquiring the home address. A shortcoming of this approach is that it requires a server to be on the same subnet as the HA, because a relayed DHCP request cannot go through more than one relay on its way to a server. Thuel et al. Expires 12/00 [Page 17] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 Another approach to eliminate the broadcast traffic overhead is to have ``cooperative clients'', that is, clients that explicitly request that the server responds with a unicast by clearing the broadcast bit in its requests. The standard specifies that in this case the server unicasts its replies to the client's hardware address, with the offered IP address in the destination field of the IP header. In a similar vein, the DHCP servers may be changed instead of the clients, to respond to select clients with hardware unicast datagrams, regardless of the setting of the broadcast bit in the client request. These select clients should be hosts roaming in a foreign network, as inferred by a ``mobility-aware DHCP server'' through some mechanism not described in this memo. As in the case of cooperative clients, this approach hinges on the HA's ability to forward hardware unicast datagrams from the server to the client. Further study is needed to determine if and how the HA will intercept such replies and forward them to the client, though the addition of intelligence to the HA seems inevitable. 6.2 External Foreign Agents An underlying goal for our work was to enable mobile hosts to dynamically configure both their home address and their co-located care-of address. Regardless of whether or not co-location is used makes no difference to TT, with the exception of an issue regarding FA support for private home addressing. In particular, the use of private home addressing with M-IP, as required by our procedure, raises potential host address collisions at the foreign agent. Since by definition private addresses are not globally unique, it is possible than an overlap occurs between the private addresses of hosts belonging to different HAs but served by the same FA. To resolve such addressing conflicts and ensure proper routing to the hosts, the FA must use additional host configuration state such as the HA address. This address conflict resolution is an open issue currently being addressed [12, 13]. It is important to note that the Home Agent is the only source of packets destined to the private address of the mobile host. Moreover, all such packets are unicast encapsulations of IP broadcast packets sent by the home DHCP server. 7 Security considerations The transient-tunneling procedure described in this memo is subject to the same security considerations that apply to RFC2002, RFC2344 and RFC2131 [1, 21, 2]. Thuel et al. Expires 12/00 [Page 18] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 8 Acknowledgements We would like to express our gratitude to Tom Hiller and Pete McCann, from Lucent Technologies, for their insightful comments and suggestions. Appendix A - Patent Issues This is to inform you that Lucent Technologies has applied for and/or has patent(s) that relates to the attached submission. This submission is being made pursuant to the provisions of IETF IPR Policy, RFC 2026, Sections 10.3.1 and 10.3.2. Lucent Technologies Inc. will offer patent licenses for submissions made by it which are adopted as a standard by your organization as follows: If part(s) of a submission by Lucent is included in a standard and Lucent has patents and/or pending applications that are essential to implementation of the included part(s) in said standard, Lucent is prepared to grant - on the basis of reciprocity (grantback) - a license on such included part(s) on reasonable, non-discriminatory terms and conditions. References [1] Charles Perkins. IP Mobility Support. RFC 2002, IETF, October 1996. [2] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, IETF, March 1997. [3] S. Alexander and R. Droms. DHCP Options and BOOTP vendor Extensions. RFC 2132, IETF, March 1997. [4] Charles Perkins and Kevin Luo. Using DHCP with Computers that Move. Wireless Networks Journal, vol.1:pp.341--353, 1995. [5] Jon-Olov Vatn and Gerald Maguire Jr. The effect of using co-located care-of addresses on macro handover latency. In Proceedings of Nordic Teletraffic Seminar, August 1998. Thuel et al. Expires 12/00 [Page 19] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 [6] Jon-Olov Vatn. Long random wait-times for getting a care-of address are a danger to Mobile Multimedia. In Proceedings of IEEE Intl. Workshop on Mobile Multimedia Communications, pages 142--144, November 1999. [7] A. McAuley, S. Das, S. Baba, and Y. Shobatake. Dynamic Registration and Configuration Protocol (DRCP). Work in progress - Internet Draft, IETF, October 1999. draft-itsumo-drcp-00.txt. [8] Aravamundhan, O'Brien, and Patil. NAI Resolution for Wireless Networks. Work in progress - Internet Draft, IETF, October 1999. draft-aravamundhan-mobileip-nai-wn-00.txt. [9] Internet Software Consortium. http://www.isc.org. [10] Pat Calhoun and Charles Perkins. Mobile IP Network Access Identifier Extension for IPv4. RFC 2794, IETF, March 2000. [11] P. McCann and K. Leung. Mobile IP Session Identifier Extension. Work in progress - Internet Draft, IETF, March 2000. draft-mccann-mobileip-sessionid-00.txt. [12] C. Perkins, G. Montenegro, and P. Calhoun. Private Addresses in Mobile IP. Work in progress - Internet Draft, IETF, June 1999. draft-ietf-mobileip-privaddr-00.txt. [13] W. Teo and Y. Li. Mobile IP extension for Private Internet Support. Work in progress - Internet Draft, IETF, February 1999. draft-teoyli-mobileip-mvpn-02.txt. [14] J. Bound, M. Carney, and C. Perkins. Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Work in progress - Internet Draft, IETF, May 2000. draft-ietf-dhc-dhcpv6-15.txt. [15] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfiguration. RFC 2462, IETF, December 1998. [16] C. Perkins and J. Bound. Extensions for the Dynamic Host Configuration Protocol for IPv6. Work in progress - Internet Draft, IETF, February 1999. draft-ietf-dhc-v6exts-11.txt. [17] R. Droms and W. Arbaugh. Authentication for DHCP Messages. Work in progress - Internet Draft, IETF, October 1999. draft-ietf-dhc-authentication-12.txt. Thuel et al. Expires 12/00 [Page 20] =0C INTERNET-DRAFT draft-thuel-mobileip-tt-00.txt 19 June 2000 [18] M. Stapp and Y. Rekhter. Interaction between DHCP and DNS. Work in progress - Internet Draft, IETF, October 1999. draft-ietf-dhc-dhcp-dns-11.txt. [19] D. Johnson and C. Perkins. Mobility Support in IPv6. Work in progress - Internet Draft, IETF, April 2000. draft-ietf-mobileip-ipv6-12.txt. [20] B. Patel, B. Adoba, S. Kelly, and V. Gupta. DHCP Configuration of IPSEC Tunnel Mode. Work in progress - Internet Draft, IETF, April 2000. draft-ietf-ipsec-dhcp-05.txt. [21] G. Montenegro. Reverse Tunneling for Mobile IP. RFC 2344, IETF, May 1998. [22] Charles Perkins and David Johnson. Route Optimization in Mobile IP. Work in progress - Internet Draft, IETF, February 1999. draft-ietf-mobileip-optim-08.txt. [23] G. Waters. The Subnet Selection Option for DHCP. Work in progress - Internet Draft, IETF, June 1999. draft-ietf-dhc-subnet-option-03.txt. Authors' Addresses S. Thuel, L. Salgarelli, R. Ramjee, K. Varadhan, T. La Porta Bell Laboratories - Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733, USA Voice: +1-732-949-8897 Fax: +1-732-949-7397 e-mail: {thuel,lsalgarelli,ramjee,kvaradhan,tlp}@bell-labs.com Thuel et al. Expires 12/00 [Page 21] ------=_NextPart_000_001E_01BFDA13.F841D140-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 19 17:51:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24224 for ; Mon, 19 Jun 2000 17:51:47 -0400 (EDT) Received: from standards (47.234.32.16:4018) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB769F7@standards.nortelnetworks.com>; Mon, 19 Jun 2000 17:42:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0639 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 19 Jun 2000 17:42:22 -0400 Received: from roll.mentat.com (mentat.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB769CB@standards.nortelnetworks.com>; Mon, 19 Jun 2000 17:32:21 -0400 Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA26049 for ; Mon, 19 Jun 2000 14:41:33 -0700 (PDT) Received: (from marc@localhost) by leo.mentat.com (8.9.1b+Sun/8.9.1) id OAA27091 for MOBILE-IP@standards.nortelnetworks.com; Mon, 19 Jun 2000 14:41:34 -0700 (PDT) X-Sun-Charset: US-ASCII Message-ID: <200006192141.OAA27091@leo.mentat.com> Date: Mon, 19 Jun 2000 14:41:34 -0700 Reply-To: Marc Hasson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Marc Hasson Subject: Re: [MOBILE-IP] Deregistration question... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Steve, I didn't understand the mechanism suggested so I'd like a clarifacation on your response below to the proposed scenario. If the B-bit is set I assume that means to just relay IP broadcasts through the tunnel, not ARPs. This especially must be the case if IP-in-IP tunneling is the current tunnel that the HA has to the MN's COA. Yet an "erroneous gratuitous ARP" isn't an IP packet that can be simply relayed unless it can be repackaged/flagged as something the MN is supposed to treat as an ARP, not IP, packet. So what is it, exactly, that would be relayed through the tunnel to let the MN know that someone back home had swiped its address? I could envision some kind of "registration reply" message with a new code to let the MN user know whats going on but I'm not sure thats allowed if the MN had already received a successful registration reply earlier in life from the HA. I'm not aware of any other kind of asynchronous mobile ip "notify" message that an HA could send an MN when this situation occurs. It could be useful for multiple reasons for an HA to initiate a deregistration with a suitable code but I can't find any verbiage in the specs about such HA-initiated deregistrations. -- Marc -- > Date: Mon, 19 Jun 2000 14:45:42 -0400 > From: Steven Glass - Solaris Software > Subject: Re: [MOBILE-IP] Deregistration question... > X-To: Yoshiyuki Tsuda > To: MOBILE-IP@standards.nortelnetworks.com > X-Status: $$$$ > X-UID: 0000001540 > > > Hi, Steve, > > > > I agree with you this isn't an MIP specific issue but a common issue. > > > > I have another related issue: an MN will often register its HA without > > B-bit. Then, if an erroneous node sends erroneous gratuitous ARPs, the > > HA can detect them, but not relay them to the MN. So, in this case, > > the MN cannot detect such erroneous ARPs. > > I think, it might be better an HA should relay such erroneous ARPs to > > an MN, whether the B-bit is set or not. > > Tsudasan, > > This is a nice feature! The HA lets the mobile node, if it's still on > the other end of the tunnel, know that someone's captured its address. If > it's still at the other end of the tunnel, it reregisters to allow the HA to > resend a gratuitous arp and recapture the address. Sure, the MN can't compete > with a bag-guy on the home subnet, but it could certainly let a user know > what's happening... > > Cheers, > Steve > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 19 18:28:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24623 for ; Mon, 19 Jun 2000 18:28:15 -0400 (EDT) Received: from standards (47.234.32.16:4015) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76A4B@standards.nortelnetworks.com>; Mon, 19 Jun 2000 18:18:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0812 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 19 Jun 2000 18:18:49 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76A4A@standards.nortelnetworks.com>; Mon, 19 Jun 2000 18:08:48 -0400 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26964; Mon, 19 Jun 2000 16:17:44 -0600 (MDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA20881; Mon, 19 Jun 2000 18:17:43 -0400 (EDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by atlantic.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id SAA06598; Mon, 19 Jun 2000 18:18:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 19 Jun 2000 18:17:38 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] Deregistration question... X-To: Marc Hasson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <200006192141.OAA27091@leo.mentat.com> > Steve, > > I didn't understand the mechanism suggested so I'd like a clarifacation > on your response below to the proposed scenario. If the B-bit is set I > assume that means to just relay IP broadcasts through the tunnel, not > ARPs. This especially must be the case if IP-in-IP tunneling is the > current tunnel that the HA has to the MN's COA. Yet an "erroneous > gratuitous ARP" isn't an IP packet that can be simply relayed unless it > can be repackaged/flagged as something the MN is supposed to treat as > an ARP, not IP, packet. The issue really isn't related to M/Bcast forwarding support as it suggests using this mechanism to potentially notify a mobile node that someon's gratuitously arp'd its IP address on the home link (that is whether or not the B-bit was set in the latest registration request), though obviously [mostly] follows more naturally if the B-bit is supported by the HA, and was request in the most recent registration request. Yes, there are some interpretations of "the rules" that in some light may need to be bent, but the proposal was nothing more than that, an idea to let the MN know of a potentially damaging situation on its home subnet. > So what is it, exactly, that would be relayed through the tunnel to let > the MN know that someone back home had swiped its address? Of course, I invite Tsudasan to correct me if I've missunderstood! The gratuitous arp would be encapsulated as any M/Bcast in an IP header with a dst of the mobile node's IP address, then put into the tunnel which means adding another IP[inIP] header (type 4) with the HAs src address, and the FA's dst address. The FA then decapsulates, sees the inner dst is the MN, so it forwards it link-local. When the MN receives and decapsulates it recovers the gratuitious arp which it then defends via the reverse tunnel (which, if it's not colocated, requires encapsulated delivery into the reverse tunnel), or simply reregisters to get the HA to send another gratuitous arp on its home link. Note that if the MN is colocated (D-bit set in the registration request) just the tunnel IP header is required. > I could envision some kind of "registration reply" message with a new > code to let the MN user know whats going on but I'm not sure thats > allowed if the MN had already received a successful registration reply > earlier in life from the HA. I'm not aware of any other kind of > asynchronous mobile ip "notify" message that an HA could send an MN > when this situation occurs. It could be useful for multiple reasons for > an HA to initiate a deregistration with a suitable code but I can't > find any verbiage in the specs about such HA-initiated > deregistrations. According to 2002[-bis], the HA is not allowed to generate a registration reply that is not in response to a registration request. I'm actually in the midst of finishing my draft on registration revocation which handles this in a semi-related way. I'm not going to stick my neck out and guess a completion date as I did with the DHCP draft, though my sincere intension is to submit it by the Pitsburg IETF draft deadline... Cheers, Steve > > Date: Mon, 19 Jun 2000 14:45:42 -0400 > > From: Steven Glass - Solaris Software > > Subject: Re: [MOBILE-IP] Deregistration question... > > X-To: Yoshiyuki Tsuda > > To: MOBILE-IP@standards.nortelnetworks.com > > X-Status: $$$$ > > X-UID: 0000001540 > > > > > Hi, Steve, > > > > > > I agree with you this isn't an MIP specific issue but a common issue. > > > > > > I have another related issue: an MN will often register its HA without > > > B-bit. Then, if an erroneous node sends erroneous gratuitous ARPs, the > > > HA can detect them, but not relay them to the MN. So, in this case, > > > the MN cannot detect such erroneous ARPs. > > > I think, it might be better an HA should relay such erroneous ARPs to > > > an MN, whether the B-bit is set or not. > > > > Tsudasan, > > > > This is a nice feature! The HA lets the mobile node, if it's still > on > > the other end of the tunnel, know that someone's captured its address. If > > it's still at the other end of the tunnel, it reregisters to allow the HA > to > > resend a gratuitous arp and recapture the address. Sure, the MN can't > compete > > with a bag-guy on the home subnet, but it could certainly let a user know > > what's happening... > > > > Cheers, > > Steve > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 19 19:55:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25813 for ; Mon, 19 Jun 2000 19:55:50 -0400 (EDT) Received: from standards (47.234.32.16:1992) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76ABD@standards.nortelnetworks.com>; Mon, 19 Jun 2000 19:46:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0963 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 19 Jun 2000 19:46:22 -0400 Received: from roll.mentat.com (mentat.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76ABC@standards.nortelnetworks.com>; Mon, 19 Jun 2000 19:46:22 -0400 Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id QAA26625 for ; Mon, 19 Jun 2000 16:55:39 -0700 (PDT) Received: (from marc@localhost) by leo.mentat.com (8.9.1b+Sun/8.9.1) id QAA00591 for MOBILE-IP@standards.nortelnetworks.com; Mon, 19 Jun 2000 16:55:40 -0700 (PDT) X-Sun-Charset: US-ASCII Message-ID: <200006192355.QAA00591@leo.mentat.com> Date: Mon, 19 Jun 2000 16:55:40 -0700 Reply-To: Marc Hasson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Marc Hasson Subject: Re: [MOBILE-IP] Deregistration question... To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Steve, > The issue really isn't related to M/Bcast forwarding support as it > suggests using this mechanism to potentially notify a mobile node that > someon's gratuitously arp'd its IP address on the home link (that is whether > or not the B-bit was set in the latest registration request), though obviously > [mostly] follows more naturally if the B-bit is supported by the HA, and was Yes, I understood its a separate issue. I only (re)mentioned the B-bit to emphasize that its *IP* broadcasts that are forwarded and so how would non-IP (ARP) packets be differentiated. > request in the most recent registration request. Yes, there are some > interpretations of "the rules" that in some light may need to be bent, but the > proposal was nothing more than that, an idea to let the MN know of a > potentially damaging situation on its home subnet. Fine, I agree that detecting the conflict in addresses is a good suggestion. I'm just trying to discover how thats best conveyed. > > So what is it, exactly, that would be relayed through the tunnel to let > > the MN know that someone back home had swiped its address? > > Of course, I invite Tsudasan to correct me if I've missunderstood! > > The gratuitous arp would be encapsulated as any M/Bcast in an IP header > with a dst of the mobile node's IP address, then put into the tunnel which > means adding another IP[inIP] header (type 4) with the HAs src address, and > the FA's dst address. The FA then decapsulates, sees the inner dst is the MN, > so it forwards it link-local. When the MN receives and decapsulates it > recovers the gratuitious arp which it then defends via the reverse tunnel OK, maybe I'm being thick but this doesn't sound right. The FA will tear off the outer IP header. This leaves the next IP header with a unicast destination of MN and within it the {IP broadcast | ARP packet}. As per 2002, the unicast destination MN packet, with its inner packet, is forwarded link-local to the MN which decapsulates that packet to recover the original packet inside. Now the question I was trying to get at in my first note is "How does the MN node at this point know the inner packet is an ARP as opposed to an IP broadcast packet?" It has to know somehow else the right processing isn't going to occur, no one's passing the original packet's ethernet type or link-layer headers via IP-in-IP tunneling. (Are they?! :-) ) Another way to ask this question is, "On the first encapsulation the HA did above with the unicast MN dst, what value was set for that IP header's protocol field?" I'm not aware of an "ARP tunneled within IP" value, is there one? If there is, that could be the differentiation needed if you used it only when forwarding ARPs as opposed to IP broadcasts. Even then, I'm wondering if you'd need the original ARP packet's link-layer headers to really do things correctly but I'll not pursue that thought for now. > (which, if it's not colocated, requires encapsulated delivery into the reverse > tunnel), or simply reregisters to get the HA to send another gratuitous arp on > its home link. Note that if the MN is colocated (D-bit set in the > registration request) just the tunnel IP header is required. The same issue applies if its a co-located COA address that is used. In that case the HA only applies one outer IP header to a broadcast to tunnel it to the MN. But the MN, to make this ARP suggestion work, is still going to have to know somehow whether the inner packet is an ARP or IP packet. An ARP packet sent via IP-in-IP tunnel is going to be rejected for an invalid IP header checksum (most likely). > > According to 2002[-bis], the HA is not allowed to generate a registration > reply that is not in response to a registration request. Agreed. I was "fishing" for a way to make this work cleanly. > > I'm actually in the midst of finishing my draft on registration revocation > which handles this in a semi-related way. I'm not going to stick my neck out > and guess a completion date as I did with the DHCP draft, though my sincere > intension is to submit it by the Pitsburg IETF draft deadline... I like best the idea of a registration revocation and not getting into this business of sending ARPs back and forth through these *IP* tunnels to "defend" or be notified of an addressing conflict. Such revocation messages could be authenticated in the mobile IP protocol and I think there are multiple termination reasons besides this address conflict that would be useful for a HA to convey to its MNs. Since the revocation mechanism is probably useful for multiple things anyway it might be nice to avoid having an additional "tunnel ARP within IP" mechanism to serve this purpose, even if its fairly simple. -- Marc -- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 20 00:16:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00517 for ; Tue, 20 Jun 2000 00:16:39 -0400 (EDT) Received: from standards (47.234.32.16:2607) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76B62@standards.nortelnetworks.com>; Tue, 20 Jun 2000 0:06:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1185 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 20 Jun 2000 00:06:55 -0400 Received: from tsbgw.wide.toshiba.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76B61@standards.nortelnetworks.com>; Tue, 20 Jun 2000 0:06:55 -0400 Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id NAA03918; Tue, 20 Jun 2000 13:15:16 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id NAA04425; Tue, 20 Jun 2000 13:15:15 +0900 (JST) Received: from tanuki (tanuki.isl.rdc.toshiba.co.jp [133.196.16.162]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with SMTP id NAA13820; Tue, 20 Jun 2000 13:15:15 +0900 (JST) References: <200006192355.QAA00591@leo.mentat.com> X-Mailer: Datula version 1.21.09 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200006200415.NAA13820@isl.rdc.toshiba.co.jp> Date: Tue, 20 Jun 2000 13:26:15 +0900 Reply-To: Yoshiyuki Tsuda Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Yoshiyuki Tsuda Organization: Corporate R&D Center, Toshiba Corporation Subject: Re: [MOBILE-IP] Deregistration question... X-To: Marc Hasson , Steven.Glass@East.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <200006192355.QAA00591@leo.mentat.com> Hello, Marc and Steve, Oh, I understood what I was missing in my previous email. My issue wasn't related to M/Bcast forwarding support. My previous email must have confused Steve a lot and a lot. My apology to Steve. Anyway, I'm now concerned about this issue, because there may be a user in front of an MN, but there may not always be an administrator in front of an HA. So, letting an MN know the problem is a better solution, I think. I had missed before. But, before reading Marc's email, I had thought relaying ARP packets to an MN is much simpler, although there was a big problem how an ARP packet was packed in an IP packet. Now, I feel a registration reply with some code may be more feasible, as Marc suggested. But, according to this approach, I'm afraid another registration request with some code may also be necessary to request a gratuitous ARP to be sent from the HA and so on. I'd like to know this issue is worth adding such new mechanisms in MIP or not. Thanks for your discussion. -Yoshi On Mon, 19 Jun 2000 16:55:40 -0700, Marc Hasson wrote: >> Steve, >> >> > The issue really isn't related to M/Bcast forwarding support as it >> > suggests using this mechanism to potentially notify a mobile node that >> > someon's gratuitously arp'd its IP address on the home link (that is whether >> > or not the B-bit was set in the latest registration request), though obviously >> > [mostly] follows more naturally if the B-bit is supported by the HA, and was >> >> Yes, I understood its a separate issue. I only (re)mentioned the B-bit >> to emphasize that its *IP* broadcasts that are forwarded and so >> how would non-IP (ARP) packets be differentiated. >> >> > request in the most recent registration request. Yes, there are some >> > interpretations of "the rules" that in some light may need to be bent, but the >> > proposal was nothing more than that, an idea to let the MN know of a >> > potentially damaging situation on its home subnet. >> >> Fine, I agree that detecting the conflict in addresses is a good >> suggestion. I'm just trying to discover how thats best conveyed. >> >> >> > > So what is it, exactly, that would be relayed through the tunnel to let >> > > the MN know that someone back home had swiped its address? >> > >> > Of course, I invite Tsudasan to correct me if I've missunderstood! >> > >> > The gratuitous arp would be encapsulated as any M/Bcast in an IP header >> > with a dst of the mobile node's IP address, then put into the tunnel which >> > means adding another IP[inIP] header (type 4) with the HAs src address, and >> > the FA's dst address. The FA then decapsulates, sees the inner dst is the MN, >> > so it forwards it link-local. When the MN receives and decapsulates it >> > recovers the gratuitious arp which it then defends via the reverse tunnel >> >> OK, maybe I'm being thick but this doesn't sound right. The FA will >> tear off the outer IP header. This leaves the next IP header with a >> unicast destination of MN and within it the {IP broadcast | ARP packet}. >> As per 2002, the unicast destination MN packet, with its inner packet, >> is forwarded link-local to the MN which decapsulates that packet to >> recover the original packet inside. Now the question I was trying to >> get at in my first note is "How does the MN node at this point know the >> inner packet is an ARP as opposed to an IP broadcast packet?" It has to >> know somehow else the right processing isn't going to occur, no one's >> passing the original packet's ethernet type or link-layer headers via >> IP-in-IP tunneling. (Are they?! :-) ) Another way to ask this >> question is, "On the first encapsulation the HA did above with the >> unicast MN dst, what value was set for that IP header's protocol >> field?" I'm not aware of an "ARP tunneled within IP" value, is there >> one? If there is, that could be the differentiation needed if you used >> it only when forwarding ARPs as opposed to IP broadcasts. Even then, >> I'm wondering if you'd need the original ARP packet's link-layer >> headers to really do things correctly but I'll not pursue that thought >> for now. >> >> > (which, if it's not colocated, requires encapsulated delivery into the reverse >> > tunnel), or simply reregisters to get the HA to send another gratuitous arp on >> > its home link. Note that if the MN is colocated (D-bit set in the >> > registration request) just the tunnel IP header is required. >> >> The same issue applies if its a co-located COA address that is used. >> In that case the HA only applies one outer IP header to a broadcast to >> tunnel it to the MN. But the MN, to make this ARP suggestion work, is >> still going to have to know somehow whether the inner packet is an ARP >> or IP packet. An ARP packet sent via IP-in-IP tunnel is going to be >> rejected for an invalid IP header checksum (most likely). >> >> > >> > According to 2002[-bis], the HA is not allowed to generate a registration >> > reply that is not in response to a registration request. >> >> Agreed. I was "fishing" for a way to make this work cleanly. >> >> > >> > I'm actually in the midst of finishing my draft on registration revocation >> > which handles this in a semi-related way. I'm not going to stick my neck out >> > and guess a completion date as I did with the DHCP draft, though my sincere >> > intension is to submit it by the Pitsburg IETF draft deadline... >> >> I like best the idea of a registration revocation and not getting into >> this business of sending ARPs back and forth through these *IP* tunnels >> to "defend" or be notified of an addressing conflict. Such revocation >> messages could be authenticated in the mobile IP protocol and I think >> there are multiple termination reasons besides this address conflict >> that would be useful for a HA to convey to its MNs. Since the >> revocation mechanism is probably useful for multiple things anyway it >> might be nice to avoid having an additional "tunnel ARP within IP" >> mechanism to serve this purpose, even if its fairly simple. >> >> >> -- Marc -- >> From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 20 04:12:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15118 for ; Tue, 20 Jun 2000 04:12:37 -0400 (EDT) Received: from standards (47.234.32.16:2127) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76C1B@standards.nortelnetworks.com>; Tue, 20 Jun 2000 4:02:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1414 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 20 Jun 2000 04:02:57 -0400 Received: from stsl.siemens.com.tw (192.72.45.189:49920) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76C0C@standards.nortelnetworks.com>; Tue, 20 Jun 2000 3:52:57 -0400 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 QAA26110 for ; Tue, 20 Jun 2000 16:07:40 +0800 (CST) Received: by stslex.siemens.com.tw with Internet Mail Service (5.5.2448.0) id ; Tue, 20 Jun 2000 15:57:53 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDA8D.3C562C2C" Message-ID: Date: Tue, 20 Jun 2000 15:57:52 +0800 Reply-To: Ra Chen Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ra Chen Subject: [MOBILE-IP] A Question on draft-ietf-mobileip-ipv6-12.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDA8D.3C562C2C Content-Type: text/plain In Page 24, it is mentioned that a Bindnig Update option MAY include an Alternate Care-of Address sub-option, and the address in the Alternate Care-of Address sub-option is used for binding, instead of the Source Address of the IP header. Our question is, when is it necessary to use this sub-option? In what situation should a mobile node decide not to put the care-of address it is going to use in the Source Address field, but put it in the sub-option and use another address as the Source Address? Thanks for clarifying. Ra ------_=_NextPart_001_01BFDA8D.3C562C2C Content-Type: text/html A Question on draft-ietf-mobileip-ipv6-12.txt

In Page 24, it is mentioned that a Bindnig Update option
MAY include an Alternate Care-of Address sub-option,
and the address in the Alternate Care-of Address sub-option
is used for binding, instead of the Source Address of the IP header.

Our question is, when is it necessary to use this sub-option?
In what situation should a mobile node decide not to put the care-of address
it is going to use in the Source Address field, but put it in the sub-option
and use another address as the Source Address?

Thanks for clarifying.

Ra

------_=_NextPart_001_01BFDA8D.3C562C2C-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 20 06:57:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16629 for ; Tue, 20 Jun 2000 06:57:15 -0400 (EDT) Received: from standards (47.234.32.16:1362) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76C9A@standards.nortelnetworks.com>; Tue, 20 Jun 2000 6:47:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1576 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 20 Jun 2000 06:47:36 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76C87@standards.nortelnetworks.com>; Tue, 20 Jun 2000 6:37:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16433; Tue, 20 Jun 2000 06:46:41 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200006201046.GAA16433@ietf.org> Date: Tue, 20 Jun 2000 06:46:40 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-haverinen-mobileip-gsmsim-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : GSM SIM Authentication for Mobile IP Author(s) : H. Haverinen Filename : draft-haverinen-mobileip-gsmsim-00.txt Pages : 21 Date : 19-Jun-00 This document specifies a mechanism for generating Mobile IP authentication keys using the GSM Subscriber Identity Module (SIM). The mechanism uses new subtypes of the generalized key distribution extensions [1] for Mobile IP Registration Request and Registration Reply. After the authentication keys have been generated, the default Mobile IP authentication with these keys can be used (MD5 in prefix + suffix mode). The keys can be used for several subsequent registrations. However, there is a lifetime for these keys and before the lifetime expires, new keys can be generated with the same procedure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haverinen-mobileip-gsmsim-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-haverinen-mobileip-gsmsim-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-haverinen-mobileip-gsmsim-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000619103521.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-haverinen-mobileip-gsmsim-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-haverinen-mobileip-gsmsim-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000619103521.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 20 10:12:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22983 for ; Tue, 20 Jun 2000 10:12:34 -0400 (EDT) Received: from standards (47.234.32.16:1340) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76D98@standards.nortelnetworks.com>; Tue, 20 Jun 2000 10:02:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1899 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 20 Jun 2000 10:02:33 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76D97@standards.nortelnetworks.com>; Tue, 20 Jun 2000 10:02:32 -0400 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13942 for ; Tue, 20 Jun 2000 08:11:37 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA11891; Tue, 20 Jun 2000 07:11:36 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA18253; Tue, 20 Jun 2000 07:11:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 20 Jun 2000 07:11:07 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Fast Handovers/offs X-To: jochen.grimminger@mchp.siemens.de To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" Jochen, Of course, I cannot speak for Charlie, but my pro-active Foreign Agent hand-off draft should remain a separate document. Charlie's regtun I-D has some benefits, and could be used without my I-D. Of course, the hand-off latency would be much greater without my I-D, but it could still be used independently. I would instead suggest that the Working Group decide which "set" of Internet Drafts should be WG work items, and go from there. I will be presenting the pro-active draft in Pittsburgh, and hope that the WG agrees that this contribution should become a WG document. PatC > Hallo Charlie, > > i'm just wondering, are you thinking about merging some ideas from > Pat Calhoun or Karim El Malki for Fast Handoffs/overs into your RegTun Draft > ? > With one is prefered or are you three working allready together to produce > a Draft-ietf document for Pittsburgh ;-) ... as RegTun seems to be a very > promissing > basis for improving latencies and packet loss > > Best Regards > > Jochen > > > ******************************** > Dipl. Phys. Jochen Grimminger > Siemens AG > Otto-Hahn Ring 6 > 81730 Munich > +49 89 636 41740 > +49 89 636 51115 > ******************************** From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 20 12:18:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27718 for ; Tue, 20 Jun 2000 12:18:26 -0400 (EDT) Received: from standards (47.234.32.16:1340) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76E93@standards.nortelnetworks.com>; Tue, 20 Jun 2000 12:08:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2172 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 20 Jun 2000 12:08:47 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76E6B@standards.nortelnetworks.com>; Tue, 20 Jun 2000 11:58:47 -0400 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04406; Tue, 20 Jun 2000 09:07:41 -0700 (PDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA25657; Tue, 20 Jun 2000 12:07:37 -0400 (EDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by atlantic.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id MAA14057; Tue, 20 Jun 2000 12:08:14 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Tue, 20 Jun 2000 12:07:32 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] Deregistration question... X-To: Marc Hasson To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <200006192355.QAA00591@leo.mentat.com> > > > So what is it, exactly, that would be relayed through the tunnel to let > > > the MN know that someone back home had swiped its address? > > > > Of course, I invite Tsudasan to correct me if I've missunderstood! > > > > The gratuitous arp would be encapsulated as any M/Bcast in an IP > > header with a dst of the mobile node's IP address, then put into the tunnel > > which means adding another IP[inIP] header (type 4) with the HAs src > > address, and the FA's dst address. The FA then decapsulates, sees the inner > > dst is the MN, so it forwards it link-local. When the MN receives and > > decapsulates it recovers the gratuitious arp which it then defends via the > > reverse tunnel > > OK, maybe I'm being thick but this doesn't sound right. The FA will > tear off the outer IP header. This leaves the next IP header with a > unicast destination of MN and within it the {IP broadcast | ARP packet}. > As per 2002, the unicast destination MN packet, with its inner packet, > is forwarded link-local to the MN which decapsulates that packet to > recover the original packet inside. Now the question I was trying to > get at in my first note is "How does the MN node at this point know the > inner packet is an ARP as opposed to an IP broadcast packet?" It has to > know somehow else the right processing isn't going to occur, no one's > passing the original packet's ethernet type or link-layer headers via > IP-in-IP tunneling. (Are they?! :-) ) Another way to ask this > question is, "On the first encapsulation the HA did above with the > unicast MN dst, what value was set for that IP header's protocol > field?" I'm not aware of an "ARP tunneled within IP" value, is there > one? No, not that I'm aware of. This is what I meant by "bending some of the rules" which really mean "bear with me" (and in the real world, if someone wanted to implemnt this translates to figuring out a way to get some of this done). The original thought (as I saw it) was for the HA to simply get the gratuitious arp through the tunnel so if the MN is still out there, it knows what's going on. The nice thing about this is it doesn't require the HA to generate any registration messages, and it's in the spirit (at least) of using the tunnel to communicate with the MN. I agree with you the issue still exists with a colocated MN. > If there is, that could be the differentiation needed if you used > it only when forwarding ARPs as opposed to IP broadcasts. Even then, > I'm wondering if you'd need the original ARP packet's link-layer > headers to really do things correctly but I'll not pursue that thought > for now. I'm torn between saying "yes" and "no". If the MN is going to defend its address, then I suppose the answer is yes, it needs to form the defense as it would normally, which means needing the original link-layer header (well, 1/2 of it anyway), then get it back up the [reverse] tunnel. Of course, you'll need a similar mechanism we're hand-waving through to get the HA to deal with it as the MN must have. If the MN is simply going to see this as a need to reregister so the HA (read: if the HA were required to) send another gratuitous arp to reclaim the address, then no. > > (which, if it's not colocated, requires encapsulated delivery into the > reverse > > tunnel), or simply reregisters to get the HA to send another gratuitous > arp on > > its home link. Note that if the MN is colocated (D-bit set in the > > registration request) just the tunnel IP header is required. > > An ARP packet sent via IP-in-IP tunnel is going to be rejected for an > invalid IP header checksum (most likely). Hmmm... I didn't think about the checksum issues, then again if there was an ARP-in-IP type, it would probably specify checksum the arp (as generic payload). > I like best the idea of a registration revocation and not getting into > this business of sending ARPs back and forth through these *IP* tunnels > to "defend" or be notified of an addressing conflict. Such revocation > messages could be authenticated in the mobile IP protocol and I think > there are multiple termination reasons besides this address conflict > that would be useful for a HA to convey to its MNs. Since the > revocation mechanism is probably useful for multiple things anyway it > might be nice to avoid having an additional "tunnel ARP within IP" > mechanism to serve this purpose, even if its fairly simple. I like it, too! I'm not sure an ARP-in-IP mechanism is a case of "build it and they'll come", but it was an interesting thought. Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 20 14:37:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01333 for ; Tue, 20 Jun 2000 14:37:45 -0400 (EDT) Received: from standards (47.234.32.16:4713) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76F19@standards.nortelnetworks.com>; Tue, 20 Jun 2000 14:28:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2404 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 20 Jun 2000 14:28:10 -0400 Received: from roll.mentat.com (mentat.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76F18@standards.nortelnetworks.com>; Tue, 20 Jun 2000 14:28:09 -0400 Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA00077; Tue, 20 Jun 2000 11:37:35 -0700 (PDT) Received: (from marc@localhost) by leo.mentat.com (8.9.1b+Sun/8.9.1) id LAA18445; Tue, 20 Jun 2000 11:37:35 -0700 (PDT) X-Sun-Charset: US-ASCII Message-ID: <200006201837.LAA18445@leo.mentat.com> Date: Tue, 20 Jun 2000 11:37:35 -0700 Reply-To: Marc Hasson Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Marc Hasson Subject: Re: [MOBILE-IP] Deregistration question... X-To: Steven.Glass@East.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Steve, > > An ARP packet sent via IP-in-IP tunnel is going to be rejected for an > > invalid IP header checksum (most likely). > > Hmmm... I didn't think about the checksum issues, then again if there was > an ARP-in-IP type, it would probably specify checksum the arp (as generic > payload). Actually an IP-in-IP decapsulator would probably throw out an unflagged ARP packet due to it not having the IP version or header length fields correct before it even got to doing IP header checksumming. Anyway, I think we now have the point that an ARP packet can't be simply tunneled without *some* way of distinguishing ARP packets from IP packets. An ARP-in-IP type would do it, along with a description as to whether the ARP packet's link-layer headers/checksum were included as well so that the decapsulator understands the packet format. > > > > I like best the idea of a registration revocation and not getting into > > this business of sending ARPs back and forth through these *IP* tunnels > > to "defend" or be notified of an addressing conflict. Such revocation > > messages could be authenticated in the mobile IP protocol and I think > > there are multiple termination reasons besides this address conflict > > that would be useful for a HA to convey to its MNs. Since the > > revocation mechanism is probably useful for multiple things anyway it > > might be nice to avoid having an additional "tunnel ARP within IP" > > mechanism to serve this purpose, even if its fairly simple. > > I like it, too! I'm not sure an ARP-in-IP mechanism is a case of "build > it and they'll come", but it was an interesting thought. > > Cheers, > Steve Agreed. I think I can exit this discussion for now, pending either a strong view on the list that ARP-in-IP is required or further developments in the registration revocation proposal. Thanks for your time. -- Marc -- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 20 15:32:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02323 for ; Tue, 20 Jun 2000 15:32:02 -0400 (EDT) Received: from standards (47.234.32.16:4713) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76FA5@standards.nortelnetworks.com>; Tue, 20 Jun 2000 15:22:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2581 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 20 Jun 2000 15:22:26 -0400 Received: from mailhost.iprg.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB76FA4@standards.nortelnetworks.com>; Tue, 20 Jun 2000 15:22:25 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA29404; Tue, 20 Jun 2000 12:29:55 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id MAA32180; Tue, 20 Jun 2000 12:29:52 -0700 X-Virus-Scanned: Tue, 20 Jun 2000 12:29:52 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (icharliep-1.iprg.nokia.com [205.226.22.18]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma031943; Tue, 20 Jun 00 12:29:46 -0700 X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <394FC5D5.27628B4F@iprg.nokia.com> Date: Tue, 20 Jun 2000 12:28:21 -0700 Reply-To: Charlie Perkins Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Charlie Perkins Organization: Nokia Subject: Re: [MOBILE-IP] Fast Handovers/offs X-To: "pcalhoun@eng.sun.com" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Pat, > Of course, I cannot speak for Charlie, but my pro-active Foreign Agent > hand-off draft should remain a separate document. Charlie's regtun I-D has > some benefits, and could be used without my I-D. Of course, the hand-off > latency would be much greater without my I-D, but it could still be used > independently. I haven't read the draft under discussion, but I don't think the assertion of _much greater_ latency can be supported without either -- restricted domain of applicability, or -- _much greater_ evidence than I have seen presented. On the other hand, I do not think that anyone would dispute that an active foreign agent scheme could substantially reduce latency in some circumstances. I think that whenever a proactive foreign agent scheme would be useful for home registrations, it would also be useful for regional registrations. I also think that regional registrations will be applicable in a wider domain than would proactive foreign agents. BTW, it is interesting to note that proactive schemes typically rely on special features for signal measurement that _could_ be retooled to do layer-3 registrations anyway. That is, if we could ever get appropriate changes made to the air interface and protocol control structures. Regards, Charlie P. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 20 16:16:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03198 for ; Tue, 20 Jun 2000 16:16:17 -0400 (EDT) Received: from standards (47.234.32.16:4713) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77020@standards.nortelnetworks.com>; Tue, 20 Jun 2000 16:06:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2739 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 20 Jun 2000 16:06:45 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7701F@standards.nortelnetworks.com>; Tue, 20 Jun 2000 16:06:45 -0400 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22110; Tue, 20 Jun 2000 14:15:47 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA06146; Tue, 20 Jun 2000 13:15:36 -0700 (PDT) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA28073; Tue, 20 Jun 2000 13:15:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: qk3lxm9inJJKoBpejNtkIw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Message-ID: <200006202015.NAA28073@nasnfs.eng.sun.com> Date: Tue, 20 Jun 2000 13:19:17 -0700 Reply-To: James Kempf Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: James Kempf Subject: Re: [MOBILE-IP] Fast Handovers/offs X-To: charliep@IPRG.NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Charlie, > >BTW, it is interesting to note that proactive schemes typically >rely on special features for signal measurement that _could_ be >retooled to do layer-3 registrations anyway. That is, if we >could ever get appropriate changes made to the air interface >and protocol control structures. > I'm not quite sure what you mean by this, but I think the changes in the air interface would have to be quite substantial. Unlike radio LAN protocols, the 3G schemes don't share radio channels, so a mobile can only listen on one (bearer) channel at a time. Suppose that a mobile on one RAN needs to switch to another, but there is a mobile in the other RAN on the same channel. The mobile effectively can't "see" the other base station, so it has no choice but to perform the handoff through the network. Actually, I feel (as the draft's co-author) that the proactive draft and the regional registration draft have a natural synergy and that any solution to the fast handoff problem will require some combination, including perhaps folding in anchor handoff as well. Perhaps now is not the time to perform the combination, however, since we are still working out the details of the proactive draft. jak From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 21 06:56:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25930 for ; Wed, 21 Jun 2000 06:56:47 -0400 (EDT) Received: from standards (47.234.32.16:3292) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB773C1@standards.nortelnetworks.com>; Wed, 21 Jun 2000 6:46:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3918 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 21 Jun 2000 06:46:54 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB773A6@standards.nortelnetworks.com>; Wed, 21 Jun 2000 6:36:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25702; Wed, 21 Jun 2000 06:46:02 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200006211046.GAA25702@ietf.org> Date: Wed, 21 Jun 2000 06:46:02 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-haverinen-mobileip-reg-paging-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IP Regional Paging Author(s) : H. Haverinen, J. Malinen Filename : draft-haverinen-mobileip-reg-paging-00.txt Pages : 16 Date : 20-Jun-00 This document specifies Mobile IP Regional Paging (MIRP), a small and link-layer independent extension to Mobile IP [2] with regional registrations [3], to support power-constrained operation in the mobile nodes and to reduce routing state information in the visited domain. The extension allows a mobile node to enter a power saving idle mode during which its location is known with the coarse accuracy defined by a paging area. Downlink routes to idle mobile nodes terminate in a paging foreign agent, which re-establishes them on demand by means of paging. This does not require snooping of data packets but is a natural extension to network-level routing. Optionally, the mobile node and the visited domain can agree on communication time slots used for Agent Advertisements and paging, to restrict link interface power-on time in the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haverinen-mobileip-reg-paging-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-haverinen-mobileip-reg-paging-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-haverinen-mobileip-reg-paging-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000620112119.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-haverinen-mobileip-reg-paging-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-haverinen-mobileip-reg-paging-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000620112119.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 21 07:51:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27142 for ; Wed, 21 Jun 2000 07:51:27 -0400 (EDT) Received: from standards (47.234.32.16:3463) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77416@standards.nortelnetworks.com>; Wed, 21 Jun 2000 7:41:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4061 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 21 Jun 2000 07:41:43 -0400 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77415@standards.nortelnetworks.com>; Wed, 21 Jun 2000 7:41:43 -0400 Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e5LBoos22594 for ; Wed, 21 Jun 2000 13:50:50 +0200 (MET DST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Wed, 21 Jun 2000 13:50:50 +0200 Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 21 Jun 2000 11:50:50 0000 (GMT) Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Wed, 21 Jun 2000 13:50:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 21 Jun 2000 11:50:50.0389 (UTC) FILETIME=[F2172450:01BFDB76] Message-ID: <5F05C89FB2F8D211B6430008C791912703EA8097@esealnt190> Date: Wed, 21 Jun 2000 13:50:44 +0200 Reply-To: "Karim El-Malki (ERA)" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Karim El-Malki (ERA)" Subject: Re: [MOBILE-IP] Fast Handovers/offs To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Charlie > BTW, it is interesting to note that proactive schemes typically > rely on special features for signal measurement that _could_ be > retooled to do layer-3 registrations anyway. That is, if we > could ever get appropriate changes made to the air interface > and protocol control structures. I don't think such schemes always have to rely on (L1) signal measurements. You may want to leave that intelligence to L1/L2 and just require some event notification (e.g. handoff), QoS info etc. from L2 to L3. So I don't believe it is always appropriate to make changes to air interface and protocols. At least that's not the assumption we took in our Fast Handoffs: draft-elmalki-soliman-hmipv4v6-00 Cheers, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 22 06:00:50 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24658 for ; Thu, 22 Jun 2000 06:00:40 -0400 (EDT) Received: from standards (47.234.32.16:4033) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB776E5@standards.nortelnetworks.com>; Thu, 22 Jun 2000 5:47:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4975 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 22 Jun 2000 05:47:00 -0400 Received: from techtransfer.swift.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB776D5@standards.nortelnetworks.com>; Thu, 22 Jun 2000 5:37:00 -0400 X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on TechTransfer/Swift(Release 5.0.3 (Intl)|21 March 2000) at 06/22/2000 10:51:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Wed, 21 Jun 2000 18:15:24 +0100 Reply-To: Matthias.Kraner@SWIFT.SHEF.AC.UK Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Matthias Kraner Subject: Re: [MOBILE-IP] Fast Handovers/offs To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Karim, What is the current state of the art regarding "event notification (e.g. handoff), QoS info etc. from L2 to L3"? Can one get information about cell size and one's own location within a cell to calculate the expected cell visiting time before handover to another cell and herewith possibly to handoff to another subnetwork? This questions are becoming even more interesting considering the variety of possible wireless technologies. Cheers Matthias "Karim El-Malki (ERA)" cc: Sent by: "IP Routing for Subject: Re: [MOBILE-IP] Fast Handovers/offs Wireless/Mobile Hosts (mobile-ip)" 21/06/00 12:50 Please respond to "Karim El-Malki (ERA)" Hello Charlie > BTW, it is interesting to note that proactive schemes typically > rely on special features for signal measurement that _could_ be > retooled to do layer-3 registrations anyway. That is, if we > could ever get appropriate changes made to the air interface > and protocol control structures. I don't think such schemes always have to rely on (L1) signal measurements. You may want to leave that intelligence to L1/L2 and just require some event notification (e.g. handoff), QoS info etc. from L2 to L3. So I don't believe it is always appropriate to make changes to air interface and protocols. At least that's not the assumption we took in our Fast Handoffs: draft-elmalki-soliman-hmipv4v6-00 Cheers, Karim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 22 12:19:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09237 for ; Thu, 22 Jun 2000 12:19:43 -0400 (EDT) Received: from standards (47.234.32.16:2957) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77908@standards.nortelnetworks.com>; Thu, 22 Jun 2000 12:09:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5724 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 22 Jun 2000 12:09:51 -0400 Received: from nausicaa.coritel.it (193.205.242.5:39198) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77907@standards.nortelnetworks.com>; Thu, 22 Jun 2000 11:59:48 -0400 Received: from archimede (archimede.coritel.it [193.205.242.44]) by nausicaa.coritel.it (8.9.3/8.9.3) with SMTP id RAA12667 for ; Thu, 22 Jun 2000 17:59:08 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0292_01BFDC74.E9A3B3C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <029501bfdc64$2f6ee3e0$2cf2cdc1@coritel.it> Date: Thu, 22 Jun 2000 18:08:47 +0200 Reply-To: Raffaele Pellicciotta Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Raffaele Pellicciotta Subject: [MOBILE-IP] Private addresses To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0292_01BFDC74.E9A3B3C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I desire to have information about use of private addresses on = Mobile IP!!! What is its state of art? Thanks a lot, Raffaele ------=_NextPart_000_0292_01BFDC74.E9A3B3C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, I desire to have information about = use of=20 private addresses on Mobile IP!!!
    What is its state of = art?
    Thanks a = lot,
       =20 Raffaele
------=_NextPart_000_0292_01BFDC74.E9A3B3C0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 22 13:01:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10328 for ; Thu, 22 Jun 2000 13:01:05 -0400 (EDT) Received: from standards (47.234.32.16:3247) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77958@standards.nortelnetworks.com>; Thu, 22 Jun 2000 12:51:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5819 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 22 Jun 2000 12:51:21 -0400 Received: from ns0.utdallas.edu by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77955@standards.nortelnetworks.com>; Thu, 22 Jun 2000 12:41:14 -0400 Received: from apache.utdallas.edu (apache.utdallas.edu [129.110.16.9]) by ns0.utdallas.edu (Postfix) with ESMTP id C0F1A1A03A5 for ; Thu, 22 Jun 2000 11:48:34 -0500 (CDT) Received: from localhost (jcobb@localhost) by apache.utdallas.edu (8.9.1/8.9.1) with ESMTP id LAA15068 for ; Thu, 22 Jun 2000 11:49:35 -0500 (CDT) X-Authentication-Warning: apache.utdallas.edu: jcobb owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 22 Jun 2000 11:49:35 -0500 Reply-To: Jorge Cobb Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jorge Cobb Subject: [MOBILE-IP] CFP ISADS 2001, August 15 Deadline To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM * please forgive us if you receive multiple copies of this message * feel free to distribute to your colleagues. ISADS 2001 CALL FOR PAPERS The Fifth International Symposium on Autonomous Decentralized Systems with an emphasis on electronic commerce Monday March 26 - Wednesday March 28, 2001 Dallas, Texas, USA Sponsored by: IEEE Computer Society Information Processing Society of Japan The Society of Instrument and Control Engineers of Japan The Institute of Electronics, Infor. and Communication Engineers, Japan In Cooperation with: International Federation for Information Processing International Federation of Automatic Control OMG TINA-C Manufacturing Science and Technology Center, Japan Scope: Driven by the continuous growth in the power, intelligence and openness of computer, communication and control technologies, possibilities and opportunities for realizing highly efficient and dependable business and control systems have been steadily increasing. Dynamically changing social and economic situations demand next-generation systems based on emerging technologies and applications. Such systems are expected to have the characteristics of living systems composed of largely autonomous and decentralized components. Such systems are called Autonomous Decentralized Systems (ADS). After the successful first, second, third, and fourth International Symposium on Autonomous Decentralized Systems (ISADS) held in 1993 in Japan, in 1995 in the USA , in 1997 in Germany, and in 1999 in Japan, the fifth ISADS will be held in Dallas, Texas, USA during March 26-28, 2001. While ISADS 2001 will primarily focus on advancements and innovation in ADS concept, technologies, and applications related to the increasingly important topic of *Electronic Commerce*, other themes such as telecommunications and heterogeneous system and application integration will also be included. The ISADS 2001 committee invites papers and panel proposals on the topics of the symposium that will foster interactions among researchers and practitioners in computer, communication, management, control as applied to electronic commerce and other related fields from academia, industry, and government. The scope of discussions on ADS shall include, but not be limited to: * Computer and communication architectures / intelligent network /Internet; * Heterogeneous distributed information / control systems; * Mobile agent /computer-supported cooperative works; * Distributed software development and maintenance; * Assurance, fault tolerance and on-line expansion; * Object management architecture /design pattern / application frameworks; * Emergent control and robotic systems; * Novel applications: electronic commerce, telecommunications, information service systems, manufacturing systems, real-time event management, office automation, traffic and transportation control, logistics systems. Plant tour is scheduled on March 29, 2001. Delegates are encour- aged to participate. Information for Authors Papers should describe original work (not submitted or published elsewhere) and be 20 double-spaced pages (5,000 words) or less in length. Papers should include: title, authors, affiliations, 150-word abstract and list of keywords. Identify the author responsible for correspondence, including the author's name, position, mailing address, telephone and fax numbers, and email address. One of the authors of each accepted paper must present the paper at ISADS 2001. Information for Panel Organizers Panel proposals should include: title, organizer's affiliations, position, mailing address, telephone and fax numbers, email address, and 150-word statement on the scope, proposed chair and panelists. Submission Address Authors and panel organizers are requested to submit their manuscripts electrically in the Microsoft WORD document file format, the PDF format, or the Postscript format, and also email the abstract and the full addresses of the author(s) to the following address: thura@mitre.org Note The program committee of ISADS2001 highly encourage electronic submissions. Otherwise, papers should be sent to the program chair: Dr. Bhavani Thuraisingham Mail Stop A270 The MITRE Corporation 202 Burlington Road Bedford, MA 01730 Phone: 781-271-8873 Fax: 781-271-8752 Email: thura@mitre.org General Information For general information, see our World-Wide Web Page at: http://isads.utdallas.edu The proceedings of the symposium will be published by IEEE Computer Society Press. Important Deadlines August 15, 2000: All papers and panel proposals are due November 15, 2000: Authors and panel organizers notified of acceptance. December 15, 2000: Camera-ready copies of accepted papers and panelists' position papers General Chair William Osborne, U. of Texas, Dallas, USA Program Committee Chair: Bhavani Thuraisingham, The MITRE Corp., USA Co-Chair: Makoto Imase, NTT Labs, Japan Co-Chair: Linda Strick, GMD Fokus, Berlin, Germany Co-Chair: Jeffrey Tsai, U. of Illinois, Chicago, USA Members G. Agha, U. of IL, Urbana, USA R. Arai, U. of Tokyo, Japan D. Bae, KAIST, Korea F. Bastani, U. of TX, Dallas, USA E. Bertino, U. of Milano, Italy M. Ceruti, SPAWAR, USA I. Chen, Virginia, Tech, USA Y. Chen, U. of the Witwatersrand, South Africa R. Chow, U. of FL, USA J. Chung, IBM T.J. Watson Research Center, USA P. Chuang, Tamkang U., Taiwan P. Ciancarini, U. of Bologna. B. Cukic, West Virginia U., USA K. Eckert, GMD FOKUS Germany S. Eisenbach, Imperial College, UK D. Ferrari, U. of Catoloca, Italy M. Fisher, Manchester Metropolitan U., UK M. Fujita, Sony, Japan A. Fukuda, Nara Inst. of Science and Technology, Japan V. Garg, Univ. of TX, Austin, USA S. Ghosh, Arizona State U., USA A. Ghafoor, Purdue U., USA A. Ghose, U. of Wollongong, Australia M. Gien, Sun, France V. Gobel, U. of Oslo, Norway T. Higashino Osaka U., Japan D. Hislop, ARO, USA I. Iida, Fujitsu, Japan Y. Ishiguro, NEC, Japan K. Ito, TITECH, Japan Y. Kakuda, Hiroshima City U., Japan K. Kim, U.C. Irvine, USA H. Kopetz, TU Wien, Austria J. Kramer, Imperial College, UK L. LeLann, INRIA, France C. Liu, Chung Yuan Christian U., Taiwan M. Lyu, The Chinese U. of Hong Kong, Hong Kong Y. Masunaga, Ochanomizu U., Japan W. Meng , State U. of New York at Binghamton, USA R. Montanari, U. of Bologna, Italy W. Ng, Nanyang Technological U., Singapore A. Prakash, U. of Michigan, USA J. Putman, MITRE, USA Q. Qingquan, Southwest Jiatong U., China N. Raynal, INRIA, France W. Ruh, Concept-V, USA D. Serpanos, Inst. of Comuter Science, Technology-Hellas, Greece S. Shekhar, U. of MN, Mpls, USA L. Simoncini, CNUCE-CNR, Italy R. Stroud, U. of New Castle, UK V. Subrahmanian, U. of MD, College Park, USA K. Tsuchiya, Kyoto Uv, Japan B. Wah, U. of IL, Urbana, USA Y. Wakahara, U. of Tokyo, Japan F. Wang, National Chao Tung U., Taiwan M. Wooldridge, U. of Liverpool, UK H. Yokota, TITECH, Japan M. Yano, Tohoku U., Japan S. Yongqiang, Shanghai Jiao Tong U, China P. Yu, IBM T.J. Watson Research Center S. Zubairy, Quaid-e-Azam U., Pakistan Steering Committee Chair: Stephen S. Yau, Arizona State U., USA Hiroshi Kuwahara, Hitachi, Japan Kinji Mori, Tokyo Inst. of Technology, Japan Radu Popescu-Zeletin, GMD, Germany Publicity Chair Jorge Cobb, U. of Texas, Dallas, USA From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 22 21:46:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19292 for ; Thu, 22 Jun 2000 21:46:35 -0400 (EDT) Received: from standards (47.234.32.16:2277) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77ABB@standards.nortelnetworks.com>; Thu, 22 Jun 2000 21:36:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6291 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 22 Jun 2000 21:36:44 -0400 Received: from mirka.unet.com.mk (ns1.unet.com.mk) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77ABA@standards.nortelnetworks.com>; Thu, 22 Jun 2000 21:26:43 -0400 Received: from host (1Cust9.tnt1.providence.ri.da.uu.net [63.21.181.9]) by mirka.unet.com.mk (8.8.5/8.8.4) with ESMTP id DAA09836; Fri, 23 Jun 2000 03:35:21 +0200 X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Message-ID: <200006230135.DAA09836@mirka.unet.com.mk> Date: Thu, 22 Jun 2000 21:07:10 -0500 Reply-To: Sara Bento Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Sara Bento Subject: [MOBILE-IP] Please Join Us #7C22 X-To: part37jh@mirka.unet.com.mk To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Executive Guild Membership ApplicationResponse-O-Matic Form Dear Candidate,

You were recently selected by The Office of the Managing
Director for a free listing on The International Executive
Who's Who=2E

Our Researchers gather information from many recognized
sources, including professional associations and societies,
trade organizations, newspaper and magazine articles,
professional reference publications, web presence, and
referrals from existing members=2E

As a highly respected professional in your field of
expertise, we believe your contributions merit very
serious consideration for inclusion on The International
Executive Who's Who=2E  To maintain the highest
level of accuracy, we ask you fill out the brief bit of
information below required for inclusion=2E

There is no cost or obligation to be listed on The
International Executive Who's Who=2E
 

My Sincere Thanks,

Lorraine A=2E Michaels
Office Of Managing Director


The International Executive Who's Who is not affiliated or associated with Marquis Who's Who=2E

If you wish to be removed from our list, please submit your request
at the bottom of this email=2E
International Executive Who's Who
Registration Form
(US and Canada Only)
Please fill out this form if you would like to be included on The International Executive Who's Who=2E For accuracy and publication purposes, please complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed on The International Executive Who's Who=2E
Your Name
Your Company
Title
Address
City
State or Province
Country
ZIP/Postal Code
Day Time Telephone
Home Phone
 (Not To Be Published)
Email

TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E
Your Business
(Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E)
Type of Organization
(M= fg, Dist/Wholesaler, Retailer, Law Firm,
Investment Bank, Commercial Bank, University,
Financial Consultants, Ad Agency, Contractor, Broker, etc=2E)
Your Business Expertise
(Corp=2EMgmt, Marketing, Civil Engineering,
Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc=2E)
Major Product Line
(Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E)


Note: Submitting this form= will be made by email, not by use of www=2E  Confirmation of its delivery= is made by browsing your outgoing mail=2E

Thank you for filling in this form, we will contact you with more information=2E

The International Executive is not affiliated or associated with Marquis Who's Who=2E

List Removal
Click Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 23 00:10:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21676 for ; Fri, 23 Jun 2000 00:10:31 -0400 (EDT) Received: from standards (47.234.32.16:1421) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77B15@standards.nortelnetworks.com>; Fri, 23 Jun 2000 0:00:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6388 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 00:00:42 -0400 Received: from dnn910b (PPPa42-ResaleSyracuse1-4R7305.saturn.bbn.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77B07@standards.nortelnetworks.com>; Thu, 22 Jun 2000 23:50:38 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 23 Jun 2000 00:00:42 -0400 Reply-To: "Paul J. Milea jr." Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Paul J. Milea jr." Subject: [MOBILE-IP] Fiber Optic Cable needed immediateley ! To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM If this email has reached you by error please forgive the intrusion. Type "remove" in the subject line and hit send and I will promptlty remove you from any future mailings .Please accept my sincerest apology.I am very sorry if I have inconvenienced you in any way. Dear Sir(s),Ms.,Mrs., I have a client looking for a sizable quantity (1,156,000ft.) one million one hundred fifty six thousand feet of Fiber Optic Cable.It must be 48 Strand ,single mode ,single jacket, single armored. The cable we are looking for is similar to Chromatic 703 Series If this is available from your company, please quote price and availabilty .i.e. FOB ,amounts available, payment arrangements etc. If more specifications are needed, they are available. I need a quotation promptly and the buyer is willing to contract to purchase all ,if it is located. WE ARE NOT LOOKING FOR LEAD TIME >>>I AM LOOKING FOR INVENTORY IN STOCK OR AVAILABLE IN LESS THAN 10 DAYS. THERE IS AN IMMEDIATE NEED FOR THIS PRODUCT. PLEASE CALL IF YOU HAVE IT OR CAN HELP LOCATE !!! (there would be a finders fee awarded if you locate this fiber) Please email quotes or questions. Also please feel free to call with any questions. Regards,Paul J. Milea jr. ph 315 374 1560, fax 315 463 4337 Thank you again for your time ! From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 23 00:46:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21981 for ; Fri, 23 Jun 2000 00:46:23 -0400 (EDT) Received: from standards (47.234.32.16:1421) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77B59@standards.nortelnetworks.com>; Fri, 23 Jun 2000 0:36:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6492 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 00:36:44 -0400 Received: from ms.hansol.co.kr (203.235.136.4:4023) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77B58@standards.nortelnetworks.com>; Fri, 23 Jun 2000 0:36:43 -0400 Received: from ns ([210.112.7.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id NAA16305; Fri, 23 Jun 2000 13:45:19 +0900 References: <029501bfdc64$2f6ee3e0$2cf2cdc1@coritel.it> 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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <002901bfdcce$011fd3e0$d012060a@hansol.co.kr> Date: Fri, 23 Jun 2000 13:45:52 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: Re: [MOBILE-IP] Private addresses X-To: Raffaele Pellicciotta To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear Raffaele, You may have a look: draft-ietf-mobileip-rfc2344-bis-01.txt Reverse Tunneling for Mobile IP, revised in mobileip working group home page of IETF. Or you can find another approach for use of private ip addresses in this mailing list archives, they were not adapted as standards though. Regards, Jiwoong Lee M.com ----- Original Message ----- From: Raffaele Pellicciotta To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Sent: Friday, June 23, 2000 1:08 AM Subject: [MOBILE-IP] Private addresses Hi, I desire to have information about use of private addresses on Mobile IP!!! What is its state of art? Thanks a lot, Raffaele From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 23 10:04:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10980 for ; Fri, 23 Jun 2000 10:04:43 -0400 (EDT) Received: from standards (47.234.32.16:1473) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77D0D@standards.nortelnetworks.com>; Fri, 23 Jun 2000 9:54:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7032 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 09:54:46 -0400 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77D07@standards.nortelnetworks.com>; Fri, 23 Jun 2000 9:43:31 -0400 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA18994 for ; Fri, 23 Jun 2000 09:51:35 -0400 (EDT) Received: from ihgp24.ih.lucent.com (h135-1-53-29.lucent.com [135.1.53.29]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA17762 for ; Fri, 23 Jun 2000 09:50:14 -0400 (EDT) Received: by ihgp24.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA18862; Fri, 23 Jun 2000 08:49:15 -0500 (CDT) Received: from lucent.com by ihgp24.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA17401; Fri, 23 Jun 2000 08:47:51 -0500 (CDT) X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Original-CC: MOBILE-IP@standards.nortelnetworks.com References: <029501bfdc64$2f6ee3e0$2cf2cdc1@coritel.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39536A81.9D6F2DA3@lucent.com> Date: Fri, 23 Jun 2000 08:47:45 -0500 Reply-To: Tom Hiller Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Tom Hiller Organization: Lucent Technologies Subject: Re: [MOBILE-IP] Private addresses X-To: Raffaele Pellicciotta To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi The approach taken in 3GPP2 was to require the FA and HA to have public addresses, and then we keep track of link addresses, home address, and HA address in the FA. By maintaining this triplet of information, the FA can resolve overlapping addresses. We also authenticate the link itself (outside the scope of IETF protocols using a separate key and mobile identifier called and IMSI) -- it is important to authenticate the link with this approach. This discussion occured on the Mobile IP mailing list one year ago. Charles Perkins and Pat Calhoun also have a draft on private addresses that encompasses private HA and FA as well as MN home addresses. Thanks, Tom We did not tackle private HA or FA addresss Thanks Tom Hiller > Raffaele Pellicciotta wrote: > > Hi, I desire to have information about use of private addresses on Mobile > IP!!! > What is its state of art? > Thanks a lot, > Raffaele From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 23 13:17:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15617 for ; Fri, 23 Jun 2000 13:17:51 -0400 (EDT) Received: from standards (47.234.32.16:2883) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77DF1@standards.nortelnetworks.com>; Fri, 23 Jun 2000 13:07:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7330 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 13:07:46 -0400 Received: from rmx441-mta.mail.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77DEF@standards.nortelnetworks.com>; Fri, 23 Jun 2000 12:57:46 -0400 Received: from web312-mc.mail.com (web312-mc.mail.com [165.251.48.170]) by rmx441-mta.mail.com (8.9.3/8.9.3) with SMTP id NAA16445; Fri, 23 Jun 2000 13:07:00 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: mail.com X-Originating-IP: 204.178.20.14 Message-ID: <385898530.961780020391.JavaMail.root@web312-mc.mail.com> Date: Fri, 23 Jun 2000 13:06:59 -0400 Reply-To: lisa zheng Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: lisa zheng Subject: [MOBILE-IP] Wireless Data Usage? X-To: Tom Hiller To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, Is it safe to say most of the wireless data usage today and in the near future, follows the server-client model with mobile user being the client who initiate most of the connections? If so, can anybody provide me some pointers to support this? Also is there any statistics about the session duration vs. user mobility out on the web? Thank you in advance. Rong ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 23 13:56:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16266 for ; Fri, 23 Jun 2000 13:56:24 -0400 (EDT) Received: from standards (47.234.32.16:2883) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77E5E@standards.nortelnetworks.com>; Fri, 23 Jun 2000 13:46:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7456 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 13:46:39 -0400 Received: from ennovatenetworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77E54@standards.nortelnetworks.com>; Fri, 23 Jun 2000 13:36:39 -0400 Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id NAA03006; Fri, 23 Jun 2000 13:45:49 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Message-ID: <01d101bfdd3b$6b4d4be0$d001010a@tst.ennovatenetworks.com> Date: Fri, 23 Jun 2000 13:49:45 -0400 Reply-To: bkumar@ennovatenetworks.com Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Brijesh Kumar Subject: Re: [MOBILE-IP] Wireless Data Usage? X-To: lisa zheng To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <385898530.961780020391.JavaMail.root@web312-mc.mail.com> Content-Transfer-Encoding: 7bit > Is it safe to say most of the wireless data usage today and > in the near future, follows the server-client model with > mobile user being the client who initiate most of the > connections? Lisa, Generally true, because a device has to first register with the network to tell that it is there. Note, a few caveats here - most wireless data devices (that is its wireless transmitter) are put in the "sleep mode" after a period of inactivity to increase battery life. When the network gets a message, it "wakes" the device. Email delivery to a wireless data device works typically in this way. Telemetry applications may work either way (you poll devices or a device is programmed to send report periodically.). > If so, can anybody provide me some pointers to > support this? Also is there any statistics about the session > duration vs. user mobility out on the web? Don't have any reference right away. Cheers, --brijesh Ennovate Networks Inc. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 23 18:07:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20331 for ; Fri, 23 Jun 2000 18:07:48 -0400 (EDT) Received: from standards (47.234.32.16:1259) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77FB8@standards.nortelnetworks.com>; Fri, 23 Jun 2000 17:56:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7919 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 17:56:23 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB77FB7@standards.nortelnetworks.com>; Fri, 23 Jun 2000 17:56:22 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA24783; Fri, 23 Jun 2000 15:05:27 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id PAA05954; Fri, 23 Jun 2000 15:05:27 -0700 (PDT) Received: (from samita@localhost) by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) id e5NM5PL311795; Fri, 23 Jun 2000 15:05:25 -0700 (PDT) Content-Type: X-sun-attachment Message-ID: <200006232205.e5NM5PL311795@jurassic.eng.sun.com> Date: Fri, 23 Jun 2000 15:05:25 -0700 Reply-To: Samita Chakrabarti Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Samita Chakrabarti Subject: Re: [MOBILE-IP] Private addresses X-To: pellicciotta@CORITEL.IT, tom.hiller@LUCENT.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 76 Hello: Please see the attached proposed text for addition in the appendix in the rfc2344-bis draft. Please note that this is a rough update and it is under editor's review. Regards, Samita ----- Begin Included Message ----- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 23 07:05:39 2000 X-Accept-Language: en MIME-Version: 1.0 Original-CC: MOBILE-IP@standards.nortelnetworks.com Content-Transfer-Encoding: 7bit Date: Fri, 23 Jun 2000 08:47:45 -0500 From: Tom Hiller Subject: Re: [MOBILE-IP] Private addresses X-To: Raffaele Pellicciotta To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi The approach taken in 3GPP2 was to require the FA and HA to have public addresses, and then we keep track of link addresses, home address, and HA address in the FA. By maintaining this triplet of information, the FA can resolve overlapping addresses. We also authenticate the link itself (outside the scope of IETF protocols using a separate key and mobile identifier called and IMSI) -- it is important to authenticate the link with this approach. This discussion occured on the Mobile IP mailing list one year ago. Charles Perkins and Pat Calhoun also have a draft on private addresses that encompasses private HA and FA as well as MN home addresses. Thanks, Tom We did not tackle private HA or FA addresss Thanks Tom Hiller > Raffaele Pellicciotta wrote: > > Hi, I desire to have information about use of private addresses on Mobile > IP!!! > What is its state of art? > Thanks a lot, > Raffaele ----- End Included Message ----- ----- Begin Included Message ----- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 22 09:20:29 2000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Date: Thu, 22 Jun 2000 18:08:47 +0200 From: Raffaele Pellicciotta Subject: [MOBILE-IP] Private addresses To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, I desire to have information about use of private addresses on Mobile IP!!! What is its state of art? Thanks a lot, Raffaele ----- End Included Message ----- ---------- X-Sun-Data-Type: default X-Sun-Data-Name: draft_update.privaddr X-Sun-Charset: us-ascii X-Sun-Content-Lines: 83 A.4. Requirements for Limited Private Address Support 10.10.1.2 |----| IF1=COA1|-------| HAA2 |-----| | MN1|--------------------------------| FA |---------------| HA2 | |----| |---------| | |-----| | IF2=COA2|-------| |--------------| | | | |-----| | | MN2 | | |-----| | 10.10.1.2 | | HAA1 |------| | HA1 | |------| Figure: ?? The above figure X presents a possible scenario for private address deployment. In this simple private address deployment scenario, only mobile node home addresses are private addresses. Private addresses are strictly those defined in RFC1918. The foreign agent FA has publicly routable addresses on all of it's advertising interfaces. In the above scenario, FA advertises COA1 and COA2 on two different advertising interfaces. Similarly both HA2 and HA1 have publicly routable home agent addresses. COA1 and COA2 are topologically connected with HAA1 and HAA2 respectively, i.e, it's possible that HAA1 is reachable via a physical interface other than IF1 from the foreign agent, but the tunnels between FA and HA1 are configured using COA1 and HAA1 addresses. Also, note that two different mobile-nodes with same private address are visiting the same FA. Requirements for the above private address scenario: Mobile node requirements: Mobile nodes (MN) intending to use private address mobile-ip MUST use the 'T' bit and employ reverse tunneling. Mobile node's private addresses within a given address space MUST be unique. Thus two mobile nodes belonging to single home agent cannot have overlapping private addresses. In this scenario the mobile- nodes always remain outside their home network. If the mobile node happens to register with multiple home agents simultaneously through the same foreign agent and through the same link, then the mobile node MUST use unique home address for each connection to the home agents. Foreign agent requirements: All advertising interfaces of the foreign agent MUST have publicly routable Care Of Addresses (COA). Thus a MN with a private address visits the foreign agent only in it's publicly routable network. Foreign agent MUST support reverse tunneling in order to support private addressed mobile-nodes. (Q: Should it reject a registration request with turned off 'T' bit from a private addressed MN ? ) For simplicity of implementation, foreign agent may not support overlapping private addressed mobile nodes per link. Foreign agent MUST disambiguate among overlapping private addressed mobile nodes (see figure X) in both direction of packet delivery by using link layer information like GRE key id, interface identifier and others listed previously (Appendix section A.2 and A.3). A foreign agent in absence of route optimization, should make sure that two mobile nodes visiting the same foreign agent corresponds with each other through their respective home agents. If a foreign agent supports reverse tunneling and is able to process 'T' bit in the registration request, then it MUST support the simple scenario of private address support described in this section. Home agent requirements: Home agent address which is used by the mobile node for registration request MUST be a publicly routable address. Home agent will not support overlapping private home addresses, thus each private home address of a mobile node registered with a home agent is unique. When 'T' bit is set in the registration request from the mobile node, Home agent MUST recognize and accept registration request from mobile nodes with private addresses and the home agent should also be able to assign private addresses as home address from it's address pool. This does not contravene home agent processing in section 3.8 of RFC2002-bis. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 23 20:44:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23644 for ; Fri, 23 Jun 2000 20:44:54 -0400 (EDT) Received: from standards (47.234.32.16:2253) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7807F@standards.nortelnetworks.com>; Fri, 23 Jun 2000 20:35:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8183 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 23 Jun 2000 20:35:18 -0400 Received: from webmail2.hansolm.com (210.112.10.141:4352) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7807E@standards.nortelnetworks.com>; Fri, 23 Jun 2000 20:25:17 -0400 Received: from ns ([210.112.7.7]) by webmail2.hansolm.com with Microsoft SMTPSVC(5.5.1877.197.19); Sat, 24 Jun 2000 09:29:04 +0900 References: <01d101bfdd3b$6b4d4be0$d001010a@tst.ennovatenetworks.com> 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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <004801bfdd74$0a2c8d60$d012060a@hansol.co.kr> Date: Sat, 24 Jun 2000 09:35:04 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: Re: [MOBILE-IP] Wireless Data Usage? X-To: bkumar@ennovatenetworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Some vendor's solutions provide automatic mobile ip registration after booting up. In this way, connections initiated by another node in the public internet can be established with the mobile node, even tough the end user does not labor for mobile ip registration start. By the way, a leaf node s also apt to be a client in wired communications, and there seems more terminals than routers in the world. Jiwoong Lee M.com ----- Original Message ----- From: Brijesh Kumar To: Sent: Saturday, June 24, 2000 2:49 AM Subject: Re: [MOBILE-IP] Wireless Data Usage? > > Is it safe to say most of the wireless data usage today and > > in the near future, follows the server-client model with > > mobile user being the client who initiate most of the > > connections? > > Lisa, > > Generally true, because a device has to first register with the > network to tell that it is there. Note, a few caveats here - most > wireless data devices (that is its wireless transmitter) are put in > the "sleep mode" after a period of inactivity to increase battery > life. When the network gets a message, it "wakes" the device. Email > delivery to a wireless data device works typically in this way. > Telemetry applications may work either way (you poll devices or a > device is programmed to send report periodically.). > > > If so, can anybody provide me some pointers to > > support this? Also is there any statistics about the session > > duration vs. user mobility out on the web? > > Don't have any reference right away. > > Cheers, > > --brijesh > Ennovate Networks Inc. > > From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jun 25 02:15:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02344 for ; Sun, 25 Jun 2000 02:15:20 -0400 (EDT) Received: from standards (47.234.32.16:3671) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7844B@standards.nortelnetworks.com>; 25 Jun 2000 2:04:57 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9507 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 25 Jun 2000 02:04:57 -0400 Received: from bunyip.flash.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78445@standards.nortelnetworks.com>; 25 Jun 2000 1:54:56 -0400 Received: from host (QNCYA020-1161.splitrock.net [63.252.3.145]) by bunyip.flash.net (8.9.3/Pro-8.9.3) with ESMTP id BAA25877; Sun, 25 Jun 2000 01:04:10 -0500 (CDT) X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <200006250604.BAA25877@bunyip.flash.net> Date: Sat, 24 Jun 2000 22:30:29 -0500 Reply-To: Tori Herbet Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Tori Herbet Subject: [MOBILE-IP] Home Workers Needed #68B8 X-To: unit30f@bunyip.flash.net To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA02344 HOME-WORKERS NEEDED! Earn up to $500 or more per week, performing simple assembly or clerical work in your home. Dear Future Home-Worker: Would you like to have a higher income each week, an extra $500 or more? Are you tired of trying to make ends meet on your present income? Do you find yourself envying your friends and neighbors because of the things they have, like new cars, TV's, home entertainment centers, or all the right clothes that you just can't seem to afford? Many people - just like you, for one reason or another, are choosing to take advantage of their spare time to make more money - extra money. With the economy the way it is today, a family cannot make it on one paycheck a week. Whether you are a mother needing to stay home with your children, or a single man or woman needing a bigger and better income, we all have one thing in common. WE NEED MORE MONEY! We'll Show You How to Receive that Extra Income Now you can make money by assembling products in the comfort of your own home, working at your own pace! Manufacturing and Distributing companies supply you with materials and easy-to-follow instructions, and pay you for completed work. They work across Canada and the United States, everything is done through the mail, and these companies will even pay shipping and postage! These jobs are real and honest - you can earn an honest day's wage for an honest day's work! And it is so easy to get! You will be hired in your own home through the mail - No Resumes, Experience, Selling or Running for Interviews! Work for several companies at one time. Let the whole family pitch in. Be your own boss and choose your own hours. You must be honest and trustworthy. Wouldn't it be nice if you could find a job that lets you work from your own home, in your spare time? Where there's no need to rearrange your present schedule and miss those pleasures in life you so much enjoy. And best of all...you'll receive steady paychecks each week. Your time is worth much more than just $7.00 an hour, and your family life need not suffer with you being away from home. With no boss looking over your shoulder, you'll feel like you're being paid for doing a hobby. While doing the kind of work you enjoy, you can watch your favorite TV shows and still make money. The whole family can get involved. Choose The Job You Enjoy We have all had hobbies in the past we wish we could have been paid for. Now there is a way we can earn money each week by doing these hobbies. After extensive research, we have developed the Home Employment Directory - a comprehensive guide that lists dozens of companies that need your help, and pay you TOP DOLLARS. Many companies will actually train you to work for them Here are just a few examples: * Arts & Crafts * Newspaper Clipping Assembly & Manufacturingof: * Computer Work * Recording Video Tapes * Beaded earrings * Stuffed Animals * Hand Painting * Sewing & Needlework * Cloth Flowers * Tote Bags * Mail Processing * Survey Work * Jewelry * Toys & gifts * Data Entry * Typing * Plant Hangers * Wood Products No Selling Required The companies offering home assembly do their own selling. All they want you to do is follow their easy instructions, and pay you for the completed work. You simply assemble their products or complete their home-work projects according to their instructions - and you get paid upon completion and return of the finished goods to the company. They will do the rest. Since people have a wide range of interest. The Home Employment directory also contains a large variety of home-business and home -sales opportunities as well as regular work. Positions are identified by category. If you don't want a position that requires any selling, simply ignore it and go on to those you are interested in - there are many to choose from! Below are just a few very brief descriptions of the type of assembly and clerical work available: * One agency offers typing, hand-addressing and other easy clerical work you can do from home to earn up to $500 a week! * Earn up to $495 per week assembling beautiful and distinctive earrings for this company. They will provide easy and detailed instructions - no selling involved! * Sew beautiful golf club covers for this growing company and earn up to $421.50 weekly! * Make Holiday gifts and decorations year round for a company that will pay up to $450 weekly. Assemble oven mitts, pillows, ornaments, etc. * One company will get you started in earning $625 or more per week by processing their mail! * Assemble clown dolls for a company that will pay you $750 for your completed work! * All you need is a sewing machine to earn up to $350 a week by sewing nylon sports bags for this company! About Our Directory: The Home Employment Directory includes the name and address of each company with a full description of the assembly or clerical work offered. Our listings include a large assortment of companies and exciting home-work opportunities, the above is just a small sample of what's available. Our directory is a comprehensive, up-to-date publication containing information on the most profitable opportunities available. Most of the assembly opportunities require no special training, skills or equipment - just a sincere desire to get started. Others require basic sewing, typing, writing, computer skills, etc. Many companies will train you to work with them. They will provide you with instructions that are easy to understand, and projects that can be mastered quickly. All the opportunities are easy to get started in, and can be done either part-time or full-time for an excellent income! Now. It's All up to YOU! These companies NEED YOU! They want you to be able to earn a large income from home, and pay you handsomely for your efforts. What more could you ask for? The only way on earth that these jobs will work for you is... if you do it! For your sake and your family's - DON'T PASS UP THIS GOLDEN OPPORTUNITY! SOME DAY SOON YOU'LL PROBABLY LOOK BACK AND CONSIDER THIS TO BE THE BEST INVESTMENT YOU'VE EVER MADE. It is our sincere hope that you respond today and get started making money from your own home NOW! Similar guides are sold by others for $29.00 and more, but our Home Employment Directory is yours for only $18.00. With some of the opportunities we have listed in our directory, you can make that much money in one hour or less. To receive your copy of the directory through first class mail, fill in the order form below, and mail it in along with $18.00 plus $2.00 shipping & handling ($20.00 total) Please don't delay - don't let someone else take YOUR work-at -home job away from you! --------------------------------------------------------------------- --------------------------------------------------------------------- ------------ Home Employment Directory I'm ready to start making money from home now! Order Form: Please RUSH me a copy of the Home Employment Directory. I understand it is guaranteed to contain Send $20 Cash, Check or Money Order To: everything as promised or my money back. P D Enterprises P. O. Box 924 Ottawa, Kansas 66067 Name_____________________________________ Address___________________________________ City______________State________Zip__________ ************************************************************ Please remove at: mailto:brnt25r@netscape.net?subject=remove ************************************************************ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Sun Jun 25 07:23:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07006 for ; Sun, 25 Jun 2000 07:23:39 -0400 (EDT) Received: from standards (47.234.32.16:4169) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB784DE@standards.nortelnetworks.com>; 25 Jun 2000 7:13:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9707 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Sun, 25 Jun 2000 07:13:54 -0400 Received: from 255.255.255.255 (bbig005122.netvigator.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB784DD@standards.nortelnetworks.com>; 25 Jun 2000 7:03:53 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <419.436702.75008067bd_recycle@hongkong.com> Date: Sun, 25 Jun 2000 07:13:54 -0400 Reply-To: BD Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: BD Subject: [MOBILE-IP] °ª»ù¦¬ÁʦUÃþ·s¹q¤l²£«~¡B¹s¥ó¤Îª÷Äݪ«®Æ To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit ¦¹¸ê®Æ¤£¶Ç²Ä¤G¦¸¡A¦p¦X¥Î½Ð«O¯d¡F¦p¤£¦X¥Î¡A·q½Ð­ì½Ì¡C ¥»¤½¥q¤j¶q¦¬ÁʦUÃþ·s¤ⴣ¹q¸Ü¤Î¹q¦À¡B¶Ç©I¾÷¡B¹q¸£¡B¤â´£¹q¸£¡B¥´¦L¾÷¤Î¯»²°¡B¶Ç¯u¾÷¤Î¯» ²°¡B¹q¤l²£«~¤Î¹s¥ó¡B¤­ª÷ª«®Æ¤Î°t¥óµ¥µ¥¡]¨ä¥LÃþ§O¥i­P¹q¬d¸ß¡^¡A¦nÃa³£¦¬¡C´`Àô¦A³y©ÎÀô«O ³B²z¡A°ê¤º©Î³fÂd½XÀY´£³f§¡¥i¡CÀô«O¸pµn°O¡C½Ð­P¹q (852) 8207 3186. Purchase your stock of electronic products, parts, etc. This information would not send second time. If you find useful, please keep. If not, we are sorry for inconveniences caused. We purchase new / old mobile phone / batteries, pager, computer, notebook computer, printer, toner cartridge, fax machine, electronic products and components, etc. Either good or damaged - for recycle and special treatment. We can get your goods from China, Container Port. Please call me at (852) 8207 3186. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 26 04:52:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28440 for ; Mon, 26 Jun 2000 04:52:17 -0400 (EDT) Received: from standards (47.234.32.16:3554) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB786D0@standards.nortelnetworks.com>; Mon, 26 Jun 2000 4:41:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10383 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 26 Jun 2000 04:41:40 -0400 Received: from nausicaa.coritel.it (193.205.242.5:41412) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB786CF@standards.nortelnetworks.com>; Mon, 26 Jun 2000 4:41:39 -0400 Received: from archimede (archimede.coritel.it [193.205.242.44]) by nausicaa.coritel.it (8.9.3/8.9.3) with SMTP id KAA18776 for ; Mon, 26 Jun 2000 10:41:09 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E1_01BFDF5C.65FB0C40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <00e401bfdf4b$abadd260$2cf2cdc1@coritel.it> Date: Mon, 26 Jun 2000 10:50:53 +0200 Reply-To: Raffaele Pellicciotta Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Raffaele Pellicciotta Subject: [MOBILE-IP] Information on NAI(network address identifier) To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_00E1_01BFDF5C.65FB0C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I desire to know about mobile IP implementations which support use = of private addresses=20 and use of NAI for authentication. Bye, Raffaele Pellicciotta ------=_NextPart_000_00E1_01BFDF5C.65FB0C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, I desire to know about mobile IP=20 implementations which support use of private = addresses 
    and use of = NAI for=20 authentication.
    Bye,
        = Raffaele=20 Pellicciotta
------=_NextPart_000_00E1_01BFDF5C.65FB0C40-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 26 05:30:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28643 for ; Mon, 26 Jun 2000 05:30:55 -0400 (EDT) Received: from standards (47.234.32.16:3554) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78705@standards.nortelnetworks.com>; Mon, 26 Jun 2000 5:19:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10449 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 26 Jun 2000 05:19:02 -0400 Received: from cedar.dcs.shef.ac.uk by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78701@standards.nortelnetworks.com>; Mon, 26 Jun 2000 5:19:01 -0400 Received: from borg (borg.dcs.shef.ac.uk [143.167.11.44]) by cedar.dcs.shef.ac.uk (8.9.3+Sun/8.9.3) with SMTP id KAA29761; Mon, 26 Jun 2000 10:28:23 +0100 (BST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0185_01BFDF59.9299CE60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: <018801bfdf51$3107c100$2c0ba78f@dcs.shef.ac.uk> Date: Mon, 26 Jun 2000 10:30:39 +0100 Reply-To: Chern Nam Yap Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Chern Nam Yap Subject: [MOBILE-IP] Internet Draft To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0185_01BFDF59.9299CE60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I've summitted a draft on Itinerant Internet Protocol. It defines how to achieve mobility on both IPv4 and IPv6. Any comments are welcome. You can grap a copy from http://www.ietf.org/internet-drafts/draft-cnyap-iip-00.txt Thanks -------------------------------------------------------------------------= ------ Chern Nam Yap Center for Mobile Communication Research Department of Electronic and Electrical Engineering University of Sheffield Regent Court 211 Portobello Street Sheffield S1 4DP United Kingdom Tel:+44 (0) 114-222-3308 Fax:+44 (0) 114-222-8299 Web: www.mobile1.net E-mail: cny@dcs.shef.ac.uk E-mail: cny@ieee.org ------=_NextPart_000_0185_01BFDF59.9299CE60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
I've summitted a draft on = Itinerant Internet=20 Protocol.
It defines how to achieve mobility = on both=20 IPv4 and IPv6.
Any comments are welcome.
You can grap a copy from
http:= //www.ietf.org/internet-drafts/draft-cnyap-iip-00.txt
 
Thanks
----------------------------------------------------------------= ---------------
Chern=20 Nam Yap
Center for Mobile Communication Research
Department of = Electronic=20 and Electrical Engineering
University of Sheffield
Regent = Court
211=20 Portobello Street
Sheffield S1 4DP
United Kingdom
Tel:+44 (0)=20 114-222-3308
Fax:+44 (0) 114-222-8299
Web: www.mobile1.net
E-mail: cny@dcs.shef.ac.uk
E-mail: cny@ieee.org
------=_NextPart_000_0185_01BFDF59.9299CE60-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 26 08:13:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02027 for ; Mon, 26 Jun 2000 08:13:32 -0400 (EDT) Received: from standards (47.234.32.16:2092) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7878D@standards.nortelnetworks.com>; Mon, 26 Jun 2000 8:03:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10633 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 26 Jun 2000 08:03:39 -0400 Received: from tiku.hut.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7878C@standards.nortelnetworks.com>; Mon, 26 Jun 2000 8:03:39 -0400 Received: from akaatti.hut.fi (tweckstr@akaatti.hut.fi [130.233.249.61]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id PAA08067; Mon, 26 Jun 2000 15:12:16 +0300 (EET DST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Message-ID: Date: Mon, 26 Jun 2000 15:12:05 +0300 Reply-To: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: =?ISO-8859-1?Q?Tom_Weckstr=F6m?= Subject: Re: [MOBILE-IP] Private addresses X-To: Raffaele Pellicciotta To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <029501bfdc64$2f6ee3e0$2cf2cdc1@coritel.it> Content-Transfer-Encoding: 8BIT Hello! Private address issue is discussed in Jouni Malinen's thesis and a solution is implemented in Dynamics - HUT Mobile IP. The solution allows private addresses for all other interfaces except the ones from a FA to the Internet and a HA to the Internet. More information from http://www.cs.hut.fi/Research/Dynamics/ Regards Tom On Thu, 22 Jun 2000, Raffaele Pellicciotta wrote: pellic >Hi, I desire to have information about use of private pellic >addresses on Mobile IP!!! pellic > What is its state of art? pellic > Thanks a lot, pellic > Raffaele pellic > -- Tom Weckström Dynamics group Helsinki University of Technology dynamics@cs.hut.fi http://www.cs.hut.fi/Research/Dynamics/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 26 11:34:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08675 for ; Mon, 26 Jun 2000 11:34:34 -0400 (EDT) Received: from standards (47.234.32.16:1276) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7880B@standards.nortelnetworks.com>; Mon, 26 Jun 2000 11:24:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0075 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 26 Jun 2000 11:24:19 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7880A@standards.nortelnetworks.com>; Mon, 26 Jun 2000 11:14:18 -0400 Received: from cse.uta.edu (cse.uta.edu [129.107.12.1]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id KAA24577 for ; Mon, 26 Jun 2000 10:23:38 -0500 (CDT) Received: from cse.uta.edu (IDENT:ramesh@[129.107.55.202]) by cse.uta.edu (8.9.0/8.9.0) with ESMTP id KAA28408; Mon, 26 Jun 2000 10:15:18 -0500 (CDT) X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39577488.B97C6C85@cse.uta.edu> Date: Mon, 26 Jun 2000 10:19:36 -0500 Reply-To: ramesh@cse.uta.edu Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ramesh Yerraballi Organization: UTA Computer Science and Engineering Subject: [MOBILE-IP] WoWMoM-2000: Call for Participation X-To: MOBICOM@ACM.ORG To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit --------------------------------------------------------------------- CALL FOR PARTICIPATION WoWMoM-2000 The Third ACM International Workshop on Wireless Mobile Multimedia (in conjunction with MobiCom-2000) August 11, 2000 (Friday) Seaport Hotel at the World Trade Center, Boston, Massachusetts, USA --------------------------------------------------------------------- Sponsors: * ACM SigMobile Support from: * Nortel Networks * The University of California at Riverside * DIMACS - The Center for Discrete Mathematics & Theoretical Computer Science * CReWMaN at the University of Texas at Arlington --------------------------------------------------------------------- For uptodate technical program, registration information, and hotel information for the WoWMoM workshop are now available at http://www-cse.uta.edu/crewman/conferences/wowmom-2000/ If you are unable to access the above web page, please send e-mail to ramesh@cse.uta.edu -------------------------------------------------------------------------- WoWMoM 2000 Technical Program -------------------------------------------------------------------------- Welcome Address (8:00 am - 8:30 am) -------------------------------------------------------------------------- Session I ( 8:30 am - 10:00 am) Wireless QoS: Admission and Call Control * W2F2Q: Packet Fair Queuing in Wireless Packet Networks Yung Yi, Yongho Seok, Taekyoung Kwon and Yanghee Choi Seoul National University * A Wireless Fair Scheduling Algorithm for Error'Prone Wireless Channels Peng Lin, B. Bensaou, Q. L. Ding, and K.C. Chua National University of Singapore * A Novel Distributed Call Admission Control for Wireless Mobile Multimedia Networks Youssef Iraqi , University of Montreal Raouf Boutaba, University of Waterloo, Canada * Real-time Prioritized Call Admission Control in a Base Station Scheduler Jay R. Moorma, John W. Lockwood and Sung Mo Kang University of Illinois and Washington University, St. Louis -------------------------------------------------------------------------- Coffee Break (10:00 am - 10:30 am) -------------------------------------------------------------------------- Session II (10:30 am - 12:00 noon) Wireless Mobility: Support and Performance Analysis * An Integrated Mobility and Traffic Model for Resource Allocation in Wireless Networks Hisashi Kobayashi, Shum-Zheng Yu and Brian L. Mark Princeton University and George Mason University * Mobility Modeling of Rush Hour Traffic for Location Design Area in Cellular Networks Apurva Kumer, IBM - India Research Lab. M. N. Umesh, Silicon Automation Systems, India Rajesh Jha, Lucent Technologies, NJ * Multicast Support for Mobile IP with the Hierarchical Local Registration Approach H. Omar, T. Saadawi and M. Lee The City University of New York * Performance Evaluation of ATM/AAL2 as switching technology in 3G Mobile Access Networks Oscar Mezquita Baeza, GMD Fokus GmbH Berlin, Germany Enrico Scarrone, CSELT Turin, Italy -------------------------------------------------------------------------- Lunch Break (12:00 noon - 1:30 pm) -------------------------------------------------------------------------- Session III (1:30 pm - 3:00 pm) Resource Management in Mobile Systems * Managing the Storage and Battery Resources in an Image Capture Device (Digital Camera) using Dynamic Transcoding Surendar Chandra, Carla Schlatter Ellis and Amin Vahdat Duke University * Performance Modelling of Speculative Prefetching for Compound Requests in Low Bandwidth Networks N.J. Tuah, M. Kumar and S. Venkatesh Curtin University of Technology, Australia * A Modified CDMA/PRMA Medium Access Control Protocol for Integrated Services in LEO Satellite Systems Abbas Ibrahim and Samie Tohme Ecole Nationale Superieure des Telecommunications, Paris, France * Delay Jitter Performance of Video Traffic in a Cellular Wireless ATM Network T.C. Wong, J. W. Mark and K. C. Chua National University of Singapore and University of Waterloo, Canada -------------------------------------------------------------------------- Coffee Break (3:00 pm - 3:30 pm) -------------------------------------------------------------------------- Session IV (3:30 pm - 5:00 pm) Topic: Can Mobile Internet Be All Pervasive? Moderator: Kalyan Basu, Director, Nortel Networks Panelists: TBD -------------------------------------------------------------------------- END OF PROGRAM From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 26 12:15:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09662 for ; Mon, 26 Jun 2000 12:15:28 -0400 (EDT) Received: from standards (47.234.32.16:3180) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78861@standards.nortelnetworks.com>; Mon, 26 Jun 2000 12:05:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0173 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 26 Jun 2000 12:05:16 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7885C@standards.nortelnetworks.com>; Mon, 26 Jun 2000 11:55:16 -0400 Received: from uci.agh.edu.pl (root@galaxy.uci.agh.edu.pl [149.156.96.9]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id LAA24747 for ; Mon, 26 Jun 2000 11:04:37 -0500 (CDT) Received: from saturn.kt.agh.edu.pl (proms@saturn.kt.agh.edu.pl [149.156.114.3]) by uci.agh.edu.pl (8.9.3/8.8.7/rchk1.20) with SMTP id SAA07405 for ; Mon, 26 Jun 2000 18:04:14 +0200 (MET DST) Received: by saturn.kt.agh.edu.pl (AIX 3.2/UCB 5.64/5.1) for mobile-ip@smallworks.com id AA35356; Mon, 26 Jun 2000 18:03:21 +0200 Address: Mickiewicza 30, 30-059 Krakow, POLAND Message-ID: <10006261603.AA35356@saturn.kt.agh.edu.pl> Date: Mon, 26 Jun 2000 18:03:21 +0200 Reply-To: Piotr Pacyna Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Piotr Pacyna Organization: University of Mining and Metallurgy Subject: [MOBILE-IP] PROMS2000, deadline extended X-To: mobile-ip@smallworks.com To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear Sirs, Due to numerous requests for deadline extension we will keep accepting papers until 7th July 2000. Piotr Pacyna OC Chair ++++++++++++++++++++++++++++++++++++++++++++++++++++++ (We do apologize, if you receive multiple copies of this CfP) PROTOCOLS FOR MULTIMEDIA SYSTEMS - PROMS2000 DEADLINE EXTENDED Cracow, Poland, October 22-25, 2000 Sponsored by IEEE Poland Sect. and Cracow Communications Soc. Chap. Lucent Technologies, ZWUT a Siemens Company, http://PROMS2000.kt.agh.edu.pl/ After past successful PROMS conferences held in Berlin, Salzburg, Madrid, and Santiago de Chile now we cordially invite you to Cracow/Poland, a lovely university city, with a 1000 year history, today one of cultural capitals of Europe. Emerging broadband interactive applications along with a development of different networking technologies should draw telecom operators' and service providers' attention to protocols supporting multimedia systems as an interface between these two environments that has to be still investigated and modified. The PROMS2000 conference is intended to contribute to a scientific, strategical and practical cooperation between research institutes and industrial companies in the area of distributed multimedia applications, protocols, and intelligent management tools, with emphasis on their provision over broadband networks. PROMS2000 will cover papers and demonstrations on research and achievements related to the following topics: TOPICS * design and implementation of multimedia protocols for public switched telephony networks, mobile networks, data networks, and satellite networks using IP, ATM or other connectivity techniques; * application, media, and protocol integration: synchronization of media streams; * multiparty and group communication protocols; * mobile networking and routing: multimedia communication architectures for mobile networks; * multimedia applications: video-on-demand, digital video libraries, video games, virtual community, teleworking, teleteaching, e-commerce, telemeeting, virtual reality simulations; * content based searching and querying; * techniques for the specification of communication services required by multimedia applications; * methods for real-time testing and analysis of service implementations; * integration of media storage and communication mechanisms, operating system and high-performance issues; * experiences with service provisioning using distributed multimedia applications, eg. voice over IP; * performance of protocols, such as TCP, and applications: modeling, simulation and optimization in different networks; * definition, provisioning, and supervision of QoS parameters for networked applications and services, eg. in IntServ/DiffServ networks; * multimedia traffic engineering; * applications and platforms for service management and provisioning; * intelligent management tools pertaining to costs and quality of service, network access, accounting, security, and system resilience; * service access - security, authentication, privacy; * accounting and tariff policing for multimedia teleservices. IMPORTANT DATES * Full papers due July 7, 2000 * Authors notified July 24, 2000 * Full paper camera ready due September 25, 2000 CONFERENCE TIMETABLE * 1st day October 22 full-day sightseeing tour (optional) * 2nd day October 23 tutorials, welcome reception * 3rd day October 24 invited talks, sessions, panel, banquet * 4th day October 25 invited talks, sessions VENUE Its history rooted deep in the Middle Ages, Cracow, is the most celebrated city in Poland. UNESCO has added its architectural complex to the World Heritage List. Cracow's appeal today, however, is no longer attributable solely to the beauty of its medieval architecture, but to its strong scientific potential for applied research and development. The PROMS2000 Conference will be held on the modern premises of the Department of Telecommunications within walking distance of both the downtown area and hotels. Direct flights to Cracow are available to and from Chicago, Copenhagen, New York, Toronto, Frankfurt, London, Paris, Rome, Tel Aviv, Vienna and Zurich. SUBMISSION Submit a full manuscript to the PROMS chair in an electronic form (MSWord, Postscript or pdf file); editorial requirements can be found at http://PROMS2000.kt.agh.edu.pl/. PROCEEDINGS 1. Each participant will receive Proceedings from the conference. 2. Two best papers will be considered for publication in the IEEE Communications Magazine (March 2001 issue) in a feature topic "Protocols for Multimedia Systems". CONFERENCE CHAIR Zdzislaw PAPIR Department of Telecommunications University of Mining and Metallurgy Al. Mickiewicza 30 30-059 Cracow, Poland E-mail: papir@kt.agh.edu.pl Phone: +48 12 634 55 82 Fax: +48 12 634 23 72 PROGRAM COMMITTEE Koichi Asatani, Univ. Kogakuin, asatani@sin.cc.kogakuin.ac.jp William Atwood, Univ. Concordia, Bill@cs.Concordia.ca Arturo Azcorra, Univ. Carlos III de Madrid, azcorra@it.uc3m.es Stanislaw Budkowski, INT-Evry, stan@int-evry.fr Andrew Campbell, Univ. Columbia, campbell@ctr.columbia.edu Michel Diaz, LAAS-CNRS, diaz@laas.fr Wolfgang Effelsberg, Univ. Mannheim, effelsberg@informatik.uni-mannheim.de Paolo Fasano, CSELT, Paolo.Fasano@cselt.it Francisco Fontes, Portugal Telecom, fontes@ptinovacao.pt Nicolas D. Georganas, Univ. Ottawa, georgana@mcrlab.uottawa.ca Per Gunningberg, Univ. Uppsala, Per.Gunningberg@docs.uu.se Ibrahim Habib, Univ. New York Ulrich Hofmann, Univ. Salzburg, ulrich.hofmann@fh-sbg.ac.at David Hutchison, Univ. Lancaster, dh@comp.lancs.ac.uk Yuji Inoue, NTT, yuji@rd.nttdata.co.jp Andrzej Jajszczyk, Univ. Mining and Metallurgy, jajszcz@kt.agh.edu.pl Pedro Lizcano, Telefonica Labs, lizcano@tid.es John C. S. Lui, Chinese Univ. Hong Kong, cslui@cse.cuhk.edu.hk Andrzej R. Pach, Univ. Mining & Metallurgy, pach@kt.agh.edu.pl Sergio Palazzo, Univ. Catania, palazzo@iit.unict.it Thomas Plagemann, Center for Technology, plageman@unik.no Radia Perlman, SUN, radia.perlman@sun.com Radu Popescu-Zeletin, GMD, zeletin@fokus.gmd.de Marten J. van Sinderen, Univ. Twente, sinderen@cs.utwente.nl Kazem Sohraby, Lucent, sohraby@lucent.com Joan I. Solana, Nokia Telecom R & D, juan.solana@nokia.com Eduardo Vera, Univ. of Chile, evera@accessnova.cl Johan Zuidweg, Tecsidel, johan.zuidweg@ieee.org ORGANISING COMMITTEE Chair: Piotr PACYNA, proms@kt.agh.edu.pl K. Juszkiewicz, juszkiew@kt.agh.edu.pl J. Gozdecki, gozdecki@kt.agh.edu.pl J. Roman, roman@kt.agh.edu.pl From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 26 14:16:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12663 for ; Mon, 26 Jun 2000 14:16:11 -0400 (EDT) Received: from standards (47.234.32.16:2573) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78962@standards.nortelnetworks.com>; Mon, 26 Jun 2000 14:06:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0514 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 26 Jun 2000 14:06:16 -0400 Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7895B@standards.nortelnetworks.com>; Mon, 26 Jun 2000 13:56:15 -0400 Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA02326 for ; Mon, 26 Jun 2000 14:05:39 -0400 (EDT) Received: from ihgp24.ih.lucent.com (h135-1-53-29.lucent.com [135.1.53.29]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA02315 for ; Mon, 26 Jun 2000 14:05:39 -0400 (EDT) Received: by ihgp24.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA20951; Mon, 26 Jun 2000 13:05:34 -0500 (CDT) Received: from lucent.com by ihgp24.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA20938; Mon, 26 Jun 2000 13:05:31 -0500 (CDT) X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Original-CC: MOBILE-IP@standards.nortelnetworks.com References: Content-Type: text/plain; charset=iso-8859-1 Message-ID: <39579B65.A7E53AA0@lucent.com> Date: Mon, 26 Jun 2000 13:05:25 -0500 Reply-To: Tom Hiller Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Tom Hiller Organization: Lucent Technologies Subject: Re: [MOBILE-IP] Private addresses To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA12663 Hi, I'll check out your URL. The solution I discussed in my previous email is incorporated into 3GPP2's cdma2000 packet data standard IS-835. Thanks, Tom Tom Weckström wrote: > > Hello! > > Private address issue is discussed in Jouni Malinen's thesis and a > solution is implemented in Dynamics - HUT Mobile IP. The solution allows > private addresses for all other interfaces except the ones from a FA to > the Internet and a HA to the Internet. More information from > http://www.cs.hut.fi/Research/Dynamics/ > > Regards > Tom > > On Thu, 22 Jun 2000, Raffaele Pellicciotta wrote: > > pellic >Hi, I desire to have information about use of private > pellic >addresses on Mobile IP!!! > pellic > What is its state of art? > pellic > Thanks a lot, > pellic > Raffaele > pellic > > > -- > Tom Weckström Dynamics group > Helsinki University of Technology > dynamics@cs.hut.fi > http://www.cs.hut.fi/Research/Dynamics/ From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Mon Jun 26 16:54:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15647 for ; Mon, 26 Jun 2000 16:54:24 -0400 (EDT) Received: from standards (47.234.32.16:1462) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB789D3@standards.nortelnetworks.com>; Mon, 26 Jun 2000 16:44:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0663 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Mon, 26 Jun 2000 16:44:19 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB789D2@standards.nortelnetworks.com>; Mon, 26 Jun 2000 16:44:19 -0400 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29763 for ; Mon, 26 Jun 2000 14:53:40 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA19469 for ; Mon, 26 Jun 2000 13:53:36 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA06034 for ; Mon, 26 Jun 2000 13:53:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Mon, 26 Jun 2000 13:53:01 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: [MOBILE-IP] Comments on draft-haverinen-mobileip-gsmsim-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM I have some comments on the above mentioned Internet Draft. PatC 1. The title is misleading. It currently reads "GSM SIM Authentication for Mobile IP", and perhaps should be changed to "GSM SIM Authentication and Key Generation for Mobile IP". An alternative is to split up the functionality into two, but I am not sure whether one could use the authentication scheme described in the draft without key generation. 2. Section 1.0 states: "GSM subscribers are identified by an IMSI (International Mobile Subscriber Identifier), which is a string of digits. The format of IMSI is specified in [3]. The mobile node sends its IMSI to the mobility agent it is registering with in the first Registration Request." There has been some talk in 3GPP2 to support NAIs on the SIM card. Is 3GPP looking at something similar? It would terribly useful for the existing AAA infrastructure to be able to key off the same information to determine where the requests must be forwarded to. 3. Section 1.0 states: "The SIM key exchange uses two Mobile IP registration round trips. One reason for using two round trips is to let the GSM infrastructure generate the RANDs. This aims at facilitating the integration with the existing GSM networks. Another reason for using two round trips is to protect against SIM cracking attacks." This is a fairly substantitive change to Mobile IP, and there are high chances that the authentication will be done with an AAA server. Unfortunately, the current Challenge/Response Internet Draft, which has been through WG and IESG last call, does not allow the MN-AAA to be present in the Registration Reply. However, thinking about your proposal, it would require that the first round trip response be sent by the AAA server given that: 1. The user hasn't been authenticated, and 2. There may not be a Home Agent assigned So, a change to the Challenge/Response draft may be necessary. I would much prefer that this doesn't require a change in the current draft, but rather a change in the PS->DS document (at which point we should have a pretty good idea whether this draft will survive). 4. Section 3.1, figure 1 shows: Mobile Node Mobility Agent | | | Reg. Request + NAI ext. + SIM Key Request ext. | | Auth. ext. calculated with old key (if exists) | |------------------------------------------------>| I would prefer that we remove Mobility Agent, and substitute it for "Authenticating Entity". Of course, the AE MAY be the Home Agent, but it could also be an AAA server. 5. Section 3.1 states: "In this context, the NAI extension contains the user's IMSI." An IMSI does NOT conform to the syntactical rules specified in RFC 2486, so unless some changes are done to the AAA protocol, the AAA servers will not know how to "route" the requests. I do remember some work a while back that proposed using IMSI to map to NAI (or something along these lines). What is needed is an Internet Draft that defines the components of the IMSI, and how an AAA server determines where the Home AAA server is. 6. Section 3.1 states: "The mobile node SHOULD use a good source of randomness for generating nonceMN." I would add a reference to: D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness Recommendations for Security. Request for Comments (Informational) 1750, Internet Engineering Task Force, December 1994 7. Section 3.1 states: "The default hash function is MD5 [6] and the default MAC function is HMAC-MD5 [7]" Is the above stating that both MD5 (in the traditional sense) and HMAC MD5 are simultaneously used? Is this for compatibility with the existing SIM card? Furthermore, is h(n*Kc | nonceMN) using traditional MD5, while MAC(K, n*RAND | key lifetime) uses the HMAC version? 8. Section 3.2 states: "This message contains a SIM Key Request extension and the IMSI in a NAI extension [8]. The SIM Key Request extension contains a random number nonceMN picked by the mobile node and a key lifetime proposal. The NAI extension contains the user's NAI (Network Access Identifier) [9]" The above implies that the request contains TWO NAI extensions. If this is the case, I would prefer to not see the NAI be overloaded, and a new extension created to contain the IMSI. 9. Section 3.3 states: "In this case, the mobile node may retry the key exchange immediately. If, however, the Registration Reply doesn't contain a valid authentication extension, the mobile node must consider this message informational. The mobile node must not change its state or react to it in any way except write an entry to a log or show an error message to the user." Is this true? If an unauthenticated reply is received, then it isn't informational at all, but a likely malicious reply. Since one cannot distinguish one from the other, I would simply state that receiving such a message should be logged or ignored. 10. Section 3.3 states: "Discussion: Instead of sending an empty authenticator, should we omit the Mobile-Home Authentication extension if the mobile node and the home agent do not share an authentication key? This should be clarified once [1] is augmented with a specification of MN-HA Key Request extension." Discussion: no. My Foreign Agent ensures that either of the following is present: 1. MN-AAA, or 2. MN-HA (and MN-FA is configured as mandatory) I would have a serious problem with a request that does not contain an authentication extension with the Home Domain, even if the information is bogus. 11. Section 3.3 states: "If the mobile node and the foreign agent do not share a security association, authentication extensions are not used in the..." I presume the above should have read: "If the mobile node and the foreign agent do not share a security association, the Mobile-Foreign authentication extension is not used in the..." Of course, this is much more problematic than the above, since the Foreign Agent would have to know that the Mobile doesn't have an SA, and the Mobile-Foreign contains cannot be authenticated. In the Challenge/Response draft, this is solved by not requiring that the MN-FA be present if the MN-AAA is present. How would you propose to solve this issue in this draft? 12. Section 3.4 states: "The mobility agent uses an AAA protocol to send the MAC_SRES to the GSM network, which verifies it and sends an indication to the mobility agent." This is the first time that the AAA protocol is discussed to transport the Mobile IP messages. It (sort-of) implies that this is only done on the second round trip. Perhaps similar language needs to be crafter earlier on in the document when discussing the other extensions. This would eliminate the possible confusion. 13. Section 3.5 states: "The security association created with the session key exchange mechanism described above must have a Security Parameter Index (SPI). We use the well-known SPI SIM_SECURITY_CONTEXT_SPI (Section 5.1) for SIM-generated security association. Since the Mobile IP entities identify security associations with the pair (peer's IP address, SPI), it is possible to use the same SPI between all the entities." Would it be possible to have a different rule? The initial message cotains the specified SPI above, and the key generating entity forms an SPI with the key. All authentications using the generated key would use the SPI that was provided with the key. This way, when a new key is generated, a new SPI is used. This makes it MUCH easier to identify the key to use in order to authenticate. 14. Section 3.6 states: "The SIM Key Request extension is a non-skippable extension, so if the foreign agent doesn't support it, it silently discards the Registration Request." Personally, I think that RFC 2002 bis MUST fix this problem. A Mobility Entity that receives an non-skippable and unrecognzied extension should return an error. Otherwise, you have no idea why no response is being received. Is it because the Mobility Agent is no longer available, is it the request? 15. Section 2.6 states: "Later, we can specify support for parallel processing of SIM Key Request in the Foreign Agent. This means that the foreign agent may forward a Registration Request to the home agent and do the new session key exchange in parallel. The foreign agent would wait for the home agent's reply and insert the SIM Key Reply extension to it. This would speed up the first registration and allow grace periods. Adding this won't require any changes to the specified protocol messages." Is this an editor's note? 16. Section 4.3 states: "Error code The MN-FA SIM Key Reply and MN-HA SIM Key Reply extensions use the following error codes: 1 Reason unspecified 2 Operator does not have a roaming agreement with user's home operator. 3 Users calls are barred. 4 Insufficient resources. 5 User does not have the service subscribed." Is there a particular reason why the code in the Registration Reply cannot be re-used? It would make it MUCH simpler to parse and find an error. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Tue Jun 27 06:55:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06640 for ; Tue, 27 Jun 2000 06:55:53 -0400 (EDT) Received: from standards (47.234.32.16:2322) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78B74@standards.nortelnetworks.com>; Tue, 27 Jun 2000 6:45:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1215 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Tue, 27 Jun 2000 06:45:32 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78B73@standards.nortelnetworks.com>; Tue, 27 Jun 2000 6:35:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06389; Tue, 27 Jun 2000 06:44:57 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200006271044.GAA06389@ietf.org> Date: Tue, 27 Jun 2000 06:44:57 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-thuel-mobileip-tt-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Dynamic Home Addressing in Mobile IP using Transient Tunnels Author(s) : S. Thuel, L. Salgarelli, R. Ramjee, K. Varadhan, T. La Porta Filename : draft-thuel-mobileip-tt-00.txt Pages : 21 Date : 20-Jun-00 Dynamic home addressing has lately become a popular and viable approach for configuring mobile IP hosts. This draft introduces a method for these hosts to dynamically acquire a home address through DHCP when powering up in a foreign network, referred to as the Transient Tunneling (TT) procedure. Our procedure solves the problem that mobile hosts cannot rely on conventional broadcasting procedures to properly discover an addressing server in their home network. While leveraging the growing DHCP code-base, our procedure requires no changes to protocol standards and only minor changes to server implementations. In addition, its impact on host power-up latency is acceptable in conventional wide-area networks scenarios. Alternative solutions are discussed along with other issues related to dynamic addressing on mobile hosts such as wireless bandwidth usage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thuel-mobileip-tt-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-thuel-mobileip-tt-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-thuel-mobileip-tt-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000626143245.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-thuel-mobileip-tt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-thuel-mobileip-tt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000626143245.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 28 01:09:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03907 for ; Wed, 28 Jun 2000 01:09:03 -0400 (EDT) Received: from standards (47.234.32.16:4299) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78FA2@standards.nortelnetworks.com>; Wed, 28 Jun 2000 0:58:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2626 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 28 Jun 2000 00:58:57 -0400 Received: from ms.hansol.co.kr (203.235.136.4:3100) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB78FA1@standards.nortelnetworks.com>; Wed, 28 Jun 2000 0:58:57 -0400 Received: from ns ([210.112.7.7]) by ms.hansol.co.kr (8.9.3/8.9.3) with SMTP id OAA31603 for ; Wed, 28 Jun 2000 14:07:55 +0900 References: <200006141057.GAA14960@ietf.org> 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.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <013401bfe0be$f8181880$d012060a@hansol.co.kr> Date: Wed, 28 Jun 2000 14:08:28 +0900 Reply-To: "Lee, Jiwoong" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Lee, Jiwoong" Subject: Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-12.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear authors, I've read studies Mobile IP Challenge/Response I-D recently. There are minor problmes in semantics used in this I-D. Mixed use of defined terminology: [1] defines - Mobile-Home Authentication Extension - Mobile-Foreign Authentication Extension - Foreign-Home Authentication Extension [2] defines - Mobile IP Agent Advertisement Challenge Extension - MN-FA Challenge Extension - MN-AAA Authentication subtype of Generalized Mobile IP Authentication Extension Although everyone knows that 'Mobile' here in defined terminology means Mobile Node(MN) and 'Home' means Home Agent(HA), 'Mobile-HA Authentication extension' or 'MN-HA Authentcation Extension' is not defined, which both of them are used in this I-D though. [1] RFC2002bis [2] draft-ietf-mobileip-challenge-12.txt Thank you in advance for your comments Jiwoong Lee M.com From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 28 04:52:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17059 for ; Wed, 28 Jun 2000 04:52:14 -0400 (EDT) Received: from standards (47.234.32.16:4665) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79030@standards.nortelnetworks.com>; Wed, 28 Jun 2000 4:41:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2807 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 28 Jun 2000 04:41:59 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7902F@standards.nortelnetworks.com>; Wed, 28 Jun 2000 4:41:58 -0400 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id LAA22718 for ; Wed, 28 Jun 2000 11:51:26 +0300 (EETDST) Received: from esebh02nok.ntc.nokia.com (esebh02nok.ntc.nokia.com [131.228.118.151]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id LAA06607 for ; Wed, 28 Jun 2000 11:51:25 +0300 (EETDST) Received: by esebh02nok with Internet Mail Service (5.5.2650.10) id ; Wed, 28 Jun 2000 11:51:24 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <6D1A8E7871B9D211B3B00008C7490AA501697E48@treis03nok> Date: Wed, 28 Jun 2000 11:43:10 +0300 Reply-To: henry.haverinen@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Henry Haverinen Subject: Re: [MOBILE-IP] Comments on draft-haverinen-mobileip-gsmsim-00.tx t To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Pat, Thank you for your comments! > 1. The title is misleading. Yes, adding "key generation" to the title could clarify it. I don't think it's possible or even necessary to split up the functionality into authentication and key generation. > There has been some talk in 3GPP2 to support NAIs on the SIM > card. Is 3GPP > looking at something similar? I don't know. Storing the NAI on the SIM card would of course be very useful. With traditional SIM cards, the mobile node software probably needs to map the IMSI to a NAI. We could use NAIs like IMSI@realm. Since we currenly have no way of deducing the realm from IMSI, the realm could be configured to the Mobile IP software. This is what I intented to say in my draft, but it obviously needs clarification. I think that IMSI conforms to RFC2486 as the user part of a NAI. > What is needed is an Internet Draft that defines the components of > the IMSI, and how > an AAA server determines where the Home AAA server is. The IMSI is composed of a three digit Mobile Contry Code (MCC), a two digit Mobile Network Code (MNC) and a not more than 10 digit Mobile Subscriber Identification Number (MSIN). MCC and MNC uniquely identify the GSM operator. I guess we could reserve well known AAA domains for GSM operators, for example domains operator.gsm.org. Then an IMSI could be mapped to a NAI like this: MSIN@operator.gsm.org. Or perhaps GSM operators could establish a broker AAA server (for example gsm.org) which would know where to route the AAA requests. In this case we could use NAIs like IMSI@gsm.org. Once such a convention is established, an (informational?) Internet-Draft would be useful. > 3. Section 1.0 states: > "The SIM key exchange uses two Mobile > IP registration round trips. > This is a fairly substantitive change to Mobile IP, and there > are high chances > that the authentication will be done with an AAA server. First we thought of using an Agent Solicitation and an Agent Advertisement for the first round trip. However, that wouldn't have worked for the key exchange with the home agent (for example when we're using co-located addresses). The GSM case is a good example when it makes sense to have a different AAA home domain (the GSM operator) and Mobile IP home domain (for example user's corporation). The AAA domain may not be able to assign a home agent for the mobile node, but the mobile node would be configured with a home agent address (perhaps anycast in the IPv6 case). The home agent could use a pull sequence to talk to the user's HAAA server. I don't see much difference in the roles of the foreign agent and the home agent in this case. We're also testing the protocol with co-located care-of addresses, so the home agent may be the first mobility agent the mobile node is in contact with. > Unfortunately, the > current Challenge/Response Internet Draft, which has been > through WG and IESG > last call, does not allow the MN-AAA to be present in the > Registration Reply. Our draft uses MN-HA Key Replies, so is that an issue? BTW, we're also using MN-HA Key Requests, which are not specified in the current version of the generalized key distribution extensions draft. The GSM case shows that session keys are not always transported to the MN but they can be derived by the MN, based on some seed values. I suppose there could be other similar authentication methods which could require two round trips as well. > However, thinking about your proposal, it would require that > the first round > trip response be sent by the AAA server given that: > 1. The user hasn't been authenticated, and > 2. There may not be a Home Agent assigned The home agent could handle item 1 with a bogus Authentication extension. Item 2 is more difficult. I guess dynamic home agent assignment can only be used when the mobile node is using foreign agent care-of addresses. In this case the HAAA server would sent the first response. But then we couldn't use MN-HA key requests/replies? I agree that we should wait until the PS->DS phase before changing the Challenge/Response draft. > I would prefer that we remove Mobility Agent, and substitute it for > "Authenticating Entity". OK, that shouldn't be a problem. > I would add a reference to: > D. Eastlake, 3rd, S. Crocker, and J. Schiller. Randomness > Recommendations for Security. Request for Comments > (Informational) 1750, Internet Engineering Task > Force, December > 1994 Thanks! > 7. Section 3.1 states: > "The default hash function is MD5 [6] and the default MAC > function is > HMAC-MD5 [7]" > Is the above stating that both MD5 (in the traditional sense) > and HMAC MD5 are > simultaneously used? Is this for compatibility with the > existing SIM card? It's not for compatibility, it's just that the key is generated with a one-way hash function h(), which is not a message authentication code, and there are actual message authentication codes used as well. MD5 is used as the one-way hash function for generating the key. Message authentication codes are generated with HMAC_MD5, although I could have specified MD5 in prefix+suffix mode (which is a MAC function) to be used as well. Do you think this is a problem? > 8. Section 3.2 states: > "This message contains a SIM Key Request > extension and the IMSI in a NAI extension [8]. The SIM Key Request > extension contains a random number nonceMN picked by the > mobile node > and a key lifetime proposal. The NAI extension contains the user's > NAI (Network Access Identifier) [9]" > The above implies that the request contains TWO NAI > extensions. No, the request contains just one NAI extension, where the NAI has been mapped from the IMSI. I'll rewrite this part more clearly. > 9. Section 3.3 states: > "In this case, the > mobile node may retry the key exchange immediately. If, > however, the > Registration Reply doesn't contain a valid authentication > extension, > the mobile node must consider this message informational. > The mobile > node must not change its state or react to it in any way except > write an entry to a log or show an error message to the user." > Is this true? If an unauthenticated reply is received, then it isn't > informational at all, but a likely malicious reply. Since one cannot > distinguish one from the other, I would simply state that > receiving such a > message should be logged or ignored. I guess "informational" is not a good term. The words "doesn't contain a valid authentication extension" are intended to cover the bogus authentication extensions which the home agent might need to use if there is no previous MN-HA session key. If the error is for example "user does not have the service subscribed", it would be good if we could show this to the user. Maybe unsuccessful SIM Key Replies could also be accompanied with a RANDs and MAC_RAND, just to authenticate the reply message? In this case it would be safe to show the message to the user. > 10. Section 3.3 states: > "Discussion: Instead of sending an empty authenticator, should we > omit the Mobile-Home Authentication extension if the > mobile node and > the home agent do not share an authentication key? This should be > clarified once [1] is augmented with a specification of MN-HA Key > Request extension." > Discussion: no. My Foreign Agent ensures that either of the > following is > present: 1. MN-AAA, or > 2. MN-HA (and MN-FA is configured as mandatory) > I would have a serious problem with a request that does not contain an > authentication extension with the Home Domain, even if the > information is > bogus. OK. > 11. Section 3.3 states: > "If the mobile node and the foreign agent do not share a security > association, authentication extensions are not used in the..." > I presume the above should have read: > "If the mobile node and the foreign agent do not share a security > association, the Mobile-Foreign authentication extension is not > used in the..." Yes, you're right. > Of course, this is much more problematic than the above, > since the Foreign > Agent would have to know that the Mobile doesn't have an SA, and the > Mobile-Foreign contains cannot be authenticated. In the > Challenge/Response > draft, this is solved by not requiring that the MN-FA be > present if the MN-AAA > is present. How would you propose to solve this issue in this draft? MN-FA is not required to be present in the Reg.Request if MN-FA SIM Key Request is present, and MN-FA is not required to be present in the Reg.Reply if MN-FA SIM Key Reply is present? If the foreign agent requires Mobile-Foreign Authentication, this reply would have the code 67, "Mobile node failed authentication". If this is not the first SIM key exchange between the mobile node and the foreign domain, then MN-FA can be present. The authenticator is just calculated with the previous session key. > 12. Section 3.4 states: > "The mobility agent uses an AAA protocol to send the > MAC_SRES to the GSM > network, which verifies it and sends an indication to the > mobility agent." > This is the first time that the AAA protocol is discussed to > transport the > Mobile IP messages. It (sort-of) implies that this is only > done on the second > round trip. Perhaps similar language needs to be crafter > earlier on in the > document when discussing the other extensions. This would > eliminate the > possible confusion. Yes, I'll craft similar language for the first round trip as well. An AAA protocol is needed there too. > 13. Section 3.5 states: > "The security association created with the session key exchange > mechanism described above must have a Security Parameter Index > (SPI). We use the well-known SPI SIM_SECURITY_CONTEXT_SPI (Section > 5.1) for SIM-generated security association. Since the Mobile IP > entities identify security associations with the pair (peer's IP > address, SPI), it is possible to use the same SPI between all the > entities." > Would it be possible to have a different rule? The initial > message cotains the > specified SPI above, and the key generating entity forms an > SPI with the key. > All authentications using the generated key would use the SPI that was > provided with the key. This way, when a new key is generated, > a new SPI is > used. This makes it MUCH easier to identify the key to use in order to > authenticate. Sure we can use a different rule. This SPI business has just always puzzled me... In the generalized key distribution extensions, only the key request contains an SPI (Mobile Node SPI). The foreign agent and the home agent do not pick an SPI. Once the key has been distributed, is the Mobile Node SPI in used both ways, for both Registration Requests and Replies? > 14. Section 3.6 states: > "The SIM Key Request extension is a non-skippable extension, so if > the foreign agent doesn't support it, it silently discards the > Registration Request." > Personally, I think that RFC 2002 bis MUST fix this problem. It would make sense. I don't think this fix would make it very much easier to bring the mobility agent to its knees with a denial of service attack. However, in this case an unauthenticated Reg.Reply with an error code wouldn't help much, as the mobile node would silently discard it. > 15. Section 2.6 states: > "Later, we can specify support for parallel processing --- > Is this an editor's note? Yes it is. I wasn't sure if such parallel processing would be feasible. This needs further thought. > Is there a particular reason why the code in the Registration > Reply cannot be > re-used? It would make it MUCH simpler to parse and find an error. There could be MN-FA and MN-HA SIM key exchanges going on in parallel. If a Registration Reply contains both a MN-FA SIM Key Reply and a MN-HA SIM Key Reply, we can have two failure codes, so both the foreign agent and the home agent cannot set the code in Registration Reply. Another (not so important) reason is that the registration may be successful even if the SIM key exchange fails. This can happen when we already have a previous key to authenticate the registration messages that contain SIM key exhange extensions. On the other hand, if the key exchange fails, it doesn't help much to know that the registration was successful. If we don't support parallel MN-FA and MN-HA key exchanges, then I guess we could use the code in the Reg.Reply. Best regards, Henry From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 28 06:59:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18042 for ; Wed, 28 Jun 2000 06:59:19 -0400 (EDT) Received: from standards (47.234.32.16:4612) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79096@standards.nortelnetworks.com>; Wed, 28 Jun 2000 6:49:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2944 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 28 Jun 2000 06:48:57 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79095@standards.nortelnetworks.com>; Wed, 28 Jun 2000 6:38:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17797; Wed, 28 Jun 2000 06:48:26 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200006281048.GAA17797@ietf.org> Date: Wed, 28 Jun 2000 06:48:25 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-zhong-mobile-ip-mpls-01.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Integration of Mobile IP and MPLS Author(s) : R. Zhong, C. Tham, C. Foo, C. Ko Filename : draft-zhong-mobile-ip-mpls-01.txt Pages : 15 Date : 27-Jun-00 Multiprotocol Label Switching (MPLS) combines the efficiency and simplicity of IP routing together with the high-speed switching of ATM. Mobile IP is a protocol that allows mobile users to maintain continuous IP network connectivity. In this document, we describe a scheme to integrate both the Mobile IP and MPLS protocols. The integration of both these protocols improves the scalability of the Mobile IP data forwarding process by leveraging on the features of MPLS which are fast switching, small state maintenance and high scalability. In addition, we have removed the need for IP-in-IP tunneling from Home Agent (HA) to Foreign Agent (FA) under this scheme. This document defines the signaling and control mechanisms required to integrate MPLS and Mobile IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zhong-mobile-ip-mpls-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-zhong-mobile-ip-mpls-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zhong-mobile-ip-mpls-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000627104818.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zhong-mobile-ip-mpls-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-zhong-mobile-ip-mpls-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000627104818.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 28 09:58:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23296 for ; Wed, 28 Jun 2000 09:58:30 -0400 (EDT) Received: from standards (47.234.32.16:4642) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7915B@standards.nortelnetworks.com>; Wed, 28 Jun 2000 9:48:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3200 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 28 Jun 2000 09:48:23 -0400 Received: from zmamail03.zma.compaq.com (mailin.zma.compaq.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7915A@standards.nortelnetworks.com>; Wed, 28 Jun 2000 9:38:22 -0400 Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 945E9436A; Wed, 28 Jun 2000 09:47:52 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 3DF9441C5; Wed, 28 Jun 2000 09:47:52 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id JAA0000548831; Wed, 28 Jun 2000 09:47:51 -0400 (EDT) X-Mts: smtp Message-ID: <200006281347.JAA0000548831@anw.zk3.dec.com> Date: Wed, 28 Jun 2000 09:47:51 -0400 Reply-To: Jim Bound Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jim Bound Subject: [MOBILE-IP] IPv6 Bake-Off and Testing at ETSI X-To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com X-cc: Reinhard.Scholl@etsi.fr, whl@unh.edu To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Dear IPv6-ers, Sorry for the Interrupt. Please only respond to Reinhard Scholl, Bill Lenharth (both in cc list) and me and not the Working Group mail lists if you have input per the questions below. Please find below the invitation to an IPv6 Bake-off on ETSI premises. regards and thanks, /jim == Invitation == GOAL: test IPv6 and IPv6-related protocols, with feedback to the IETF, the IPv6 Forum, and 3GPP (3rd generation mobile). DATE: 2-6 October 2000 LOCATION: ETSI in Sophia Antipolis, France, located between Nice and Cannes in the French Silicon Valley. PARTICIPATION: Only engineers with implementations to test are invited to participate. This is neither a marketing event nor a conference. REGISTRATION: A web site for registration is under construction and will be online shortly. PROTOCOLS TO BE TESTED: - - IPv6 core protocols (base, neighbor discovery, stateless address configuration, path MTU discovery, basic transition mechanisms) - - Mobile IPv6 - - BGP4+ - - RIPng We'd also like to get your feedback if other protocols are ready to be tested (checkboxes on the website). Depending on the number of those implementations we will decide whether to include them as well in the event: - - IPv6 extended protocols (RSVP for v6, DHCPv6, translation mechanisms with v6, dual stack transition mechanisms) - - IPSec v6 - - PPPv6 - - diffserv v6 - - OSPF v6 - - IPv6 MIBs - - DIAMETER SERVICES OFFERED: * Conformance Testing: - - The University of New Hampshire has an extensive set of conformance test suites for IPv6 and mobile IPv6 (www.iol.unh.edu/testsuites/iprouting/index.html). Staff of UNH will be on site and run your implementations through their test suites. - - Ericsson has conformance test suites for IPv6 and mobile IPv6, written in TTCN, a formal testing language. Participants have a chance to have their implementations checked against those test suites as well and learn about TTCN. * "One-on-one" Interoperability Testing: Participants test against each other under controlled network conditions. PARTICIPATION FEE: There will be a participation fee of 800 Euros/company and 500 Euros/participant. Universities can participate for free. We are actively looking for sponsors. mailto:Reinhard.Scholl@etsi.fr ETSI Bake-off Service From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 28 10:18:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23836 for ; Wed, 28 Jun 2000 10:18:54 -0400 (EDT) Received: from standards (47.234.32.16:4642) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB791A1@standards.nortelnetworks.com>; Wed, 28 Jun 2000 10:08:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3252 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 28 Jun 2000 10:08:50 -0400 Received: from tuminfo2.informatik.tu-muenchen.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79182@standards.nortelnetworks.com>; Wed, 28 Jun 2000 9:58:49 -0400 Received: from atspies29.informatik.tu-muenchen.de ([131.159.8.249] EHLO informatik.tu-muenchen.de ident: NO-IDENT-SERVICE [port 2304]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <111846-235>; Wed, 28 Jun 2000 16:08:14 +0000 X-Mailer: Mozilla 4.6 [de] (WinNT; I) X-Accept-Language: de MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <395A0645.92D77115@informatik.tu-muenchen.de> Date: Wed, 28 Jun 2000 16:08:13 +0000 Reply-To: Wolfgang Liebl Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Wolfgang Liebl Organization: Technische =?iso-8859-1?Q?Universit=E4t=20M=FCnchen?= Subject: Re: [MOBILE-IP] Fast Handovers/offs To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Matthias, > What is the current state of the art regarding "event notification (e.g. > handoff), QoS info > etc. from L2 to L3"? In context of my Ph. D. thesis I'm currently developping an architecture dealing with that. > Can one get information about cell size and one's own location within a > cell to calculate the expected cell visiting time before handover to > another cell and herewith possibly to handoff to another subnetwork? At IPCN 2000 I presented a geographic information framework which allows for querying those two kinds of data. Furthermore there's the possibility to extend the location service to arbitrary (even dynamic) network-related information. > This questions are becoming even more interesting considering the variety > of possible wireless technologies. totally agreed :-) Kind regards, Wolfgang From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Wed Jun 28 12:07:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26689 for ; Wed, 28 Jun 2000 12:07:06 -0400 (EDT) Received: from standards (47.234.32.16:3657) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79232@standards.nortelnetworks.com>; Wed, 28 Jun 2000 11:56:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3484 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Wed, 28 Jun 2000 11:56:46 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79231@standards.nortelnetworks.com>; Wed, 28 Jun 2000 11:56:45 -0400 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29634; Wed, 28 Jun 2000 10:06:11 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA20533; Wed, 28 Jun 2000 09:06:09 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA04068; Wed, 28 Jun 2000 09:06:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Wed, 28 Jun 2000 09:05:33 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Comments on draft-haverinen-mobileip-gsmsim-00.tx t X-To: henry.haverinen@NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <6D1A8E7871B9D211B3B00008C7490AA501697E48@treis03nok> > Hello Pat, > > Thank you for your comments! My pleasure. I found this I-D most intriguing... I have additional comments below. PatC > > I think that IMSI conforms to RFC2486 as the user part of a NAI. This needs to be clarified in the draft. > > > What is needed is an Internet Draft that defines the components of > > the IMSI, and how > > an AAA server determines where the Home AAA server is. > > The IMSI is composed of a three digit Mobile Contry Code (MCC), > a two digit Mobile Network Code (MNC) and a not more than 10 digit > Mobile Subscriber Identification Number (MSIN). MCC and MNC uniquely > identify the GSM operator. > I guess we could reserve well known AAA domains for GSM operators, > for example domains operator.gsm.org. Then an IMSI could be mapped > > to a NAI like this: MSIN@operator.gsm.org. > > Or perhaps GSM operators could establish a broker AAA server (for > example gsm.org) which would know where to route the AAA requests. > In this case we could use NAIs like IMSI@gsm.org. > > Once such a convention is established, an (informational?) Internet-Draft > would be useful. I do believe that an Internet-Draft needs to be written that describes the format above, and informational would be fine. The only issue I have is that the above implies that both the phone AND the laptop (in the case where the browser is on the laptop) need to be configured. One with IMS and the other with the NAI. I am not sure if most phones can have their IMSI's retrieved via a standard fashion, otherwise Mobile IP will have to run on the phone (and then they don't have access to the other information on the laptop). Something that needs careful attention, IMHO. > > > Unfortunately, the > > current Challenge/Response Internet Draft, which has been > > through WG and IESG > > last call, does not allow the MN-AAA to be present in the > > Registration Reply. > > Our draft uses MN-HA Key Replies, so is that an issue? > BTW, we're also using MN-HA Key Requests, which are not > specified in the current version of the generalized key > distribution extensions draft. > > The GSM case shows that session keys are not always > transported to the MN but they can be derived by the MN, > based on some seed values. I suppose there could be other > similar authentication methods which could require two round > trips as well. My point was that ALL registration requests will have to include either the MN-HA (and perhaps MN-FA), or the MN-AAA authentication extension. I believe that your model works very well with the MN-AAA. The Mobile can use the key it shares with the AAA server (perhaps even the one it uses to decrypt the key), to generate the MN-AAA authentication extension. All that would need to be done would be to provide the Registration Request to the SIM, and have it generate the response, which is then included in the RegReq. Of course, the above implies that I actually understand how the SIM works, which I don't :( > > > However, thinking about your proposal, it would require that > > the first round > > trip response be sent by the AAA server given that: > > 1. The user hasn't been authenticated, and > > 2. There may not be a Home Agent assigned > > The home agent could handle item 1 with a bogus Authentication > extension. Item 2 is more difficult. I don't like bogus authentication extension... see my statement above on the use of the MN-AAA. > guess dynamic home > agent assignment can only be used when the mobile node is using foreign > agent care-of addresses. Unless the mobile was able to communicate with the AAA infrastructure, but that implies that the mobile supports AAA, and that it has a routable address... > In this case the HAAA server would sent the > first response. But then we couldn't use MN-HA key requests/replies? This is not for authentication, though. > > > 7. Section 3.1 states: > > "The default hash function is MD5 [6] and the default MAC > > function is > > HMAC-MD5 [7]" > > Is the above stating that both MD5 (in the traditional sense) > > and HMAC MD5 are > > simultaneously used? Is this for compatibility with the > > existing SIM card? > > It's not for compatibility, it's just that the key is generated > with a one-way hash function h(), which is not a message authentication > code, and there are actual message authentication codes used as well. > MD5 is used as the one-way hash function for generating the key. MD5 is not a key generation algorithm, unless you have a REALLY good random generator function, and the output it put through MD5, but I don't see the benefits. Did you, perhaps, mean to state that MD5 is used to "mask" the key? > Message authentication codes are generated with HMAC_MD5, although > I could have specified MD5 in prefix+suffix mode (which is a MAC function) > to be used as well. Do you think this is a problem? HMAC-MD5 is the correct way to do it. prefix+suffix has problems, and will have to change when the IESG reviews the document (assuming it moves ahead, of course). > > > 9. Section 3.3 states: > > "In this case, the > > mobile node may retry the key exchange immediately. If, > > however, the > > Registration Reply doesn't contain a valid authentication > > extension, > > the mobile node must consider this message informational. > > The mobile > > node must not change its state or react to it in any way except > > write an entry to a log or show an error message to the user." > > Is this true? If an unauthenticated reply is received, then it isn't > > informational at all, but a likely malicious reply. Since one cannot > > distinguish one from the other, I would simply state that > > receiving such a > > message should be logged or ignored. > > I guess "informational" is not a good term. > The words "doesn't contain a valid authentication extension" > are intended to cover the bogus authentication extensions which the > home agent might need to use if there is no previous MN-HA session key. > If the error is for example "user does not have the service subscribed", > it would be good if we could show this to the user. > > Maybe unsuccessful SIM Key Replies could also be accompanied with a > RANDs and MAC_RAND, just to authenticate the reply message? In this > case it would be safe to show the message to the user. How about all registrations (perhaps except the last reply) include the MN-AAA. This solves all of your problems, and you can REALLY ignore any un-authenticated message (which is what you should do!). > > > Of course, this is much more problematic than the above, > > since the Foreign > > Agent would have to know that the Mobile doesn't have an SA, and the > > Mobile-Foreign contains cannot be authenticated. In the > > Challenge/Response > > draft, this is solved by not requiring that the MN-FA be > > present if the MN-AAA > > is present. How would you propose to solve this issue in this draft? > > MN-FA is not required to be present in the Reg.Request if MN-FA SIM Key > Request > is present, and MN-FA is not required to be present in the Reg.Reply if > MN-FA SIM Key Reply is present? If the foreign agent > requires Mobile-Foreign Authentication, this reply would > have the code 67, "Mobile node failed authentication". What I am missing here is the lack of authentication extensions. The SIM Key Request is not an authentication extension, correct? Since the Mobile already has a secret with the key generating entity, simply re-use that to secure the initial messages... > > > 13. Section 3.5 states: > > "The security association created with the session key exchange > > mechanism described above must have a Security Parameter Index > > (SPI). We use the well-known SPI SIM_SECURITY_CONTEXT_SPI (Section > > 5.1) for SIM-generated security association. Since the Mobile IP > > entities identify security associations with the pair (peer's IP > > address, SPI), it is possible to use the same SPI between all the > > entities." > > Would it be possible to have a different rule? The initial > > message cotains the > > specified SPI above, and the key generating entity forms an > > SPI with the key. > > All authentications using the generated key would use the SPI that was > > provided with the key. This way, when a new key is generated, > > a new SPI is > > used. This makes it MUCH easier to identify the key to use in order to > > authenticate. > > Sure we can use a different rule. This SPI business has just always > puzzled me... > > In the generalized key distribution extensions, only > the key request contains an SPI (Mobile Node SPI). The foreign agent > and the home agent do not pick an SPI. > Once the key has been distributed, is the Mobile Node SPI > in used both ways, for both Registration Requests and Replies? Well, if a key is bi-directional, you could have the mobile "suggest" the SPI to use when communicating with it, and the same for the Home Agent. Or, you could take a chance and have the key generating entity propose the SPI to both entities. Of course, there is a 1 in 2^32 chance that the SPI is already in use (assuming no more than 2 pending SPIs between the nodes). I think this is a fairly safe assumption. So, if we can (again) discuss the MN-AAA auth ext, then the Mobile Node would use its secret, and the SPI associated with the long lived secret, to authenticate the initial messages. When the key is distributed in the reply, then Home Agent would authenticate it using the newly generate session key (and its associated SPI). > > > 14. Section 3.6 states: > > "The SIM Key Request extension is a non-skippable extension, so if > > the foreign agent doesn't support it, it silently discards the > > Registration Request." > > Personally, I think that RFC 2002 bis MUST fix this problem. > > It would make sense. I don't think this fix would make it very much > easier to bring the mobility agent to its knees with a denial > of service attack. However, in this case an unauthenticated Reg.Reply > with an error code wouldn't help much, as the mobile node would silently > discard it. I wasn't discussing un-authenticated messages, but rather messages with an unrecognized un-skippable extension. Silent discard is a problem in this case. > > > 15. Section 2.6 states: > > "Later, we can specify support for parallel processing --- > > Is this an editor's note? > > Yes it is. I wasn't sure if such parallel processing would be feasible. > This needs further thought. I agree. > > > Is there a particular reason why the code in the Registration > > Reply cannot be > > re-used? It would make it MUCH simpler to parse and find an error. > > There could be MN-FA and MN-HA SIM key exchanges going on in parallel. > If a Registration Reply contains both a MN-FA SIM Key Reply and > a MN-HA SIM Key Reply, we can have two failure codes, so both > the foreign agent and the home agent cannot set the code in Registration > Reply. > > Another (not so important) reason is that the registration may be successful > even if the SIM key exchange fails. This can happen when we already have > a previous key to authenticate the registration messages that contain SIM > key > exhange extensions. On the other hand, if the key exchange fails, it doesn't > > help much to know that the registration was successful. > > If we don't support parallel MN-FA and MN-HA key exchanges, then > I guess we could use the code in the Reg.Reply. Simplicity is nice, but keep in mind that EVEN with RFC 2002, it is possible for the Home Agent to have a problem with the request, and the Foreign Agent to have a problem with the reply. In this case, both nodes would insert their error code into the reply. Since there is a precendence, I would prefer that this method be re-used. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 29 05:50:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24822 for ; Thu, 29 Jun 2000 05:50:08 -0400 (EDT) Received: from standards (47.234.32.16:3540) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79570@standards.nortelnetworks.com>; Thu, 29 Jun 2000 5:39:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4586 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 29 Jun 2000 05:39:46 -0400 Received: from qhars002.nortel.com (47.101.112.102:42951) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7956F@standards.nortelnetworks.com>; Thu, 29 Jun 2000 5:29:41 -0400 Received: from qnsgs000.nortel.com (actually znsgs016) by qhars002.nortel.com; Thu, 29 Jun 2000 10:38:52 +0100 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qnsgs000.nortel.com; Thu, 29 Jun 2000 10:38:51 +0100 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Jun 2000 10:38:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE1AD.D1786B68" Message-ID: <61ABD11436FED21192440000F81F3E364FF52B@nwcwi1a.europe.nortel.com> Date: Thu, 29 Jun 2000 10:38:31 +0100 Reply-To: Iain Sharp Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Iain Sharp Subject: [MOBILE-IP] FW: [MOBILE-IP] IPv6 Bake-Off and Testing at ETSI X-To: Alan Stoddard X-cc: John Phillips , Russ Coffin , Glenn Morrow , Mel Woinsky 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_01BFE1AD.D1786B68 Content-Type: text/plain; charset="iso-8859-1" Folks, There is a lot of politics around this event - and we are not convinced that it is a valuable technical exercise as claimed in this e-mail. Therefore we need to coordinate a Nortel response internally before we do anything externally. Therefore please: 1) DO NOT reply to this e-mail from ETSI 2) If you feel you would be able to particpate please e-mail myself and Alan Stoddard with a summary of what you feel you could offer. Thanks, Iain Sharp Product Planning -----Original Message----- From: Morrow, Glenn [RICH2:C301:EXCH] Sent: 28 June 2000 15:57 To: ipv6-strategy@zrtph02h.us.nortel.com Subject: FW: [MOBILE-IP] IPv6 Bake-Off and Testing at ETSI FYI -----Original Message----- From: Jim Bound [SMTP:bound@ZK3.DEC.COM] Sent: Wednesday, June 28, 2000 8:48 AM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: [MOBILE-IP] IPv6 Bake-Off and Testing at ETSI Dear IPv6-ers, Sorry for the Interrupt. Please only respond to Reinhard Scholl, Bill Lenharth (both in cc list) and me and not the Working Group mail lists if you have input per the questions below. Please find below the invitation to an IPv6 Bake-off on ETSI premises. regards and thanks, /jim == Invitation == GOAL: test IPv6 and IPv6-related protocols, with feedback to the IETF, the IPv6 Forum, and 3GPP (3rd generation mobile). DATE: 2-6 October 2000 LOCATION: ETSI in Sophia Antipolis, France, located between Nice and Cannes in the French Silicon Valley. PARTICIPATION: Only engineers with implementations to test are invited to participate. This is neither a marketing event nor a conference. REGISTRATION: A web site for registration is under construction and will be online shortly. PROTOCOLS TO BE TESTED: - - IPv6 core protocols (base, neighbor discovery, stateless address configuration, path MTU discovery, basic transition mechanisms) - - Mobile IPv6 - - BGP4+ - - RIPng We'd also like to get your feedback if other protocols are ready to be tested (checkboxes on the website). Depending on the number of those implementations we will decide whether to include them as well in the event: - - IPv6 extended protocols (RSVP for v6, DHCPv6, translation mechanisms with v6, dual stack transition mechanisms) - - IPSec v6 - - PPPv6 - - diffserv v6 - - OSPF v6 - - IPv6 MIBs - - DIAMETER SERVICES OFFERED: * Conformance Testing: - - The University of New Hampshire has an extensive set of conformance test suites for IPv6 and mobile IPv6 (www.iol.unh.edu/testsuites/iprouting/index.html). Staff of UNH will be on site and run your implementations through their test suites. - - Ericsson has conformance test suites for IPv6 and mobile IPv6, written in TTCN, a formal testing language. Participants have a chance to have their implementations checked against those test suites as well and learn about TTCN. * "One-on-one" Interoperability Testing: Participants test against each other under controlled network conditions. PARTICIPATION FEE: There will be a participation fee of 800 Euros/company and 500 Euros/participant. Universities can participate for free. We are actively looking for sponsors. mailto:Reinhard.Scholl@etsi.fr ETSI Bake-off Service ------_=_NextPart_001_01BFE1AD.D1786B68 Content-Type: text/html; charset="iso-8859-1" FW: [MOBILE-IP] IPv6 Bake-Off and Testing at ETSI
Folks,
 
There is a lot of politics around this event - and we are not convinced that it is a valuable technical exercise as claimed in this e-mail. Therefore we need to coordinate a Nortel response internally before we do anything externally.
 
Therefore please:
1) DO NOT reply to this e-mail from ETSI
2) If you feel you would be able to particpate please e-mail myself and Alan Stoddard with a summary of what you feel you could offer.
 
 
Thanks,
 
Iain Sharp
Product Planning
 
 
 
-----Original Message-----
From: Morrow, Glenn [RICH2:C301:EXCH]
Sent: 28 June 2000 15:57
To: ipv6-strategy@zrtph02h.us.nortel.com
Subject: FW: [MOBILE-IP] IPv6 Bake-Off and Testing at ETSI

FYI

-----Original Message-----
From:   Jim Bound [SMTP:bound@ZK3.DEC.COM]
Sent:   Wednesday, June 28, 2000 8:48 AM
To:     MOBILE-IP@STANDARDS.NORTELNETWORKS.COM
Subject:        [MOBILE-IP] IPv6 Bake-Off and Testing at ETSI

Dear IPv6-ers,

Sorry for the Interrupt.  Please only respond to Reinhard Scholl, Bill
Lenharth (both in cc list) and me and not the Working Group mail lists
if you have input per the questions below.

Please find below the invitation to an IPv6 Bake-off on ETSI premises.

regards and thanks,
/jim
                == Invitation ==

GOAL: test IPv6 and IPv6-related protocols, with feedback
to the IETF, the IPv6 Forum, and 3GPP (3rd generation
mobile).

DATE: 2-6 October 2000

LOCATION: ETSI in Sophia Antipolis, France, located
between Nice and Cannes in the French Silicon Valley.

PARTICIPATION: Only engineers with implementations to test
are invited to participate. This is neither a marketing
event nor a conference.

REGISTRATION: A web site for registration is under
construction and will be online shortly.

PROTOCOLS TO BE TESTED:
- - IPv6 core protocols (base, neighbor discovery, stateless
  address configuration, path MTU discovery, basic transition
  mechanisms)
- - Mobile IPv6
- - BGP4+
- - RIPng

We'd also like to get your feedback if other protocols are
ready to be tested (checkboxes on the website). Depending
on the number of those implementations we will decide
whether to include them as well in the event:
- - IPv6 extended protocols (RSVP for v6, DHCPv6, translation
  mechanisms with v6, dual stack transition mechanisms)
- - IPSec v6
- - PPPv6
- - diffserv v6
- - OSPF v6
- - IPv6 MIBs
- - DIAMETER

SERVICES OFFERED:
* Conformance Testing:
- - The University of New Hampshire has an extensive set of
conformance test suites for IPv6 and mobile IPv6
(www.iol.unh.edu/testsuites/iprouting/index.html).
Staff of UNH will be on site and run your implementations
through their test suites.
- - Ericsson has conformance test suites for IPv6 and
mobile IPv6, written in TTCN, a formal testing language.
Participants have a chance to have their implementations
checked against those test suites as well and learn about
TTCN.

* "One-on-one" Interoperability Testing: Participants
test against each other under controlled network conditions.

PARTICIPATION FEE: There will be a participation fee of
800 Euros/company and 500 Euros/participant. Universities
can participate for free. We are actively looking for
sponsors.

        mailto:Reinhard.Scholl@etsi.fr
        ETSI Bake-off Service

------_=_NextPart_001_01BFE1AD.D1786B68-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 29 06:57:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25539 for ; Thu, 29 Jun 2000 06:57:05 -0400 (EDT) Received: from standards (47.234.32.16:1914) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB795D7@standards.nortelnetworks.com>; Thu, 29 Jun 2000 6:46:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4705 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 29 Jun 2000 06:46:50 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB795CE@standards.nortelnetworks.com>; Thu, 29 Jun 2000 6:36:50 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25171; Thu, 29 Jun 2000 06:46:22 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200006291046.GAA25171@ietf.org> Date: Thu, 29 Jun 2000 06:46:12 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-3gwireless-ext-04.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobile IP Based Micro Mobility Management Protocol in The Third Generation Wireless Network Author(s) : Y. Xu et al. Filename : draft-ietf-mobileip-3gwireless-ext-04.txt Pages : 16 Date : 28-Jun-00 This document defines extensions to the Mobile IP protocol [1] to allow mobility management for the interface between a radio network and a packet data network in the third generation cdma2000 network. Mobile IP requires link layer connectivity between the Mobile Node and the Foreign Agent. This draft proposes a protocol for achieving this when the physical layer terminating at a point distant from the FA. In particular, this protocol applies to cdma2000 networks where the physical layer terminates at a Radio Network Node (RNN) and the FA resides inside a separate Packet Data Serving Node (PDSN). The PDSN is responsible for establishing, maintaining, and terminating the link layer to the Mobile Node. A RNN is responsible for relaying the link layer protocol between a Mobile Node and its corresponding PDSN. The interface between the RNN and the PDSN is called the RP interface. This interface requires mobility management for handling handoff from one RNN to another without interrupting end to end communication. It also requires the support of the link layer protocol encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-3gwireless-ext-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-3gwireless-ext-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-3gwireless-ext-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000628101031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-3gwireless-ext-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-3gwireless-ext-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000628101031.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 29 07:01:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25696 for ; Thu, 29 Jun 2000 07:01:15 -0400 (EDT) Received: from standards (47.234.32.16:1914) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB795E7@standards.nortelnetworks.com>; Thu, 29 Jun 2000 6:47:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4706 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 29 Jun 2000 06:47:40 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB795CF@standards.nortelnetworks.com>; Thu, 29 Jun 2000 6:37:39 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25286; Thu, 29 Jun 2000 06:47:11 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200006291047.GAA25286@ietf.org> Date: Thu, 29 Jun 2000 06:47:11 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: [MOBILE-IP] I-D ACTION:draft-soliman-mobileip-hmipv6-00.txt To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Hierarchical Mobile IPv6 and Fast Handoffs Author(s) : K. Malki, H. Soliman Filename : draft-soliman-mobileip-hmipv6-00.txt Pages : 17 Date : 28-Jun-00 This draft introduces some extensions for MIPv6 and neighbour discovery to allow for the introduction of a hierarchical MIPv6 mobility management model. The proposed hierarchical mobility management for MIPv6 will improve the performance of MIPv6 in terms of handoff speed and is well-suited to implement access control and handoffs between different access technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-soliman-mobileip-hmipv6-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-soliman-mobileip-hmipv6-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-soliman-mobileip-hmipv6-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000628120525.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-soliman-mobileip-hmipv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-soliman-mobileip-hmipv6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000628120525.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 29 07:08:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25781 for ; Thu, 29 Jun 2000 07:08:23 -0400 (EDT) Received: from standards (47.234.32.16:1914) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79653@standards.nortelnetworks.com>; Thu, 29 Jun 2000 6:58:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4739 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 29 Jun 2000 06:58:05 -0400 Received: from qhars002.nortel.com (47.101.112.102:53206) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB795E9@standards.nortelnetworks.com>; Thu, 29 Jun 2000 6:48:05 -0400 Received: from qnsgs000.nortel.com (actually znsgs016) by qhars002.nortel.com; Thu, 29 Jun 2000 11:56:22 +0100 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qnsgs000.nortel.com; Thu, 29 Jun 2000 11:56:21 +0100 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Jun 2000 11:56:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE1B8.A54A9024" Message-ID: <61ABD11436FED21192440000F81F3E364FF532@nwcwi1a.europe.nortel.com> Date: Thu, 29 Jun 2000 11:56:14 +0100 Reply-To: Iain Sharp Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Iain Sharp Subject: [MOBILE-IP] FW: [MOBILE-IP] IPv6 Bake-Off and Testing at ETSI X-To: Alan Stoddard X-cc: John Phillips , Russ Coffin , Glenn Morrow , Mel Woinsky 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_01BFE1B8.A54A9024 Content-Type: text/plain; charset="iso-8859-1" Sorry apologies for my earlier message. A slip at the keyboard ------_=_NextPart_001_01BFE1B8.A54A9024 Content-Type: text/html; charset="iso-8859-1" FW: [MOBILE-IP] IPv6 Bake-Off and Testing at ETSI
Sorry apologies for my earlier message. A slip at the keyboard
 
------_=_NextPart_001_01BFE1B8.A54A9024-- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 29 10:13:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08469 for ; Thu, 29 Jun 2000 10:13:37 -0400 (EDT) Received: from standards (47.234.32.16:2563) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB7976D@standards.nortelnetworks.com>; Thu, 29 Jun 2000 10:03:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5213 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 29 Jun 2000 10:03:24 -0400 Received: from hosaka.smallworks.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79760@standards.nortelnetworks.com>; Thu, 29 Jun 2000 9:53:23 -0400 Received: from beta.vinet.com.mx ([200.34.41.11]) by hosaka.smallworks.com (8.9.1/8.9.1) with ESMTP id JAA15170 for ; Thu, 29 Jun 2000 09:02:51 -0500 (CDT) Received: from MICHELLE (bay1-103.orlando.ziplink.net [209.206.56.103]) by beta.vinet.com.mx (Build 98 8.9.3/NT-8.9.3) with SMTP id IAA02675; Thu, 29 Jun 2000 08:58:54 -0500 Message-ID: <200006291358.IAA02675@beta.vinet.com.mx> Date: Thu, 29 Jun 2000 08:58:54 -0500 Reply-To: Michelle_Williams1@2BMAIL.CO.UK Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Michelle_Williams1@2BMAIL.CO.UK Subject: [MOBILE-IP] How you can make $100 - $1,500 cash per job To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM From: Michelle Williams - publisher of the "Work From Home Opportunities" Newsletter Wednesday, 10:30 p.m. Hello, If you're interested in earning $100 - $1,500 CASH per job, then I want to share something with you... I wrote this just before leaving for the night. I hope you weren't glued to your computer working like me... I hope you were at home with your family and having a nice relaxing evening. As for me... I had to put in some late hours to wrap up a few loose ends before I went for a drive. Imagine coming home from a hard day's work (exhausted..), You immediately go straight to bed. You get undressed, lay down, turn off the lights, and snuggle up face-down on the pillow. A few moments later, you feel uncomfortable and stressed out so you lie on your back. When you look up at the ceiling, it's as if the ceiling has been removed! You see exactly what you would see if outside stargazing! A stunning, accurate 3-dimensional re-creation of the starry night sky, including constellations such as the Big Dipper, Pegasus and the Milky Way galaxy, ...and even shooting stars! You can't see it during the day. The ceiling looks normal. But at night, when the lights are off, you see what looks like the sky outside! It's so relaxing and romantic. And educational! And talk about stress-relief! The moment you look at it, it'll melt your tension away faster than a great massage! Now how many people do you think would LOVE seeing this when they look up in their beds at night? "It's like you're sleeping under the stars!" Ok, I know you want to know How You Make Money. Here's how. You can put that awesome "convertible ceiling" in ANYONE'S bedroom with a product cost to you of.. Guess how much.. Only ONE to TWO Dollars! And you offer this masterpiece for $100 - $1,500! Talk about *nice* profits! And it only takes you an hour or two! Here's an important point: These profits are similar to the profits of selling Information: the material costs next to nothing, but the customer really VALUES the END RESULT. So you can charge more (a LOT more). "Who'd want this?" Anyone with a bedroom ceiling (or any ceiling), as well as homes, hotels, etc. Who do you know that has a bedroom ceiling? Whew! The official money-making opportunity of the Millenium! (Well... I think it should be!) |;-) Anyway, I know you want more information to make a decision, so ... To receive more FREE information on How You Can Make $100 - $1,500 CASH per job, Simply Click On The Email Link Below and Send Back The Following: Mailto:starbiz127@newmail.net Name: E-Mail: Phone: Street: City: State: ZIP or Postal Code: Country (available INTERNATIONALLY): Mailto:starbiz127@newmail.net And you'll be sent the full details on how you can make $100 - $1,500 CASH per job, as well as pictures of these murals so you can see for yourself how breathtaking they are! Best regards, Michelle Williams P.S. We'll also send you a free Opportunity E-zine with more interesting Money-Making Opportunities like this one, and important info. for the home-based entrepreneur! P.P.S. Also, even though 99% of people don't know about this opportunity, that won't be the case forever, so hurry up and reply to make sure you get to lock down YOUR city! To unsubscribe mailto:unsubscribe628@newmail.net From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 29 15:02:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17912 for ; Thu, 29 Jun 2000 15:02:36 -0400 (EDT) Received: from standards (47.234.32.16:3248) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB798DD@standards.nortelnetworks.com>; Thu, 29 Jun 2000 14:52:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0230 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 29 Jun 2000 14:52:27 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB798DC@standards.nortelnetworks.com>; Thu, 29 Jun 2000 14:52:27 -0400 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05590 for ; Thu, 29 Jun 2000 13:01:57 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA28214 for ; Thu, 29 Jun 2000 12:01:56 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA21898 for ; Thu, 29 Jun 2000 12:01:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 29 Jun 2000 12:01:16 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: [MOBILE-IP] RFC 2002 (+bis) and the 'V' bit To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM All, I am wondering if there are any Mobile IP implementations that support the 'V' bit (Van Jacobson), and if so, whether they have ever had interoperability with other implementations. In the process of looking to 'V' bit, I noticed that one important parameter that must be negotiated to setup VJ is never discussed in RFC 2002, which led to my question. RFC 1144 states: " There are two configuration parameters associated with header compression: Whether or not compressed packets should be sent on a particular line and, if so, how many state slots (saved packet headers) to reserve. There is also one link-level configuration parameter, the maximum packet size or MTU, and one front-end configuration parameter, data compression, that interact with header compression. Compression configuration is discussed in this section. MTU and data compression are discussed in the next two sections." Obviously, RFC 2002 does negotiate the first, but not the second parameter. So either every implementation picked the same random number, or no interoperability has ever been achieved. If the latter is true, I would like to know whether it makes sense to remove VJ compression from the standard. In most cases, VJ is run over PPP, so I believe that most VJ compliant hosts actually negotiate it during PPP setup, and not Mobile IP. PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 29 15:40:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18641 for ; Thu, 29 Jun 2000 15:40:21 -0400 (EDT) Received: from standards (47.234.32.16:3933) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79930@standards.nortelnetworks.com>; Thu, 29 Jun 2000 15:29:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0300 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 29 Jun 2000 15:29:14 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79913@standards.nortelnetworks.com>; Thu, 29 Jun 2000 15:19:14 -0400 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA24450 for ; Thu, 29 Jun 2000 13:28:46 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA03948 for ; Thu, 29 Jun 2000 12:28:45 -0700 (PDT) Received: from sun.com (d-mpk15-122-15 [129.146.122.15]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id MAA22091 for ; Thu, 29 Jun 2000 12:28:42 -0700 (PDT) X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <395BA3EA.5E31B749@sun.com> Date: Thu, 29 Jun 2000 12:30:50 -0700 Reply-To: gab Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: gab Subject: Re: [MOBILE-IP] RFC 2002 (+bis) and the 'V' bit To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "pcalhoun@eng.sun.com" wrote: > If the latter is true, I would like to know whether it makes sense to remove > VJ compression from the standard. In most cases, VJ is run over PPP, so I > believe that most VJ compliant hosts actually negotiate it during PPP setup, > and not Mobile IP. i second that. besides, rfc2507 is preferrable to VJ, right? this wouldn't be supported or negotiable via the V bit. rather, one negotiates compression via NCP according to rfc's 2509,1332 and 2023. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 29 17:34:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20555 for ; Thu, 29 Jun 2000 17:34:55 -0400 (EDT) Received: from standards (47.234.32.16:3155) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB799E0@standards.nortelnetworks.com>; Thu, 29 Jun 2000 17:24:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0564 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 29 Jun 2000 17:24:56 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB799DD@standards.nortelnetworks.com>; Thu, 29 Jun 2000 17:14:56 -0400 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19417 for ; Thu, 29 Jun 2000 15:24:29 -0600 (MDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA13402; Thu, 29 Jun 2000 17:24:28 -0400 (EDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by atlantic.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id RAA18052; Thu, 29 Jun 2000 17:25:10 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 29 Jun 2000 17:24:24 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] RFC 2002 (+bis) and the 'V' bit X-To: gab To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <395BA3EA.5E31B749@sun.com> > "pcalhoun@eng.sun.com" wrote: > > > If the latter is true, I would like to know whether it makes sense to remove > > VJ compression from the standard. In most cases, VJ is run over PPP, so I > > believe that most VJ compliant hosts actually negotiate it during PPP setup, > > and not Mobile IP. > > i second that. besides, rfc2507 is preferrable to VJ, right? this wouldn't > be supported or negotiable via the V bit. > rather, one negotiates compression via NCP according to rfc's 2509,1332 > and 2023. I third this, and add that this is a link-layer specific bit that doesn't belong here. Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Thu Jun 29 18:42:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21742 for ; Thu, 29 Jun 2000 18:42:52 -0400 (EDT) Received: from standards (47.234.32.16:4355) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79A70@standards.nortelnetworks.com>; Thu, 29 Jun 2000 18:32:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0753 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Thu, 29 Jun 2000 18:32:52 -0400 Received: from mercury.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79A6F@standards.nortelnetworks.com>; Thu, 29 Jun 2000 18:22:51 -0400 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26722 for ; Thu, 29 Jun 2000 15:32:24 -0700 (PDT) Received: from atlantic.East.Sun.COM (atlantic.East.Sun.COM [129.148.174.27]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA22513; Thu, 29 Jun 2000 18:32:23 -0400 (EDT) Received: from onion.east.sun.com (onion [129.148.174.110]) by atlantic.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id SAA18302; Thu, 29 Jun 2000 18:33:05 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Thu, 29 Jun 2000 18:32:19 -0400 Reply-To: Steven Glass - Solaris Software Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Steven Glass - Solaris Software Subject: Re: [MOBILE-IP] RFC 2002 (+bis) and the 'V' bit X-To: Steven Glass - Solaris Software To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" > > "pcalhoun@eng.sun.com" wrote: > > > > > If the latter is true, I would like to know whether it makes sense to remove > > > VJ compression from the standard. In most cases, VJ is run over PPP, so I > > > believe that most VJ compliant hosts actually negotiate it during PPP setup, > > > and not Mobile IP. > > > > i second that. besides, rfc2507 is preferrable to VJ, right? this wouldn't > > be supported or negotiable via the V bit. > > rather, one negotiates compression via NCP according to rfc's 2509,1332 > > and 2023. > > I third this, and add that this is a link-layer specific bit that doesn't > belong here. Sorry, didn't mean link-layer (as strictly defined), meant a link-specific bit, that is it's dependent on the link topology between the MN and FA. As Vipul points out, there are other ways to negotiate (IPhdr, VJ, etc) compression, of which a single bit in the mip registrtion isn't going to be complete enough, assuming such a thing belongs there. Cheers, Steve Cheers, Steve From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 30 05:51:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11993 for ; Fri, 30 Jun 2000 05:51:47 -0400 (EDT) Received: from standards (47.234.32.16:3036) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79C1F@standards.nortelnetworks.com>; Fri, 30 Jun 2000 5:41:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1331 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 30 Jun 2000 05:41:29 -0400 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79C1E@standards.nortelnetworks.com>; Fri, 30 Jun 2000 5:41:29 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nok.ntc.nokia.com [131.228.10.153]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id MAA27160 for ; Fri, 30 Jun 2000 12:51:03 +0300 (EETDST) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 30 Jun 2000 12:51:02 +0300 Received: by esebh01nok with Internet Mail Service (5.5.2650.10) id ; Fri, 30 Jun 2000 12:51:02 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <6D1A8E7871B9D211B3B00008C7490AA501697E52@treis03nok> Date: Fri, 30 Jun 2000 12:50:52 +0300 Reply-To: henry.haverinen@NOKIA.COM Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Henry Haverinen Subject: Re: [MOBILE-IP] Comments on draft-haverinen-mobileip-gsmsim-00.tx t To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hello Pat, This mail contains comments from N. Asokan (n.asokan@nokia.com), thanks Asokan! [IMSI format] > I do believe that an Internet-Draft needs to be written that > describes the > format above, and informational would be fine. The only issue > I have is that > the above implies that both the phone AND the laptop (in the > case where the > browser is on the laptop) need to be configured. One with IMS > and the other > with the NAI. I am not sure if most phones can have their > IMSI's retrieved via > a standard fashion, otherwise Mobile IP will have to run on > the phone (and > then they don't have access to the other information on the laptop). I'll craft an appendix to the GSM SIM draft about the IMSI format and the use of the IMSI as part of the NAI. An appendix should be enough, since GSM IMSI issues are specific to this contribution. In addition to getting the IMSI from the SIM card, the Mobile IP software needs to use the SIM card for getting the Kc keys that correspond to given RANDs. We could use smart card readers on the laptop. For example, the Nokia 11 Mbit/s WLAN card has a built-in smart card reader. Or we could run Mobile IP on PDA type of phones. > My point was that ALL registration requests will have to > include either the MN-HA (and perhaps MN-FA), or the MN-AAA > authentication extension. I believe that your model works > very well with the MN-AAA. The Mobile can use the key it > shares with the AAA server (perhaps even the one it uses to > decrypt the key), to generate the MN-AAA authentication extension. > All that would need to be done would be to provide the Registration > Request to the SIM, and have it generate the response, which is then > included in the RegReq. The "AAA server" in this case is deep within the GSM cloud. Therefore, the "MN-AAA key" (which is the GSM SIM key Ki) cannot be used in arbitrary ways. The mobile node must get the RAND values from the AAA server before it is able to generate a usable key. In other words, the mobile node doesn't have any key available until the first round trip has been completed. Thus, the first round trip will have to use some sort of bogus authentication extensions or bogus AAA extensions. Using dummy MN-AAA authentication extension instead of dummy MN-FA or MN-HA authentication extensions does seem to have the advantage that it avoids the need for mobility agents (FA or HA) to know about the GSM Key Request sub types: when they see an MN-AAA authentication extension, they'll promptly forward the key request and the authext to the AAA server. This needs further study. > > > 7. Section 3.1 states: > > > "The default hash function is MD5 [6] and the default MAC > > > function is > > > HMAC-MD5 [7]" > > > Is the above stating that both MD5 (in the traditional sense) > > > and HMAC MD5 are > > > simultaneously used? Is this for compatibility with the > > > existing SIM card? > > > > It's not for compatibility, it's just that the key is generated > > with a one-way hash function h(), which is not a message > authentication > > code, and there are actual message authentication codes > used as well. > > MD5 is used as the one-way hash function for generating the key. > > MD5 is not a key generation algorithm, unless you have a > REALLY good random > generator function, and the output it put through MD5, but I > don't see the > benefits. Did you, perhaps, mean to state that MD5 is used to > "mask" the key? Yes, MD5 is not a key generation algorithm, and it wasn't our intent. We use the hash function as a mixing function to combine several session keys (Kc's) generated by the GSM authentication procedure into a single key to be used in Mobile IP. The reason for this is twofold: - the current GSM session keys are at most 64 bits; so two or more of them are needed to generate a 128 bit key - by using a one-way hash function to combine the keys, we are assured that the even if an attacker manages to learn the key used in Mobile IP, it doesn't help him in learning the original GSM Kc's. This seems to be a reasonable precaution given that we are using GSM SIM authentication procedure in ways not intended by the original designers. > How about all registrations (perhaps except the last reply) > include the MN-AAA. This solves all of your problems, and you > can REALLY ignore any un-authenticated message (which is what you > should do!). [...] > What I am missing here is the lack of authentication > extensions. The SIM Key Request is not an authentication extension, > correct? Since the Mobile already has a secret with the key generating > entity, simply re-use that to secure the initial messages... As explained above, the equivalent of the MN-HAAA key (Ki) is known to the SIM card on the MN and the GSM AuC (authentication center), the latter does not participate in the Mobile IP authorization process (because it is deep within the GSM cloud). The gateway between the GSM and the IP world cannot know Ki. The Mobile IP software on the mobile node cannot know it either, since the SIM card does not have (and is not allowed to have) an interface for retrieving Ki. Hence, it is not possible to use MN-AAA authentication extensions in the normal way. > Well, if a key is bi-directional, you could have the mobile > "suggest" the SPI > to use when communicating with it, and the same for the Home > Agent. RFC 2002 bis reads that SPI is "an index identifying a security context between a pair of nodes among the contexts available in the Mobility Security Association". A Mobility Security Association is "a collection of security contexts, between a pair of nodes, which may be applied to Mobile IP protocol messages exchanged between them." Our keys are bi-directional. Since a Mobile IP entity is able to uniquely identify the security context with the pair (SPI, peer's IP address), I think it's enough if the mobile node suggests the SPI. It doesn't matter if the mobility agent is already using the same SPI with some other Mobile IP entity, since the security context is identified with the above mentioned pair. But we still need a well-known SPI for "bogus authentication extension". I'll rewrite the SPI assignment section in the draft. > Simplicity is nice, but keep in mind that EVEN with RFC 2002, > it is possible > for the Home Agent to have a problem with the request, and > the Foreign Agent > to have a problem with the reply. In this case, both nodes > would insert their > error code into the reply. Since there is a precendence, I > would prefer that > this method be re-used. I agree. I'll remove the reply code from the SIM Key Reply extensions and specify that the code in the Reg.Reply will be used. Best regards, Henry From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 30 06:10:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12161 for ; Fri, 30 Jun 2000 06:10:37 -0400 (EDT) Received: from standards (47.234.32.16:3036) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79C61@standards.nortelnetworks.com>; Fri, 30 Jun 2000 6:00:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1405 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 30 Jun 2000 06:00:31 -0400 Received: from zmamail03.zma.compaq.com (mailin.zma.compaq.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79C54@standards.nortelnetworks.com>; Fri, 30 Jun 2000 5:50:31 -0400 Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id D4CD142B5; Fri, 30 Jun 2000 06:00:06 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id AACBE4E85; Fri, 30 Jun 2000 06:00:06 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id GAA0000906938; Fri, 30 Jun 2000 06:00:05 -0400 (EDT) X-Mts: smtp Message-ID: <200006301000.GAA0000906938@anw.zk3.dec.com> Date: Fri, 30 Jun 2000 06:00:05 -0400 Reply-To: Jim Bound Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Jim Bound Subject: [MOBILE-IP] test is real and technical X-To: isharp@NORTELNETWORKS.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi Ian, no big deal. just want to state that part of the testing will be an extended test suite from University of New Hampshire (UNH) and if you check with your router and v6 folks this test stuff beats the snott out of all our implementations for core IPv6 stuff. So its useful stuff/test. UNH has found bugs in code I personally have wrote in the past (very rare of course that I produce bugs!!) that I would not have seen till it shipped maybe. so that is always a good thing. also UNH began doing MIPv6 testing at Sun Connectathon this year on the left coast back in march 2000 and for example caught bugs just because different implementors brought different versions of MIPv6 spec implementations. I found that impressive. ETSI will add value for other parts of testing and add other value to the test suite they may have concerns with from a 3GPP perspective, which as an implementor I find useful. Carl Williams from Sun, Bill Lenharth from UNH, and I spent a lot of time making sure this was a technical event and effort. Also UNH would not send equipment to Europe for a political event for sure or us send valuable engineers who are working on products. That being said I am sure there are politics going on but not for the testing or by the folks from here or ETSI doing all the work. Also Carl, Bill, and I made it very clear our testing model is NO TELL philosophy so even if folks go with prototype new code to test thats cool no one is going to send out press release stating XXX FAILED or stuff like that. That was part of the agreement. regards, /jim From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 30 09:55:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17626 for ; Fri, 30 Jun 2000 09:55:59 -0400 (EDT) Received: from standards (47.234.32.16:2866) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79D5E@standards.nortelnetworks.com>; Fri, 30 Jun 2000 9:45:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1741 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 30 Jun 2000 09:45:43 -0400 Received: from kryptonmail.spacenet.com (12.1.237.116:2222) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79D53@standards.nortelnetworks.com>; Fri, 30 Jun 2000 9:35:42 -0400 Received: by kryptonmail.spacenet.com with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Jun 2000 09:43:59 -0400 Received: from mimesw.gilat.com (MIMESW [10.101.0.128]) by kryptonmail.spacenet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NWNMCRVW; Fri, 30 Jun 2000 09:43:58 -0400 Received: from mail.gilat.com (unverified) by mimesw.gilat.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 30 Jun 2000 16:43:46 +0200 Received: by mail.gvtele.com with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Jun 2000 16:43:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Message-ID: Date: Fri, 30 Jun 2000 16:43:44 +0200 Reply-To: Noam Gonen - Israel Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Noam Gonen - Israel Subject: [MOBILE-IP] begginers question To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Hi, Where does one find the required stuff/documentation for a beginners lecture on IP & cellulars ? I mean the required stuff to make a bottom-up acquaintance with how these two sectors "meet" and work it from there . (not straghit into FAs, and PDSNs etc. but more structured) Appologies for the "beginner" tone of the question, yet if one shall not ask..... Noam Gonnen Gilat Satellite Networks LTD. Direct : 972-4-9939330 ---------------------------------------------------------------------------- ---------------- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 30 10:21:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18102 for ; Fri, 30 Jun 2000 10:21:28 -0400 (EDT) Received: from standards (47.234.32.16:2866) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79DAB@standards.nortelnetworks.com>; Fri, 30 Jun 2000 10:11:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1857 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 30 Jun 2000 10:11:14 -0400 Received: from lukla.Sun.COM by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79DAA@standards.nortelnetworks.com>; Fri, 30 Jun 2000 10:11:14 -0400 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA21105; Fri, 30 Jun 2000 08:20:47 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA28189; Fri, 30 Jun 2000 07:20:46 -0700 (PDT) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA06386; Fri, 30 Jun 2000 07:20:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Message-ID: Date: Fri, 30 Jun 2000 07:19:58 -0700 Reply-To: "pcalhoun@eng.sun.com" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "pcalhoun@eng.sun.com" Subject: Re: [MOBILE-IP] Comments on draft-haverinen-mobileip-gsmsim-00.tx t X-To: henry.haverinen@NOKIA.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: "Your message with ID" <6D1A8E7871B9D211B3B00008C7490AA501697E52@treis03nok> > > I'll craft an appendix to the GSM SIM draft about the IMSI > format and the use of the IMSI as part of the NAI. An appendix > should be enough, since GSM IMSI issues are specific to this > contribution. That sounds very reasonable. > > The "AAA server" in this case is deep within the GSM cloud. > Therefore, the "MN-AAA key" (which is the GSM SIM key Ki) cannot be > used in arbitrary ways. The mobile node must get the RAND values > from the AAA server before it is able to generate a usable key. > > In other words, the mobile node doesn't have any key available until > the first round trip has been completed. Thus, the first round trip > will have to use some sort of bogus authentication extensions or > bogus AAA extensions. > > Using dummy MN-AAA authentication extension instead of dummy > MN-FA or MN-HA authentication extensions does seem to have the > advantage that it avoids the need for mobility agents (FA or HA) to > know about the GSM Key Request sub types: when they see an MN-AAA > authentication extension, they'll promptly forward the key request and > the authext to the AAA server. This needs further study. OK, here is where my mis-understanding is. I was under the impression that the Mobile has a secret that it shared with some entity in its home network. Be it a AAA server, the Authentication Center, the HLR, whatever. This is the key that is used to decrypt the dynamic keys, and the one I was proposing that is used to generate the authentication extensions. Is there a particular reason why this long lived key cannot be used in the initial round trip? Or is there truly NO long lived key, and there is magic involved in the key decryption that I am unaware of :) > > > > > 7. Section 3.1 states: > > > > "The default hash function is MD5 [6] and the default MAC > > > > function is > > > > HMAC-MD5 [7]" > > > > Is the above stating that both MD5 (in the traditional sense) > > > > and HMAC MD5 are > > > > simultaneously used? Is this for compatibility with the > > > > existing SIM card? > > > > > > It's not for compatibility, it's just that the key is generated > > > with a one-way hash function h(), which is not a message > > authentication > > > code, and there are actual message authentication codes > > used as well. > > > MD5 is used as the one-way hash function for generating the key. > > > > MD5 is not a key generation algorithm, unless you have a > > REALLY good random > > generator function, and the output it put through MD5, but I > > don't see the > > benefits. Did you, perhaps, mean to state that MD5 is used to > > "mask" the key? > > Yes, MD5 is not a key generation algorithm, and it wasn't our intent. > We use the hash function as a mixing function to combine several > session keys (Kc's) generated by the GSM authentication procedure into a > single key to be used in Mobile IP. The reason for this is twofold: > - the current GSM session keys are at most 64 bits; so two or more of > them are needed to generate a 128 bit key > - by using a one-way hash function to combine the keys, we are assured > that the even if an attacker manages to learn the key used in Mobile > IP, it doesn't help him in learning the original GSM Kc's. This > seems to be a reasonable precaution given that we are using GSM SIM > authentication procedure in ways not intended by the original > designers. ok, and perhaps that is the answer to my previous question. However, if so, I would argue that the amount of traffic generated using the long lived key will not provide enough data for the malicious hacker to find the key, short of a brute force attack. > > > How about all registrations (perhaps except the last reply) > > include the MN-AAA. This solves all of your problems, and you > > can REALLY ignore any un-authenticated message (which is what you > > should do!). > [...] > > What I am missing here is the lack of authentication > > extensions. The SIM Key Request is not an authentication extension, > > correct? Since the Mobile already has a secret with the key generating > > entity, simply re-use that to secure the initial messages... > > As explained above, the equivalent of the MN-HAAA key (Ki) is known to > the SIM card on the MN and the GSM AuC (authentication center), the latter > does not participate in the Mobile IP authorization process (because it is > deep > within the GSM cloud). Ahhh... here is my answer. Can the AuC then not perform some hashing of its own to generate the authentication extension response? Can it be modified in any way to handle this? PatC From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 30 14:45:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24033 for ; Fri, 30 Jun 2000 14:45:46 -0400 (EDT) Received: from standards (47.234.32.16:4321) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79ED7@standards.nortelnetworks.com>; Fri, 30 Jun 2000 14:35:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2241 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 30 Jun 2000 14:35:35 -0400 Received: from sigma.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79ED6@standards.nortelnetworks.com>; Fri, 30 Jun 2000 14:35:35 -0400 Received: (from kleung@localhost) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA04581; Fri, 30 Jun 2000 11:37:58 -0700 (PDT) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200006301837.LAA04581@sigma.cisco.com> Date: Fri, 30 Jun 2000 11:37:58 -0700 Reply-To: "Kent K. Leung" Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: "Kent K. Leung" Subject: Re: [MOBILE-IP] RFC 2002 (+bis) and the 'V' bit X-To: Pat.Calhoun@Eng.Sun.COM To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In-Reply-To: from "pcalhoun@eng.sun.com" at Jun 29, 2000 12:01:16 PM Content-Transfer-Encoding: 7bit > > If the latter is true, I would like to know whether it makes sense to remove > VJ compression from the standard. In most cases, VJ is run over PPP, so I > believe that most VJ compliant hosts actually negotiate it during PPP setup, > and not Mobile IP. > I agree with removal of V bit, which is not supported by Cisco implementation. Frees up a bit. :) -- Kent -- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 30 15:20:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24728 for ; Fri, 30 Jun 2000 15:20:42 -0400 (EDT) Received: from standards (47.234.32.16:4321) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79F4A@standards.nortelnetworks.com>; Fri, 30 Jun 2000 15:10:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2348 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 30 Jun 2000 15:10:27 -0400 Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79F28@standards.nortelnetworks.com>; Fri, 30 Jun 2000 15:00:27 -0400 Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e5T0KX303451 for ; Wed, 28 Jun 2000 20:20:33 -0400 (EDT) Message-ID: <200006290020.e5T0KX303451@breeze.research.telcordia.com> Date: Wed, 28 Jun 2000 20:20:33 -0400 Reply-To: Ashutosh Dutta Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Ashutosh Dutta Subject: [MOBILE-IP] Mobicom 2000 To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Please ignore any duplicate mailings. Thanks Ashutosh ANNOUNCEMENT AND CALL FOR PARTICIPATION MobiCom 2000 The Sixth Annual International Conference on Mobile Computing and Networking August 6 - 11, 2000 Seaport Hotel at World Trade Center Boston Boston, Massachusetts, USA THE COMPLETE ADVANCE PROGRAM AND REGISTRATION INFORMATION ARE AVAILABLE AT ---------------------------------------------- http://www.research.telcordia.com/mobicom2000/ ---------------------------------------------- Sponsored by ACM SIGMOBILE In cooperation with ACM SIGCOMM and SIGMETRICS; IEEE Communications Society; the USENIX Association; the IEE (UK); the IEICE and IPSJ (Japan); the KICS (Korea); and the IFIP WG 6.3 With support from IBM Research (Platinum supporter), HP Laboratories (Platinum supporter), Nokia (Gold supporter) and AT&T Laboratories Cambridge (Gold supporter) CONFERENCE HIGHLIGHTS --------------------- o Keynote Address: "Sentient Computing: The Interface is Everywhere," by Andy Hopper, Professor, University of Cambridge, and Managing Director, AT&T Laboratories Cambridge. o Technical Sessions: Twenty-eight technical papers will be presented describing previously unpublished research on a wide variety of topics in mobile computing and wireless networking, including prototype systems and networks, location support and data dissemination, packet scheduling and channel allocation, mobile internetworking, data management in mobile systems, and routing for ad hoc networks. Papers in a special session will challenge the community with new technologies and visionary applications. This year's conference received the largest number of paper submissions ever, resulting in a highly selective technical program. o Panels: We have organized two panels on timely issues with panelists who are passionate about these topics. P1: Comm'n Sense: Wireless Sensor Networks (Moderator: Deborah Estrin, UCLA and USC/ISI) P2: The Future Wireless Internet: Gazing Into the Crystal Ball (Moderator: Armando Fox, Stanford University) o Tutorials: There will be eight tutorials on cutting-edge topics: T1: Mobile IP for Current and Future Internet (David B. Johnson, CMU and Rice University) T2: Database Management Systems and Mobile Computing (Wang-Chien Lee, GTE Labs, Sandeep K.S. Gupta and Pradeep Srimani, Colorado State University) T3: Personal Area Networking Over Bluetooth (Pravin Bhagwat, AT&T Labs Research) T4: Service Discovery and Device Cooperation (Golden Richard III, University of New Orleans) T5: Energy Efficiency in Mobile Computing and Networking (Mani Srivastava, UCLA) T6: Mobile Voice over IP (Prathima Agrawal, Telcordia, Parmesh Ramanathan, University of Wisconsin, and Cormac J. Sreenan, University College Cork) T7: Mobile Ad Hoc Networks: Routing, MAC and Transport Issues (Nitin Vaidya, Texas A&M University) T8: Shaping the User Experience for Handheld Computing (Phillip B. Shoemaker, Palm Inc.) o Research Demos and Exhibits: The conference will also feature research demos from academic and industry research groups as well as the newest cutting edge products and services from a wealth of companies. o Workshops: Tackling the dominant issues of the day, the following workshops will allow extended considerations of particular topics. - Dial-M: Discrete Algorithms and Methods for Mobile Computing and Communications - WoWMoM: Wireless Mobile Multimedia - MSWiM: Modeling Analysis and Simulation of Wireless and Mobile Systems - MobiHOC: Mobile Ad Hoc Networking and Computing REGISTRATION ------------ The MobiCom 2000 web pages have all the conference registration and hotel reservation specific information: http://www.research.telcordia.com/mobicom2000/ Important Dates: July 7, 2000 -- Discounted hotel reservation deadline. July 15, 2000 -- Early conference registration deadline. Don't delay -- register today for MobiCom 2000. Come, celebrate the wireless revolution and its convergence with the Internet, on Boston's historic waterfront. It is THE conference to attend. We look forward to seeing you in Boston. From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 30 15:48:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25197 for ; Fri, 30 Jun 2000 15:48:47 -0400 (EDT) Received: from standards (47.234.32.16:3175) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79F96@standards.nortelnetworks.com>; Fri, 30 Jun 2000 15:38:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2491 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 30 Jun 2000 15:38:44 -0400 Received: from motgate2.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79F95@standards.nortelnetworks.com>; Fri, 30 Jun 2000 15:28:44 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA28753 for ; Fri, 30 Jun 2000 12:38:20 -0700 (MST)] Received: [from il02exi01.comm.mot.com (il02exi01.comm.mot.com [145.1.204.40]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id MAA13079 for ; Fri, 30 Jun 2000 12:38:20 -0700 (MST)] Received: by il02exi01.comm.mot.com with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Jun 2000 14:38:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <1DA6058E1005D411BC0600805F31E078616C4F@il02exi01.comm.mot.com> Date: Fri, 30 Jun 2000 14:38:16 -0500 Reply-To: Stanaway Chris-CCS018 Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: Stanaway Chris-CCS018 Subject: Re: [MOBILE-IP] RFC 2002 (+bis) and the 'V' bit To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM If the V bit is removed, then it needs to be marked as obsolete and can't be reused for anything else. It's possible that some implementation may have set it. It can't be considered freed up. Chris > -----Original Message----- > From: Kent K. Leung [mailto:kleung@CISCO.COM] > Sent: Friday, June 30, 2000 1:38 PM > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] RFC 2002 (+bis) and the 'V' bit > > > If the latter is true, I would like to know whether it > makes sense to remove > > VJ compression from the standard. In most cases, VJ is run > over PPP, so I > > believe that most VJ compliant hosts actually negotiate it > during PPP setup, > > and not Mobile IP. > > I agree with removal of V bit, which is not supported by Cisco > implementation. Frees up a bit. :) > > -- Kent -- From owner-mobile-ip@STANDARDS.NORTELNETWORKS.COM Fri Jun 30 16:39:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26114 for ; Fri, 30 Jun 2000 16:39:53 -0400 (EDT) Received: from standards (47.234.32.16:1596) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79FCF@standards.nortelnetworks.com>; Fri, 30 Jun 2000 16:29:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 2567 for MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; Fri, 30 Jun 2000 16:29:46 -0400 Received: from kc.ac.kr (210.100.244.1:2596) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB79FCE@standards.nortelnetworks.com>; Fri, 30 Jun 2000 16:19:45 -0400 Received: by kc.ac.kr id AA29347; Sat, 1 Jul 2000 05:02:21 +0900 Received: from enamesoncd@earthlink.net by enamesoncd13@earthlink.net (8.8.5/8.6.5) with SMTP id GAA06610 for ; Fri, 30 Jun 2000 11:46:48 -0600 (EST) Message-ID: <200006302002.AA29347@kc.ac.kr> Date: Fri, 30 Jun 2000 11:46:48 EST Reply-To: enamesoncd@EARTHLINK.NET Sender: "IP Routing for Wireless/Mobile Hosts (mobile-ip)" From: enamesoncd@EARTHLINK.NET Subject: [MOBILE-IP] INCREASE SALES! X-To: enamesoncd13@earthlink.net To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM HELLO: THIS IS AN ADVERTISEMENT FOR 50 MILLION E-MAIL ADDRESSES ON CD-ROM. IF YOU HAVE NO INTEREST IN THIS INFORMATION, PLEASE CLICK DELETE. THANK YOU. Dear Consumer, Increase your business sales! How?? By targeting millions of buyers via e-mail !! We are offering over 50 million FRESH, DELIVERABLE, e-mail addresses on CD-ROM. The cd-rom includes targeted addresses, such as business opportuinty seekers, sports buffs, mlm, impulsive buyers and investors. The cd-rom also includes general internet, United States, United kingdom, mixed domains, International, Canadian, earthlink, aol, compuserve, misc and much more. The list's are divided into groups and are compressed. This will allow you to uses the names right off the cd. ORDER IN THE NEXT 7 DAYS AND RECEIVE TWO FREE BONUSES!!! RECEIVE AN ADDITIONAL CD-ROM WITH MILLIONS OF DELIVERABLE E-MAIL ADDRESSES AND THE MASS MAILER BULKING SOFTWARE FREE !! THE BONUSES ALONE ARE WORTH ACTING NOW! DON'T MISS THIS SUPER SALE!! ACT NOW!! The bonus cd-rom contains such address as general internet, msn, aol, compuserve, delphi and much more. The Mass mailer bulking software is designed for speed. THIS PACKAGE IS WORTH HUNDREDS OF $$ DOLLARS!! ACT NOW WHILE SUPPLIES LAST! ACT NOW AND RECEIVE ALL THIS FOR A ONE TIME UNBELIEVEABLE LOW, LOW PRICE OF ONLY $99.95 ! THAT'S RIGHT ONLY $99.95 SIMPLY SEND $99.95, check or money order, PAYABLE TO: R GOODWIN SHIP TO: MARKETING AND MORE PO BOX 1862, SANTA ROSA BEACH, FL 32459 ----------------------------------------------------------------------------------------- FOR CREDIT CARD ORDERS print and mail form to the above address You may charge my account for $99.95 for the cd-rom and 2 bonuses. ACCOUNT NUMBER__________________________________ EXPIRATION DATE_________________________________ NAME______________________________________________ ADDRESS___________________________________________ CITY/STATE/ZIP______________________________________ PHONE NUMBER(_____)______________________________ If we have reached you in error, and you would like to be removed ronaldp@china.com