From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 1 03:41:36 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02771 for ; Sat, 1 Jun 2002 03:41:36 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA29855; Sat, 1 Jun 2002 00:41:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA00512; Sat, 1 Jun 2002 00:40:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g517dVrP010616 for ; Sat, 1 Jun 2002 00:39:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g517dVrP010615 for mobile-ip-dist; Sat, 1 Jun 2002 00:39:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g517dMrP010600; Sat, 1 Jun 2002 00:39:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA20552; Sat, 1 Jun 2002 00:39:22 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24488; Sat, 1 Jun 2002 01:40:24 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g517d2880528; Sat, 1 Jun 2002 16:39:02 +0900 (JST) Date: Sat, 01 Jun 2002 16:40:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Richard Draves" Cc: "Charles E. Perkins" , "Hesham Soliman (ERA)" , , "IPng Working Group " Subject: [mobile-ip] Re: RFC 2462 DAD optimization In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >>>>> On Fri, 31 May 2002 10:39:18 -0700, >>>>> "Richard Draves" said: > I'm curious about the implementation status. I know the Windows > implementation does not implement the RFC 2462 optimization - it > performs DAD on every address independently. What about other > implementations? KAME (*BSDs) does not implement the optimization either. That's intentional - we once implemented the optimization, but then we changed our mind because doing DAD for every (unicast) address is a SHOULD in RFC 2462 and we did not have any strong reason not to follow the SHOULD (at least at that moment). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 1 04:04:54 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04819 for ; Sat, 1 Jun 2002 04:04:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21548; Sat, 1 Jun 2002 02:05:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03380; Sat, 1 Jun 2002 01:04:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5183urP010696 for ; Sat, 1 Jun 2002 01:03:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g5183u9O010695 for mobile-ip-dist; Sat, 1 Jun 2002 01:03:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5183qrP010688; Sat, 1 Jun 2002 01:03:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13462; Sat, 1 Jun 2002 01:03:52 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA18079; Sat, 1 Jun 2002 02:03:45 -0600 (MDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id RAA21767; Sat, 1 Jun 2002 17:03:44 +0900 To: ipng@sunroof.eng.sun.com Cc: charliep@iprg.nokia.com, hesham.soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com, richdr@microsoft.com, yoshfuji@linux-ipv6.org Subject: [mobile-ip] Re: RFC 2462 DAD optimization In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020601170344V.yoshfuji@linux-ipv6.org> Date: Sat, 01 Jun 2002 17:03:44 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Lines: 11 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit In article <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> (at Fri, 31 May 2002 10:39:18 -0700), "Richard Draves" says: > I'm curious about the implementation status. I know the Windows > implementation does not implement the RFC 2462 optimization - it > performs DAD on every address independently. What about other > implementations? Linux / USAGI does not support DAD optimization and I don't think DAD optimization is a good idea. --yoshfuji From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 1 21:53:26 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29916 for ; Sat, 1 Jun 2002 21:53:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA05932; Sat, 1 Jun 2002 19:53:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA29772; Sat, 1 Jun 2002 18:53:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g521pYrP011867 for ; Sat, 1 Jun 2002 18:51:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g521pYqZ011866 for mobile-ip-dist; Sat, 1 Jun 2002 18:51:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g521pVrP011859; Sat, 1 Jun 2002 18:51:31 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA28419; Sat, 1 Jun 2002 18:51:28 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01448; Sat, 1 Jun 2002 19:51:27 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id EAA27500; Sun, 2 Jun 2002 04:51:19 +0300 Date: Sun, 2 Jun 2002 04:51:19 +0300 Message-Id: <200206020151.EAA27500@burp.tkv.asdf.org> From: Markku Savela To: richdr@microsoft.com CC: charliep@IPRG.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <7695E2F6903F7A41961F8CF888D87EA8063CED28@red-msg-06.redmond.corp.microsoft.com> (richdr@microsoft.com) Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <7695E2F6903F7A41961F8CF888D87EA8063CED28@red-msg-06.redmond.corp.microsoft.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > From: "Richard Draves" > > You are basically arguing for DIID (duplicate interface-id detection) > instead of DAD (duplicate address detection), by using DAD on the > link-local address to perform DIID. I'm very much for the Unique Interface ID on a link (DIID?). I don't see any harm from such policy. It just greatly simplifies the matters. > It seems strange to me to perform DAD on a link-local address that is > not actually being used. For better or worse, it's not the architecture > that we have today and I'm not inclined to change it. It could perphaps be considered, that doing DAD (DIID) on any address on link, would automaticly also reserve the ID for all prefixes. If you don't do unique ID on link, every time a new prefix is announced by RA, there will be a flood of DAD's, as every host on the links is "dadding" their new prefix/id combinations. (And this will go on for global, site local prefixes or 6to4 prefixes. From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 1 23:28:02 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01006 for ; Sat, 1 Jun 2002 23:28:02 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18265; Sat, 1 Jun 2002 21:28:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA13106; Sat, 1 Jun 2002 20:27:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g523R6rP012029 for ; Sat, 1 Jun 2002 20:27:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g523R6ag012028 for mobile-ip-dist; Sat, 1 Jun 2002 20:27:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g523QxrP012013; Sat, 1 Jun 2002 20:26:59 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA07717; Sat, 1 Jun 2002 20:27:01 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA29016; Sat, 1 Jun 2002 20:27:01 -0700 (PDT) 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 UAA20067; Sat, 1 Jun 2002 20:27:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g523R0d02372; Sat, 1 Jun 2002 20:27:00 -0700 X-mProtect: <200206020327> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVaYcEr; Sat, 01 Jun 2002 20:26:57 PDT Message-ID: <3CF9907B.E0DBFCEB@iprg.nokia.com> Date: Sat, 01 Jun 2002 20:26:51 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: IPng Working Group , Mobile IP Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <2E33960095B58E40A4D3345AB9F65EC1047CF128@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Dave, Actually, I would be in favor of making link-local to be the same as "subnet-local". I don't see the advantage in making any distinction. And, I think that the advantage of only having to do DAD for a single address per subnet is a very good advantage, one that turns out to be especially handy for mobile nodes while they are traveling. In fact, I would say that not having this feature is tantamount to restricting mobile nodes to a single home address. Otherwise, it gets to be too much work for the home agent. Am I missing some good feature that results from making the distinction? Regards, Charlie P. Dave Thaler wrote: > As mentioned in email I sent a week or two back, this is > related to the issue of whether a link-local address has to be > unique across an entire subnet, not just a link. Today it's > defined as a "link-local" not a "subnet-local" address. This > means that it is not guaranteed to be unique across a subnet. > > Manually configured global addresses don't need to require > rights to the corresponding link-local address since > a) it's not necessary as they don't use the link-local address, > b) it's not sufficient since they need to be unique across the > subnet, not just the link. > > So unless you're proposing we redefine "link-local" addresses > as "subnet-local" addresses (which would at least be a > consistent argument, albeit a change to the architecture), > then what you suggest does not seem to me to be the right solution. > > -Dave From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 1 23:43:30 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01516 for ; Sat, 1 Jun 2002 23:43:30 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03458; Sat, 1 Jun 2002 20:43:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA15964; Sat, 1 Jun 2002 20:42:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g523frrP012130 for ; Sat, 1 Jun 2002 20:41:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g523frkF012129 for mobile-ip-dist; Sat, 1 Jun 2002 20:41:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g523forP012122; Sat, 1 Jun 2002 20:41:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA15778; Sat, 1 Jun 2002 20:41:52 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA20946; Sat, 1 Jun 2002 21:41:51 -0600 (MDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with ESMTP id XAA03972; Sat, 1 Jun 2002 23:41:50 -0400 (EDT) From: "Dr. Subrata Goswami" Cc: , "'IPng Working Group'" Subject: RE: [mobile-ip] RE: RFC 2462 DAD optimization Date: Sat, 1 Jun 2002 20:45:32 -0700 Message-ID: <005e01c209e7$f2de5e70$6701a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1047CF128@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I am just curious about what are the technical differences between a link-local address and a subnet-local address. I agree with Dave that, doing a DAD for "link-local" type of post-fix address is a unnecessary restriction. 1. There might be global addresss manually configured with the same post-fix but with different pre-fix as the link-local address of a node. What would HA do if a node like that moves into its territory ? 2. For 64-bit post-fix it would render 2**64 perfectly good addresses useless. Subrata -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Dave Thaler Sent: Friday, May 31, 2002 10:59 AM To: Charles E. Perkins; Richard Draves Cc: mobile-ip@sunroof.eng.sun.com; IPng Working Group Subject: [mobile-ip] RE: RFC 2462 DAD optimization As mentioned in email I sent a week or two back, this is related to the issue of whether a link-local address has to be unique across an entire subnet, not just a link. Today it's defined as a "link-local" not a "subnet-local" address. This means that it is not guaranteed to be unique across a subnet. Manually configured global addresses don't need to require rights to the corresponding link-local address since a) it's not necessary as they don't use the link-local address, b) it's not sufficient since they need to be unique across the subnet, not just the link. So unless you're proposing we redefine "link-local" addresses as "subnet-local" addresses (which would at least be a consistent argument, albeit a change to the architecture), then what you suggest does not seem to me to be the right solution. -Dave > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, May 31, 2002 10:45 AM > To: Richard Draves > Cc: mobile-ip@sunroof.eng.sun.com; IPng Working Group > Subject: Re: RFC 2462 DAD optimization > > > Hello Richard, > > Even manually configured global addresses should be required > to acquire rights to the corresponding link-local address. Why not? > > Regards, > Charlie P. > > > Richard Draves wrote: > > > > I disagree. I think the problem is in the RFC 2462 optimization. The RFC > > 2462 optimization also can fail with manually-configured addresses - > > it's not just a problem with RFC 3041 temporary addresses. > > > > I'm curious about the implementation status. I know the Windows > > implementation does not implement the RFC 2462 optimization - it > > performs DAD on every address independently. What about other > > implementations? > > > > Rich > > > > > -----Original Message----- > > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > > Sent: Friday, May 31, 2002 10:03 AM > > > To: Hesham Soliman (ERA) > > > Cc: 'mobile-ip@sunroof.eng.sun.com '; 'IPng Working Group ' > > > Subject: Re: [mobile-ip] Issue #23 and Issue #30 > > > > > > > > > > > > Hello Hesham, > > > > > > "Hesham Soliman (ERA)" wrote: > > > > > > > => RFC 2462 makes an optimisation (not a good > > > > one IMHO) that if a node does DAD on link-local > > > > addresses, it 'owns the interface id' for any other > > > > address with any scope. > > > > > > I think this is a good idea. > > > > > > > RFC3041 says that a node can generate a new iid > > > > and does DAD for _that_ address which uses the > > > > new iid. Since this is typically not a link local > > > > address, you could get a conflict if the HA > > > > does not defend all addresses. > > > > > > The problem is that RFC 3041 should require any > > > such node to first acquire rights to the link-local > > > address. I hope that is viewed as an omission, and > > > one which can be quickly repaired. > > > > > > Regards, > > > Charlie P. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 01:42:28 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02431 for ; Sun, 2 Jun 2002 01:42:28 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA13834; Sat, 1 Jun 2002 23:42:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA04910; Sat, 1 Jun 2002 22:42:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g525fVrP012331 for ; Sat, 1 Jun 2002 22:41:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g525fVQ4012330 for mobile-ip-dist; Sat, 1 Jun 2002 22:41:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g525fSrP012323; Sat, 1 Jun 2002 22:41:28 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA08178; Sat, 1 Jun 2002 22:41:29 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA13519; Sat, 1 Jun 2002 23:41:28 -0600 (MDT) 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 WAA22845; Sat, 1 Jun 2002 22:41:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g525fQ030352; Sat, 1 Jun 2002 22:41:26 -0700 X-mProtect: <200206020541> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9kVvD0; Sat, 01 Jun 2002 22:41:24 PDT Message-ID: <3CF9AFF9.B4DC528F@iprg.nokia.com> Date: Sat, 01 Jun 2002 22:41:13 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Dr. Subrata Goswami" CC: mobile-ip@sunroof.eng.sun.com, "'IPng Working Group'" Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <005e01c209e7$f2de5e70$6701a8c0@SGOSWAMIPCL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Subrata, I reckon I am missing your point, so here is a request for clarification: "Dr. Subrata Goswami" wrote: > I agree with Dave that, doing a DAD for "link-local" type of post-fix > address is a unnecessary restriction. The choice seems to be to do DAD once for a "link-local" or "subnet-local" address (even if the node didn't configure one (?!?)), vs. doing DAD for _every_ configured address. So, the thing you label a "restriction" seems to bring a large measure of freedom, if I understand you correctly. > 1. There might be global addresss manually configured with the same > post-fix but with different pre-fix as the link-local address of a > node. What would HA do if a node like that moves into its territory ? The HA would deny that node use of the link. This is quite unlikely to ever happen, though. > 2. For 64-bit post-fix it would render 2**64 perfectly good addresses > useless. I don't understand what you mean here. Which addresses are useless? Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 04:06:49 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11875 for ; Sun, 2 Jun 2002 04:06:48 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09749; Sun, 2 Jun 2002 02:07:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA28903; Sun, 2 Jun 2002 01:06:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52858rP012537 for ; Sun, 2 Jun 2002 01:05:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52858M6012536 for mobile-ip-dist; Sun, 2 Jun 2002 01:05:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52855rP012529; Sun, 2 Jun 2002 01:05:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03078; Sun, 2 Jun 2002 01:05:05 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA02570; Sun, 2 Jun 2002 02:05:03 -0600 (MDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with ESMTP id EAA10383; Sun, 2 Jun 2002 04:05:01 -0400 (EDT) From: "Dr. Subrata Goswami" Cc: , "'IPng Working Group'" Subject: RE: [mobile-ip] RE: RFC 2462 DAD optimization Date: Sun, 2 Jun 2002 01:08:41 -0700 Message-ID: <005f01c20a0c$b65e16a0$6701a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0060_01C209D2.09FF3EA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3CF9AFF9.B4DC528F@iprg.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0060_01C209D2.09FF3EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The HA would deny that node use of the link. This is quite unlikely to ever happen, though. Why is that ? I don't understand what you mean here. Which addresses are useless? Because you are ignoring the pre-fix (which can be 64 bits). -----Original Message----- From: Charlie Perkins [mailto:charliep@iprg.nokia.com] Sent: Saturday, June 01, 2002 10:41 PM To: Dr. Subrata Goswami Cc: mobile-ip@sunroof.eng.sun.com; 'IPng Working Group' Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization Hello Subrata, I reckon I am missing your point, so here is a request for clarification: "Dr. Subrata Goswami" wrote: > I agree with Dave that, doing a DAD for "link-local" type of post-fix > address is a unnecessary restriction. The choice seems to be to do DAD once for a "link-local" or "subnet-local" address (even if the node didn't configure one (?!?)), vs. doing DAD for _every_ configured address. So, the thing you label a "restriction" seems to bring a large measure of freedom, if I understand you correctly. > 1. There might be global addresss manually configured with the same > post-fix but with different pre-fix as the link-local address of a > node. What would HA do if a node like that moves into its territory ? The HA would deny that node use of the link. This is quite unlikely to ever happen, though. > 2. For 64-bit post-fix it would render 2**64 perfectly good addresses > useless. I don't understand what you mean here. Which addresses are useless? Regards, Charlie P. ------=_NextPart_000_0060_01C209D2.09FF3EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The HA would deny that node use of the link.  This is quite = unlikely

to ever happen, = though.

 

Why is that = ?

 

 

 

I don't understand what you mean here.  Which addresses are = useless?

 

Because you are ignoring the pre-fix (which can be 64 bits).

 

 

 

 

 

-----Original Message-----
From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
Sent: Saturday, June 01, 2002 10:41 = PM
To: Dr. Subrata Goswami
Cc: mobile-ip@sunroof.eng.sun.com; = 'IPng Working Group'
Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization

 

 

Hello Subrata,

 

I reckon I am missing your point, so here is a request for clarification:

 

"Dr. Subrata Goswami" = wrote:

 

> I agree with Dave that, doing a DAD for = "link-local" type of post-fix

> address is a unnecessary = restriction.

 

The choice seems to be to do DAD once for a = "link-local" or

"subnet-local" address (even if the node didn't = configure one (?!?)),

vs. doing DAD for _every_ configured = address.

 

So, the thing you label a "restriction" seems to bring = a large

measure of freedom, if I understand you = correctly.

 

> 1. There might be global addresss manually configured with = the same

> post-fix but  = with different pre-fix as the link-local address of = a

> node. What would HA do if a node like that moves into its territory  = ?

 

The HA would deny that node use of the link.  This is quite = unlikely

to ever happen, though.

 

> 2. For 64-bit post-fix it would render  2**64 perfectly good = addresses

> useless.

 

I don't understand what you mean here.  Which addresses are = useless?

 

 

Regards,

Charlie P.

 

------=_NextPart_000_0060_01C209D2.09FF3EA0-- From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 09:59:31 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14746 for ; Sun, 2 Jun 2002 09:59:30 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26568; Sun, 2 Jun 2002 06:58:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25427; Sun, 2 Jun 2002 06:58:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52DvLrP012960 for ; Sun, 2 Jun 2002 06:57:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52DvLoT012959 for mobile-ip-dist; Sun, 2 Jun 2002 06:57:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52DvErP012944; Sun, 2 Jun 2002 06:57:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18185; Sun, 2 Jun 2002 06:57:14 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29913; Sun, 2 Jun 2002 07:57:13 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g52Dutc05736; Sun, 2 Jun 2002 15:56:55 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA22643; Sun, 2 Jun 2002 15:56:55 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g52DusT60120; Sun, 2 Jun 2002 15:56:54 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206021356.g52DusT60120@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Richard Draves" cc: "Charles E. Perkins" , "Hesham Soliman (ERA)" , mobile-ip@sunroof.eng.sun.com, "IPng Working Group " Subject: Re: [mobile-ip] RFC 2462 DAD optimization In-reply-to: Your message of Fri, 31 May 2002 10:39:18 PDT. <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> Date: Sun, 02 Jun 2002 15:56:54 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I disagree. I think the problem is in the RFC 2462 optimization. The RFC 2462 optimization also can fail with manually-configured addresses - it's not just a problem with RFC 3041 temporary addresses. => I agree: the RFC 2462 optimization is based on many implicit assumptions... We have to drop it or to respecify it clearly/cleanly. I'm curious about the implementation status. I know the Windows implementation does not implement the RFC 2462 optimization - it performs DAD on every address independently. What about other implementations? => in my implementation, DAD was done on every address with an user control to disable it (default was to enable DAD) but the autoconfig client tool didn't perform DAD (it was considered as a bug). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 10:57:19 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15474 for ; Sun, 2 Jun 2002 10:57:19 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25985; Sun, 2 Jun 2002 07:56:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23505; Sun, 2 Jun 2002 07:56:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52Eu6rP013082 for ; Sun, 2 Jun 2002 07:56:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52Eu50L013081 for mobile-ip-dist; Sun, 2 Jun 2002 07:56:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52Eu2rP013074 for ; Sun, 2 Jun 2002 07:56:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23459 for ; Sun, 2 Jun 2002 07:56:02 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10881 for ; Sun, 2 Jun 2002 08:57:06 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g52Etfc08211; Sun, 2 Jun 2002 16:55:41 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA23035; Sun, 2 Jun 2002 16:55:42 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g52EtfT60959; Sun, 2 Jun 2002 16:55:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206021455.g52EtfT60959@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Hesham Soliman (ERA)" cc: Vijay Devarapalli , jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 In-reply-to: Your message of Wed, 22 May 2002 13:55:08 +0200. <4DA6EA82906FD511BE2F00508BCF0538044F064B@Esealnt861.al.sw.ericsson.se> Date: Sun, 02 Jun 2002 16:55:41 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I might be missing something, but I'm not sure that your steps below will work. => they did work. => If the HA does not defend the MN's link-local address while it's away, how can you send a dereg if someone else took the MN's link-local address? => if someone else took your link-local address you are in the same situation as when you boot and attach to a link where someone else have taken your link-local address... Francis.Dupont@enst-bretagne.fr PS: I tried to move this discussion on the IPv6 mailing-list (topic DAD or DIIDD). From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 11:12:06 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15707 for ; Sun, 2 Jun 2002 11:12:06 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13597; Sun, 2 Jun 2002 09:13:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24991; Sun, 2 Jun 2002 08:12:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52FBHrP013179 for ; Sun, 2 Jun 2002 08:11:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52FBH2N013178 for mobile-ip-dist; Sun, 2 Jun 2002 08:11:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52FBDrP013171 for ; Sun, 2 Jun 2002 08:11:14 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06547 for ; Sun, 2 Jun 2002 08:11:14 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28526 for ; Sun, 2 Jun 2002 08:11:13 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g52FB2c08978; Sun, 2 Jun 2002 17:11:02 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA23157; Sun, 2 Jun 2002 17:11:02 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g52FB2T61082; Sun, 2 Jun 2002 17:11:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206021511.g52FB2T61082@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Charles E. Perkins" cc: "Dr. Subrata Goswami" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 In-reply-to: Your message of Tue, 28 May 2002 12:26:25 PDT. <3CF3D9E1.A7D724C6@iprg.nokia.com> Date: Sun, 02 Jun 2002 17:11:01 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I should clarify: My expectation is that the home agent should ONLY defend the mobile node's link-local address, not its other addresses. Then, by implication, the other addresses will be unavailable to nodes on the link because they can't form the link-local address to start with. => if you follow the discussion (?) on the IPv6 mailing-list, this is a clear claim of the DIIDD option. Regards Francis.Dupont@enst-bretagne.fr PS: I am not in favour of nuking DIIDD: I'd like to first choose between DAD and DIIDD then to nuke the loser. From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 11:14:41 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15756 for ; Sun, 2 Jun 2002 11:14:40 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20105; Sun, 2 Jun 2002 09:14:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25369; Sun, 2 Jun 2002 08:14:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52FE6rP013244 for ; Sun, 2 Jun 2002 08:14:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52FE6r7013243 for mobile-ip-dist; Sun, 2 Jun 2002 08:14:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52FE3rP013236 for ; Sun, 2 Jun 2002 08:14:03 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08552 for ; Sun, 2 Jun 2002 08:14:03 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13100 for ; Sun, 2 Jun 2002 08:14:02 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g52FDsc09020; Sun, 2 Jun 2002 17:13:54 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA23178; Sun, 2 Jun 2002 17:13:54 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g52FDsT61113; Sun, 2 Jun 2002 17:13:54 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206021513.g52FDsT61113@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Dr. Subrata Goswami" cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 In-reply-to: Your message of Tue, 28 May 2002 12:49:59 PDT. <000d01c20680$da3df7f0$6600a8c0@SGOSWAMIPCL> Date: Sun, 02 Jun 2002 17:13:54 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Hi Charlie, I can not think of any at this point. Eliminating the requirement (of link-local address defence by HA) would simplify HA design. => I don't think so: I believe for HA design DAD and DIIDD are roughly equivalent. The only little problem is that they are not compatible... Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 11:30:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15892 for ; Sun, 2 Jun 2002 11:30:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16458; Sun, 2 Jun 2002 09:32:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11689; Sun, 2 Jun 2002 08:30:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52FTxrP013360 for ; Sun, 2 Jun 2002 08:29:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52FTxEw013359 for mobile-ip-dist; Sun, 2 Jun 2002 08:29:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52FTqrP013344; Sun, 2 Jun 2002 08:29:52 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26557; Sun, 2 Jun 2002 08:29:52 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13383; Sun, 2 Jun 2002 09:29:51 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g52FTjc09485; Sun, 2 Jun 2002 17:29:45 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA23297; Sun, 2 Jun 2002 17:29:46 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g52FTjT61255; Sun, 2 Jun 2002 17:29:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206021529.g52FTjT61255@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Charles E. Perkins" cc: "Hesham Soliman (ERA)" , "'mobile-ip@sunroof.eng.sun.com '" , "'IPng Working Group '" Subject: Re: [mobile-ip] Issue #23 and Issue #30 In-reply-to: Your message of Fri, 31 May 2002 10:02:59 PDT. <3CF7ACC3.9272AFBF@iprg.nokia.com> Date: Sun, 02 Jun 2002 17:29:45 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > RFC3041 says that a node can generate a new iid > and does DAD for _that_ address which uses the > new iid. Since this is typically not a link local > address, you could get a conflict if the HA > does not defend all addresses. The problem is that RFC 3041 should require any such node to first acquire rights to the link-local address. I hope that is viewed as an omission, and one which can be quickly repaired. => this point is clearly at the advantage of the DIIDD option but don't forget a direct consequence of to choose DIIDD is the MN returning back to home should use an alternative IID (a RFC 3041 one for instance) because its `own' IDD is defended by the HA until the deregistration succeeds: this is clean, easy to implement/understand but costs a DAD (oups, a DIIDD :-) for the temporary IID check in all cases... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 18:56:34 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20031 for ; Sun, 2 Jun 2002 18:56:33 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAB00570; Sun, 2 Jun 2002 16:57:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25182; Sun, 2 Jun 2002 15:56:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52MtjrP013653 for ; Sun, 2 Jun 2002 15:55:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52Mtjpf013652 for mobile-ip-dist; Sun, 2 Jun 2002 15:55:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52MtfrP013645; Sun, 2 Jun 2002 15:55:41 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25053; Sun, 2 Jun 2002 15:55:42 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09270; Sun, 2 Jun 2002 16:55:42 -0600 (MDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 2 Jun 2002 15:55:41 -0700 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 02 Jun 2002 15:55:39 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 2 Jun 2002 15:55:41 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 2 Jun 2002 15:55:40 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Sun, 2 Jun 2002 15:55:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] RE: RFC 2462 DAD optimization Date: Sun, 2 Jun 2002 15:55:40 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1073840F9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [mobile-ip] RE: RFC 2462 DAD optimization Thread-Index: AcIJ58nXPGJBzaAkS1anYiXRfDqWTAAnxP6A From: "Dave Thaler" To: "Dr. Subrata Goswami" Cc: , "IPng Working Group" X-OriginalArrivalTime: 02 Jun 2002 22:55:39.0297 (UTC) FILETIME=[9D6FB910:01C20A88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g52MtgrQ013646 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Dr. Subrata Goswami [mailto:sgoswami@umich.edu] > Sent: Saturday, June 01, 2002 8:46 PM > Cc: mobile-ip@sunroof.eng.sun.com; 'IPng Working Group' > Subject: RE: [mobile-ip] RE: RFC 2462 DAD optimization > > I am just curious about what are the technical differences between a > link-local address and a subnet-local address. A subnet can cover multiple links, whenever you have some type of RA/ND proxying going on. A link-local address is unique only within a single link, and is never proxied. Today fe80::/10 and ffx2::/16 addresses are defined as being link-local. This means that two links in the same subnet can reuse the same link-local addresses. Ffx3::/16 is a subnet-local multicast range. There is no subnet-local unicast range today. Charlie is arguing that he would like to see fe80::/10 redefined as the "subnet-local" unicast range, rather than the link-local unicast range, which means that a multilink subnet router (of which a home agent is one special case) would be required to proxy ND for link-local addresses. (Personally, I think it's way too late to define fe80 as subnet-local.) Today, a multilink subnet router would have no need to do that, other than the problems resulting from anyone not doing DAD on every address - which does not appear to be a problem today. See draft-ietf-ipngwg-scoping-arch-03.txt and draft-thaler-ipngwg-multilink-subnets-02.txt for more information. > I agree with Dave that, doing a DAD for "link-local" type of post-fix > address is a unnecessary restriction. > > 1. There might be global addresss manually configured with the same > post-fix but with different pre-fix as the link-local address of a > node. What would HA do if a node like that moves into its territory ? > 2. For 64-bit post-fix it would render 2**64 perfectly good addresses > useless. > > Subrata -Dave From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 19:14:55 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20190 for ; Sun, 2 Jun 2002 19:14:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03468; Sun, 2 Jun 2002 16:14:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28088; Sun, 2 Jun 2002 16:14:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NDLrP013876 for ; Sun, 2 Jun 2002 16:13:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52NDLqr013875 for mobile-ip-dist; Sun, 2 Jun 2002 16:13:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NDErP013860; Sun, 2 Jun 2002 16:13:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20920; Sun, 2 Jun 2002 16:13:15 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26693; Sun, 2 Jun 2002 17:13:14 -0600 (MDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 2 Jun 2002 16:13:14 -0700 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 02 Jun 2002 16:13:13 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 2 Jun 2002 16:13:12 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 2 Jun 2002 16:13:12 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Sun, 2 Jun 2002 16:13:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] RE: RFC 2462 DAD optimization Date: Sun, 2 Jun 2002 16:13:11 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1073840FA@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [mobile-ip] RE: RFC 2462 DAD optimization Thread-Index: AcIJ5VyRnAUz04u0QkyxrNRt2CtdewAo1k9A From: "Dave Thaler" To: "Charlie Perkins" Cc: "IPng Working Group" , "Mobile IP Working Group" X-OriginalArrivalTime: 02 Jun 2002 23:13:10.0391 (UTC) FILETIME=[0FEFF070:01C20A8B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g52NDErP013861 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Charlie Perkins writes: > Actually, I would be in favor of making link-local to be the > same as "subnet-local". I don't see the advantage in making > any distinction. [Note: This email is not Mobile-IP specific. I'm talking about the general case, of which a home agent is a special case which corresponds to an ND proxy as defined in the multilink subnet draft.] The distinction in scope is especially important for multicast, which uses two separate ranges for link- and subnet-local today. The distinction is that link-local addresses are never forwarded by any router, and hence are always possible to use even when no multicast routing protocol is deployed. Subnet-local addresses require a routing protocol which must have some concept akin to host routes within the subnet. This is fine for multicast since multicast routing protocols already use address-specific state today, rather than multicast prefixes. For unicast, domains typically don't use host routes, and hence as noted in draft-thaler-ipngwg-multilink-subnets-02.txt, this is a difficult problem with no simple solution in the general case. (Which is why the RA/ND proxy solution that people often use is not tailored to the general case, and indeed can cause problems in the general case, leading to rules to prevent meltdown like in section 5.4 of that draft.) > And, I think that the advantage of only having > to do DAD for a single address per subnet is a very good > advantage, one that turns out to be especially handy for > mobile nodes while they are traveling. [End of explanation, begin personal opinions:] It seems to me that it's just an optimization that's not worth the complexity of creating a problem in the general case. I also don't think we should be changing the addressing architecture (specifically, redefining fe80::/10 as subnet-local) this late, especially if it can cause problems in some cases (which I believe it does, details are in Appendix A of the multilink subnet draft). > In fact, I would say that not having this feature is tantamount > to restricting mobile nodes to a single home address. > Otherwise, it gets to be too much work for the home agent. I don't understand why it's tantamount to having a single home address. Certainly one could conceivably have one home address for each of two separate home agents, without adding any additional work for each home agent, right? It's also non-obvious to me why it's too much work if there's multiple home addresses at the same home agent. Can you elaborate? -Dave > Am I missing some good feature that results from making > the distinction? > > Regards, > Charlie P. > > > Dave Thaler wrote: > > > As mentioned in email I sent a week or two back, this is > > related to the issue of whether a link-local address has to be > > unique across an entire subnet, not just a link. Today it's > > defined as a "link-local" not a "subnet-local" address. This > > means that it is not guaranteed to be unique across a subnet. > > > > Manually configured global addresses don't need to require > > rights to the corresponding link-local address since > > a) it's not necessary as they don't use the link-local address, > > b) it's not sufficient since they need to be unique across the > > subnet, not just the link. > > > > So unless you're proposing we redefine "link-local" addresses > > as "subnet-local" addresses (which would at least be a > > consistent argument, albeit a change to the architecture), > > then what you suggest does not seem to me to be the right solution. > > > > -Dave From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 19:33:52 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20322 for ; Sun, 2 Jun 2002 19:33:48 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00248; Sun, 2 Jun 2002 17:34:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02232; Sun, 2 Jun 2002 16:33:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NX5rP014090 for ; Sun, 2 Jun 2002 16:33:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52NX574014089 for mobile-ip-dist; Sun, 2 Jun 2002 16:33:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NX2rP014082; Sun, 2 Jun 2002 16:33:02 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22900; Sun, 2 Jun 2002 16:33:03 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00021; Sun, 2 Jun 2002 17:33:02 -0600 (MDT) 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 QAA18327; Sun, 2 Jun 2002 16:33:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g52NX1v14756; Sun, 2 Jun 2002 16:33:01 -0700 X-mProtect: <200206022333> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhvjuXe; Sun, 02 Jun 2002 16:33:00 PDT Message-ID: <3CFAAB2C.B7CA5661@iprg.nokia.com> Date: Sun, 02 Jun 2002 16:33:00 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <2E33960095B58E40A4D3345AB9F65EC1073840F9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dave Thaler wrote: > Ffx3::/16 is a subnet-local multicast range. There is no > subnet-local unicast range today. Charlie is arguing that he would > like to see fe80::/10 redefined as the "subnet-local" unicast > range, rather than the link-local unicast range, which means > that a multilink subnet router (of which a home agent is one > special case) would be required to proxy ND for link-local addresses. > (Personally, I think it's way too late to define fe80 as subnet-local.) > > Today, a multilink subnet router would have no need to do that, > other than the problems resulting from anyone not doing DAD on > every address - which does not appear to be a problem today. Today there aren't any problems, but that's because nobody is using very many subnet prefixes on the same {,multi-}link. I think the current design decision essentially codifies that, at least for mobile nodes. Is that the intended result? Another possibility would be to declare that on any link that has the capability to support mobility agents, a link-local address semantically has to be same as a subnet-local address. This would require extra work from the multi-link proxy agent, but would make the life of network administrators much easier since my suggested design choice is much simpler to understand. In fact, I would argue that the current "architecture" of link-local addresses as you have detailed it is wrong, because it's not in the realm of layer-3 design. I'll have to work out the implications for multicast later, but my initial impression is that it's workable. I also owe you more text about why it's a lot of work for home agents. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 19:39:30 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20389 for ; Sun, 2 Jun 2002 19:39:30 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01404; Sun, 2 Jun 2002 17:39:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11138; Sun, 2 Jun 2002 16:39:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NctrP014206 for ; Sun, 2 Jun 2002 16:38:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52NcsJ6014205 for mobile-ip-dist; Sun, 2 Jun 2002 16:38:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NcjrP014190; Sun, 2 Jun 2002 16:38:45 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23319; Sun, 2 Jun 2002 16:38:47 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18203; Sun, 2 Jun 2002 17:38:45 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D65864B24; Mon, 3 Jun 2002 08:38:40 +0900 (JST) To: "Charles E. Perkins" Cc: mobile-ip@sunroof.eng.sun.com, IPng Working Group In-reply-to: charliep's message of Sun, 02 Jun 2002 16:33:00 MST. <3CFAAB2C.B7CA5661@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization From: itojun@iijlab.net Date: Mon, 03 Jun 2002 08:38:40 +0900 Message-ID: <2212.1023061120@itojun.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >Today there aren't any problems, but that's because nobody >is using very many subnet prefixes on the same {,multi-}link. >I think the current design decision essentially codifies that, >at least for mobile nodes. Is that the intended result? (just for clarifications, not sure if it is related to the discussion) i don't quite parse the above paragraph. there are a lot of links where we assign multiple subnet prefixes (different /64 from different upstream ISP). it is useful, for example, for RFC3178. also, if you are willing to use router renumbering and such, a /64 prefix out of fec0::/48 range will be added too. itojun From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 19:44:27 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20496 for ; Sun, 2 Jun 2002 19:44:27 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02422; Sun, 2 Jun 2002 17:44:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11718; Sun, 2 Jun 2002 16:44:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NhcrP014296 for ; Sun, 2 Jun 2002 16:43:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52Nhcmh014295 for mobile-ip-dist; Sun, 2 Jun 2002 16:43:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NhZrP014288; Sun, 2 Jun 2002 16:43:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03629; Sun, 2 Jun 2002 16:43:35 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA02083; Sun, 2 Jun 2002 17:43:34 -0600 (MDT) 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 QAA18612; Sun, 2 Jun 2002 16:43:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g52NhYK22703; Sun, 2 Jun 2002 16:43:34 -0700 X-mProtect: <200206022343> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkhMxvd; Sun, 02 Jun 2002 16:43:32 PDT Message-ID: <3CFAADA4.F74461E5@iprg.nokia.com> Date: Sun, 02 Jun 2002 16:43:32 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <2212.1023061120@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit itojun@iijlab.net wrote: > there are a lot of links where we assign multiple subnet prefixes > (different /64 from different upstream ISP). it is useful, for example, > for RFC3178. also, if you are willing to use router renumbering > and such, a /64 prefix out of fec0::/48 range will be added too. This is interesting information. Can you say how many prefixes are typically advertised? Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 19:48:31 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20552 for ; Sun, 2 Jun 2002 19:48:30 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10908; Sun, 2 Jun 2002 17:49:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12363; Sun, 2 Jun 2002 16:48:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NlmrP014405 for ; Sun, 2 Jun 2002 16:47:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52NlmDF014404 for mobile-ip-dist; Sun, 2 Jun 2002 16:47:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NldrP014389; Sun, 2 Jun 2002 16:47:39 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12283; Sun, 2 Jun 2002 16:47:41 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11565; Sun, 2 Jun 2002 16:47:40 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 70DA14B25; Mon, 3 Jun 2002 08:47:36 +0900 (JST) To: "Charles E. Perkins" Cc: mobile-ip@sunroof.eng.sun.com, IPng Working Group In-reply-to: charliep's message of Sun, 02 Jun 2002 16:43:32 MST. <3CFAADA4.F74461E5@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization From: itojun@iijlab.net Date: Mon, 03 Jun 2002 08:47:36 +0900 Message-ID: <2285.1023061656@itojun.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >> there are a lot of links where we assign multiple subnet prefixes >> (different /64 from different upstream ISP). it is useful, for example, >> for RFC3178. also, if you are willing to use router renumbering >> and such, a /64 prefix out of fec0::/48 range will be added too. >This is interesting information. Can you say how many prefixes >are typically advertised? not sure about "typically", but around 3 to 5 prefixes are advertised in my office, another office, and home. at past IETFs and ipngwg interim meetings, we advertised 2 or 3 prefixes because we were multi-homed. so pls do not assume that there's single subnet prefix on a link. itojun From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 20:00:15 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20736 for ; Sun, 2 Jun 2002 20:00:14 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11924; Sun, 2 Jun 2002 16:59:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13341; Sun, 2 Jun 2002 16:59:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NwvrP014527 for ; Sun, 2 Jun 2002 16:58:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g52NwvVq014526 for mobile-ip-dist; Sun, 2 Jun 2002 16:58:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g52NwrrP014519; Sun, 2 Jun 2002 16:58:53 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06042; Sun, 2 Jun 2002 16:58:54 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13009; Sun, 2 Jun 2002 18:00:00 -0600 (MDT) 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 QAA18962; Sun, 2 Jun 2002 16:58:53 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g52Nwro31414; Sun, 2 Jun 2002 16:58:53 -0700 X-mProtect: <200206022358> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpduKeJB7; Sun, 02 Jun 2002 16:58:51 PDT Message-ID: <3CFAB13C.5B1AC3B7@iprg.nokia.com> Date: Sun, 02 Jun 2002 16:58:52 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <2285.1023061656@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Itojun, itojun@iijlab.net wrote: > not sure about "typically", but around 3 to 5 prefixes are advertised > in my office, another office, and home. at past IETFs and ipngwg > interim meetings, we advertised 2 or 3 prefixes because we were > multi-homed. so pls do not assume that there's single subnet prefix > on a link. My guess is that you are using this feature more than most IPv6 installations. But anyway, it's not 20 or even a dozen prefixes. Is it reasonable for us to assume that, for most links, the number of advertised prefixes will never exceed 10? 7? I never meant to make the assumption that a links would see only a single advertised prefix. I had thought that most installations were not using the feature very heavily, and that 1 or 2 would be the typical number of prefixes advertised. Now you point out that there are some with up to 5. This is good to know. I wonder if we can get to the point of agreeing on a maximum for all future applications, so that we can agree to avoid designing for problems of scalability that won't exist over the lifetime of IPv6. Regards, Charlie P. PS. Please let me know what I can do to clarify any parsing issues in the above or any previous notes. I am not trying to be writing mysteries or puzzles. From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 20:08:24 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20846 for ; Sun, 2 Jun 2002 20:08:24 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24508; Sun, 2 Jun 2002 18:08:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14411; Sun, 2 Jun 2002 17:08:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5307erP014636 for ; Sun, 2 Jun 2002 17:07:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g5307ekY014635 for mobile-ip-dist; Sun, 2 Jun 2002 17:07:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5307VrP014620; Sun, 2 Jun 2002 17:07:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25686; Sun, 2 Jun 2002 17:07:33 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14717; Sun, 2 Jun 2002 18:08:38 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A821A4B24; Mon, 3 Jun 2002 09:07:25 +0900 (JST) To: "Charles E. Perkins" Cc: mobile-ip@sunroof.eng.sun.com, IPng Working Group In-reply-to: charliep's message of Sun, 02 Jun 2002 16:58:52 MST. <3CFAB13C.5B1AC3B7@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization From: itojun@iijlab.net Date: Mon, 03 Jun 2002 09:07:25 +0900 Message-ID: <2462.1023062845@itojun.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >> not sure about "typically", but around 3 to 5 prefixes are advertised >> in my office, another office, and home. at past IETFs and ipngwg >> interim meetings, we advertised 2 or 3 prefixes because we were >> multi-homed. so pls do not assume that there's single subnet prefix >> on a link. >My guess is that you are using this feature more than most IPv6 >installations. But anyway, it's not 20 or even a dozen prefixes. >Is it reasonable for us to assume that, for most links, the number >of advertised prefixes will never exceed 10? 7? we never know what the future operators will do, so it is safer not to make assumptions. itojun From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 20:21:20 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20910 for ; Sun, 2 Jun 2002 20:21:20 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27257; Sun, 2 Jun 2002 18:21:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15822; Sun, 2 Jun 2002 17:21:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530KUrP014725 for ; Sun, 2 Jun 2002 17:20:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g530KUtn014724 for mobile-ip-dist; Sun, 2 Jun 2002 17:20:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530KQrP014717; Sun, 2 Jun 2002 17:20:26 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09304; Sun, 2 Jun 2002 17:20:28 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27039; Sun, 2 Jun 2002 18:20:27 -0600 (MDT) 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 RAA20022; Sun, 2 Jun 2002 17:20:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g530KQ910114; Sun, 2 Jun 2002 17:20:26 -0700 X-mProtect: <200206030020> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgs8M5O; Sun, 02 Jun 2002 17:20:25 PDT Message-ID: <3CFAB649.45AF7391@iprg.nokia.com> Date: Sun, 02 Jun 2002 17:20:25 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <2462.1023062845@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit itojun@iijlab.net wrote: >> Is it reasonable for us to assume that, for most links, the number >> of advertised prefixes will never exceed 10? 7? > > we never know what the future operators will do, so it is safer > not to make assumptions. In that case, I think we have to do something to avoid doing DAD for all those prefixes. One solution would be to just do it for link-local prefixes, which according to Dave Thaler's argument then become subnet-local prefixes. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 20:24:50 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20969 for ; Sun, 2 Jun 2002 20:24:50 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA17810; Sun, 2 Jun 2002 17:24:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA16227; Sun, 2 Jun 2002 17:24:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530NkrP014812 for ; Sun, 2 Jun 2002 17:23:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g530NjUr014811 for mobile-ip-dist; Sun, 2 Jun 2002 17:23:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530NbrP014793; Sun, 2 Jun 2002 17:23:37 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09715; Sun, 2 Jun 2002 17:23:36 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27730; Sun, 2 Jun 2002 18:23:35 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D9AA54B24; Mon, 3 Jun 2002 09:23:29 +0900 (JST) To: "Charles E. Perkins" Cc: mobile-ip@sunroof.eng.sun.com, IPng Working Group In-reply-to: charliep's message of Sun, 02 Jun 2002 17:20:25 MST. <3CFAB649.45AF7391@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization From: itojun@iijlab.net Date: Mon, 03 Jun 2002 09:23:29 +0900 Message-ID: <2625.1023063809@itojun.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >> we never know what the future operators will do, so it is safer >> not to make assumptions. >In that case, I think we have to do something to avoid doing DAD >for all those prefixes. One solution would be to just do it for >link-local prefixes, which according to Dave Thaler's argument >then become subnet-local prefixes. i don't think it necessary to do anything about DAD. we perform DAD (not DIIDD) for all addresses assigned, and we will be fine. itojun From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 20:37:08 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21164 for ; Sun, 2 Jun 2002 20:37:08 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA00811; Sun, 2 Jun 2002 18:37:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA28480; Sun, 2 Jun 2002 17:37:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530aUrP014931 for ; Sun, 2 Jun 2002 17:36:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g530aU9C014930 for mobile-ip-dist; Sun, 2 Jun 2002 17:36:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530aRrP014923; Sun, 2 Jun 2002 17:36:27 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA28340; Sun, 2 Jun 2002 17:36:26 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20594; Sun, 2 Jun 2002 17:36:25 -0700 (PDT) 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 RAA20399; Sun, 2 Jun 2002 17:36:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g530aOU18979; Sun, 2 Jun 2002 17:36:24 -0700 X-mProtect: <200206030036> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnTDBrd; Sun, 02 Jun 2002 17:36:21 PDT Message-ID: <3CFABA06.79CF83E4@iprg.nokia.com> Date: Sun, 02 Jun 2002 17:36:22 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: mobile-ip@sunroof.eng.sun.com, IPng Working Group , Dave Thaler Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <2625.1023063809@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello itojun, itojun@iijlab.net wrote: > >> we never know what the future operators will do, so it is safer > >> not to make assumptions. > >In that case, I think we have to do something to avoid doing DAD > >for all those prefixes. One solution would be to just do it for > >link-local prefixes, which according to Dave Thaler's argument > >then become subnet-local prefixes. > > i don't think it necessary to do anything about DAD. we perform DAD > (not DIIDD) for all addresses assigned, and we will be fine. Do you still think that is true if the mobile node has to send out 10, or some unbounded number, of Binding Updates each time it changes its care-of address? The discussion in the mobile-ip group is whether a single Binding Update can suffice for all home addresses of a mobile node that share the same interface ID. This led to discussion about DAD. The subjects are not inseparably intertwined, but there is a relationship. It has been my understanding that a home agent, charged with the protocol responsibility for defending the addresses of 4,095 mobile nodes (or, say, 500,000 for some cellular plans), would effectively disable the ability of mobile nodes to use multiple prefixes, because equipment vendors would just "say no" if they thought only a few mobile nodes would use this feature. Thus, I thought that it would be a lot better to have a very simple scaling mechanism that would still allow for a large number of prefixes. This is simple, if the home agent can just defend the link-local prefix. It's not so simple if any increase in the number of advertised prefixes requires a linear increase in storage or performance requirements at the home agent. It's really quite bad if the communication requirement at the mobile node experiences a linear increase in capacity requirement at handover time. My guess is that it will just effectively mean people will not use multiple prefixes for mobile nodes. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 20:55:56 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21331 for ; Sun, 2 Jun 2002 20:55:55 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA05735; Sun, 2 Jun 2002 18:56:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00209; Sun, 2 Jun 2002 17:56:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530tCrP015081 for ; Sun, 2 Jun 2002 17:55:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g530tCOx015080 for mobile-ip-dist; Sun, 2 Jun 2002 17:55:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g530sxrP015065; Sun, 2 Jun 2002 17:54:59 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14371; Sun, 2 Jun 2002 17:54:59 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00381; Sun, 2 Jun 2002 17:54:58 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A2F9F4B24; Mon, 3 Jun 2002 09:54:54 +0900 (JST) To: "Charles E. Perkins" Cc: mobile-ip@sunroof.eng.sun.com, IPng Working Group , Dave Thaler In-reply-to: charliep's message of Sun, 02 Jun 2002 17:36:22 MST. <3CFABA06.79CF83E4@iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization From: itojun@iijlab.net Date: Mon, 03 Jun 2002 09:54:54 +0900 Message-ID: <2905.1023065694@itojun.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >My guess is that it will just effectively mean people will not >use multiple prefixes for mobile nodes. i guess so too, and therefore, i don't feel a need to provide special hack in DAD. it is not a protocol issue, but an operational matter. itojun From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 2 22:12:25 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22440 for ; Sun, 2 Jun 2002 22:12:25 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA24628; Sun, 2 Jun 2002 20:12:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA08022; Sun, 2 Jun 2002 19:12:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g532BDrP015248 for ; Sun, 2 Jun 2002 19:11:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g532BDOS015247 for mobile-ip-dist; Sun, 2 Jun 2002 19:11:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g532B4rP015232; Sun, 2 Jun 2002 19:11:04 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA07924; Sun, 2 Jun 2002 19:11:05 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13223; Sun, 2 Jun 2002 20:12:10 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g5328JM11099; Sun, 2 Jun 2002 22:08:19 -0400 (EDT) Message-Id: <200206030208.g5328JM11099@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Charles E. Perkins" cc: itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-reply-to: (Your message of "Sun, 02 Jun 2002 16:58:52 PDT.") <3CFAB13C.5B1AC3B7@iprg.nokia.com> Date: Sun, 02 Jun 2002 22:08:19 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > My guess is that you are using this feature more than most IPv6 > installations. But anyway, it's not 20 or even a dozen prefixes. > Is it reasonable for us to assume that, for most links, the number > of advertised prefixes will never exceed 10? 7? any number of prefixes is probably okay as far as applications are concerned, PROVIDED that all prefixes are equally valid - i.e. any address is as good as any other, and applications aren't expected to pick the "right" prefix in order to be able to interoperate. If this condition does not hold, even two prefixes is too many. Keith From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 02:04:34 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01827 for ; Mon, 3 Jun 2002 02:04:34 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00548; Mon, 3 Jun 2002 00:04:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA07674; Sun, 2 Jun 2002 23:04:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5363orP015623 for ; Sun, 2 Jun 2002 23:03:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g5363oBM015622 for mobile-ip-dist; Sun, 2 Jun 2002 23:03:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5363lrP015615 for ; Sun, 2 Jun 2002 23:03:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA07364 for ; Sun, 2 Jun 2002 23:03:48 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28503 for ; Mon, 3 Jun 2002 00:03:47 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id PAA07540; Mon, 3 Jun 2002 15:03:46 +0900 (JST) Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA25235; Mon, 3 Jun 2002 15:03:45 +0900 (JST) Date: Mon, 03 Jun 2002 15:03:12 +0900 (JST) Message-Id: <20020603.150312.97139500.keiichi@iij.ad.jp> To: vijayd@IPRG.nokia.com Cc: jari.arkko@kolumbus.fi, hesham.soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on MIPv6 draft-17 From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <3CF666A8.D3F691F2@iprg.nokia.com> References: <3CF5915D.634A794F@iprg.nokia.com> <20020530.121237.120953247.keiichi@iij.ad.jp> <3CF666A8.D3F691F2@iprg.nokia.com> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Vijay, I think I understand what you are talking about. There are four types of CN. CN0: has no special MIP6 processing code. CN1: processes HAO only if it is protected (by IPsec). CN2: processes HAO only if it is protected (by IPsec) and accepts a BU only if it is protected (by IPsec). CN3: does RR and processes HAO if it is verified and accepts a BU if it is protected (by RR). There is a combination of CN1/CN2 and CN3 also. If we want to mandate something, we must make sure the following. for CN0: nothing. for CN1: we never change the HAO processing. For example, we never say 'IPseced HAO is not enough. Lets' obsolete it!' as we have done in the transision to ID16. for CN2: same for CN1 and, we never change BCE related processing. For example, we never change the binding update format, the routing header type 2 format, etc... for CN3: same for CN1 and CN2 and, we never change RR processing. You want to make CN2 functions mandate for all IPv6 node, don't you? Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 07:44:01 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08686 for ; Mon, 3 Jun 2002 07:44:00 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09856; Mon, 3 Jun 2002 05:39:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA17055; Mon, 3 Jun 2002 04:39:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53BcMrP016140 for ; Mon, 3 Jun 2002 04:38:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53BcMK8016139 for mobile-ip-dist; Mon, 3 Jun 2002 04:38:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53BcIrP016132 for ; Mon, 3 Jun 2002 04:38:18 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05523 for ; Mon, 3 Jun 2002 04:38:19 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09573 for ; Mon, 3 Jun 2002 05:38:18 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08340; Mon, 3 Jun 2002 07:37:48 -0400 (EDT) Message-Id: <200206031137.HAA08340@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-nat-traversal-03.txt Date: Mon, 03 Jun 2002 07:37:47 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --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 NAT/NAPT Traversal using UDP Tunnelling Author(s) : H. Levkowetz, S. Vaarala Filename : draft-ietf-mobileip-nat-traversal-03.txt Pages : 31 Date : 31-May-02 Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-nat-traversal-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-nat-traversal-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020531131613.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-nat-traversal-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-nat-traversal-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020531131613.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 08:15:32 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09713 for ; Mon, 3 Jun 2002 08:15:32 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19613; Mon, 3 Jun 2002 06:10:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20903; Mon, 3 Jun 2002 05:10:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53C9rrP016268 for ; Mon, 3 Jun 2002 05:09:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53C9q3r016267 for mobile-ip-dist; Mon, 3 Jun 2002 05:09:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53C9nrP016260 for ; Mon, 3 Jun 2002 05:09:49 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20857 for ; Mon, 3 Jun 2002 05:09:49 -0700 (PDT) Received: from muminmamman.lifix.fi ([213.15.142.68]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19317 for ; Mon, 3 Jun 2002 06:09:49 -0600 (MDT) Received: from ban by muminmamman.lifix.fi with local (Exim 3.33 #1 (Debian)) id 17Eqeh-0005Hc-00 for ; Mon, 03 Jun 2002 15:09:47 +0300 Date: Mon, 3 Jun 2002 15:09:47 +0300 From: Bjorn Andersson To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: I-D ACTION:draft-ietf-mobileip-nat-traversal-03.txt Message-ID: <20020603120947.GB18944@lifix.fi> Mail-Followup-To: Bjorn Andersson , mobile-ip@sunroof.eng.sun.com References: <200206031137.HAA08340@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200206031137.HAA08340@ietf.org> User-Agent: Mutt/1.3.25i Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Mon, Jun 03 2002, at 07:37:47 -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 NAT/NAPT Traversal using UDP Tunnelling > Author(s) : H. Levkowetz, S. Vaarala > Filename : draft-ietf-mobileip-nat-traversal-03.txt > Pages : 31 > Date : 31-May-02 > Section 7, "IANA Considerations" says: Likewise, the values for the "Tunnel Request" and "Tunnel Reply" extension type fields in Section 3.1 and Section 3.2 must be assigned from the numbering space defined for Mobile IP extensions as defined in RFC 3220 [10]. For interoperability testing until values are assigned, the values 41 and 141 are suggested. Type 41 has been used for the Unsolicitated MN-FA Key Material type for quite some time. I suggest the the recommended values for interoperability testing are 51 and 151 respectively. These values have previously been used by at least three MIP implementations for interoperabilty testing. I am about to put up a web page of type and subtype numbers that have not yet been blessed by the IANA. This should ease interoperability testing. I will inform the URL to this list when I have the page done. Regards, Björn -- Björn Andersson +358 50 341 2556 Lifix Systems Oy PGP id 5AFC144B Innopoli 2, Tekniikantie 14, FIN-02150 Espoo From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 10:18:56 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14789 for ; Mon, 3 Jun 2002 10:18:56 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06949; Mon, 3 Jun 2002 07:18:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09032; Mon, 3 Jun 2002 07:18:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53EGurP016555 for ; Mon, 3 Jun 2002 07:16:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53EGut6016554 for mobile-ip-dist; Mon, 3 Jun 2002 07:16:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53EGrrP016547 for ; Mon, 3 Jun 2002 07:16:53 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27697 for ; Mon, 3 Jun 2002 07:16:53 -0700 (PDT) From: Sourajeet.Mohanty@lntinfotech.com Received: from vashiout.lntinfotech.com ([203.199.118.66]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19311 for ; Mon, 3 Jun 2002 08:16:51 -0600 (MDT) Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Build 166.1) with ESMTP id 2002060319510875:72 ; Mon, 3 Jun 2002 19:51:08 +0530 Subject: [mobile-ip] Option Length for PadN To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Date: Mon, 3 Jun 2002 19:47:07 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 06/03/2002 07:47:10 PM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 06/03/2002 07:51:08 PM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 06/03/2002 07:51:11 PM, Serialize complete at 06/03/2002 07:51:11 PM Message-ID: X-Priority: 3 (Normal) Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Option Length for PadN ---------------------------- According to "RFC2460" -> For N octets of padding, the Opt Data Len field contains the value N-2, and the Option Data consists of N-2 zero-valued octets. According to "draft-ietf-mobileip-ipv6-17" -> For N octets of padding, the Option Len field contains the value N, and the Option Data consists of N-2 zero-valued octets. Does this mean that draft-17 updates what is defined in RFC2460 ?? From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 12:14:27 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21696 for ; Mon, 3 Jun 2002 12:14:27 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29699; Mon, 3 Jun 2002 10:14:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27846; Mon, 3 Jun 2002 09:14:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53GDBrP016893 for ; Mon, 3 Jun 2002 09:13:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53GDAa6016892 for mobile-ip-dist; Mon, 3 Jun 2002 09:13:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53GD6rP016883 for ; Mon, 3 Jun 2002 09:13:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27381 for ; Mon, 3 Jun 2002 09:13:07 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04856 for ; Mon, 3 Jun 2002 10:13:06 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g53GD5mG021642; Mon, 3 Jun 2002 18:13:05 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jun 2002 18:13:05 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF05380498BAE2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Jari Arkko , "Hesham Soliman (ERA)" Cc: "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] comments on MIPv6 draft-17 Date: Mon, 3 Jun 2002 18:12:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: However, there are other types of attacks. For instance, > > I could visit your office and install a BCE at some CN > > that claims your PC is somewhere else. > > > > => Not if my HA tunnels the HOT message securely > > to me. That's one of the reasons I was suggesting > > a MUST for ESP tunnelling of HOT messages. > > Does that answer your attack scenario? > > > Yes, partially. > > But if your office has just one LAN, an ESP tunnel between > the HA and the MN will not help, as the CN's packets will > be arriving in cleartext on that LAN. => Sure, but this falls into the 'CN-HA path vulnerability' domain. > > Yes. So, if I'm on your home LAN or on the CN-hA > path for a small amount of time and there is no > limit on the BCE lifetimes, I'll install a BCE > that redirects your traffic to, say, my server > at some other location. > => Sure, what you're saying though is that on top of being on the CN-HA path, the attacker will also have an associate somewhere else that will get the COT message (and send COTI perhaps) then receive the HOT message contents and sends the BU. It's certainly possible if you're on the CN-HA path. A bit of a long shot but possible. So it seems like 2 things should be done: 1. Agree on the seriousness of these attacks 2. Decide whether 5 min is an appropriate value. Personally I see little difference between 5 and 10 min (in terms of the seriousness of the attack) but better performance gains. There is more danger, I think, in allowing more BUs during the 5 min. > > => I'm not sure I understand what you mean. > > My concern was that there will be overlapping > > lifetimes for the nonces and the CN's keys > > for the different BCEs. So it wasn't a question > > of lack of memory, but rather the frequency > > of generating new keys and remembering which > > keys are valid for which BCE. But after I > > thought about it some more, I realised that > > it's probably not a big issue. > > > If you have a suggestion on how this could be made > clearer for implementers, it would be very useful. => OK, I'll try to send some text. Cycles are a problem this week. > > => Yes it is for the benefit of the MN. It > > makes the protocol more secure. Especially > > against attackers on the MN's link. > > But I don't understand the relation between > > 'good for the MN only and not other nodes' > > and the 'SHOULD'. I might just need some > > coffee :) but it sounds like you're saying > > that being good for the MN alone does not > > justify a MUST. > > > Something that prevents bad things from happening > to other nodes would be a sufficient condition for > a MUST. There might of course be other reasons to > make something a MUST, such as a security advantage > for the node in question. I suppose it's a judgement > call in this case. The earlier debate showed that > people had different opinions about this particular > situation. => I think I missed that debate :(, anyway FWIW, I think all RR messages must be encrypted by the HA. > > => Well, I suppose create if it doesn't already > > have it. I guess, except for the IP address > > of the MN, everything else can be copied, right? > > > I'm a bit uneasy on spending too much effort on us > creating lots of IPsec SAs in some dynamic fashion. > Could be easier to just require that these SAs exist, > and have been manually configured. => It is more flexible to have dynamic creation, for renumbering/multihoming ...etc. The HA has to create SAs/policies dynamically anyway for the CoA. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 12:17:14 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21761 for ; Mon, 3 Jun 2002 12:17:13 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17715; Mon, 3 Jun 2002 10:18:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10249; Mon, 3 Jun 2002 09:17:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53GGWrP016979 for ; Mon, 3 Jun 2002 09:16:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53GGWbx016978 for mobile-ip-dist; Mon, 3 Jun 2002 09:16:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53GGSrP016964; Mon, 3 Jun 2002 09:16:28 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28661; Mon, 3 Jun 2002 09:16:29 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01115; Mon, 3 Jun 2002 10:16:28 -0600 (MDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g53GG8g5061792; Mon, 3 Jun 2002 12:16:09 -0400 Received: from d03nm801.boulder.ibm.com (d03nm801.boulder.ibm.com [9.17.194.244]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g53GEue133338; Mon, 3 Jun 2002 10:15:10 -0600 Subject: Re: [mobile-ip] Option Length for PadN To: Sourajeet.Mohanty@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com, owner-mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Mon, 3 Jun 2002 09:10:37 -0700 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 5.0.9 |November 16, 2001) at 06/03/2002 10:15:40 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: No, that seems to be a mistake in the draft. In the section 6.2.1, it is clear that the value is N-2. But all examples after that use the wrong value. - KK Sourajeet.Mohanty@lntinf otech.com To: mobile-ip@sunroof.eng.sun.com Sent by: cc: owner-mobile-ip@sunroof. Subject: [mobile-ip] Option Length for PadN eng.sun.com 06/03/2002 07:17 AM Option Length for PadN ---------------------------- According to "RFC2460" -> For N octets of padding, the Opt Data Len field contains the value N-2, and the Option Data consists of N-2 zero-valued octets. According to "draft-ietf-mobileip-ipv6-17" -> For N octets of padding, the Option Len field contains the value N, and the Option Data consists of N-2 zero-valued octets. Does this mean that draft-17 updates what is defined in RFC2460 ?? From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 12:27:16 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22095 for ; Mon, 3 Jun 2002 12:27:15 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10102; Mon, 3 Jun 2002 09:26:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13316; Mon, 3 Jun 2002 09:26:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53GPrrP017133 for ; Mon, 3 Jun 2002 09:25:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53GPrZR017132 for mobile-ip-dist; Mon, 3 Jun 2002 09:25:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53GPorP017125 for ; Mon, 3 Jun 2002 09:25:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13068 for ; Mon, 3 Jun 2002 09:25:51 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11260 for ; Mon, 3 Jun 2002 10:25:50 -0600 (MDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g53GPaPI012791; Mon, 3 Jun 2002 09:25:36 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA00617; Mon, 3 Jun 2002 12:25:36 -0400 (EDT) Date: Mon, 3 Jun 2002 12:25:36 -0400 From: "Madhavi W. Chandra" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] RFC3012bis clarification Message-ID: <20020603122536.B578@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Charlie and Pat, Please clarify... In Section 3.2, it says... "If the Challenge extension is not removed, it MUST precede the Foreign-Home Authentication extension." Is this mandating that the challenge extension be protected by the FHAE, or is it mandating the order of the extensions? Since the following is written in Section 3.4 (HA Processing)... 'The Challenge Extension MUST be placed after the Mobile-Home authentication extension, and the *extension SHOULD be authenticated by a Foreign-Home Authentication extension*.' Since the FHAE is a SHOULD from HA processing...Section 3.2 is probably refering to the ordering of the extensions. Maybe the text can be clarified to avoid any confusion. Thanks, Madhavi From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 14:02:20 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25717 for ; Mon, 3 Jun 2002 14:02:20 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22990; Mon, 3 Jun 2002 12:03:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08186; Mon, 3 Jun 2002 11:02:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53I1ArP017741 for ; Mon, 3 Jun 2002 11:01:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53I1AIF017740 for mobile-ip-dist; Mon, 3 Jun 2002 11:01:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53I17rP017733 for ; Mon, 3 Jun 2002 11:01:07 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07549 for ; Mon, 3 Jun 2002 11:01:07 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07279 for ; Mon, 3 Jun 2002 11:01:06 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 98EF16A907; Mon, 3 Jun 2002 21:00:50 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C1B096A906; Mon, 3 Jun 2002 21:00:48 +0300 (EEST) Message-ID: <3CFBAF18.8050805@kolumbus.fi> Date: Mon, 03 Jun 2002 21:02:00 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Krishna Kumar Cc: Sourajeet.Mohanty@lntinfotech.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Option Length for PadN References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Section 6.2. deals with mobility options, not hop-by-hop or destination options. Nevertheless, the text is inconsistent and the length field of N-2 should be used. Corrected text for draft 18 will be found in Sections 6.2.3 to 6.2.7. Assigned issue #24 and tagged it as 'Adopted'. Jari Krishna Kumar wrote: > No, that seems to be a mistake in the draft. In the section 6.2.1, it is > clear that > the value is N-2. But all examples after that use the wrong value. > > - KK > > > > > Sourajeet.Mohanty@lntinf > otech.com To: mobile-ip@sunroof.eng.sun.com > Sent by: cc: > owner-mobile-ip@sunroof. Subject: [mobile-ip] Option Length for PadN > eng.sun.com > > > 06/03/2002 07:17 AM > > > > > > Option Length for PadN > ---------------------------- > > According to "RFC2460" -> > For N octets of padding, the Opt Data Len field contains the value N-2, and > the Option Data > consists of N-2 zero-valued octets. > > According to "draft-ietf-mobileip-ipv6-17" -> > For N octets of padding, the Option Len field contains the value N, and the > Option > Data consists of N-2 zero-valued octets. > > Does this mean that draft-17 updates what is defined in RFC2460 ?? > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 14:11:16 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25961 for ; Mon, 3 Jun 2002 14:11:15 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13663; Mon, 3 Jun 2002 11:10:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11703; Mon, 3 Jun 2002 11:10:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53I9nrP017878 for ; Mon, 3 Jun 2002 11:09:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53I9nGR017877 for mobile-ip-dist; Mon, 3 Jun 2002 11:09:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53I9YrP017840; Mon, 3 Jun 2002 11:09:34 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21517; Mon, 3 Jun 2002 11:09:34 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12766; Mon, 3 Jun 2002 11:09:32 -0700 (PDT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g53I71624842; Tue, 4 Jun 2002 01:07:01 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Charles E. Perkins" cc: itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, IPng Working Group , Dave Thaler Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-Reply-To: <3CFABA06.79CF83E4@iprg.nokia.com> References: <3CFABA06.79CF83E4@iprg.nokia.com> <2625.1023063809@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Jun 2002 01:07:01 +0700 Message-ID: <24840.1023127621@munnari.OZ.AU> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Date: Sun, 02 Jun 2002 17:36:22 -0700 From: "Charles E. Perkins" Message-ID: <3CFABA06.79CF83E4@iprg.nokia.com> | Do you still think that is true if the mobile node has to send | out 10, or some unbounded number, of Binding Updates each time it | changes its care-of address? Can't speak for itojun, but I would. I assume these could all be combined into one packet (not being a MIP person) - if not, why not? | It has been my understanding that a home agent, charged with | the protocol responsibility for defending the addresses of 4,095 | mobile nodes (or, say, 500,000 for some cellular plans), would | effectively disable the ability of mobile nodes to use multiple | prefixes, because equipment vendors would just "say no" if they | thought only a few mobile nodes would use this feature. That may be, many nodes of that type (where there are huge numbers connected to one HA) may quite likely only be offered one prefix. The router config at the home base will make that choice. | My guess is that it will just effectively mean people will not | use multiple prefixes for mobile nodes. Probably true. So what? Other mobile nodes will still use multiple prefixes (the HA that I would be dealing with would perhaps be coping with a half dozen mobile nodes at any one time .. .I think it could cope with my few prefixes). And since all this is related, from an earlier message of yours ... charliep@iprg.nokia.com said: | Even manually configured global addresses should be required to | acquire rights to the corresponding link-local address. Why not? Simple. There is no requirement that a node configure an address from every available prefix. (See above for a reason why some modes might choose not to). And, there's no reason at all why if a link has prefix1::/64 and prefix2::/64 assigned to it, I shouldn't be able to manually configure prefix1::1/128 as the address of one node, and prefix2::1/128 as the address of an entirely different node. They cannot both claim fe80::1 In some cases doing this might be the reason for adding a new prefix to a link - if I have a system with a well known address (prefix1::1) and I want to move it to a link that is currently prefix2::/64 and where prefix2::1 is already allocated, I might choose to assign prefix1::/64 to this link (perhaps disable auto-config of addresses in that prefix, or perhaps not) just so my node can keep using the well known address it has become accustomed to (as much as I hate well known addresses, I know this kind of thing will happen). The argument for going from a link-local which has had DAD performed upon it, to allowing auto-config from the same IID using other prefixes has some attraction, though it really doesn't seem to work at all in the multi-link prefix cases (and no, changing link local to become subnet local is not the way out of this). But going the other way, and requiring link local to every wider scope address is simply impossible, no matter how much easier that might make life for home agents. kre ps: don't we already have a way to tell from RAs which prefix is multi-link and which is not (because it matters to whether we send packets to routers of just do ND for them?). If so, we can use that to solve the DAD optimisation problem can't we? That is, simply prohibit DAD optimisation for multi-link prefixes. If we don't currently have such a method, there are still spare bits in the RA that can easily be used to mark a prefix as multi-subnet and hence ban DAD optimisation for it. From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 14:33:40 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26764 for ; Mon, 3 Jun 2002 14:33:40 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13421; Mon, 3 Jun 2002 12:35:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22448; Mon, 3 Jun 2002 11:33:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53IWbrP018125 for ; Mon, 3 Jun 2002 11:32:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53IWbqI018124 for mobile-ip-dist; Mon, 3 Jun 2002 11:32:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53IWYrP018117; Mon, 3 Jun 2002 11:32:34 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09844; Mon, 3 Jun 2002 11:32:34 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10390; Mon, 3 Jun 2002 11:32:34 -0700 (PDT) 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 LAA28004; Mon, 3 Jun 2002 11:32:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g53IWSH10437; Mon, 3 Jun 2002 11:32:28 -0700 X-mProtect: <200206031832> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEZpYM0; Mon, 03 Jun 2002 11:32:25 PDT Message-ID: <3CFBB63A.30DCB2E9@iprg.nokia.com> Date: Mon, 03 Jun 2002 11:32:26 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Robert Elz CC: mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <3CFABA06.79CF83E4@iprg.nokia.com> <2625.1023063809@itojun.org> <24840.1023127621@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Robert Elz wrote: > | My guess is that it will just effectively mean people will not > | use multiple prefixes for mobile nodes. > > Probably true. So what? Other mobile nodes will still use > multiple prefixes (the HA that I would be dealing with would perhaps > be coping with a half dozen mobile nodes at any one time .. .I think > it could cope with my few prefixes). No doubt that many IPv6 networks will have only a few nodes, and many will have only a few prefixes. My questions were related whether that model should be our design goal. > And since all this is related, from an earlier message of yours ... > > charliep@iprg.nokia.com said: > | Even manually configured global addresses should be required to > | acquire rights to the corresponding link-local address. Why not? > > Simple. ...?... > There is no requirement that a node configure an address from every > available prefix. (See above for a reason why some modes might choose > not to). I was by no means suggesting that a node should configure an address from every available prefix. > And, there's no reason at all why if a link has prefix1::/64 and > prefix2::/64 assigned to it, I shouldn't be able to manually configure > prefix1::1/128 as the address of one node, and prefix2::1/128 as the > address of an entirely different node. > > They cannot both claim fe80::1 Exactly -- and I am suggesting that there are enough IPv6 addresses available so that there is no motivation to support the use of prefix{1,2}::1 for two different nodes on the same link. Maybe one of them could find a different interface ID. I didn't yet see why enabling the behavior you suggest has any advantages. > In some cases doing this might be the reason for adding a new prefix > to a link - if I have a system with a well known address (prefix1::1) > and I want to move it to a link that is currently prefix2::/64 and > where prefix2::1 is already allocated, I might choose to assign > prefix1::/64 to this link (perhaps disable auto-config of addresses > in that prefix, or perhaps not) just so my node can keep using the well > known address it has become accustomed to (as much as I hate well known > addresses, I know this kind of thing will happen). Honestly, I think IPv6 would be better off by prohibiting this behavior. > But going the other way, and requiring link local to every wider scope > address is simply impossible, no matter how much easier that might make > life for home agents. Either I didn't understand this, or I don't see why it's impossible. Actually, I was only concerned with global scope and site-local scope. Is the only roadblock the desire to maintain an interface ID when moving a node to a new subnet? > ps: don't we already have a way to tell from RAs which prefix is multi-link > and which is not (because it matters to whether we send packets to routers > of just do ND for them?). If so, we can use that to solve the DAD > optimisation problem can't we? That is, simply prohibit DAD optimisation > for multi-link prefixes. If we don't currently have such a method, there > are still spare bits in the RA that can easily be used to mark a prefix as > multi-subnet and hence ban DAD optimisation for it. This solution works for me, I guess because I don't see any driving need to put home agents on multi-link subnets. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 14:47:13 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27212 for ; Mon, 3 Jun 2002 14:47:13 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16908; Mon, 3 Jun 2002 12:47:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28725; Mon, 3 Jun 2002 11:47:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53Ik9rP018283 for ; Mon, 3 Jun 2002 11:46:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53Ik8tq018282 for mobile-ip-dist; Mon, 3 Jun 2002 11:46:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53Ik5rP018275; Mon, 3 Jun 2002 11:46:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05246; Mon, 3 Jun 2002 11:46:05 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08957; Mon, 3 Jun 2002 12:46:05 -0600 (MDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 3 Jun 2002 11:46:04 -0700 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 03 Jun 2002 11:46:04 -0700 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 3 Jun 2002 11:46:04 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 3 Jun 2002 11:46:04 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Mon, 3 Jun 2002 11:46:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] RE: RFC 2462 DAD optimization Date: Mon, 3 Jun 2002 11:46:03 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1047CF14D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [mobile-ip] RE: RFC 2462 DAD optimization Thread-Index: AcILKdMWC7Yd1V5NTs2H+SufA1CfeAABE90w From: "Dave Thaler" To: "Robert Elz" , "Charles E. Perkins" Cc: , , "IPng Working Group" X-OriginalArrivalTime: 03 Jun 2002 18:46:03.0977 (UTC) FILETIME=[E9DCFB90:01C20B2E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g53Ik5rQ018276 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Robert Elz writes: > ps: don't we already have a way to tell from RAs which prefix is multi- > link > and which is not No. In fact, I would expect that if any prefix is multilink, then all of them should be. > (because it matters to whether we send packets to routers > of just do ND for them?). There is a bit that says whether to send packets to routers or just do ND for them, which is probably what you're thinking of. However, a multilink subnet can work either way (see section 4.1 of the multilink draft), so that bit doesn't tell you anything about whether you're on a multilink subnet. > If so, we can use that to solve the DAD > optimisation problem can't we? That is, simply prohibit DAD optimisation > for multi-link prefixes. If we don't currently have such a method, there > are still spare bits in the RA that can easily be used to mark a prefix as > multi-subnet and hence ban DAD optimisation for it. My preference is that we just ban DAD optimization in all cases. -Dave From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 16:50:06 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00534 for ; Mon, 3 Jun 2002 16:50:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06296; Mon, 3 Jun 2002 14:51:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08587; Mon, 3 Jun 2002 13:50:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53KnCrP018594 for ; Mon, 3 Jun 2002 13:49:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53KnCsV018593 for mobile-ip-dist; Mon, 3 Jun 2002 13:49:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53Kn8rP018586 for ; Mon, 3 Jun 2002 13:49:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19300 for ; Mon, 3 Jun 2002 13:49:08 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05527 for ; Mon, 3 Jun 2002 14:50:15 -0600 (MDT) 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 NAA05071; Mon, 3 Jun 2002 13:49:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g53Kn7A15021; Mon, 3 Jun 2002 13:49:07 -0700 X-mProtect: <200206032049> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdn9VptV; Mon, 03 Jun 2002 13:49:05 PDT Message-ID: <3CFBD641.7CED3052@iprg.nokia.com> Date: Mon, 03 Jun 2002 13:49:05 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Samita Chakrabarti CC: jari.arkko@kolumbus.fi, hesham.soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on MIPv6 draft-17 References: <200206010204.g5124J6U597926@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Samita Chakrabarti wrote: > Agree. Without having ESP tunnel mode for both > HOT/HOTI, the HOA is prone to hijacking. I am > not able to understand the logic behind having > optional ESP tunnel mode for HOT message. > This leaves a security hole in the protocol. If a MN can send > HOTI message in ESP tunnel mode, then it should > be able to process incoming HOT message in > ESP tunnel mode. > > Besides, making it optional means more complicated > implemenation on MN (and HA) and more lines of unnecessary code. > > I am not able to see any merrit of having ESP tunnel > mode optional in HOT path. Making ESP tunnel bidirectional > for both HOTI/HOT seems simple, secure and reasonable > from the protocol perspective. lets assume there is a link layer encryption between the MN and the access router/access point. having an ESP header in this situation is an overhead. the assumption here is that the MN's public link is the most vulnerable. the spec currently says MUST implement. this takes care of interop issues. but the MN/HA can chose not to use it when the MN visits certain environments. for easier implementation, I did suggest a flag in the home registration BU. the MN, through this flag could turn on/off the ESP tunnel whenever it wants. but others in the list felt that it is best done through the IPsec SPD (which was fine with me). Vijay ps: I hope we dont start opening issues that are already closed. what we are discussing here is issue #14. please see the discussion on issue #14. From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 17:01:34 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00894 for ; Mon, 3 Jun 2002 17:01:29 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23543; Mon, 3 Jun 2002 14:01:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13848; Mon, 3 Jun 2002 14:00:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53L06rP018697 for ; Mon, 3 Jun 2002 14:00:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53L06ai018696 for mobile-ip-dist; Mon, 3 Jun 2002 14:00:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53L03rP018689 for ; Mon, 3 Jun 2002 14:00:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10605 for ; Mon, 3 Jun 2002 14:00:03 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA27814 for ; Mon, 3 Jun 2002 15:00:01 -0600 (MDT) 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 OAA05505; Mon, 3 Jun 2002 14:00:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g53Kxxs25283; Mon, 3 Jun 2002 13:59:59 -0700 X-mProtect: <200206032059> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtIcNeL; Mon, 03 Jun 2002 13:59:56 PDT Message-ID: <3CFBD8CC.B8BBEAF8@iprg.nokia.com> Date: Mon, 03 Jun 2002 13:59:56 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: keiichi@iij.ad.jp CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on MIPv6 draft-17 References: <3CF5915D.634A794F@iprg.nokia.com> <20020530.121237.120953247.keiichi@iij.ad.jp> <3CF666A8.D3F691F2@iprg.nokia.com> <20020603.150312.97139500.keiichi@iij.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Keiichi SHIMA / $BEg7D0l(B wrote: > > Hi Vijay, > > I think I understand what you are talking about. There are four types > of CN. > > CN0: has no special MIP6 processing code. > CN1: processes HAO only if it is protected (by IPsec). > CN2: processes HAO only if it is protected (by IPsec) > and accepts a BU only if it is protected (by IPsec). > CN3: does RR > and processes HAO if it is verified > and accepts a BU if it is protected (by RR). > > There is a combination of CN1/CN2 and CN3 also. you are right. for example something like CN2 and CN3. > > If we want to mandate something, we must make sure the following. > > for CN0: nothing. > for CN1: we never change the HAO processing. > For example, we never say 'IPseced HAO is not enough. > Lets' obsolete it!' as we have done in the transision to ID16. > for CN2: same for CN1 and, > we never change BCE related processing. > For example, we never change the binding update format, > the routing header type 2 format, etc... > for CN3: same for CN1 and CN2 and, > we never change RR processing. I am bit uncomfortable using the term 'never'. but I am reasonably sure that these wont change. I dont know who can give you that guarantee. > > You want to make CN2 functions mandate for all IPv6 node, don't you? yes. but in addition I would also like CN3 mandated. RR can only improve from now on. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 17:31:18 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01801 for ; Mon, 3 Jun 2002 17:31:16 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08626; Mon, 3 Jun 2002 14:30:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21413; Mon, 3 Jun 2002 14:30:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53LThrP018828 for ; Mon, 3 Jun 2002 14:29:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53LThXV018827 for mobile-ip-dist; Mon, 3 Jun 2002 14:29:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53LTerP018820 for ; Mon, 3 Jun 2002 14:29:40 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10809 for ; Mon, 3 Jun 2002 14:29:40 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26440 for ; Mon, 3 Jun 2002 14:29:39 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id DDA3C6A906; Tue, 4 Jun 2002 00:29:32 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BA2EB6A901; Tue, 4 Jun 2002 00:29:29 +0300 (EEST) Message-ID: <3CFBE001.2080905@kolumbus.fi> Date: Tue, 04 Jun 2002 00:30:41 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Krishna Kumar Cc: Basavaraj.Patil@nokia.com, PRoberts@MEGISTO.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: MIPv6 - 17 Review (Fixed tabs, please ignore earlier mail) References: <200205300104.g4U14w319947@eng2.beaverton.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Many thanks Krishna for your in-depth review! Filed the technical and editorial issues as #40 and #41, then created #42 and #43 for two of the technical issues that may be perhaps best discussed separately. Comments inline below: > 1. Section 6.1.3 : The Header Len value is incorrect if the option is present. > According to the draft, the size would be 2 + size of mobility options in > 8 octets = 2 + 1 = 3. In reality, the packet would be 12 bytes long till the > options, and since the UID aligns at offset of 2n (and 12 happens to be a > multiple of 2n), the UID option will fit right at the end of the Message Data > field of the MH. So total length is 12 + 4 = 16 bytes = 2 (and not 3). The > draft should definitely change the statement to something like : > > "The Header Length field in the Mobility Header for this message MUST be > set to 12 bytes + the length of padding if necessary before possible > options + the total length of all mobility options present, divided by 8, > to give a value in units of 8. If no actual options are present in this > message, 4 bytes of padding is necessary." Yes. You know, maybe it's best if we delete the length discussion from the individual messages, given that it is already described in the definition of Mobility Header itself. I'll clarify the treatment of padding there as well. (It may make sense to still mention how much padding is needed if no options are present.) > 2. Section 6.1.4 : Same as #1 above. Yes. > Section 6.1.8 happens to be correct in this respect due to following > magic : > a. different alignment of option, AND > b. different length of the option. (2 bytes extra in both > adding to 4 bytes). > > 3. Section 6.1.7 : > > Clarify in following para, that the address is the Home Address : > > "When a packet contains both a Home Address destination option and a > Binding Update message, the sender MUST use the same *home* address > in both." Yes. > 4. Section 6.1.8 : > > In the third last para, the following line : > > "If no actual options are present in this message, 4 bytes of Pad1 or > PadN mobility options are needed" > > The " 4 bytes of Pad1 or" should be removed, since Section 6.2.2 > prohibits using multiple Pad1 options. Fixed. > 5. Section 6.2.3 : > > "For N octets of padding, the Option Len field contains the value N , > and the Option Data consists of N-2 zero-valued octets." > > should be changed to : > > "For N octets of padding, the Option Len field contains the value N - 2, > and the Option Data consists of N-2 zero-valued octets." > > This is as per description of Option Len in 6.2.1. Fixed, see also issue #24 that was brought up later. > 6. Section 6.2.4 : > > "2 4 Unique Identifier" should be change to "2 2 Unique Identifier". > > 7. Section 6.2.5 : > > "3 18" should be changed to "3 16" > > 8. Section 6.2.6 : > > "4 6" should be changed to "4 4" > > 9. Section 6.2.7 : > > "5 2 + Len" should be changed to "5 Len" > And > subsequent reference to "2 + Len" should be changed to "Len". Done, all of the above. > 10. Section 6.8 : Under description of "Destination Address" : > > "Otherwise, the mobile node's home address SHOULD be used." > > Why is that so ? This is unsolicited Prefix Advertisement, so how can > the Home Agent find this home address if it is not registered with it (and > thus not present in the binding cache) ? And this also conflicts with the > first sentence in this section anyway, "A home agent will send a Mobile > Prefix Advertisement message to a mobile node to distribute prefix information > about the home link while the mobile node is traveling away from the home > network." > > Shouldn't this be removed ? It does appear to be so. Other mechanisms work on the home link, and when the mobile node is away, we really need to use either the source or the care of address. > 11. Section 7.5 : > > - MinRtrAdvInterval 0.05 seconds > - MaxRtrAdvInterval 1.5 seconds > > This interval is too long, a range of 30 times. If the router is using > 1.5 seconds (using Advertisement Interval Option), the MN may need a very > long time to register the fact that it has moved, probably having to miss > a few of these router advertisements. I think suggested values should be > in the range of 0.05 to 0.25 seconds at the most, implementors are welcome > to increase this if they want, but Mobile Specs should be more stringent > on smooth handoff. Ok - but how do other folks see this? Filed this as a separate issue #42 for better separation of the discussions. > 12. Section 8.1 : > > There has been some discussion on this, but I don't know what the final > consensus is. But I feel that the first "MUST" for processing Home > Address option should be changed to "SHOULD". If the node is processing this > option, it should have a Binding Cache (since the MN would have sent > this option only after establishing a Binding Cache). Since the third point > is using "SHOULD", this one too should use "SHOULD". Making all three a > "MUST" might be restricting some implementation of special mobile devices, > which might not need the full functionality, eg a MN which is going to > interact with a CN, and never with another MN (this is the scenario where the > second bullet is not applicable). We have another issue #22 and on ongoing discussion about this... > 13. Section 9.1 : Remove the two bullets under : > > "- A flag indicating whether or not this Binding Cache entry represents > a mobile node" ... > AND > " - The length of the routing prefix for the home address. This" ... > > Both of these have been removed since draft 14/15 or so. The second one need > not be replaced with the 'S' bit flag, since the implementation of the 'S' > bit would create multiple entries in the binding cache anyway. Hence both of > these can be removed. Ok. Done. > 14. Section 9.4.5 : The last sentence of the second para should be changed to : > > "When the mobile node receives a packet from some sender containing a Binding > Refresh Request option, it MUST confirm that a binding exists in it's BUL for > this sender, and then it MAY start a return routability procedure, if > necessary, before sending its current binding and a new lifetime in a new > Binding Update. Ok. > 15. Section 10.2 : The 4th bullet is confusing to me. > > It looks like a BU to HA MUST have both BU as well as a Home Address option, > while to a CN, the BU MUST NOT have the Home Address option. I guess this was > a subject of debate on the mailing list, but I didn't follow it if it happened. > Is this a conscious decision to have two Home Addresses when sending to HA, and > is it really necessary ? This relates to issue #10. > 16. Section 10.2 : The 5th bullet should be changed to : > > "This ensures that no other node on the home link was using the mobile node's > home address when the Binding Update arrived". Ok. > 17. Section 10.2 : The 5th bullet needs another modification : > > "When the home agent sends a successful Binding Acknowledgement to the mobile > node, in response to a Binding Update with the `D' bit set, the home agent > assures to the mobile node that its home address will continue to be kept > unique by the home agent at least as long as the lifetime granted for that > home address binding is not over, or while the mobile node transmits Binding > Updates with new care-of addresses for that home address. Hmm... I think we can skip the part after "or while". Those are binding updates too, and the first part applies. > 18. Section 10.2 : The para about 'S' bit should be changed to : > > "The set of such home addresses is formed by replacing the routing prefix for > the given home address with all other routing prefixes *on the mobile node's > home link* that are supported by the home agent processing the Binding Update. Ok > 19. Section 10.2 : The para about : > > "- The Refresh field MUST be set to a value less than or equal to" > > Is Refresh useful at all ? I don't believe it is. It seems to imply that it > helps in the case of the Home Agent crashing and has only a volatile storage > for the binding cache. But if the Home Agent crashed before the Refresh > interval is over, the behaviour is identical to the case where the Refresh > field contains the same value as Lifetime. > > It will be useful only if the HA crashed after the Refresh interval but before > the Lifetime interval. Hence it is completely useless in most situations. > > If this can be removed safely, all references need to be removed in the > draft and the Format of the BU section (6.1.8) needs to reflect this. How do others feel about this? Assigned a separate issue #43. > 20. Section 10.4 : The first bullet is slightly wrong. It should say : > > "- The home agent examines the value of the `S' bit in the new "home > registration" Binding Update Packet. If this bit is nonzero," ... > > The HA has just got a BU packet from MN, and the Binding Cache entry did > not exist. Also the Binding Cache doesn't contain a 'S' bit field. We should > specify that the HA looks at the BU packet and not the BC entry. Yes. > 21. Section 10.4 : Part of the last para should be changed to : > > "In addition, the Router (R) bit in the Advertisement MUST be set to zero. > Acting as a proxy ....". Ok > 22. Section 10.5 : First sentence of the second para should be changed to : > > "While the mobile node is away from home and this node is acting as the > mobile node's home agent, the home agent intercepts any packets on the > home link addressed to the mobile node's home address (including addresses > formed from other on-link prefixes, if the 'S' bit was zero in the Binding > Update), as described in Section 10.4." > > Prefix Len is removed. Ok. > 23. Section 11.2.3 : > > "- The segments left field in the RH is either 0 or 1." > > This should be 1 since that is the value set. Also, section 6.4.1 confirms > that. This has been separately discussed. Are you happy with Erik's clarification? > 24. Section 11.6.2 : Do we need to mention that the binding to CN be done > only after getting a success BA from the HA. I am referring to : > > "When a mobile node sends a Binding Update to its home agent to register a new > primary care-of address (as described in Section 11.6.1), the mobile node SHOULD > also start a return routability procedure to each other node for which an entry > exists in the mobile node's Binding Update List, as detailed below. Upon > successful return routability procedure, a Binding Update message is sent." ... > > The last sentence could be changed to : > > "Upon successful return routability procedure and after receiving a successful > Binding Acknowledgement from the Home Agent, a Binding Update message is sent > to all other nodes". Sounds good. > 25. Section 11.6.2 : When the BU packet is formed, should it be specified that > a Home Address option MUST NOT be included ? This is relevant to my comment > on item #15. Latest discussion points to that HAO must be included. > 26. Section 11.6.4 : In the second last para, the last sentence should be changed > to : > > "In this case, the mobile node instead SHOULD return a Binding Update to > the sender, in which the Lifetime field is set to zero and the care-of > address (using a Alternate Care-Of Address option) is set to the mobile > node's home address." > > The source address cannot be set to the Home Address due to ingress filtering, > and this should be made more clear. Ok. > 27. Section 11.6.7 : The last sentence of the second para should include some > re-transmission policy in case the NS is lost. Otherwise the MN cannot > send a BU to the Home Agent after returning to the Home Network. Some > values need to be specified for timeout and number of retransmissions before > the MN can assume that the Home Agent is dead (and possibly continue using > it's home address and also continue to finish the returning home procedure). I've been assuming regular NS retransmission would apply. Should we clarify that, is that somehow not possible? > *********************************** Typos ************************************ > > (1-12 snipped) Thanks, fixed! Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 17:46:51 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02238 for ; Mon, 3 Jun 2002 17:46:38 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00535; Mon, 3 Jun 2002 15:46:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28858; Mon, 3 Jun 2002 14:46:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53LjjrP018929 for ; Mon, 3 Jun 2002 14:45:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53LjjW9018928 for mobile-ip-dist; Mon, 3 Jun 2002 14:45:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53LjgrP018921 for ; Mon, 3 Jun 2002 14:45:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28554 for ; Mon, 3 Jun 2002 14:45:42 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19342 for ; Mon, 3 Jun 2002 15:45:41 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 4D8576A906; Tue, 4 Jun 2002 00:45:40 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 94AEE6A901; Tue, 4 Jun 2002 00:45:38 +0300 (EEST) Message-ID: <3CFBE3CA.1020008@kolumbus.fi> Date: Tue, 04 Jun 2002 00:46:50 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli Subject: [mobile-ip] 'S' bit and address defense issues Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Vijay has reformulated issues related to the 'S' bit and the HA's defense of home addresses in a new way. (Thanks, Vijay!) The old issues were #23 and #30. The new issues can be found from the following links. http://www.piuha.net./~jarkko/publications/mipv6/issues/issue38.txt http://www.piuha.net./~jarkko/publications/mipv6/issues/issue39.txt I think the proposals look very reasonable. Do folks agree? Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 18:10:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02720 for ; Mon, 3 Jun 2002 18:10:36 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18933; Mon, 3 Jun 2002 16:11:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09374; Mon, 3 Jun 2002 15:10:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53M9erP019028 for ; Mon, 3 Jun 2002 15:09:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53M9ePf019027 for mobile-ip-dist; Mon, 3 Jun 2002 15:09:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53M9brP019020 for ; Mon, 3 Jun 2002 15:09:37 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25908 for ; Mon, 3 Jun 2002 15:09:37 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17238 for ; Mon, 3 Jun 2002 15:09:37 -0700 (PDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 029F15559; Mon, 3 Jun 2002 18:09:37 -0400 (EDT) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id E5247113D; Mon, 3 Jun 2002 15:09:35 -0700 (PDT) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g53M9ZE11857; Mon, 3 Jun 2002 18:09:35 -0400 (EDT) Received: from hp.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id SAA0000003372; Mon, 3 Jun 2002 18:09:34 -0400 (EDT) Message-ID: <3CFBE91D.8080401@hp.com> Date: Mon, 03 Jun 2002 18:09:33 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Cc: "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli Subject: Re: [mobile-ip] 'S' bit and address defense issues References: <3CFBE3CA.1020008@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all I have a problem with the solution to issue 39. As has been discusses for a while on both IPv6 and Mobile IP lists, the posession of a non link-local address does not gurantee posession of link-local address. We can't gurantee that the waste on the HA will be all that small. My proposal (which was slightly mis-stated) removes any waste at all. The proposal is to define a bit in the BU message (lets call it 'L'). The bit will be set to 1 when the HOA contains the address to be used to form the link-local address. The link-local address generation will happen as discribed in issues 38 and 39. There are no additional options (all we do is reserver a bit). -vlad Jari Arkko wrote: > Hi, > > Vijay has reformulated issues related to the 'S' bit and > the HA's defense of home addresses in a new way. (Thanks, > Vijay!) The old issues were #23 and #30. The new issues > can be found from the following links. > > http://www.piuha.net./~jarkko/publications/mipv6/issues/issue38.txt > http://www.piuha.net./~jarkko/publications/mipv6/issues/issue39.txt > > I think the proposals look very reasonable. Do folks agree? > > Jari > > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 18:43:35 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03278 for ; Mon, 3 Jun 2002 18:43:34 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27470; Mon, 3 Jun 2002 16:43:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07287; Mon, 3 Jun 2002 15:43:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53MgurP019178 for ; Mon, 3 Jun 2002 15:42:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g53Mguk3019177 for mobile-ip-dist; Mon, 3 Jun 2002 15:42:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g53MgrrP019170 for ; Mon, 3 Jun 2002 15:42:53 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07074 for ; Mon, 3 Jun 2002 15:42:54 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24175 for ; Mon, 3 Jun 2002 16:42:53 -0600 (MDT) 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 PAA11339; Mon, 3 Jun 2002 15:42:53 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g53Mgqi27302; Mon, 3 Jun 2002 15:42:52 -0700 X-mProtect: <200206032242> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFMxvjv; Mon, 03 Jun 2002 15:42:50 PDT Message-ID: <3CFBF0EA.3888DFE5@iprg.nokia.com> Date: Mon, 03 Jun 2002 15:42:50 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: Jari Arkko , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] 'S' bit and address defense issues References: <3CFBE3CA.1020008@kolumbus.fi> <3CFBE91D.8080401@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vladislav Yasevich wrote: > My proposal (which was slightly mis-stated) removes any waste > at all. The proposal is to define a bit in the BU message > (lets call it 'L'). The bit will be set to 1 when the HOA > contains the address to be used to form the link-local address. > The link-local address generation will happen as discribed in issues 38 > and 39. this if fine with me. I thought your solution involved a new suboption containing the interface id. Vijay > > There are no additional options (all we do is reserver a bit). > > -vlad > > Jari Arkko wrote: > > Hi, > > > > Vijay has reformulated issues related to the 'S' bit and > > the HA's defense of home addresses in a new way. (Thanks, > > Vijay!) The old issues were #23 and #30. The new issues > > can be found from the following links. > > > > http://www.piuha.net./~jarkko/publications/mipv6/issues/issue38.txt > > http://www.piuha.net./~jarkko/publications/mipv6/issues/issue39.txt > > > > I think the proposals look very reasonable. Do folks agree? > > > > Jari > > > > > > > > -- > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead > Hewlett Packard Tel: (603) 884-1079 > Nashua, NH 03062 ZKO3-3/T07 From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 20:27:57 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04824 for ; Mon, 3 Jun 2002 20:27:57 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28255; Mon, 3 Jun 2002 17:27:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA22000; Mon, 3 Jun 2002 17:27:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g540QerP019417 for ; Mon, 3 Jun 2002 17:26:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g540QdqB019416 for mobile-ip-dist; Mon, 3 Jun 2002 17:26:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g540QZrP019409 for ; Mon, 3 Jun 2002 17:26:35 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14591 for ; Mon, 3 Jun 2002 17:26:35 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19204 for ; Mon, 3 Jun 2002 17:26:35 -0700 (PDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g540QRg5081006; Mon, 3 Jun 2002 20:26:27 -0400 Received: from gateway1.beaverton.ibm.com (gateway1.beaverton.ibm.com [138.95.180.2]) by northrelay03.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g540QNB82796; Mon, 3 Jun 2002 20:26:24 -0400 Received: from eng2.beaverton.ibm.com (eng2.beaverton.ibm.com [9.47.57.17]) by gateway1.beaverton.ibm.com (8.11.6/8.11.6) with ESMTP id g540QY923357; Mon, 3 Jun 2002 17:26:34 -0700 Received: (from kkumar@localhost) by eng2.beaverton.ibm.com (8.10.0.Beta10/8.8.5/token.aware-1.2) id g540QMD26221; Mon, 3 Jun 2002 17:26:23 -0700 (PDT) From: Krishna Kumar Message-Id: <200206040026.g540QMD26221@eng2.beaverton.ibm.com> Subject: [mobile-ip] Re: MIPv6 - 17 Review (Fixed tabs, please ignore earlier mail) To: jari.arkko@kolumbus.fi (Jari Arkko) Date: Mon, 3 Jun 2002 17:26:22 -0700 (PDT) Cc: krkumar@us.ibm.com (Krishna Kumar), Basavaraj.Patil@nokia.com, PRoberts@MEGISTO.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: <3CFBE001.2080905@kolumbus.fi> from "Jari Arkko" at Jun 03, 2002 11:30:41 PM PST X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Jari, Thanks for your comments. Regarding : 1. > > 23. Section 11.2.3 : > > > > "- The segments left field in the RH is either 0 or 1." > > > > This should be 1 since that is the value set. Also, section 6.4.1 confirms > > that. > > This has been separately discussed. Are you happy with Erik's clarification? Yes, I agree with Eric's clarification. 2. > > 27. Section 11.6.7 : The last sentence of the second para should include some > > re-transmission policy in case the NS is lost. Otherwise the MN cannot > > send a BU to the Home Agent after returning to the Home Network. Some > > values need to be specified for timeout and number of retransmissions before > > the MN can assume that the Home Agent is dead (and possibly continue using > > it's home address and also continue to finish the returning home procedure). > > I've been assuming regular NS retransmission would apply. Should we clarify that, > is that somehow not possible? You are right about that, the regular NS would handle this case and it doesn't need to be specified here. Thanks, - KK ### Jari Arkko writes : ### > > > Many thanks Krishna for your in-depth review! Filed the technical > and editorial issues as #40 and #41, then created #42 and #43 for > two of the technical issues that may be perhaps best discussed > separately. > > Comments inline below: > > > > 1. Section 6.1.3 : The Header Len value is incorrect if the option is present. > > According to the draft, the size would be 2 + size of mobility options in > > 8 octets = 2 + 1 = 3. In reality, the packet would be 12 bytes long till the > > options, and since the UID aligns at offset of 2n (and 12 happens to be a > > multiple of 2n), the UID option will fit right at the end of the Message Data > > field of the MH. So total length is 12 + 4 = 16 bytes = 2 (and not 3). The > > draft should definitely change the statement to something like : > > > > "The Header Length field in the Mobility Header for this message MUST be > > set to 12 bytes + the length of padding if necessary before possible > > options + the total length of all mobility options present, divided by 8, > > to give a value in units of 8. If no actual options are present in this > > message, 4 bytes of padding is necessary." > > > Yes. You know, maybe it's best if we delete the length discussion > from the individual messages, given that it is already described in > > the definition of Mobility Header itself. I'll clarify the treatment > > of padding there as well. (It may make sense to still mention > how much padding is needed if no options are present.) > > > > 2. Section 6.1.4 : Same as #1 above. > > > Yes. > > > > Section 6.1.8 happens to be correct in this respect due to following > > magic : > > a. different alignment of option, AND > > b. different length of the option. (2 bytes extra in both > > adding to 4 bytes). > > > > 3. Section 6.1.7 : > > > > Clarify in following para, that the address is the Home Address : > > > > "When a packet contains both a Home Address destination option and a > > Binding Update message, the sender MUST use the same *home* address > > in both." > > > Yes. > > > > 4. Section 6.1.8 : > > > > In the third last para, the following line : > > > > "If no actual options are present in this message, 4 bytes of Pad1 or > > PadN mobility options are needed" > > > > The " 4 bytes of Pad1 or" should be removed, since Section 6.2.2 > > prohibits using multiple Pad1 options. > > > Fixed. > > > > 5. Section 6.2.3 : > > > > "For N octets of padding, the Option Len field contains the value N , > > and the Option Data consists of N-2 zero-valued octets." > > > > should be changed to : > > > > "For N octets of padding, the Option Len field contains the value N - 2, > > and the Option Data consists of N-2 zero-valued octets." > > > > This is as per description of Option Len in 6.2.1. > > > Fixed, see also issue #24 that was brought up later. > > > > 6. Section 6.2.4 : > > > > "2 4 Unique Identifier" should be change to "2 2 Unique Identifier". > > > > > 7. Section 6.2.5 : > > > > "3 18" should be changed to "3 16" > > > > 8. Section 6.2.6 : > > > > "4 6" should be changed to "4 4" > > > > 9. Section 6.2.7 : > > > > "5 2 + Len" should be changed to "5 Len" > > And > > subsequent reference to "2 + Len" should be changed to "Len". > > > Done, all of the above. > > > > 10. Section 6.8 : Under description of "Destination Address" : > > > > "Otherwise, the mobile node's home address SHOULD be used." > > > > Why is that so ? This is unsolicited Prefix Advertisement, so how can > > the Home Agent find this home address if it is not registered with it (and > > thus not present in the binding cache) ? And this also conflicts with the > > first sentence in this section anyway, "A home agent will send a Mobile > > Prefix Advertisement message to a mobile node to distribute prefix information > > about the home link while the mobile node is traveling away from the home > > network." > > > > Shouldn't this be removed ? > > It does appear to be so. Other mechanisms work on the home link, and > when the mobile node is away, we really need to use either the source or > the care of address. > > > 11. Section 7.5 : > > > > - MinRtrAdvInterval 0.05 seconds > > - MaxRtrAdvInterval 1.5 seconds > > > > This interval is too long, a range of 30 times. If the router is using > > 1.5 seconds (using Advertisement Interval Option), the MN may need a very > > long time to register the fact that it has moved, probably having to miss > > a few of these router advertisements. I think suggested values should be > > in the range of 0.05 to 0.25 seconds at the most, implementors are welcome > > to increase this if they want, but Mobile Specs should be more stringent > > on smooth handoff. > > Ok - but how do other folks see this? Filed this as a separate issue > #42 for better separation of the discussions. > > > 12. Section 8.1 : > > > > There has been some discussion on this, but I don't know what the final > > consensus is. But I feel that the first "MUST" for processing Home > > Address option should be changed to "SHOULD". If the node is processing this > > option, it should have a Binding Cache (since the MN would have sent > > this option only after establishing a Binding Cache). Since the third point > > is using "SHOULD", this one too should use "SHOULD". Making all three a > > "MUST" might be restricting some implementation of special mobile devices, > > which might not need the full functionality, eg a MN which is going to > > interact with a CN, and never with another MN (this is the scenario where the > > second bullet is not applicable). > > We have another issue #22 and on ongoing discussion about this... > > > 13. Section 9.1 : Remove the two bullets under : > > > > "- A flag indicating whether or not this Binding Cache entry represents > > a mobile node" ... > > AND > > " - The length of the routing prefix for the home address. This" ... > > > > Both of these have been removed since draft 14/15 or so. The second one need > > not be replaced with the 'S' bit flag, since the implementation of the 'S' > > bit would create multiple entries in the binding cache anyway. Hence both of > > these can be removed. > > Ok. Done. > > > 14. Section 9.4.5 : The last sentence of the second para should be changed to : > > > > "When the mobile node receives a packet from some sender containing a Binding > > Refresh Request option, it MUST confirm that a binding exists in it's BUL for > > this sender, and then it MAY start a return routability procedure, if > > necessary, before sending its current binding and a new lifetime in a new > > Binding Update. > > Ok. > > > 15. Section 10.2 : The 4th bullet is confusing to me. > > > > It looks like a BU to HA MUST have both BU as well as a Home Address option, > > while to a CN, the BU MUST NOT have the Home Address option. I guess this was > > a subject of debate on the mailing list, but I didn't follow it if it happened. > > Is this a conscious decision to have two Home Addresses when sending to HA, and > > is it really necessary ? > > This relates to issue #10. > > > 16. Section 10.2 : The 5th bullet should be changed to : > > > > "This ensures that no other node on the home link was using the mobile node's > > home address when the Binding Update arrived". > > Ok. > > > 17. Section 10.2 : The 5th bullet needs another modification : > > > > "When the home agent sends a successful Binding Acknowledgement to the mobile > > node, in response to a Binding Update with the `D' bit set, the home agent > > assures to the mobile node that its home address will continue to be kept > > unique by the home agent at least as long as the lifetime granted for that > > home address binding is not over, or while the mobile node transmits Binding > > Updates with new care-of addresses for that home address. > > Hmm... I think we can skip the part after "or while". Those are binding > updates too, and the first part applies. > > > 18. Section 10.2 : The para about 'S' bit should be changed to : > > > > "The set of such home addresses is formed by replacing the routing prefix for > > the given home address with all other routing prefixes *on the mobile node's > > home link* that are supported by the home agent processing the Binding Update. > > Ok > > > 19. Section 10.2 : The para about : > > > > "- The Refresh field MUST be set to a value less than or equal to" > > > > Is Refresh useful at all ? I don't believe it is. It seems to imply that it > > helps in the case of the Home Agent crashing and has only a volatile storage > > for the binding cache. But if the Home Agent crashed before the Refresh > > interval is over, the behaviour is identical to the case where the Refresh > > field contains the same value as Lifetime. > > > > It will be useful only if the HA crashed after the Refresh interval but before > > the Lifetime interval. Hence it is completely useless in most situations. > > > > If this can be removed safely, all references need to be removed in the > > draft and the Format of the BU section (6.1.8) needs to reflect this. > > How do others feel about this? Assigned a separate issue #43. > > > 20. Section 10.4 : The first bullet is slightly wrong. It should say : > > > > "- The home agent examines the value of the `S' bit in the new "home > > registration" Binding Update Packet. If this bit is nonzero," ... > > > > The HA has just got a BU packet from MN, and the Binding Cache entry did > > not exist. Also the Binding Cache doesn't contain a 'S' bit field. We should > > specify that the HA looks at the BU packet and not the BC entry. > > Yes. > > > 21. Section 10.4 : Part of the last para should be changed to : > > > > "In addition, the Router (R) bit in the Advertisement MUST be set to zero. > > Acting as a proxy ....". > > Ok > > > 22. Section 10.5 : First sentence of the second para should be changed to : > > > > "While the mobile node is away from home and this node is acting as the > > mobile node's home agent, the home agent intercepts any packets on the > > home link addressed to the mobile node's home address (including addresses > > formed from other on-link prefixes, if the 'S' bit was zero in the Binding > > Update), as described in Section 10.4." > > > > Prefix Len is removed. > > Ok. > > > 23. Section 11.2.3 : > > > > "- The segments left field in the RH is either 0 or 1." > > > > This should be 1 since that is the value set. Also, section 6.4.1 confirms > > that. > > This has been separately discussed. Are you happy with Erik's clarification? > > > 24. Section 11.6.2 : Do we need to mention that the binding to CN be done > > only after getting a success BA from the HA. I am referring to : > > > > "When a mobile node sends a Binding Update to its home agent to register a new > > primary care-of address (as described in Section 11.6.1), the mobile node SHOULD > > also start a return routability procedure to each other node for which an entry > > exists in the mobile node's Binding Update List, as detailed below. Upon > > successful return routability procedure, a Binding Update message is sent." ... > > > > The last sentence could be changed to : > > > > "Upon successful return routability procedure and after receiving a successful > > Binding Acknowledgement from the Home Agent, a Binding Update message is sent > > to all other nodes". > > Sounds good. > > > 25. Section 11.6.2 : When the BU packet is formed, should it be specified that > > a Home Address option MUST NOT be included ? This is relevant to my comment > > on item #15. > > Latest discussion points to that HAO must be included. > > > 26. Section 11.6.4 : In the second last para, the last sentence should be changed > > to : > > > > "In this case, the mobile node instead SHOULD return a Binding Update to > > the sender, in which the Lifetime field is set to zero and the care-of > > address (using a Alternate Care-Of Address option) is set to the mobile > > node's home address." > > > > The source address cannot be set to the Home Address due to ingress filtering, > > and this should be made more clear. > > Ok. > > > 27. Section 11.6.7 : The last sentence of the second para should include some > > re-transmission policy in case the NS is lost. Otherwise the MN cannot > > send a BU to the Home Agent after returning to the Home Network. Some > > values need to be specified for timeout and number of retransmissions before > > the MN can assume that the Home Agent is dead (and possibly continue using > > it's home address and also continue to finish the returning home procedure). > > I've been assuming regular NS retransmission would apply. Should we clarify that, > is that somehow not possible? > > > *********************************** Typos ************************************ > > > > > (1-12 snipped) > > Thanks, fixed! > > Jari > > > > -- ******************************************************************************* ,-~~-.___ / | ' \ ( ) 0 "On the Internet no one \_/-, ,---' knows you're a dog" ==== // / \-'~; /~~~(O) / __/~| / | ==( _____| (_________| Krishna Kumar Ph : (503) 578-3602 (W) Software Engineer, IBM NUMA-Q Server Division (503) 356-9217 (H) 15450 SW Koll Parkway, Beaverton, OR 97006 Fax : (503) 578-3228 ******************************************************************************* From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 3 20:46:18 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05004 for ; Mon, 3 Jun 2002 20:46:18 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23670; Mon, 3 Jun 2002 18:47:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA20971; Mon, 3 Jun 2002 17:46:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g540jhrP019558 for ; Mon, 3 Jun 2002 17:45:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g540jg0v019557 for mobile-ip-dist; Mon, 3 Jun 2002 17:45:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g540jdrP019550 for ; Mon, 3 Jun 2002 17:45:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17171 for ; Mon, 3 Jun 2002 17:45:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA27699 for ; Mon, 3 Jun 2002 18:45:38 -0600 (MDT) 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 RAA18256; Mon, 3 Jun 2002 17:45:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g540jbc21568; Mon, 3 Jun 2002 17:45:37 -0700 X-mProtect: <200206040045> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnbqzlh; Mon, 03 Jun 2002 17:45:35 PDT Message-ID: <3CFC0DB0.92FA9D8F@iprg.nokia.com> Date: Mon, 03 Jun 2002 17:45:36 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] when the MN returns home References: <200205220848.g4M8mIT15108@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Francis, how about this as a solution, when MN returns home? 1. the MN attaches to the home link. doesnt know that it is at home yet. 2. configures a link local address. starts DAD for it. in parallel it sends a router solicitation with unspecified source address. 3. DAD fails if the HA is defending the link local address. it should also get a router advertisement in parallel. 4. the router advertisment tells the MN, that it is at home. it ignores the DAD failure (it should delay reacting to DAD failure, till it gets the router advertisement) 5. the current spec already talks about how to obtain the link layer address of the HA, if the router advertisment does not contain the source link layer address option or if the router which sent it is not the HA on the link. 6. When the MN realizes it has come home, it immediately sends a deregistration BU to the HA, using the home address as the source address. 7. the HA receives the BU and removes the binding cache entries for the MN. (steps 6 and 7 work, Francis. even if the HA is defending the home address of the MN, it can handle a unicast packet sent to it. it does not matter if this unicast packet has the home address as the source address. this has been tested at every interop I have been to.) please let me know, which of the above steps dont work. I think we can come up with a solution. regards Vijay ps: the MN should do step (2) everytime it attaches to a new link. Francis Dupont wrote: > > In your previous mail you wrote: > > > => which source address the MN should use to send the deregistration > > message? > > the global unicast home address. > > => this address is always protected by the HA: it is the worst choice. > > the deregistration BU is unicast to the HA. this works. > > => with an old draft or with my proposal: > - the MN has just been attached to the home link > - it builds its link-local address and performs DAD for it > - (perhaps in parallel) its sends a RtSol to get prefixes and > a default router > - it gets a RtAdv from any routers on the home link (by application > of the Murphy's law, the first router to answer is never the HA). > - it finds a home prefix in the RtAdv and discovers it is at home > - it builds its addresses from the prefixes: > * if it performs DAD, it fails for the home address > * if it doesn't perform DAD (it was the case when I try 4 years ago), > see after > - it tries to send a BU to the HA > - as the HA address is not in the neighbor cache it sends a NbSol with: > * the home address as the source > * the solicited-node multicast of the HA address as the destination > * the HA address at the target > - the HA receives the NbSol and does a stupid thing with it, > in my case it sends a NbAdv to the previous care-of address of the MN > with a RH. > - the MN retries > - the MN retries > ... > > Conclusion: it does not work. My fix was simple: I modify the code > to always send the BU from the link-local address. It always works > until someone has the bad idea to use S=0 or a previous equivalent. > > > => no, RFC 2462 describes a mechanism and an optional optimization. > > I simply propose(d) to keep the mechanism as it is and to forbid the > > optimization. > > it is not for MIPv6 to forbid this optimization. the safe thing to > do would be for the HA to defend the MN's link local address also. > > => but this doesn't work... > > > => I have no trouble with the second statement. IMHO the optional optimization > > is a bad idea and should remove from RFC 2462 (bis or before). I believe > > most IPv6 implementors share my opinion, for instance the KAME team has > > removed the optimization from its code (ask them why). > > you can include me among the people who share this opinion. but you > still have a problem. there could always be an IPv6 implementation > which uses this optimization. > > => could => must not > > > => as soon as an address can be formed in an other way than stateless > > autoconf (and this is the case with a HA on the link) the optimization > > why do you say if a HA exists on a link, stateful address configuration > would be used? > > => no, what I said is mobility in the HA is not using stateless autoconf > or even a stateless autoconf like mechanism. Mobility in the HA with > S=1 and D=1 is very like manual configuration. > I don't believe in DHCPv6: the highly tuned mechanisms to allocate addresses > as a rare resource are not so well suited for IPv6 where there are 2^64 > available addresses per link... > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: I propose again: > - use RFC 2462 without the link-local optimization of DAD on the home link > - engrave the value 1 for the S bit > - ask the IPv6 WG to remove the link-local optimization in 2462bis From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 02:20:36 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19467 for ; Tue, 4 Jun 2002 02:20:36 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00578; Mon, 3 Jun 2002 23:20:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA29364; Mon, 3 Jun 2002 23:20:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g546J2rP020154 for ; Mon, 3 Jun 2002 23:19:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g546J2iS020153 for mobile-ip-dist; Mon, 3 Jun 2002 23:19:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g546IsrP020138; Mon, 3 Jun 2002 23:18:55 -0700 (PDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g546Img10862; Tue, 4 Jun 2002 08:18:49 +0200 (MEST) Date: Mon, 3 Jun 2002 22:05:46 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] RFC 2462 DAD optimization To: Richard Draves Cc: "Charles E. Perkins" , "Hesham Soliman (ERA)" , mobile-ip@sunroof.eng.sun.com, IPng Working Group In-Reply-To: "Your message with ID" <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I'm curious about the implementation status. I know the Windows > implementation does not implement the RFC 2462 optimization - it > performs DAD on every address independently. What about other > implementations? FWIW The Solaris implementation does supress DAD on addresses configured using the stateless mechanism except the link local address. It does perform DAD on all manually configured addresses. My person opinion is that we should fix that implementation and other implementations that have this behavior. Forcing implementations to have more than one link-local address due to RFC 3041 (and potentially lots of them - one for every valid RFC 3041 address) since quite odd both conceptually and messy to deal with from an implementation perspective (need to track which is the "real" link-local address.) Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 05:44:58 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21986 for ; Tue, 4 Jun 2002 05:44:58 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20393; Tue, 4 Jun 2002 03:45:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24520; Tue, 4 Jun 2002 02:44:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g549htrP020548 for ; Tue, 4 Jun 2002 02:43:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g549ht4Q020547 for mobile-ip-dist; Tue, 4 Jun 2002 02:43:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g549hlrP020532; Tue, 4 Jun 2002 02:43:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24128; Tue, 4 Jun 2002 02:43:49 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07499; Tue, 4 Jun 2002 02:43:42 -0700 (PDT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g549ZV600759; Tue, 4 Jun 2002 16:35:31 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Charles E. Perkins" cc: mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-Reply-To: <3CFBB63A.30DCB2E9@iprg.nokia.com> References: <3CFBB63A.30DCB2E9@iprg.nokia.com> <3CFABA06.79CF83E4@iprg.nokia.com> <2625.1023063809@itojun.org> <24840.1023127621@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Jun 2002 16:35:31 +0700 Message-ID: <757.1023183331@munnari.OZ.AU> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Date: Mon, 03 Jun 2002 11:32:26 -0700 From: "Charles E. Perkins" Message-ID: <3CFBB63A.30DCB2E9@iprg.nokia.com> | My questions were related whether that model should be our design goal. Maximum flexibility. Long term we will find a way to use that. This implies minimum assumptions, and even fewer unnecessary rules. | Exactly -- and I am suggesting that there are enough IPv6 | addresses available so that there is no motivation to support | the use of prefix{1,2}::1 for two different nodes on the same | link. Maybe one of them could find a different interface ID. You missed the point of the example. prefix1::1 and prefix2::1 were originally assigned to different nodes on different links. Then the links were merged into one. | I didn't yet see why enabling the behavior you suggest has | any advantages. The alternative is renumbering nodes sometimes. Not renumbering is almost always an advantage. And here we're talking about the IID part changing, so we don't even get the benefit of local connections continuing to work using site local addresses - everything stops. | Honestly, I think IPv6 would be better off by prohibiting | this behavior. I certainly disagree with that. I see no compelling reason here to prohibit anything. kre From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 05:49:25 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22036 for ; Tue, 4 Jun 2002 05:49:25 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09424; Tue, 4 Jun 2002 02:49:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25471; Tue, 4 Jun 2002 02:48:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g549mJrP020678 for ; Tue, 4 Jun 2002 02:48:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g549mJnN020677 for mobile-ip-dist; Tue, 4 Jun 2002 02:48:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g549mBrP020662; Tue, 4 Jun 2002 02:48:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25262; Tue, 4 Jun 2002 02:48:12 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA05600; Tue, 4 Jun 2002 03:48:09 -0600 (MDT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g549dB600772; Tue, 4 Jun 2002 16:39:16 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "Dave Thaler" cc: "Charles E. Perkins" , itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, "IPng Working Group" Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1047CF14D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC1047CF14D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Jun 2002 16:39:11 +0700 Message-ID: <770.1023183551@munnari.OZ.AU> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Date: Mon, 3 Jun 2002 11:46:03 -0700 From: "Dave Thaler" Message-ID: <2E33960095B58E40A4D3345AB9F65EC1047CF14D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> | No. In fact, I would expect that if any prefix is multilink, then all | of them should be. Why? I'm no expert on multi-link, in fact, I'm not sure I understand the need for it at all really, but nor do I know enough to object. | There is a bit that says whether to send packets to routers or just do | ND for them, which is probably what you're thinking of. Yes, that's probably it. | However, a multilink | subnet can work either way (see section 4.1 of the multilink draft), OK. | My preference is that we just ban DAD optimization in all cases. That's certainly an option. The "new prefix causes several thousand nodes to all attempt DAD at the same time" argument is the one which makes me hesitant to simply support this without further investigation. kre From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 06:28:24 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22478 for ; Tue, 4 Jun 2002 06:28:23 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05860; Tue, 4 Jun 2002 04:28:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA07509; Tue, 4 Jun 2002 03:28:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54ARmrP020983 for ; Tue, 4 Jun 2002 03:27:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54ARmbp020982 for mobile-ip-dist; Tue, 4 Jun 2002 03:27:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54ARdrP020967; Tue, 4 Jun 2002 03:27:40 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g54ARbg01874; Tue, 4 Jun 2002 12:27:37 +0200 (MEST) Date: Tue, 4 Jun 2002 12:26:31 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization To: Robert Elz Cc: Dave Thaler , "Charles E. Perkins" , itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, IPng Working Group In-Reply-To: "Your message with ID" <770.1023183551@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > | My preference is that we just ban DAD optimization in all cases. > > That's certainly an option. The "new prefix causes several thousand > nodes to all attempt DAD at the same time" argument is the one which > makes me hesitant to simply support this without further investigation. If that is a problem then the "MAY" for the optimization in RFC 2462 wouldn't be sufficient as a solution - very few implementations do the optimization today. Possible solutions to the new prefix DAD flood could be: - mandate the DAD optimization with a MUST - update RFC 2462 to day that when a new prefix is configured (past the original "attachment" to the link) the host MUST insert a random delay before performing the DAD. - others? But do we agree that the DAD flood when a new prefix is announced is an important problem to solve? Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 08:19:24 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25093 for ; Tue, 4 Jun 2002 08:19:24 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA22145; Tue, 4 Jun 2002 03:23:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06551; Tue, 4 Jun 2002 03:22:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54ALprP020863 for ; Tue, 4 Jun 2002 03:21:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54ALppW020862 for mobile-ip-dist; Tue, 4 Jun 2002 03:21:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54ALhrP020847; Tue, 4 Jun 2002 03:21:43 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g54ALeg01465; Tue, 4 Jun 2002 12:21:40 +0200 (MEST) Date: Tue, 4 Jun 2002 12:20:34 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization To: itojun@iijlab.net Cc: mobile-ip@sunroof.eng.sun.com, IPng Working Group In-Reply-To: "Your message with ID" <2905.1023065694@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > >My guess is that it will just effectively mean people will not > >use multiple prefixes for mobile nodes. > > i guess so too, and therefore, i don't feel a need to provide > special hack in DAD. it is not a protocol issue, but an operational > matter. > I agree that we don't need to change DAD here. Doing multiple DAD messages (one per home address) should be in the noise from a performance perspective. If there is a concern that a mobile node shouldn't need to send multiple binding updates, then I think that concern applies to both having multiple prefixes on the home link as well as using RFC 3041 home addresses (and presumably DHCPv6 assigned home addresses as well). With RFC 3041 a host will by default have 7 home addresses - 6 deprecated and 1 preferred temporary address - plus whatever stable (non-temporary) home addresses it has. Allowing for a single BU to the home agent with RFC 3041 home addresses requires that the home agent to maintain the set of home address each mobile node is using and e.g. treat a BU for any address in the set as applying to the whole set. The current mechanism (with ICMP Mobile Prefix Solicitation/Advertisement) only allows the HA to guess the set of home addresses when stateless address conf is used. So perhaps this part of the protocol should be extended with explicit messages from the MN to HA to indicate which home addresses it is using. Then one can always do a single BU independent of how many home addresses a mobile node is using, and idependently of how the MN has acquired those home addresses. My 2 cents, Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 09:30:49 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27920 for ; Tue, 4 Jun 2002 09:30:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05797; Tue, 4 Jun 2002 06:30:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04961; Tue, 4 Jun 2002 06:29:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54DS5rP021334 for ; Tue, 4 Jun 2002 06:28:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54DS5SH021333 for mobile-ip-dist; Tue, 4 Jun 2002 06:28:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54DS2rP021326 for ; Tue, 4 Jun 2002 06:28:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04742 for ; Tue, 4 Jun 2002 06:28:04 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26615 for ; Tue, 4 Jun 2002 07:27:58 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g54DRgc14697; Tue, 4 Jun 2002 15:27:42 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA21439; Tue, 4 Jun 2002 15:27:42 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g54DRfT68671; Tue, 4 Jun 2002 15:27:42 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206041327.g54DRfT68671@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] when the MN returns home In-reply-to: Your message of Mon, 03 Jun 2002 17:45:36 PDT. <3CFC0DB0.92FA9D8F@iprg.nokia.com> Date: Tue, 04 Jun 2002 15:27:41 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: how about this as a solution, when MN returns home? => this is first an IPv6 WG issue so it should first be fixed by the IPv6 WG. Or ask to change the charter of both mobile-ip and ipv6 WGs? 1. the MN attaches to the home link. doesnt know that it is at home yet. 2. configures a link local address. starts DAD for it. in parallel it sends a router solicitation with unspecified source address. 3. DAD fails if the HA is defending the link local address. it should also get a router advertisement in parallel. 4. the router advertisment tells the MN, that it is at home. it ignores the DAD failure (it should delay reacting to DAD failure, till it gets the router advertisement) => IPv6 specs are very accurate about what to do when DAD fails for your own link-local address. What you suggest is *not* in the specs! 5. the current spec already talks about how to obtain the link layer address of the HA, if the router advertisment does not contain the source link layer address option or if the router which sent it is not the HA on the link. => two remarks: - the current spec is wrong (some olders are correct so this is easy to fix) - if the MN link-local address is defended then the defender (the HA?) must put its link-layer address in the NA. The problem here is not to get the link-layer address, it is to recognize it is the HA one. 6. When the MN realizes it has come home, it immediately sends a deregistration BU to the HA, using the home address as the source address. => you assume there is no security, no network access control, etc, on the home link. IMHO you should provide a temporary link-local address the MN may use without trouble. 7. the HA receives the BU and removes the binding cache entries for the MN. (steps 6 and 7 work, Francis. even if the HA is defending the home address of the MN, it can handle a unicast packet sent to it. it does not matter if this unicast packet has the home address as the source address. this has been tested at every interop I have been to.) => no interop used any kind of network access control. please let me know, which of the above steps dont work. I think we can come up with a solution. => we should get a resolution on the DAD or DIIDD issue first. We are wasting our time on this list... ps: the MN should do step (2) everytime it attaches to a new link. => yes, the MN should follow RFC 2462 as it is an IPv6 node too. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 10:16:13 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29734 for ; Tue, 4 Jun 2002 10:16:08 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14760; Tue, 4 Jun 2002 08:17:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17741; Tue, 4 Jun 2002 07:16:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54EEmrP021462 for ; Tue, 4 Jun 2002 07:14:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54EEmiB021461 for mobile-ip-dist; Tue, 4 Jun 2002 07:14:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54EEerP021446; Tue, 4 Jun 2002 07:14:40 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12419; Tue, 4 Jun 2002 07:14:41 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01676; Tue, 4 Jun 2002 08:14:35 -0600 (MDT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g54EAZ601835; Tue, 4 Jun 2002 21:10:38 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: mobile-ip@sunroof.eng.sun.com, IPng Working Group cc: Erik Nordmark Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Jun 2002 21:10:35 +0700 Message-ID: <1833.1023199835@munnari.OZ.AU> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Date: Tue, 4 Jun 2002 12:26:31 +0200 (CEST) From: Erik Nordmark Message-ID: | If that is a problem then the "MAY" for the optimization in RFC 2462 | wouldn't be sufficient as a solution - very few implementations do | the optimization today. It depends upon whether the problem is one that always needs solving, or just one that needs to be able to be solved. | Possible solutions to the new prefix DAD flood could be: | - mandate the DAD optimization with a MUST So, I don't think we need to do that, whatever else happens. Then we get to implementation quality and all that - in an environment where it matters, users may want to insist on implementations that work well. In any case, we would need a way to indicate which prefixes should not be DAD optimized (MUST NOT) because of the multi-link issue. | - update RFC 2462 to day that when a new prefix is configured (past | the original "attachment" to the link) the host MUST insert a random | delay before performing the DAD. That's certainly a reasonable approach (though I'd prase it as "before configuring an address using the prefix" to make it more clear that it isn't only the DAD that needs to be delayed). | But do we agree that the DAD flood when a new prefix is announced is | an important problem to solve? Like a lot of this, I suspect this may be known only when we get IPv6 nets that are really big enough that the effects can be measured. I'm not sure there are all that many. I suspect that even the IETF net won't have enough IPv6 nodes actively connected to it to run an experiment there and see what happens. kre From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 10:58:06 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01550 for ; Tue, 4 Jun 2002 10:58:05 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05728; Tue, 4 Jun 2002 08:59:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22051; Tue, 4 Jun 2002 07:58:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54EvMrP021605 for ; Tue, 4 Jun 2002 07:57:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54EvMeH021604 for mobile-ip-dist; Tue, 4 Jun 2002 07:57:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54EvJrP021597 for ; Tue, 4 Jun 2002 07:57:19 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21703 for ; Tue, 4 Jun 2002 07:57:20 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09371 for ; Tue, 4 Jun 2002 07:57:20 -0700 (PDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 744EC2C4B; Tue, 4 Jun 2002 09:57:19 -0500 (CDT) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 9D8611B4E; Tue, 4 Jun 2002 10:57:18 -0400 (EDT) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g54EvIE05639; Tue, 4 Jun 2002 10:57:18 -0400 (EDT) Received: from hp.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id KAA0000003899; Tue, 4 Jun 2002 10:57:17 -0400 (EDT) Message-ID: <3CFCD54C.8080700@hp.com> Date: Tue, 04 Jun 2002 10:57:16 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Francis Dupont , jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] when the MN returns home References: <200206041327.g54DRfT68671@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ahh, I just found where this is specified and it looks like this is a modification on the behavior mandated by 2461. From 2461: "7.1.1. Validation of Neighbor Solicitations A node MUST silently discard any received Neighbor Solicitation messages that do not satisfy all of the following validity checks: .... - If the IP source address is the unspecified address, the IP destination address is a solicited-node multicast address. - If the IP source address is the unspecified address, there is no source link-layer address option in the message." It looks like Mobile IPv6 draft (section 11.6.7, paragraph 2) assumes that a unicasted NS with an unspecified source will be accepted. It will not be because of the above rules. If the intension is to supercede the 2461 NS validation rules, it should be explicitely stated in the draft (and even then it's debatable if that's the right thing). -vlad Francis Dupont wrote: > > 5. the current spec already talks about how to obtain the link layer > address of the HA, if the router advertisment does not contain the > source link layer address option or if the router which sent it is > not the HA on the link. > > => two remarks: > - the current spec is wrong (some olders are correct so this is easy to fix) > - if the MN link-local address is defended then the defender (the HA?) > must put its link-layer address in the NA. The problem here is not > to get the link-layer address, it is to recognize it is the HA one. > > 6. When the MN realizes it has come home, it immediately sends a > deregistration BU to the HA, using the home address as the source > address. > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 13:22:22 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06697 for ; Tue, 4 Jun 2002 13:22:22 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03263; Tue, 4 Jun 2002 10:21:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29471; Tue, 4 Jun 2002 10:21:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54HL8rP021993 for ; Tue, 4 Jun 2002 10:21:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54HL8c8021992 for mobile-ip-dist; Tue, 4 Jun 2002 10:21:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54HL4rP021985 for ; Tue, 4 Jun 2002 10:21:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28938 for ; Tue, 4 Jun 2002 10:21:04 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16614 for ; Tue, 4 Jun 2002 11:21:04 -0600 (MDT) 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 KAA24730; Tue, 4 Jun 2002 10:21:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g54HL2K20816; Tue, 4 Jun 2002 10:21:02 -0700 X-mProtect: <200206041721> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdn0ITaZ; Tue, 04 Jun 2002 10:21:00 PDT Message-ID: <3CFCF6FC.56446139@iprg.nokia.com> Date: Tue, 04 Jun 2002 10:21:00 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] when the MN returns home References: <200206041327.g54DRfT68671@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > => IPv6 specs are very accurate about what to do when DAD fails for > your own link-local address. What you suggest is *not* in the specs! I know that. I am saying MIPv6 MNs do that. they wait till they get the router advert before responding to DAD. > > 5. the current spec already talks about how to obtain the link layer > address of the HA, if the router advertisment does not contain the > source link layer address option or if the router which sent it is > not the HA on the link. > > => two remarks: > - the current spec is wrong (some olders are correct so this is easy to fix) > - if the MN link-local address is defended then the defender (the HA?) > must put its link-layer address in the NA. The problem here is not > to get the link-layer address, it is to recognize it is the HA one. oops.. I thought the spec has been fixed. yes it is still broken. anyway here is how you can do it. this is from a mail I had sent in Aug 2001. this has been tested at the interops. the MN detects that it has returned home by getting a router advertisement from the home agent or from a router on the home link. lets assume the router advertisement does not have a source link layer address option. now the MN needs the home agent's MAC address to send a deregistration BU. the MN sends a neighbor solicitation first neighbor solicitation src = unspecified address dst = all nodes multicast address target = Home Agent the home agent receives the NS and respnds with a NA. since the source address for the NS was unspecified, the NA is sent to the all nodes multicast address. neighbor advertisment src = link local dst = all nodes multicast address target = Home Agent the MN receives this NA and creates a REACHABLE neighbor cache for the Home Agent. after that the MN sends a BU for deregistration. the NS is a basically a DAD probe. ofcourse if there are better ways, you can use it. > > 6. When the MN realizes it has come home, it immediately sends a > deregistration BU to the HA, using the home address as the source > address. > > => you assume there is no security, no network access control, etc, > on the home link. IMHO you should provide a temporary link-local address > the MN may use without trouble. most network access control elements have two paths. uncontrolled and controlled. you just need a special rule in your network access control allowing packets which contain a BU. infact you can go farther and check the destination of the BU against the known home agents on the link. ofcourse, if your default router is your HA, this is even easier. > => we should get a resolution on the DAD or DIIDD issue first. > We are wasting our time on this list... there are two parts to this. 1. somebody could configure MN's link local address if the HA is not defending it. 2. somebody can configure MN's home address if the HA is only defending the MN's home address and not the link local address. this is mainly because of RFC 2462's DAD optimization. if the IPv6 WG decides DAD optimization is a bad idea, we still have (1), right?? regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 13:29:01 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06851 for ; Tue, 4 Jun 2002 13:29:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05907; Tue, 4 Jun 2002 11:30:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02980; Tue, 4 Jun 2002 10:29:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54HSKrP022106 for ; Tue, 4 Jun 2002 10:28:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54HSKLv022105 for mobile-ip-dist; Tue, 4 Jun 2002 10:28:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54HSIrP022098 for ; Tue, 4 Jun 2002 10:28:18 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07546 for ; Tue, 4 Jun 2002 13:28:19 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g54HSMqp024664 for ; Tue, 4 Jun 2002 13:28:22 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g54HSMvl024663 for mobile-ip@sunroof.eng.sun.com; Tue, 4 Jun 2002 13:28:22 -0400 (EDT) Date: Tue, 4 Jun 2002 13:28:22 -0400 (EDT) From: Steven Glass - Solaris Software Message-Id: <200206041728.g54HSMvl024663@onion.East.Sun.COM> Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54ANurP020896 for ; Tue, 4 Jun 2002 03:23:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA23245 for ; Tue, 4 Jun 2002 03:23:56 -0700 (PDT) To: undisclosed-recipients:; Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: From: "Dr. Kurt Tutschku" To: mobile-ip@sunroof.eng.sun.com Subject: ITC Specialist Seminar - 1st Call for participation Date: Tue Jun 04, 2002 11:02:13 AM US/Eastern ----- PLEASE ACCEPT OUR APOLOGIES FOR MULTIPLE COPIES 1st CALL FOR PARTICIPATION: Dear colleagues, we'd like to announce an upcoming ITC Specialist Seminar: 15th ITC Specialist Seminar: "Internet Traffic Engineering and Traffic Management (IP2002)", July 22-24 2002, Wuerzburg, Germany. http://www.itcspecialistseminar.com/ The seminar will bring researchers and practitioners in the area of Internet traffic engineering and traffic management together to present the most up-to-date results and achievements in the field. The seminar will feature 28 rigorously reviewed contributions, a keynote speech from one of the leading experts in IP tele- traffic engineering, and a high-ranked panel of industry experts and researchers. The program of the workshop will soon be available on the seminar's website. a) Seminar registration: A registration form for the IP2002 workshop is available at: http://www.itcspecialistseminar.com/RegistrationForm.pdf The deadline for early registration is June 22, 2002. b) Hotel reservation: The seminar's web pages provides a reservation form for accommodations in Wuerzburg. A hotel reservation form is available at: http://www.itcspecialistseminar.com/HotelReservation.pdf The deadline for advance hotel reservation is June16, 2002. Please remember that July is touristic high season in Germany. We strongly advise you to book your hotel as soon as possible. We are looking forward to welcome you in Wuerzburg. Best Regards, Phuoc Tran-Gia James Roberts Kurt Tutschku Klaus Heck, your IP2002 Organizing Team From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 13:30:12 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06891 for ; Tue, 4 Jun 2002 13:30:12 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14412; Tue, 4 Jun 2002 10:29:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03331; Tue, 4 Jun 2002 10:29:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54HT7rP022123 for ; Tue, 4 Jun 2002 10:29:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54HT66a022122 for mobile-ip-dist; Tue, 4 Jun 2002 10:29:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54HT3rP022115 for ; Tue, 4 Jun 2002 10:29:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03012 for ; Tue, 4 Jun 2002 10:29:04 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26015 for ; Tue, 4 Jun 2002 11:29:01 -0600 (MDT) 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 KAA25121; Tue, 4 Jun 2002 10:29:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g54HT0832196; Tue, 4 Jun 2002 10:29:00 -0700 X-mProtect: <200206041729> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBO9xyn; Tue, 04 Jun 2002 10:28:58 PDT Message-ID: <3CFCF8DA.65324D84@iprg.nokia.com> Date: Tue, 04 Jun 2002 10:28:58 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: Francis Dupont , jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] when the MN returns home References: <200206041327.g54DRfT68671@givry.rennes.enst-bretagne.fr> <3CFCD54C.8080700@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vladislav Yasevich wrote: > > Ahh, I just found where this is specified and it looks like this > is a modification on the behavior mandated by 2461. > > From 2461: > > "7.1.1. Validation of Neighbor Solicitations > > A node MUST silently discard any received Neighbor Solicitation > messages that do not satisfy all of the following validity checks: > > .... > > - If the IP source address is the unspecified address, the IP > destination address is a solicited-node multicast address. > > - If the IP source address is the unspecified address, there is no > source link-layer address option in the message." > > It looks like Mobile IPv6 draft (section 11.6.7, paragraph 2) assumes that > a unicasted NS with an unspecified source will be accepted. It will not be > because of the above rules. this is wrong in the spec. I thought this was fixed long back. see my earlier mail replying to Francis. the destination address is set to all nodes multicast address. it is basically a DAD probe for the HA's address. maybe Francis has a better way of doing this. but currently we do a DAD probe for the HA's address and obtain the link layer address from the subsequent Neighbor Advertisment from the HA. ofcourse the best thing is for the HA to include Source Link Layer address option in the router advert. this has two problems. (1) overhead. (2) the router which sent the router advert might not be the MN's HA. (I hate this. I wish there was just one HA on the home link and that is the default router). > If the intension is to supercede the 2461 NS validation rules, it should nope! regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 13:45:43 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07397 for ; Tue, 4 Jun 2002 13:45:43 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15359; Tue, 4 Jun 2002 11:47:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12545; Tue, 4 Jun 2002 10:45:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54HiwrP022375 for ; Tue, 4 Jun 2002 10:44:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54Hiwbm022374 for mobile-ip-dist; Tue, 4 Jun 2002 10:44:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54HiurP022367 for ; Tue, 4 Jun 2002 10:44:56 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12881 for ; Tue, 4 Jun 2002 13:44:56 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g54Hj0qp024677 for ; Tue, 4 Jun 2002 13:45:00 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g54Hj01X024676 for mobile-ip@sunroof.eng.sun.com; Tue, 4 Jun 2002 13:45:00 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54ANurP020896 for ; Tue, 4 Jun 2002 03:23:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA23245 for ; Tue, 4 Jun 2002 03:23:56 -0700 (PDT) Received: from demokritos.cytanet.com.cy (demokritos.cytanet.com.cy [195.14.133.252]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA16754 for ; Tue, 4 Jun 2002 04:25:04 -0600 (MDT) Received: from andreasp (adsl-169-144.cytanet.com.cy [213.149.169.144]) by demokritos.cytanet.com.cy (8.11.4/8.11.4) with SMTP id g54AMQu16859; Tue, 4 Jun 2002 13:22:27 +0300 (EET DST) Message-ID: <000a01c20bb1$bbe41880$09350b0a@andreasp> From: "Andreas Pitsillides" To: , , , , , , , , , , Cc: "Andreas Pitsillides" References: <030d01c1fd9e$0217aa50$09350b0a@andreasp> Subject: [mobile-ip] 2nd Call for Participation INFOCOM 2002 + HOTEL RATE REDUCTION Date: Tue, 4 Jun 2002 13:04:18 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit PLEASE ACCEPT OUR APOLOGIES FOR MULTIPLE COPIES ----- CALL FOR PARTICIPATION - INFOCOM 2002 --------------- Note: 1. The deadline for low rate hotel reservation cut-off is extended to Friday 14 2. Hotel rates have been reduced to $239 for single and $259 for double occupancy 3. All earlier bookings made at the earlier higher rate, will be reimbursed the difference The 21st Annual Joint Conference of the IEEE Computer and Communications Societies June 23-27, 2002, Hilton New York, New York, USA http://www.ieee-infocom.org/2002 From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 13:45:49 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07410 for ; Tue, 4 Jun 2002 13:45:48 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01049; Tue, 4 Jun 2002 11:46:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12437; Tue, 4 Jun 2002 10:45:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54HijrP022365 for ; Tue, 4 Jun 2002 10:44:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54HijqL022364 for mobile-ip-dist; Tue, 4 Jun 2002 10:44:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54HifrP022357 for ; Tue, 4 Jun 2002 10:44:41 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16290 for ; Tue, 4 Jun 2002 10:44:42 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00203 for ; Tue, 4 Jun 2002 11:44:42 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.121]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0GX6003PFZYGVE@edgemail1.Central.Sun.COM> for mobile-ip@sunroof.eng.sun.com; Tue, 04 Jun 2002 11:44:42 -0600 (MDT) Received: from dhcp-174-234.East.Sun.COM ([129.148.174.234]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0GX6003LYZYFEE@mail.sun.net> for mobile-ip@sunroof.eng.sun.com; Tue, 04 Jun 2002 11:44:40 -0600 (MDT) Date: Tue, 04 Jun 2002 13:44:44 -0400 From: "Steven M. Glass" Subject: [mobile-ip] Re: ITC Specialist Seminar - 1st Call for participation In-reply-to: <200206041728.g54HSMvl024663@onion.East.Sun.COM> To: mobile-ip@sunroof.eng.sun.com Cc: "Dr. Kurt Tutschku" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.481) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Due apparently to some poorly forged mail headers on my part, the message I forwarded to the list actually appeared to not only come from the original sender, "Dr. Kurt Tutschku" , but to also initially come from me. I don't really understand why, since the original file doesn't contain my email address in it at all, but regardless - please contact Dr. Tutschku, cc:ed above, if you have any questions with regard to the following Call for Participation. Cheers, Steven M. Glass your confused list administrator Dr. Kurt Tutschku On Tuesday, June 4, 2002, at 01:28 PM, -S-t-e-v-e-n- -G-l-a-s-s- wrote: > ----- > > PLEASE ACCEPT OUR APOLOGIES FOR MULTIPLE COPIES > 1st CALL FOR PARTICIPATION: > > Dear colleagues, > > we'd like to announce an upcoming ITC Specialist Seminar: > 15th ITC Specialist Seminar: "Internet Traffic Engineering > and Traffic Management (IP2002)", July 22-24 2002, Wuerzburg, > Germany. > http://www.itcspecialistseminar.com/ > > The seminar will bring researchers and practitioners in the > area of Internet traffic engineering and traffic management > together to present the most up-to-date results and achievements > in the field. > > The seminar will feature 28 rigorously reviewed contributions, > a keynote speech from one of the leading experts in IP tele- > traffic engineering, and a high-ranked panel of industry experts > and researchers. > > The program of the workshop will soon be available on the seminar's > website. > > a) Seminar registration: > A registration form for the IP2002 workshop is available at: > http://www.itcspecialistseminar.com/RegistrationForm.pdf > > The deadline for early registration is June 22, 2002. > > b) Hotel reservation: > The seminar's web pages provides a reservation form for > accommodations in Wuerzburg. A hotel reservation form is > available at: > http://www.itcspecialistseminar.com/HotelReservation.pdf > > The deadline for advance hotel reservation is June16, 2002. > > Please remember that July is touristic high season in Germany. > We strongly advise you to book your hotel as soon as possible. > > We are looking forward to welcome you in Wuerzburg. > > Best Regards, > Phuoc Tran-Gia > James Roberts > Kurt Tutschku > Klaus Heck, your IP2002 Organizing Team From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 14:05:01 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08145 for ; Tue, 4 Jun 2002 14:05:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26859; Tue, 4 Jun 2002 12:06:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22119; Tue, 4 Jun 2002 11:05:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54I44rP022634 for ; Tue, 4 Jun 2002 11:04:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54I44vZ022633 for mobile-ip-dist; Tue, 4 Jun 2002 11:04:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54I41rP022626 for ; Tue, 4 Jun 2002 11:04:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21399 for ; Tue, 4 Jun 2002 11:04:02 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14665 for ; Tue, 4 Jun 2002 12:04:01 -0600 (MDT) 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 LAA27175 for ; Tue, 4 Jun 2002 11:04:00 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g54I40p19207 for ; Tue, 4 Jun 2002 11:04:00 -0700 X-mProtect: <200206041804> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd50Q1yx; Tue, 04 Jun 2002 11:03:58 PDT Message-ID: <3CFD010E.419A64BD@iprg.nokia.com> Date: Tue, 04 Jun 2002 11:03:58 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] when the MN returns home References: <200206041327.g54DRfT68671@givry.rennes.enst-bretagne.fr> <3CFCF6FC.56446139@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > neighbor solicitation > src = unspecified address > dst = all nodes multicast address > target = Home Agent > correction: the dst is set to solicted node multicast address of the target address. Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 14:09:36 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08341 for ; Tue, 4 Jun 2002 14:09:35 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06739; Tue, 4 Jun 2002 11:09:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24182; Tue, 4 Jun 2002 11:09:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54I8erP022722 for ; Tue, 4 Jun 2002 11:08:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54I8evb022721 for mobile-ip-dist; Tue, 4 Jun 2002 11:08:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54I8arP022708 for ; Tue, 4 Jun 2002 11:08:36 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23922 for ; Tue, 4 Jun 2002 11:08:37 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06363 for ; Tue, 4 Jun 2002 11:08:37 -0700 (PDT) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.48 2002/05/24 00:39:04 root Exp $) with ESMTP id g54I76M27947 for ; Tue, 4 Jun 2002 18:07:06 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.22 2002/05/24 00:38:22 root Exp $) with SMTP id g54I6Vh15090 for ; Tue, 4 Jun 2002 18:06:31 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002060411083719331 ; Tue, 04 Jun 2002 11:08:37 -0700 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 11:08:31 -0700 Message-ID: From: "Adrangi, Farid" To: "'Tessier, Serge'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] [mobile-IP]: Comments on draft-ietf-mobileip-vpn- problem-statemen t-00 Date: Tue, 4 Jun 2002 11:08:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Serge Thanks for reading the draft, and providing feedback. Please see my reply below (marked by Farid Writes>). Best regards, Farid -----Original Message----- From: Tessier, Serge [mailto:Serge.Tessier@t-systems.com] Sent: Friday, May 31, 2002 7:41 AM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] [mobile-IP]: Comments on draft-ietf-mobileip-vpn-problem-statemen t-00 This draft appears to be a product of the working group so I address my comments (minor -maybe very personnal- and major -technical- ones) to the authors through the mailing list. a. Abstract & Introduction: When VPN is mentionned I think it should be precised L3-based VPN or even IPSec-based VPN since in the rest of the document IPSec is mentioned but never L2 tunneling mechanisms. Somehow, the following limited scope should be stated : "The scenarios described here assume that the VPN solution is based on L3 mechansims" or alternatively: "The scenarios described here excludes any L2-based VPN realisation". It could even be justified that for the sake of coherence since for interaction purposes (triggerring event notification) mobility and security may need to be put on the 'same level' i.e. network layer (maybe too much implementation specific). It is also an obvious benefit to maintain the well-known Mobile IP link layer independancy through the exclusion of L2TP solution. Farid Writes > Agree. We will make changes to both abstract and introduction sections to make it clear that the scenarios assume an IPsec-based VPN solution. a'. There may be a lack of 'motivation' chapter (see also d.). In such a chapter it would be the place to mention that for example one could extend already deployed VPN solutions through the offer of 'mobility services' as a VPN add-on feature. Farid Writes > The draft's intent is to not suggest any solutions at all, but simply descibe a problem. And I think the VPN extension that you are talking about falls into the solution space. b. In all the figures the terms 'GW' is missing in each boxes containing the text 'IPSec-based VPN' Farid Writes> Yes. Easy to fix! c. Also some typos (ASCII conversion) in the text... Farid Writes > Good catch! Somehow, we missed that! d. Page 4. After figure 4.0b: This motivation is very important and should be put IMO at the beginning of the document (abstract). Even if it is mentioned in the introduction I think it comes too late, it is too vague (on the contrary, the references to EDGE, GPRS, UMTS do not bring IMO any motivation per se). Sorry, I do not propose anything better. Farid Writes> We can make changes to the abstract to bring out that the motivation part (through some usage scenarios) comes in later sections. Do you think that would help? e. Page 5: "Dr. Joe needs to establish an IPsec tunnel to the VPN gateway first so that he can register with the home agent while roaming outside the home network. This implies that the MIPv4 traffic destined to the home network has to run inside an IPsec tunnel." Here I am a bit puzzle: It is indeed a bit hard to state that spontaneously without any introduction/motivation about the fact that the tunnels should be put in that order. Farid Writes > The fact is that the home network is not directly reachable by the MN, therefore, the MN has to run MIP traffic inside the IPsec tunnel. Perhaps, the text should be modified to make this more clear -- so, how about the following? "Dr. Joe needs has to establish an IPsec tunnel to the VPN gateway first so that he can register with the home agent while roaming outside the home network. This also implies that the MIPv4 traffic destined to the home network has to run inside an IPsec tunnel, as the home network will not directly be reachable." I am not sure we (at least I) have reached an exhaustive understanding and I would be happy to have discussion for clarifying these issues (draft-ietf-mobileip-ipsec-use-00.txt is maybe a starting point (?), not the proposal itself but the general philosophy especially the requirements, but it expired in 1998. There are other studies about that topic). There was also a thread on the mobileip-nat-vpn mailing list.. Why not including a section describing tunneling order, listing at least the alternatives and the pros/cons or, at the minimum, letting the door open for issues that are IMHO not understood? With a statement like: "It has still to be investigated in a further version of this document weather the Mobile IP tunnel should be put within the IPSec tunnel or the other way around. In this document we do not make any assumption regarding the tunnelling order." Farid Writes > In my mind, the draft should not suggest any tunneling order - this falls into the solution space. Agree/Disagre? f. Page 5. Section 5.2: If the imaginary mobile user Dr. Joe is introduced, then why not using him here? This document should be about usage scenario so it could be helpfull to state that in the case 1, Dr. Joe visit a 'branch office' (e.g. surgery dept.) outside the hospital's main building. Farid Writes > Agree. Will fix it. Anyway, more important here: "The FA is trusted, i.e. an SA has been established a priori between the FA and the home VPN gateway." Wouldn't it be more generic to state that there is a GW-to-GW security scheme between a VPN GW located at the edge of the Foreign Network and the 'IPSec-based VPN (GW)' at the edge of the home network? IMHO it would more fit in existing usage scenario, at least the ones I can foreseen. Farid Writes> Maybe we should mention both cases. So, how about the following? "The FA is trusted, i.e. an SA has been established a priori between the FA and the home VPN gateway, or a GW-to-GW security scheme exists between a VPN GW located at the edge of the Foreign Network and the 'IPSec-based VPN (GW)' at the edge of the home network" g. Page 7. Figure 6.1b: "Figure 6.1b u Shows IPsec tunnel endpoints, MN-CoA and the VPN External IP address, in co-located mode" It is here abruptly stated that the MN-CoA is the tunnelling end point of the IPSec tunnel. It is a consequence of page 5 sections. I know some other possible combination, which I do not pretend to be better. Wouldn't it be possible to write 'for example' in the previous statement, once again not to preclude any solution? Please also see my comment e. FArid Write> Here again, we are not suggesting any tunneling order or solutions. The diagram shows how a node (from outside) communicates to its home network (protected by a VPN). And to make this communication possible, the MN has to establish an IPsec tunnel to the VPN gateway first, and run the traffic to the home network inside that tunnel (this is true even if MIP is not in the picture) Maybe you can help us understand why you think we are suggesting any tunneling order (or a solution) here. Thanks -Serge From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 14:12:31 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08571 for ; Tue, 4 Jun 2002 14:12:31 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15529; Tue, 4 Jun 2002 12:12:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26204; Tue, 4 Jun 2002 11:12:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54IC6rP022849 for ; Tue, 4 Jun 2002 11:12:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54IC5ie022848 for mobile-ip-dist; Tue, 4 Jun 2002 11:12:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54IC2rP022841 for ; Tue, 4 Jun 2002 11:12:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25922 for ; Tue, 4 Jun 2002 11:12:03 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18326 for ; Tue, 4 Jun 2002 12:12:02 -0600 (MDT) 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 LAA28147; Tue, 4 Jun 2002 11:12:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g54IC1h31868; Tue, 4 Jun 2002 11:12:01 -0700 X-mProtect: <200206041812> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdeVzwmE; Tue, 04 Jun 2002 11:11:59 PDT Message-ID: <3CFD02EF.A175A2BD@iprg.nokia.com> Date: Tue, 04 Jun 2002 11:11:59 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] when the MN returns home References: <200206041327.g54DRfT68671@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > => IPv6 specs are very accurate about what to do when DAD fails for > your own link-local address. What you suggest is *not* in the specs! and the IPv6 specs say the interface SHOULD be disabled if DAD fails for link-local address formed from the interface identifier. section 5.4.5, RFC 2462 5.4.5. When Duplicate Address Detection Fails A tentative address that is determined to be a duplicate as described above, MUST NOT be assigned to an interface and the node SHOULD log a system management error. If the address is a link-local address formed from an interface identifier, the interface SHOULD be disabled. this is extremem (IMO). I am just saying that an MN before disabling the interface, wait for the router advert to detect that it has returned home. the router solicitation was sent in parallel to the DAD neighbor solicitation. the router advert might even reach the MN first. Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 14:15:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08765 for ; Tue, 4 Jun 2002 14:15:37 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02864; Tue, 4 Jun 2002 12:17:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01434; Tue, 4 Jun 2002 11:15:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54IEXrP022929 for ; Tue, 4 Jun 2002 11:14:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54IEXxq022928 for mobile-ip-dist; Tue, 4 Jun 2002 11:14:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54IETrP022918 for ; Tue, 4 Jun 2002 11:14:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25891 for ; Tue, 4 Jun 2002 11:14:30 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02981 for ; Tue, 4 Jun 2002 11:14:30 -0700 (PDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 155123ABA; Tue, 4 Jun 2002 11:22:16 -0700 (PDT) Received: from anw.zk3.dec.com (fanw4.zk3.dec.com [16.140.160.17]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id E315C1642; Tue, 4 Jun 2002 14:14:29 -0400 (EDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g54IETM0002154453; Tue, 4 Jun 2002 14:14:29 -0400 (EDT) Message-ID: <3CFD0385.3080100@hp.com> Date: Tue, 04 Jun 2002 14:14:29 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Francis Dupont , jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] when the MN returns home References: <200206041327.g54DRfT68671@givry.rennes.enst-bretagne.fr> <3CFCD54C.8080700@hp.com> <3CFCF8DA.65324D84@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > > > this is wrong in the spec. I thought this was fixed long back. see my > earlier mail replying to Francis. the destination address is set to all > nodes multicast address. it is basically a DAD probe for the HA's > address. This is the only spec I have (draft 17). Also, it'll probably be better to send to solicited node multicast of the HA address instead of all nodes. -vlad +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 14:19:04 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09120 for ; Tue, 4 Jun 2002 14:19:04 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05371; Tue, 4 Jun 2002 11:18:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02914; Tue, 4 Jun 2002 11:18:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54II1rP023025 for ; Tue, 4 Jun 2002 11:18:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54II16A023024 for mobile-ip-dist; Tue, 4 Jun 2002 11:18:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54IHvrP023011 for ; Tue, 4 Jun 2002 11:17:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27136 for ; Tue, 4 Jun 2002 11:17:59 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA21148 for ; Tue, 4 Jun 2002 12:17:58 -0600 (MDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 568C343A5; Tue, 4 Jun 2002 13:17:57 -0500 (CDT) Received: from anw.zk3.dec.com (fanw4.zk3.dec.com [16.140.160.17]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id DE3E519DB; Tue, 4 Jun 2002 14:17:56 -0400 (EDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g54IHuM0002154976; Tue, 4 Jun 2002 14:17:56 -0400 (EDT) Message-ID: <3CFD0454.7040408@hp.com> Date: Tue, 04 Jun 2002 14:17:56 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Francis Dupont , jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] when the MN returns home References: <200206041327.g54DRfT68671@givry.rennes.enst-bretagne.fr> <3CFD02EF.A175A2BD@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay As you the spec states it is a SHOULD. If you find a very good reason (which you did) to not do that, you can overide the SHOULD behavior. All we have to do is document the new behavior in the Mobile IPv6 spec stating that this updates the bahavior in 2462. -vlad Vijay Devarapalli wrote: > Francis Dupont wrote: > > >>=> IPv6 specs are very accurate about what to do when DAD fails for >>your own link-local address. What you suggest is *not* in the specs! > > > and the IPv6 specs say the interface SHOULD be disabled if DAD fails > for link-local address formed from the interface identifier. > > section 5.4.5, RFC 2462 > > 5.4.5. When Duplicate Address Detection Fails > > A tentative address that is determined to be a duplicate as described > above, MUST NOT be assigned to an interface and the node SHOULD log a > system management error. If the address is a link-local address > formed from an interface identifier, the interface SHOULD be > disabled. > > this is extremem (IMO). I am just saying that an MN before disabling > the interface, wait for the router advert to detect that it has > returned home. the router solicitation was sent in parallel to the > DAD neighbor solicitation. the router advert might even reach the MN > first. > > Vijay > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 14:33:49 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09915 for ; Tue, 4 Jun 2002 14:33:49 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26743; Tue, 4 Jun 2002 12:34:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09589; Tue, 4 Jun 2002 11:33:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54IX7rP023213 for ; Tue, 4 Jun 2002 11:33:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54IX7Q4023212 for mobile-ip-dist; Tue, 4 Jun 2002 11:33:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54IX4rP023205 for ; Tue, 4 Jun 2002 11:33:04 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05017 for ; Tue, 4 Jun 2002 11:33:05 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20157 for ; Tue, 4 Jun 2002 11:33:05 -0700 (PDT) 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 LAA29634; Tue, 4 Jun 2002 11:33:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g54IX4N32651; Tue, 4 Jun 2002 11:33:04 -0700 X-mProtect: <200206041833> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2GbMTo; Tue, 04 Jun 2002 11:33:02 PDT Message-ID: <3CFD07DE.2536E94D@iprg.nokia.com> Date: Tue, 04 Jun 2002 11:33:02 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: Francis Dupont , jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] when the MN returns home References: <200206041327.g54DRfT68671@givry.rennes.enst-bretagne.fr> <3CFD02EF.A175A2BD@iprg.nokia.com> <3CFD0454.7040408@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vladislav Yasevich wrote: > As you the spec states it is a SHOULD. If you find a very good reason > (which you did) to not do that, you can overide the SHOULD behavior. > > All we have to do is document the new behavior in the Mobile IPv6 spec > stating that this updates the bahavior in 2462. I agree. Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 4 19:33:49 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19860 for ; Tue, 4 Jun 2002 19:33:49 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22215; Tue, 4 Jun 2002 16:33:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20722; Tue, 4 Jun 2002 16:33:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54NWUrP023632 for ; Tue, 4 Jun 2002 16:32:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g54NWTBI023631 for mobile-ip-dist; Tue, 4 Jun 2002 16:32:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g54NWQrP023624 for ; Tue, 4 Jun 2002 16:32:26 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA19378 for ; Tue, 4 Jun 2002 16:32:29 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14313 for ; Tue, 4 Jun 2002 16:32:28 -0700 (PDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g54NVlh02976; Tue, 4 Jun 2002 18:31:47 -0500 (CDT) Message-ID: <3CFD4DFD.6090408@alcatel.com> Date: Tue, 04 Jun 2002 18:32:13 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Adrangi, Farid" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] [mobile-IP]: Comments on draft-ietf-mobileip-vpn- problem-statemen t-00 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Farid, Here are my questions on the draft: - where is draft-bpatil-mobileip-sec-guide-01.txt? It does not seem to be at the drafts directory any more. Same for draft-ietf-mobileip-ipsec-use-00.txt? - Are you trying then to come up with similar solutions as in these two drafts? - How is the problem domain different than draft-ietf-mobileip-nat-traversal-03.txt? Especially if you are not considering MNs behind foreign NATs? Regards, Adrangi, Farid wrote: >Hello Serge >Thanks for reading the draft, and providing feedback. Please >see my reply below (marked by Farid Writes>). >Best regards, >Farid > --behcet > From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 5 15:18:23 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13527 for ; Wed, 5 Jun 2002 15:18:22 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28696; Wed, 5 Jun 2002 13:19:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17445; Wed, 5 Jun 2002 12:18:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g55JH5k7025803 for ; Wed, 5 Jun 2002 12:17:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g55JH5Ys025802 for mobile-ip-dist; Wed, 5 Jun 2002 12:17:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g55JH1k7025795 for ; Wed, 5 Jun 2002 12:17:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28519 for ; Wed, 5 Jun 2002 12:17:02 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27763 for ; Wed, 5 Jun 2002 13:18:12 -0600 (MDT) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.48 2002/05/24 00:39:04 root Exp $) with ESMTP id g55JFNe29777 for ; Wed, 5 Jun 2002 19:15:23 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.22 2002/05/24 00:38:22 root Exp $) with SMTP id g55JEnn10123 for ; Wed, 5 Jun 2002 19:14:50 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002060512155025215 ; Wed, 05 Jun 2002 12:15:50 -0700 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 12:16:49 -0700 Message-ID: From: "Adrangi, Farid" To: "'Behcet Sarikaya'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] [mobile-IP]: Comments on draft-ietf-mobileip-vpn- problem-statemen t-00 Date: Tue, 4 Jun 2002 19:24:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Behcet, I downloaded those two draft a while ago -- they might've been obsoleted by now. The solution described in draft-bpatil-mobileip-sec-quide-01.txt was provided for a different problem -- but I found it sort of related to this topic. The draft-ietf-mobileip-nat-traversal-03.txt describes a solution for Mobile IP traversal across NAT gateways (not involving any VPNs). The problem statement draft does not consider any foreign NATs, because 1) we wanted to make the problem statement focused on MIP/VPN. 2) NAT traversal problem has already been solved. However, a solution for MIP/VPN traversal can leverage the draft-ietf-mobileip-nat-traversal-03.txt to provide a Mobile IP VPN or "NAT and VPN" solution. We have also proposed a solution to the MIP/VPN problem in the past, and we are going to submit an update on that draft soon. Hope this helps, please let me know if you have any questions. regards, Farid -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Tuesday, June 04, 2002 4:32 PM To: Adrangi, Farid Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] [mobile-IP]: Comments on draft-ietf-mobileip-vpn- problem-statemen t-00 Hi Farid, Here are my questions on the draft: - where is draft-bpatil-mobileip-sec-guide-01.txt? It does not seem to be at the drafts directory any more. Same for draft-ietf-mobileip-ipsec-use-00.txt? - Are you trying then to come up with similar solutions as in these two drafts? - How is the problem domain different than draft-ietf-mobileip-nat-traversal-03.txt? Especially if you are not considering MNs behind foreign NATs? Regards, Adrangi, Farid wrote: >Hello Serge >Thanks for reading the draft, and providing feedback. Please >see my reply below (marked by Farid Writes>). >Best regards, >Farid > --behcet > From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 6 01:55:26 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20323 for ; Thu, 6 Jun 2002 01:55:26 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05188; Wed, 5 Jun 2002 22:55:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA05147; Wed, 5 Jun 2002 22:54:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g565rvk7027115 for ; Wed, 5 Jun 2002 22:53:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g565rvjj027114 for mobile-ip-dist; Wed, 5 Jun 2002 22:53:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g565rsk7027107 for ; Wed, 5 Jun 2002 22:53:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA22942 for ; Wed, 5 Jun 2002 22:53:56 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA20564 for ; Wed, 5 Jun 2002 23:55:13 -0600 (MDT) Message-ID: <026b01c20d1e$4f7605f0$4e6015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] New Draft on Localized Mobility Management using Fast Handover Date: Wed, 5 Jun 2002 22:52:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit In response to the discussion on the list a few weeks back about using fast handover protocols for localized mobility management, a group of authors have written a draft with an outline about how to do it. Until it shows up in the drafts directory, it is on the Docomo Labs USA web page. To get to it, you must go to the Docomo Labs web site (http://www.docomolabs-usa.com/) then click on Publications, click on 2002, and select the name ("Leveraging Fast Handover Protocols to Support Localized Mobility Management in Mobile IP"). Comments appreciated. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 7 04:37:28 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21198 for ; Fri, 7 Jun 2002 04:37:28 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06888; Fri, 7 Jun 2002 02:37:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA18492; Fri, 7 Jun 2002 01:37:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g578aCk7029625 for ; Fri, 7 Jun 2002 01:36:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g578aClq029624 for mobile-ip-dist; Fri, 7 Jun 2002 01:36:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g578a8k7029617 for ; Fri, 7 Jun 2002 01:36:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA00598 for ; Fri, 7 Jun 2002 01:36:10 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12213 for ; Fri, 7 Jun 2002 02:37:30 -0600 (MDT) Message-ID: <025101c20dfe$23024200$446015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] BOF on Securing Neighbor Discovery Date: Fri, 7 Jun 2002 01:34:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tues. afternoon of IETF 54 13:00-14:00, there will be a BOF held to discuss securing Neighbor Discovery. The BOF description, along with a suggested reading list, will appear when the agenda is posted on the IETF 54 Web page. If you are interested in this problem, please attend. If you would like to speak, please send email to me or Pekka Nikkander (Pekka.Nikander@nomadiclab.com). Note that this issue is especially relevent to Mobile IP, because attacks on Neighbor Discovery are one of the most likely places for MiTM attackes on route optimization security. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 7 05:01:20 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21683 for ; Fri, 7 Jun 2002 05:01:20 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24935; Fri, 7 Jun 2002 03:01:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24164; Fri, 7 Jun 2002 02:01:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5790Sk7029768 for ; Fri, 7 Jun 2002 02:00:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5790SN3029767 for mobile-ip-dist; Fri, 7 Jun 2002 02:00:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5790Ok7029760 for ; Fri, 7 Jun 2002 02:00:25 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA23905 for ; Fri, 7 Jun 2002 02:00:26 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29842 for ; Fri, 7 Jun 2002 02:00:25 -0700 (PDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g57922a00765 for ; Fri, 7 Jun 2002 12:02:02 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Jun 2002 12:00:24 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 7 Jun 2002 12:00:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] BOF on Securing Neighbor Discovery Date: Fri, 7 Jun 2002 12:00:27 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC65398@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] BOF on Securing Neighbor Discovery Thread-Index: AcIN/tqh9iGHaGUMTgWxQ34ph+HBSQAArFZw To: , X-OriginalArrivalTime: 07 Jun 2002 09:00:24.0548 (UTC) FILETIME=[C2C8A240:01C20E01] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5790Pk7029761 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi James, > On Tues. afternoon of IETF 54 13:00-14:00, there will be a BOF held to > discuss securing Neighbor Discovery. The BOF description, along with a > suggested reading list, will appear when the agenda is posted on the > IETF 54 Web page. A heads-up on the reading list would be helpful. John From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 7 11:54:46 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01796 for ; Fri, 7 Jun 2002 11:54:45 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26622; Fri, 7 Jun 2002 09:54:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19375; Fri, 7 Jun 2002 08:54:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57Frnk7000420 for ; Fri, 7 Jun 2002 08:53:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57FrnIj000419 for mobile-ip-dist; Fri, 7 Jun 2002 08:53:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57Frkk7000412 for ; Fri, 7 Jun 2002 08:53:46 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09613 for ; Fri, 7 Jun 2002 08:53:47 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00110 for ; Fri, 7 Jun 2002 08:53:47 -0700 (PDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g57Fv4U25506 for ; Fri, 7 Jun 2002 10:57:05 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Jun 2002 10:53:46 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 7 Jun 2002 10:52:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Re: I-D ACTION:draft-ietf-mobileip-nat-traversal-03.txt Date: Fri, 7 Jun 2002 10:52:25 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12EED@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] Re: I-D ACTION:draft-ietf-mobileip-nat-traversal-03.txt Thread-Index: AcIK968LI8mV0+/VSSCrVcahHB23fADQ35aQ To: , X-OriginalArrivalTime: 07 Jun 2002 15:52:25.0988 (UTC) FILETIME=[51E90440:01C20E3B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g57Frkk7000413 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Bjorn, Thanks for noting the conflict with the type numbers planned for interop use in the IANA section. The IANA section will be updated in the new version of the I-D. -Basavaraj > > On Mon, Jun 03 2002, at 07:37:47 -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 NAT/NAPT Traversal using > UDP Tunnelling > > Author(s) : H. Levkowetz, S. Vaarala > > Filename : draft-ietf-mobileip-nat-traversal-03.txt > > Pages : 31 > > Date : 31-May-02 > > > > Section 7, "IANA Considerations" says: > > Likewise, the values for the "Tunnel Request" and "Tunnel Reply" > extension type fields in Section 3.1 and Section 3.2 must > be assigned > from the numbering space defined for Mobile IP extensions as defined > in RFC 3220 [10]. For interoperability testing until values are > assigned, the values 41 and 141 are suggested. > > > Type 41 has been used for the Unsolicitated MN-FA Key Material > type for quite some time. I suggest the the recommended values for > interoperability testing are 51 and 151 respectively. These values > have previously been used by at least three MIP implementations for > interoperabilty testing. > > I am about to put up a web page of type and subtype numbers that have > not yet been blessed by the IANA. This should ease interoperability > testing. I will inform the URL to this list when I have the page done. > > Regards, > Björn > > -- > Björn Andersson +358 > 50 341 2556 > Lifix Systems Oy PGP > id 5AFC144B > Innopoli 2, Tekniikantie 14, FIN-02150 Espoo > From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 7 13:07:53 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04229 for ; Fri, 7 Jun 2002 13:07:52 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10334; Fri, 7 Jun 2002 11:08:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19588; Fri, 7 Jun 2002 10:07:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57H6ak7000622 for ; Fri, 7 Jun 2002 10:06:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57H6Z70000621 for mobile-ip-dist; Fri, 7 Jun 2002 10:06:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57H6Wk7000614 for ; Fri, 7 Jun 2002 10:06:32 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19205 for ; Fri, 7 Jun 2002 10:06:35 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07681 for ; Fri, 7 Jun 2002 10:06:35 -0700 (PDT) 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 KAA28928; Fri, 7 Jun 2002 10:06:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g57H6Yw28904; Fri, 7 Jun 2002 10:06:34 -0700 X-mProtect: <200206071706> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.71, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMzKhM1; Fri, 07 Jun 2002 10:06:31 PDT Message-ID: <3D00E805.315F5877@iprg.nokia.com> Date: Fri, 07 Jun 2002 10:06:13 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Madhavi W. Chandra" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC3012bis clarification References: <20020603122536.B578@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Madhavi, "Madhavi W. Chandra" wrote: > Hi Charlie and Pat, > > Please clarify... > > In Section 3.2, it says... > > "If the Challenge extension is not removed, it MUST precede the > Foreign-Home Authentication extension." > > Is this mandating that the challenge extension be protected by the FHAE, > or is it mandating the order of the extensions? > ................. > Maybe the text can be clarified to avoid any confusion. How about: "If the Challenge extension is not removed, it MUST precede the Foreign-Home Authentication extension (if present)." Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 7 13:19:37 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04688 for ; Fri, 7 Jun 2002 13:19:36 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14851; Fri, 7 Jun 2002 10:19:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19530; Fri, 7 Jun 2002 10:19:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57HI9k7000775 for ; Fri, 7 Jun 2002 10:18:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57HI9os000774 for mobile-ip-dist; Fri, 7 Jun 2002 10:18:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57HI5k7000767 for ; Fri, 7 Jun 2002 10:18:05 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23476 for ; Fri, 7 Jun 2002 10:18:06 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25563 for ; Fri, 7 Jun 2002 11:18:05 -0600 (MDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g57HHrHs014242; Fri, 7 Jun 2002 10:17:53 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA06937; Fri, 7 Jun 2002 13:17:53 -0400 (EDT) Date: Fri, 7 Jun 2002 13:17:53 -0400 From: "Madhavi W. Chandra" To: Charlie Perkins Cc: "Madhavi W. Chandra" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC3012bis clarification Message-ID: <20020607131753.A6933@cisco.com> References: <20020603122536.B578@cisco.com> <3D00E805.315F5877@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3D00E805.315F5877@iprg.nokia.com>; from charliep@iprg.nokia.com on Fri, Jun 07, 2002 at 10:06:13AM -0700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Charlie, Looks good...easy fix...and much clearer. Regards, Madhavi On Fri, Jun 07, 2002 at 10:06:13AM -0700, Charlie Perkins wrote: > > Hello Madhavi, > > "Madhavi W. Chandra" wrote: > > > Hi Charlie and Pat, > > > > Please clarify... > > > > In Section 3.2, it says... > > > > "If the Challenge extension is not removed, it MUST precede the > > Foreign-Home Authentication extension." > > > > Is this mandating that the challenge extension be protected by the FHAE, > > or is it mandating the order of the extensions? > > ................. > > Maybe the text can be clarified to avoid any confusion. > > How about: > "If the Challenge extension is not removed, it MUST precede the > Foreign-Home Authentication extension (if present)." > > Regards, > Charlie P. > From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 7 13:50:47 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05593 for ; Fri, 7 Jun 2002 13:50:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29523; Fri, 7 Jun 2002 11:52:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29893; Fri, 7 Jun 2002 10:50:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57HnRk7000945 for ; Fri, 7 Jun 2002 10:49:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57HnRf5000944 for mobile-ip-dist; Fri, 7 Jun 2002 10:49:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57HnOk7000937 for ; Fri, 7 Jun 2002 10:49:24 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29357 for ; Fri, 7 Jun 2002 10:49:24 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28705 for ; Fri, 7 Jun 2002 11:50:46 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 93A016A909; Fri, 7 Jun 2002 20:49:17 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A529F6A907; Fri, 7 Jun 2002 20:49:15 +0300 (EEST) Message-ID: <3D00F266.5060409@kolumbus.fi> Date: Fri, 07 Jun 2002 20:50:30 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: arvind.sevalkar@lntinfotech.com Cc: Francis Dupont , mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Binding Error Message and HAO References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm trying figure out if we have already closed this issue. (http://www.piuha.net./~jarkko/publications/mipv6/issues/issue33.txt) The original question was what to fill in when there is no HAO. In another discussion on the list we have noted that the HAO can be included in BUs to the CN. We then discussed whether we could simply drop packets that don't have a HAO, and not even respond with a BE. Arvind noted that if the MH type is unrecognized, it is hard to know if a HAO should have been present or not. He proposed that the home address be placed in an option that could be carried by the BE when necessary. Note that the HoT message goes via the home agent and does not have a home address option. The source of the packet is the home address. So, what happens if the CN does not support this message, or some similar future message? If we are strict about the no-BE-if-no-HAO rule then we can't send an error. My suggestions is therefore that a new mobility option should be created, the "Home Address mobility option" (can this be mistaken for the HAO -- any ideas for a better name?). This new mobility option would be included when the BE is sent with Status 1. Another alternative is to allow the home address field to be zero in the BE message, if HAO was not present in the offending message. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 7 15:26:33 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10055 for ; Fri, 7 Jun 2002 15:26:33 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20178; Fri, 7 Jun 2002 13:28:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10582; Fri, 7 Jun 2002 12:26:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57JPQk7001219 for ; Fri, 7 Jun 2002 12:25:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57JPQvi001218 for mobile-ip-dist; Fri, 7 Jun 2002 12:25:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57JPNk7001211 for ; Fri, 7 Jun 2002 12:25:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05485 for ; Fri, 7 Jun 2002 12:25:20 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA19717 for ; Fri, 7 Jun 2002 13:25:19 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g57JPg625847 for ; Fri, 7 Jun 2002 22:25:43 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Jun 2002 22:25:17 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 7 Jun 2002 22:25:17 +0300 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 7 Jun 2002 14:25:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Binding Error Message and HAO Date: Fri, 7 Jun 2002 14:25:14 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12EFD@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] Binding Error Message and HAO Thread-Index: AcIOS9D8z12ySx2rSFqvSI3p8vhKzwADSpew To: , Cc: , X-OriginalArrivalTime: 07 Jun 2002 19:25:15.0134 (UTC) FILETIME=[0CEA11E0:01C20E59] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g57JPNk7001212 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit >I'm trying figure out if we have already closed this issue. >(http://www.piuha.net./~jarkko/publications/mipv6/issues/issue33.txt) > >The original question was what to fill in when there is no HAO. >In another discussion on the list we have noted that the HAO >can be included in BUs to the CN. We then discussed whether we >could simply drop packets that don't have a HAO, and not even >respond with a BE. Arvind noted that if the MH type is unrecognized, >it is hard to know if a HAO should have been present or not. He >proposed that the home address be placed in an option that could >be carried by the BE when necessary. > >Note that the HoT message goes via the home agent and >does not have a home address option. The source of the >packet is the home address. So, what happens if the CN does >not support this message, or some similar future message? If the CN does not support this message and RR is mandated as the baseline RO mechanism for MIPv6, then obviously the CN does not have the functionality required for supporting RO. I believe emphasizing the need for CNs to implement RO functionality should be strongly recommended (in lieu of making it a MUST). >If we are strict about the no-BE-if-no-HAO rule then we can't >send an error. Capability to send an error message is required. > >My suggestions is therefore that a new mobility option should >be created, the "Home Address mobility option" (can this be >mistaken for the HAO -- any ideas for a better name?). This >new mobility option would be included when the BE is sent >with Status 1. > >Another alternative is to allow the home address field to be >zero in the BE message, if HAO was not present in the offending >message. I like Option 2 (home address zero). > >Jari -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 7 16:47:33 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12068 for ; Fri, 7 Jun 2002 16:47:32 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09707; Fri, 7 Jun 2002 14:47:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08520; Fri, 7 Jun 2002 13:47:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57KkBk7001405 for ; Fri, 7 Jun 2002 13:46:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57KkBjO001404 for mobile-ip-dist; Fri, 7 Jun 2002 13:46:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57Kk8k7001397 for ; Fri, 7 Jun 2002 13:46:08 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08108 for ; Fri, 7 Jun 2002 13:46:10 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08826 for ; Fri, 7 Jun 2002 14:46:09 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 951F26A907; Fri, 7 Jun 2002 23:46:03 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 42E7F6A909; Fri, 7 Jun 2002 23:46:01 +0300 (EEST) Message-ID: <3D011BD3.20609@kolumbus.fi> Date: Fri, 07 Jun 2002 23:47:15 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Samita Chakrabarti Cc: mobile-ip@sunroof.eng.sun.com, samita@eng.sun.com Subject: Re: [mobile-ip] Relationship between RR_BINDING and COOKIE_LIFE References: <200206010232.g512Wn6U600086@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Samita Chakrabarti wrote: > It may have been discussed before, sorry if I missed the discussion. > > I am a bit unclear on the actual binding lifetime as section 14.3 > of draft-17 states: > However, > one difference is that in basic IPv6 an on-path attacker must be > constantly present on the link or the path (e.g., in order to perform > a man-in-the-middle attack), whereas with Mobile IPv6 an attacker > can leave an existing binding behind, even after it is no longer on > the link or on the path [23]. For this reason, this specification > limits the validity of bindings authorized by return routability to > a maximum of MAX_COOKIE_LIFE + MAX_RR_BINDING_LIFE seconds after the > last routability check has been performed. > > > Again in section 5.5.7 states: > However, it is recommended that correspondent > nodes try to keep these cookies acceptable as long as possible and > SHOULD NOT accept them beyond MAX_COOKIE_LIFE seconds. > > > So, if RR has been performed at time t and then I expect that > the refresh should be performed before t+MAX_COOKIE_LIFE in order > to use the same cookie(s). I think the intention of the "reusable" cookies is that you can change your position quickly and reuse a cookie from an old position. With the way they are currently defined, you might actually use them also for refreshing the same binding. This wasn't the intention however. > However, if we keep the binding valid beyond t+MAX_COOKIE_LIFE > period, then anyway MN needs to do RR check again after cookie > lifetime expires. So, my point is what is the purpose of having > extended max binding life that is: > MAX_COOKIE_LIFE + MAX_RR_BINDING_LIFE ? > > Does it mean that frequency of RR check could be > MAX_COOKIE_LIFE + MAX_RR_BINDING_LIFE in the worst case. > > That means a BU can be as infrequent as 300 +240 = 9 min. Yes. Section 14 seems a bit vague on this point. But the intention was that the lifetime of any CN binding, when you create it, would be limited to MAX_RR_BINDING_LIFE s. Now, you can still create this binding with cookies that are MAX_COOKIE_LIFE s old. Therefore, BUs must always be sent at least every MAX_RR_BINDING_LIFE seconds. Note that it would be possible to have the CNs inform the MNs about the remaining cookie lifetime, or have the CN calculate real lifetimes based on how old the cookies are. I'm not sure the complexity buys enough. It's easier implementation-wise to keep the cookie and binding lifetimes separate. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 7 16:53:02 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12230 for ; Fri, 7 Jun 2002 16:53:01 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02485; Fri, 7 Jun 2002 13:52:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10494; Fri, 7 Jun 2002 13:51:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57Kotk7001490 for ; Fri, 7 Jun 2002 13:50:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57KosaL001489 for mobile-ip-dist; Fri, 7 Jun 2002 13:50:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57Kopk7001482 for ; Fri, 7 Jun 2002 13:50:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13665 for ; Fri, 7 Jun 2002 13:50:52 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02005 for ; Fri, 7 Jun 2002 13:50:52 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 7BA726A909; Fri, 7 Jun 2002 23:50:51 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A68FC6A907; Fri, 7 Jun 2002 23:50:49 +0300 (EEST) Message-ID: <3D011CF3.1070000@kolumbus.fi> Date: Fri, 07 Jun 2002 23:52:03 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Cc: arvind.sevalkar@lntinfotech.com, Francis.Dupont@enst-bretagne.fr, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Binding Error Message and HAO References: <697DAA22C5004B4596E033803A7CEF44A12EFD@daebe007.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Basavaraj.Patil@nokia.com wrote: > If the CN does not support this message and RR is mandated as the > baseline RO mechanism for MIPv6, then obviously the CN does not have > the functionality required for supporting RO. I believe emphasizing > the need for CNs to implement RO functionality should be strongly > recommended (in lieu of making it a MUST). HoTI was a good example for showing a message that doesn't use HAO. Perhaps it wasn't as good example for showing how the CN must be able to refuse such a message. Still, there might be some future message for some mobility related purpose that also doesn't use HAO. >>My suggestions is therefore that a new mobility option should >>be created, the "Home Address mobility option" (can this be >>mistaken for the HAO -- any ideas for a better name?). This >>new mobility option would be included when the BE is sent >>with Status 1. >> >>Another alternative is to allow the home address field to be >>zero in the BE message, if HAO was not present in the offending >>message. > > I like Option 2 (home address zero). It would be simpler, yes. I don't feel strongly either way. Anyone else? Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 7 17:27:59 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13612 for ; Fri, 7 Jun 2002 17:27:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19333; Fri, 7 Jun 2002 14:27:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22378; Fri, 7 Jun 2002 14:27:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57LQAk7001639 for ; Fri, 7 Jun 2002 14:26:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g57LQAjX001638 for mobile-ip-dist; Fri, 7 Jun 2002 14:26:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g57LQ7k7001631 for ; Fri, 7 Jun 2002 14:26:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16957 for ; Fri, 7 Jun 2002 14:26:08 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA10995 for ; Fri, 7 Jun 2002 15:26:07 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id A53076A909; Sat, 8 Jun 2002 00:26:00 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 65F0D6A907; Sat, 8 Jun 2002 00:25:58 +0300 (EEST) Message-ID: <3D012530.7010406@kolumbus.fi> Date: Sat, 08 Jun 2002 00:27:12 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: Francis Dupont , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] when the MN returns home References: <200206041327.g54DRfT68671@givry.rennes.enst-bretagne.fr> <3CFCF6FC.56446139@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> 5. the current spec already talks about how to obtain the link layer >> address of the HA, if the router advertisment does not contain the >> source link layer address option or if the router which sent it is >> not the HA on the link. >> >>=> two remarks: >> - the current spec is wrong (some olders are correct so this is easy to fix) >> - if the MN link-local address is defended then the defender (the HA?) >> must put its link-layer address in the NA. The problem here is not >> to get the link-layer address, it is to recognize it is the HA one. >> > > oops.. I thought the spec has been fixed. yes it is still broken. Assigned issue #44. > anyway here is how you can do it. this is from a mail I had sent > in Aug 2001. this has been tested at the interops. Looks good to me. Vladislav Yasevich wrote: > As you the spec states it is a SHOULD. If you find a very good reason > (which you did) to not do that, you can overide the SHOULD behavior. I agree. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 7 21:59:27 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19880 for ; Fri, 7 Jun 2002 21:59:26 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29251; Fri, 7 Jun 2002 19:59:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA29218; Fri, 7 Jun 2002 18:59:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g581w8k7002096 for ; Fri, 7 Jun 2002 18:58:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g581w7lP002095 for mobile-ip-dist; Fri, 7 Jun 2002 18:58:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g581w4k7002088 for ; Fri, 7 Jun 2002 18:58:04 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.4+Sun/8.12.4) with SMTP id g581w5wU321117; Fri, 7 Jun 2002 18:58:06 -0700 (PDT) Message-Id: <200206080158.g581w5wU321117@jurassic.eng.sun.com> Date: Fri, 7 Jun 2002 19:00:33 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Binding Error Message and HAO To: jari.arkko@kolumbus.fi Cc: arvind.sevalkar@lntinfotech.com, Francis.Dupont@enst-bretagne.fr, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: GILLAYCnCpOu5TAK6JFTPQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > I'm trying figure out if we have already closed this issue. > (http://www.piuha.net./~jarkko/publications/mipv6/issues/issue33.txt) > > The original question was what to fill in when there is no HAO. > In another discussion on the list we have noted that the HAO > can be included in BUs to the CN. We then discussed whether we > could simply drop packets that don't have a HAO, and not even > respond with a BE. Arvind noted that if the MH type is unrecognized, > it is hard to know if a HAO should have been present or not. He > proposed that the home address be placed in an option that could > be carried by the BE when necessary. > If the CN is an old CN and does not understand MIPv6 RO, it should generate ICMP PARAM problem (section 11.5.2) Both HOTI/COTI messages don't have HAO option. So, if the MH type is unknown, it makes sense to either drop them or send rate limited ICMP PARAM problems in case of HOTI/COTI error messages. If MH type is known (HOTI/COTI) and there is other problem in the option, then CN can send BE with home-addr=0. > Note that the HoT message goes via the home agent and > does not have a home address option. The source of the > packet is the home address. So, what happens if the CN does > not support this message, or some similar future message? If > we are strict about the no-BE-if-no-HAO rule then we can't > send an error. > This rule may make sense for BUs only, but not for HOTI/COTI message, I think. > My suggestions is therefore that a new mobility option should > be created, the "Home Address mobility option" (can this be > mistaken for the HAO -- any ideas for a better name?). This > new mobility option would be included when the BE is sent > with Status 1. > There is not much strong reason to add yet another new mobility option for this cause. > Another alternative is to allow the home address field to be > zero in the BE message, if HAO was not present in the offending > message. This seems to be a reasonable solution, if the offending message does not contain HAO and we know it's a mobility message. -Samita From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 8 03:08:38 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02587 for ; Sat, 8 Jun 2002 03:08:37 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26215; Sat, 8 Jun 2002 00:08:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA11683; Sat, 8 Jun 2002 00:08:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5877Bk7002529 for ; Sat, 8 Jun 2002 00:07:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5877Bf7002528 for mobile-ip-dist; Sat, 8 Jun 2002 00:07:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g58778k7002521 for ; Sat, 8 Jun 2002 00:07:08 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24337 for ; Sat, 8 Jun 2002 00:07:07 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01508 for ; Sat, 8 Jun 2002 01:07:07 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 36D306A909; Sat, 8 Jun 2002 10:07:06 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 26BD16A907; Sat, 8 Jun 2002 10:07:04 +0300 (EEST) Message-ID: <3D01AD63.7000505@kolumbus.fi> Date: Sat, 08 Jun 2002 10:08:19 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Samita Chakrabarti Cc: arvind.sevalkar@lntinfotech.com, Francis.Dupont@enst-bretagne.fr, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Binding Error Message and HAO References: <200206080158.g581w5wU321117@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Samita Chakrabarti wrote: >>Another alternative is to allow the home address field to be >>zero in the BE message, if HAO was not present in the offending >>message. > > This seems to be a reasonable solution, if the offending message does not > contain HAO and we know it's a mobility message. Seems like folks prefer this approach. Let's do it. Jari From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 9 03:39:25 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27372 for ; Sun, 9 Jun 2002 03:39:19 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA29679; Sun, 9 Jun 2002 01:39:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA14522; Sun, 9 Jun 2002 00:39:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g597bmk7003930 for ; Sun, 9 Jun 2002 00:37:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g597bmOX003929 for mobile-ip-dist; Sun, 9 Jun 2002 00:37:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g597bik7003922 for ; Sun, 9 Jun 2002 00:37:44 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA29142 for ; Sun, 9 Jun 2002 00:37:47 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA17148 for ; Sun, 9 Jun 2002 01:37:46 -0600 (MDT) Message-ID: <013d01c20f88$4fca92c0$1e6015ac@T23KEMPF> From: "James Kempf" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65398@esebe004.NOE.Nokia.com> Subject: Re: [mobile-ip] BOF on Securing Neighbor Discovery Date: Sun, 9 Jun 2002 00:24:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here's the reading list so far: RFC 2461 draft-kempf-netaccess-threats-00.txt draft-arkko-manual-icmpv6-sas-00.txt draft-roe-mobileip-updateauth-01.txt I know there is at least one effort underway to write a draft on using CGAs, possibly others as well, and hopefully at least one draft complete by the 00 drafts deadline. jak ----- Original Message ----- From: To: ; Sent: Friday, June 07, 2002 2:00 AM Subject: RE: [mobile-ip] BOF on Securing Neighbor Discovery > Hi James, > > > On Tues. afternoon of IETF 54 13:00-14:00, there will be a BOF held to > > discuss securing Neighbor Discovery. The BOF description, along with a > > suggested reading list, will appear when the agenda is posted on the > > IETF 54 Web page. > > A heads-up on the reading list would be helpful. > > John > From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 9 15:02:15 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06452 for ; Sun, 9 Jun 2002 15:02:14 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15452; Sun, 9 Jun 2002 12:01:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21015; Sun, 9 Jun 2002 12:01:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59J0kk7004829 for ; Sun, 9 Jun 2002 12:00:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g59J0k3Y004828 for mobile-ip-dist; Sun, 9 Jun 2002 12:00:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g59J0hk7004821 for ; Sun, 9 Jun 2002 12:00:43 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20787 for ; Sun, 9 Jun 2002 12:00:46 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29076 for ; Sun, 9 Jun 2002 13:00:45 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 0E89A6A901; Sun, 9 Jun 2002 22:00:39 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5F7926A905; Sun, 9 Jun 2002 22:00:31 +0300 (EEST) Message-ID: <3D03A619.2000300@kolumbus.fi> Date: Sun, 09 Jun 2002 22:01:45 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf Cc: john.loughney@nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BOF on Securing Neighbor Discovery References: <0C1353ABB1DEB74DB067ADFF749C4EEFC65398@esebe004.NOE.Nokia.com> <013d01c20f88$4fca92c0$1e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James, perhaps you could post a link to draft-kempf-ipng-netaccess-threats-01.txt as that seems expired. The rest of the reading list has also some slightly changed URLs...one draft has been updated and another expired years ago. http://www.arkko.com/publications/draft-arkko-manual-icmpv6-sas-00.txt http://www.ietf.org/internet-drafts/draft-roe-mobileip-updateauth-02.txt Jari From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 9 23:12:33 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12290 for ; Sun, 9 Jun 2002 23:12:33 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17733; Sun, 9 Jun 2002 20:12:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA00714; Sun, 9 Jun 2002 20:12:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A3B5k7005457 for ; Sun, 9 Jun 2002 20:11:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5A3B5gJ005456 for mobile-ip-dist; Sun, 9 Jun 2002 20:11:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5A3B2k7005448 for ; Sun, 9 Jun 2002 20:11:02 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA00413 for ; Sun, 9 Jun 2002 20:11:06 -0700 (PDT) Received: from mx1.ustc.edu.cn ([61.132.182.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17385 for ; Sun, 9 Jun 2002 20:11:04 -0700 (PDT) Received: from ylpeng (infonet.ipv6.ustc.edu.cn [202.38.75.75]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id LAA29109 for ; Mon, 10 Jun 2002 11:02:58 +0800 Message-ID: <001d01c2102c$72174bd0$0705a8c0@ylpeng> From: "Peng YanLin" To: Subject: [mobile-ip] what should be the HI message of anticipate handove in fmipv6 Date: Mon, 10 Jun 2002 11:10:59 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C2106F.802B4990" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C2106F.802B4990 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGkgYWxsLA0KICAgIEkgcmVhbGxseSB3YW50IHRvIGtub3cgaG93IGNhbiBJIGZpbGwgdGhlIGZp ZWxkcyBvZiBISSBtZXNzYWdlIG9mIGFudGljaXBhdGVkIGhhbmRvdmVyIGluIGZhc3QgbWlwdjYu IFNob3VsZCBJIGxldCB0aGUgJ0gnIGFuZCAnVCcgYml0cyBiZQ0KYmxhbms/ICdIJyBhbmQgJ1Qn IGJpdHMgYXJlIHJlc2VydmVkIGZvciB0dW5uZWwtYmFzZWQgaGFuZG92ZXI/DQo= ------=_NextPart_000_001A_01C2106F.802B4990 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yNzE2LjIyMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5oaSBhbGwsPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgcmVhbGxseSB3YW50 IHRvIGtub3cgaG93IGNhbiBJIGZpbGwgdGhlIA0KZmllbGRzIG9mIEhJIG1lc3NhZ2Ugb2YgYW50 aWNpcGF0ZWQgaGFuZG92ZXIgaW4gZmFzdCBtaXB2Ni4gU2hvdWxkIEkgbGV0IHRoZSAnSCcgDQph bmQmbmJzcDsnVCcgYml0cyBiZTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmJsYW5r PyAnSCcgYW5kICdUJyBiaXRzIGFyZSByZXNlcnZlZCBmb3IgdHVubmVsLWJhc2VkIA0KaGFuZG92 ZXI/PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_001A_01C2106F.802B4990-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 10 07:18:16 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28486 for ; Mon, 10 Jun 2002 07:18:15 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24311; Mon, 10 Jun 2002 05:18:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19563; Mon, 10 Jun 2002 04:18:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ABH3k7006693 for ; Mon, 10 Jun 2002 04:17:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5ABH3tE006692 for mobile-ip-dist; Mon, 10 Jun 2002 04:17:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ABGxk7006685 for ; Mon, 10 Jun 2002 04:16:59 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19422 for ; Mon, 10 Jun 2002 04:17:02 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18561 for ; Mon, 10 Jun 2002 05:17:01 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28168; Mon, 10 Jun 2002 07:16:26 -0400 (EDT) Message-Id: <200206101116.HAA28168@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-nat-traversal-04.txt Date: Mon, 10 Jun 2002 07:16:26 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --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 NAT/NAPT Traversal using UDP Tunnelling Author(s) : H. Levkowetz, S. Vaarala Filename : draft-ietf-mobileip-nat-traversal-04.txt Pages : 31 Date : 07-Jun-02 Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-nat-traversal-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-nat-traversal-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: <20020607132512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-nat-traversal-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-nat-traversal-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020607132512.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 10 08:46:53 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01449 for ; Mon, 10 Jun 2002 08:46:53 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23438; Mon, 10 Jun 2002 06:47:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA03158; Mon, 10 Jun 2002 05:45:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ACixk7007050 for ; Mon, 10 Jun 2002 05:44:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5ACix7T007049 for mobile-ip-dist; Mon, 10 Jun 2002 05:44:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ACitk7007042 for ; Mon, 10 Jun 2002 05:44:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA12471 for ; Mon, 10 Jun 2002 05:44:59 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA25589 for ; Mon, 10 Jun 2002 06:44:58 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01350; Mon, 10 Jun 2002 08:43:35 -0400 (EDT) Message-Id: <200206101243.IAA01350@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-kempf-mobileip-fastho-lmm-00.txt Date: Mon, 10 Jun 2002 08:43:35 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Leveraging Fast Handover Protocols to Support Localized Mobility Management in Mobile IP Author(s) : J. Kempf et al. Filename : draft-kempf-mobileip-fastho-lmm-00.txt Pages : 7 Date : 05-Jun-02 Longstanding work in the Mobile IP Working Group has been directed at enhancements to Mobile IPv4 and Mobile IPv6 to reduce the amount of latency in binding updates sent to the Home Agent and, for route- optimization, Correspondent Nodes, upon Care of Address change. In cases where the Home Agent and Mobile Node are separated by continental or transcontinental distances, this latency can be rather high and can interfere with the Mobile Node receiving its traffic upon Care of Address change when break-before-make handover is required. This draft discusses a solution that leverages the more recent fast handover work and mechanisms already described in the protocol specifications for Mobile IPv6 and the route optimization extension of Mobile IPv4. This alternative has certain simplicity, scalability, and robustness advantages over a design that incorporates additional mobility agents, and requires no additional mechanism in the network or change to the Mobile Node beyond that required to support these protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kempf-mobileip-fastho-lmm-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-kempf-mobileip-fastho-lmm-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-kempf-mobileip-fastho-lmm-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: <20020605094730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kempf-mobileip-fastho-lmm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kempf-mobileip-fastho-lmm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020605094730.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 10 13:27:12 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14894 for ; Mon, 10 Jun 2002 13:27:12 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16606; Mon, 10 Jun 2002 11:27:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23375; Mon, 10 Jun 2002 10:27:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AHQEk7007570 for ; Mon, 10 Jun 2002 10:26:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AHQEZ8007569 for mobile-ip-dist; Mon, 10 Jun 2002 10:26:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AHQAk7007562 for ; Mon, 10 Jun 2002 10:26:10 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01292 for ; Mon, 10 Jun 2002 10:26:12 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25796 for ; Mon, 10 Jun 2002 11:26:12 -0600 (MDT) 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 KAA13136; Mon, 10 Jun 2002 10:26:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5AHQBD15769; Mon, 10 Jun 2002 10:26:11 -0700 X-mProtect: <200206101726> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZWJ7ov; Mon, 10 Jun 2002 10:26:08 PDT Message-ID: <3D04E130.5CA2EA20@iprg.nokia.com> Date: Mon, 10 Jun 2002 10:26:08 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Peng YanLin CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] what should be the HI message of anticipate handove in fmipv6 References: <001d01c2102c$72174bd0$0705a8c0@ylpeng> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Peng YanLin, Peng YanLin wrote: > hi all, I reallly want to know how can I fill the fields of HI > message of anticipated handover in fast mipv6. Should I let the 'H' > and 'T' bits beblank? 'H' and 'T' bits are reserved for tunnel-based > handover? I am editing the draft. You may wish to wait until the next version comes out.. Regards, -Rajeev From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 10 15:17:38 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20445 for ; Mon, 10 Jun 2002 15:17:38 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03291; Mon, 10 Jun 2002 13:19:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14160; Mon, 10 Jun 2002 12:17:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AJEpk7008096 for ; Mon, 10 Jun 2002 12:14:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5AJEpEG008095 for mobile-ip-dist; Mon, 10 Jun 2002 12:14:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5AJEmk7008088 for ; Mon, 10 Jun 2002 12:14:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05797 for ; Mon, 10 Jun 2002 12:14:52 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17599 for ; Mon, 10 Jun 2002 12:14:52 -0700 (PDT) Message-ID: <008101c210b2$d5d822d0$246015ac@T23KEMPF> From: "James Kempf" To: "Peng YanLin" , References: <001d01c2102c$72174bd0$0705a8c0@ylpeng> Subject: Re: [mobile-ip] what should be the HI message of anticipate handove in fmipv6 Date: Mon, 10 Jun 2002 12:12:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yes. They are only set for tunnel-based handover. jak ----- Original Message ----- From: "Peng YanLin" To: Sent: Sunday, June 09, 2002 8:10 PM Subject: [mobile-ip] what should be the HI message of anticipate handove in fmipv6 > hi all, > I reallly want to know how can I fill the fields of HI message of anticipated handover in fast mipv6. Should I let the 'H' and 'T' bits be > blank? 'H' and 'T' bits are reserved for tunnel-based handover? > From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 10 20:28:55 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29849 for ; Mon, 10 Jun 2002 20:28:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20128; Mon, 10 Jun 2002 17:27:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05458; Mon, 10 Jun 2002 17:27:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B0O7k7008779 for ; Mon, 10 Jun 2002 17:24:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5B0O6xv008778 for mobile-ip-dist; Mon, 10 Jun 2002 17:24:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B0O4k7008771 for ; Mon, 10 Jun 2002 17:24:04 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA04709 for ; Mon, 10 Jun 2002 17:24:08 -0700 (PDT) From: piechoci@mail.colorado.edu Received: from farley.colorado.edu (farley.Colorado.EDU [128.138.129.53]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26718 for ; Mon, 10 Jun 2002 17:24:08 -0700 (PDT) Received: (from nobody@localhost) by farley.colorado.edu (8.11.2/8.11.2/ITS-5.0/webmail) id g5B0O7T15983; Mon, 10 Jun 2002 18:24:07 -0600 (MDT) To: nsis@ietf.org, seamoby@ietf.org, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] master's thesis on RSVP/IntServ in mobile networks Message-ID: <1023755047.3d05432724479@webmail.colorado.edu> Date: Mon, 10 Jun 2002 18:24:07 -0600 (MDT) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.4 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Fragments of my master's thesis titled "Protocol Enhancements Required to Provide IP-based QoS in Mobile Networks" are posted on http://www3.sympatico.ca/ra.piechocinski/RSVP.htm I appreciate any comments and feedback on IntServ/RSVP additions described in that document. Please sent your comments to maciej.piechocinski@colorado.edu. Two aspects of QoS are considered: -RSVP signaling of traffic characterization parameters required by wireless environment -dynamic adaptation of IntServ/RSVP to changing resource availability in the network Regards, Maciej Piechocinski From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 11 10:34:34 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26537 for ; Tue, 11 Jun 2002 10:34:33 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21672; Tue, 11 Jun 2002 07:34:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23596; Tue, 11 Jun 2002 07:34:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BEWmk7010109 for ; Tue, 11 Jun 2002 07:32:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BEWmjv010108 for mobile-ip-dist; Tue, 11 Jun 2002 07:32:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BEWik7010101 for ; Tue, 11 Jun 2002 07:32:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26668 for ; Tue, 11 Jun 2002 07:32:47 -0700 (PDT) Received: from Mistralsoftware.com (ptil-243-146-ban.primus-india.net [203.196.146.243] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01520 for ; Tue, 11 Jun 2002 08:32:44 -0600 (MDT) Received: from anji [192.168.15.19] by mistralsoftware.com [192.168.10.12] with SMTP (MDaemon.PRO.v5.0.0.R) for ; Tue, 11 Jun 2002 20:01:44 +0530 Message-ID: <00cc01c21152$b887e760$130fa8c0@anji> From: "Anjaneyulu" To: "MIPWorking Group" Subject: [mobile-ip] MIPv6 - selection of default router ??? Date: Tue, 11 Jun 2002 19:47:29 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C9_01C21180.D233EE60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.15.19 X-Return-Path: Anjaneyulu@Mistralsoftware.com X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00C9_01C21180.D233EE60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, When the Mobile Node is in the Home Network, which routers will it = select as candidates for default router. As home agents are also candidated for default routers. I have a doubt that when the mobility feature is enabled on a = host(Mobile Node) , should he only consider entries in the home agents = list as the default router or can it also opt from default router list. Regards, Anj ------=_NextPart_000_00C9_01C21180.D233EE60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
When the Mobile Node is in the Home = Network, which=20 routers will it select as candidates for default router.
As home agents are also candidated for = default=20 routers.
I have a doubt that when the = mobility feature=20 is enabled on a host(Mobile Node) , should he only consider entries = in the=20 home agents list as the default router or can it also opt from default = router=20 list.
 
Regards,
Anj
------=_NextPart_000_00C9_01C21180.D233EE60-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 11 12:41:41 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02350 for ; Tue, 11 Jun 2002 12:41:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24469; Tue, 11 Jun 2002 09:41:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14226; Tue, 11 Jun 2002 09:41:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BGe5k7010463 for ; Tue, 11 Jun 2002 09:40:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BGe4Dc010462 for mobile-ip-dist; Tue, 11 Jun 2002 09:40:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BGe0k7010455 for ; Tue, 11 Jun 2002 09:40:00 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06451 for ; Tue, 11 Jun 2002 09:40:04 -0700 (PDT) Received: from cgprelay.ua.pt (smtprelay.ua.pt [193.136.80.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11084 for ; Tue, 11 Jun 2002 09:39:57 -0700 (PDT) Received: from [193.136.92.65] (HELO trantor.it.pt) by cgprelay.ua.pt (CommuniGate Pro SMTP 4.0b2) with ESMTP id 2667150 for mobile-ip@sunroof.eng.sun.com; Tue, 11 Jun 2002 17:39:54 +0100 Received: from verne.av.it.pt (verne.av.it.pt [193.136.92.50]) by trantor.it.pt (sendmail) with ESMTP id 854F12C1A for ; Tue, 11 Jun 2002 17:38:09 +0100 (PST) Received: from IT/SpoolDir by verne.av.it.pt (Mercury 1.47); 11 Jun 02 17:38:53 +0100 Received: from SpoolDir by IT (Mercury 1.47); 11 Jun 02 17:38:24 +0100 Received: from loliveira (193.136.92.235) by verne.av.it.pt (Mercury 1.47); 11 Jun 02 17:38:24 +0100 Message-ID: <006601c21166$ebf8c240$eb5c88c1@loliveira> From: =?iso-8859-1?Q?Lu=EDs_Miguel_Oliveira?= To: Subject: [mobile-ip] MN source address in MIPv6 Date: Tue, 11 Jun 2002 17:42:05 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C2116F.4D81A7E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C2116F.4D81A7E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'm studding mobile IPv6 in transition scenarios (IPv4 /IPv6). When MN = way from home network it uses the CoAddr as source address to avoid = triangle routing and its home address are sent in one of destination = option. These comportment is problematic when we try to use transitions = mechanisms (like NAT-PT, TRT) to connect to IPv4 CN. It is possible to disable IPv6 Binding mechanisms under these = situations?=20 Anyone was a solution? Thanks in Advance. Lu=EDs Miguel Oliveira ------=_NextPart_000_0063_01C2116F.4D81A7E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 

I=92m=20 studding mobile IPv6 in transition scenarios (IPv4 /IPv6). When MN way = from home=20 network it uses the CoAddr as source address to avoid triangle routing = and its=20 home address are sent in one of destination option. These comportment is = problematic when we try to use transitions mechanisms (like NAT-PT, TRT) = to=20 connect to IPv4 CN.

It is=20 possible to disable IPv6 Binding mechanisms under these situations?=20

Anyone was a=20 solution?

Thanks in Advance.

 

Lu=EDs=20 Miguel = Oliveira

------=_NextPart_000_0063_01C2116F.4D81A7E0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 11 17:00:40 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13040 for ; Tue, 11 Jun 2002 17:00:39 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13746; Tue, 11 Jun 2002 14:00:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23316; Tue, 11 Jun 2002 14:00:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BKwpk7011676 for ; Tue, 11 Jun 2002 13:58:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BKwpJS011675 for mobile-ip-dist; Tue, 11 Jun 2002 13:58:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BKwnk7011668 for ; Tue, 11 Jun 2002 13:58:49 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18841 for ; Tue, 11 Jun 2002 16:58:51 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g5BKwsqp027545 for ; Tue, 11 Jun 2002 16:58:55 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g5BKwsvC027544 for mobile-ip@sunroof.eng.sun.com; Tue, 11 Jun 2002 16:58:54 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5B842k7009604 for ; Tue, 11 Jun 2002 01:04:03 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20567 for ; Tue, 11 Jun 2002 01:04:05 -0700 (PDT) Received: from mail.dsi.uniroma1.it (mail.dsi.uniroma1.it [151.100.17.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22662 for ; Tue, 11 Jun 2002 01:04:04 -0700 (PDT) Received: from flashnet.it (Petrioli.dsi.uniroma1.it [151.100.17.132]) by mail.dsi.uniroma1.it (8.9.3/8.9.3) with ESMTP id KAA18545; Tue, 11 Jun 2002 10:32:31 +0200 (CEST) Message-ID: <3D05AECA.34DAF1F8@flashnet.it> Date: Tue, 11 Jun 2002 10:03:22 +0200 From: Chiara Petrioli X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: petrioli@dsi.uniroma1.it Subject: [mobile-ip] IEEE PERCOM 2003 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Sincere apologies if you receive multiple copies of this announcement. -------------------------------------------------------- P E R C O M 2 0 0 3 Dallas - Fort Worth Metroplex, Texas March 23-26, 2003 Conference Announcement and Preliminary Call for Papers --------------------------------------------------------- IEEE International Conference on Pervasive Computing and Communications (PerCom), Paper Submission Deadline --- October 1, 2002 Sponsored by the IEEE Computer Society --------------------------------------------------------- Pervasive computing and communications is emerging as an exciting new paradigm with a goal to provide computing and communication services all the time everywhere. This is a natural outcome of research and technological advances in wireless networks, mobile computing, distributed computing and agent technologies. Research is already in progress at universities and the industry to revolutionize a wide spectrum of applications including telemedicine, military, transportation, education, day-to-day life, exploiting this new paradigm. There is a need for a strong forum to create an atmosphere for researchers and developers to present their work, exchange ideas and participate in discussions. PerCom is the annual IEEE conference on pervasive computing and communications. PerCom2003 will provide a high profile, leading edge forum for researchers and engineers alike to present their latest advances in the field of pervasive computing and communications. PerCom2003 will also feature two special tracks on intelligent environments and mobile agents. Feature Topics: Contributions are solicited in all pervasive computing research and applied areas. These include, but are not limited to, the following feature topics: b Pervasive computing architectures b Intelligent environments b Wearable computers b Smart devices and smart spaces b Location-dependent/personalized applications b Service discovery mechanisms b Agent technologies b Sensors and actuators b Positioning and tracking technologies b Identification and authentication technologies b Integration of wired and wireless networks b Personal area networks b Enabling technologies such as Bluetooth, 802.11 and 802.15 b Software coordination models b Mobile / wireless computing systems and services b Context based and implicit computing b Speech processing / advanced computer vision b User interfaces and interaction models b Wireless/mobile service management and delivery b Ad hoc networking protocols and service discovery b Operating systems for pervasive computing platforms b Security and privacy issues for pervasive computing systems * Submission Guidelines: Papers must be unpublished and must not be submitted for publication elsewhere. Authors are encouraged to submit papers in electronic form, postscript or PDF only. The page limit for submissions is 15 pages (1.5 line spaced, excluding references, figures and tables). More details on submission procedures will be posted on the official PerCom website: http://www.percom.org. All submitted papers will undergo a rigorous review process managed by the technical program committee. Accepted papers will be published in the (IEEE) conference proceedings. The page limit for submissions is 15 pages (single spaced, excluding references, figures and tables). Papers of particular merit will be considered for publication in a special issue of a leading journal. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Important Dates/Deadlines: Paper Submissions: October 1, 2002 Acceptance Notification: December 10, 2002 Camera Ready Manuscripts: January 10, 2003 Conference Dates: March 23-26, 2003 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ** Organizing Committee: * General Chair Behrooz A. Shirazi University of Texas at Arlington * General Vice Chair: Sajal K. Das University of Texas at Arlington * Technical Program Committee Chair Mohan Kumar University of Texas at Arlington * Local Chair: Gergely V. ZB7ruba University of Texas at Arlington * Finance Chair: David Levine University of Texas at Arlington * Special Track Chairs: Diane Cook (Intelligent Environments) University of Texas at Arlington * Anand Tripathi (Mobile Agents) University of Minnesota * Tutorials Chair: Azzedine Boukerche University of North Texas * Industry Liaison: Kalyan Basu University of Texas at Arlington * Publicity Chairs: Albert Zomaya University of Sydney Stefano Basagni Northeastern University Chiara Petrioli Universita` di Roma "La Sapienza" *Technical Program Committee: TBA * Steering Committee TBA From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 11 17:06:22 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13154 for ; Tue, 11 Jun 2002 17:06:21 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24749; Tue, 11 Jun 2002 15:08:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25668; Tue, 11 Jun 2002 14:06:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BL5Lk7011807 for ; Tue, 11 Jun 2002 14:05:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5BL5Lqd011806 for mobile-ip-dist; Tue, 11 Jun 2002 14:05:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BL5Jk7011799 for ; Tue, 11 Jun 2002 14:05:20 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21166 for ; Tue, 11 Jun 2002 17:05:22 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g5BL5Pqp027556 for ; Tue, 11 Jun 2002 17:05:25 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g5BL5Pu2027555 for mobile-ip@sunroof.eng.sun.com; Tue, 11 Jun 2002 17:05:25 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5BJqGk7011550 for ; Tue, 11 Jun 2002 12:52:16 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27361 for ; Tue, 11 Jun 2002 12:52:20 -0700 (PDT) Received: from moutng0.schlund.de (moutng0.kundenserver.de [212.227.126.170]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09934 for ; Tue, 11 Jun 2002 13:52:19 -0600 (MDT) Received: from [212.227.126.162] (helo=mrelayng1.schlund.de) by moutng0.schlund.de with esmtp (Exim 3.22 #2) id 17Hrgg-0002Fh-00 for mobile-ip@sunroof.eng.sun.com; Tue, 11 Jun 2002 21:52:18 +0200 Received: from [148.88.242.149] (helo=dyn295.dhcp.lancs.ac.uk) by mrelayng1.schlund.de with asmtp (Exim 3.35 #1) id 17Hrgg-0001ZK-00 for mobile-ip@sunroof.eng.sun.com; Tue, 11 Jun 2002 21:52:18 +0200 Content-Type: text/plain; charset="us-ascii" From: Christian =?iso-8859-15?q?Borntr=E4ger?= To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] error in http://search.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-17.txt Date: Tue, 11 Jun 2002 20:51:53 +0100 User-Agent: KMail/1.4.1 MIME-Version: 1.0 Message-Id: <200206112051.59042.christian@borntraeger.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5BJqHk7011551 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I am not sure if it is the correct list to do, but nevertheless there seems to be an error in the draft of mobile IPv6 http://search.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-17.txt . I think In Section "5.5.3. Cookies" - - A care-of cookie sent directly to the mobile node from the correspondent node. Home cookies are produced cryptographically from nonces. Should be - - A care-of cookie sent directly to the mobile node from the correspondent node. Care-of cookies are produced cryptographically from nonces. Regards Christian For questions, please cc me I am not on the list -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9BlTdPe4/trxtfRoRAqooAJkBeRtqN0v77plVAvqatIt2whlsYwCfcHNN VY6kqRrXV8l427KB50hFIvc= =stba -----END PGP SIGNATURE----- From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 12 02:17:47 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07148 for ; Wed, 12 Jun 2002 02:17:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22346; Wed, 12 Jun 2002 00:18:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA22730; Tue, 11 Jun 2002 23:17:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C6Gnk7013001 for ; Tue, 11 Jun 2002 23:16:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5C6GnHN013000 for mobile-ip-dist; Tue, 11 Jun 2002 23:16:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5C6Gkk7012993 for ; Tue, 11 Jun 2002 23:16:46 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA03843 for ; Tue, 11 Jun 2002 23:16:50 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA06860 for ; Tue, 11 Jun 2002 23:16:49 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id AF1A26A904; Wed, 12 Jun 2002 09:16:42 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6D7E16A901; Wed, 12 Jun 2002 09:16:40 +0300 (EEST) Message-ID: <3D06E796.2010303@kolumbus.fi> Date: Wed, 12 Jun 2002 09:17:58 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Christian =?ISO-8859-1?Q?Borntr=E4ger?= Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] error in http://search.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-17.txt References: <200206112051.59042.christian@borntraeger.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Christian Bornträger wrote: > I am not sure if it is the correct list to do, but nevertheless Yes it is. > there seems to be an error in the draft of mobile IPv6 > http://search.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-17.txt . > > I think In Section "5.5.3. Cookies" > > > - - A care-of cookie sent directly to the mobile node from the > correspondent node. Home cookies are produced cryptographically > from nonces. > > Should be > > > - - A care-of cookie sent directly to the mobile node from the > correspondent node. Care-of cookies are produced cryptographically > from nonces. Yes. Fixed now, thanks! Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 14 04:51:26 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23147 for ; Fri, 14 Jun 2002 04:51:25 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07797; Fri, 14 Jun 2002 01:51:09 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA15479; Fri, 14 Jun 2002 01:50:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E8nvk7006772 for ; Fri, 14 Jun 2002 01:49:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5E8nvPv006771 for mobile-ip-dist; Fri, 14 Jun 2002 01:49:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5E8nsk7006764 for ; Fri, 14 Jun 2002 01:49:54 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA28596 for ; Fri, 14 Jun 2002 01:49:58 -0700 (PDT) From: Michael.Scharf@daimlerchrysler.com Received: from daimler-benz.com (pluto4.daimler-benz.com [53.122.2.34]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA05431 for ; Fri, 14 Jun 2002 02:49:57 -0600 (MDT) Received: by daimler-benz.com; id KAA15143; Fri, 14 Jun 2002 10:49:56 +0200 Received: from unknown(53.151.100.103) by pluto4.daimler-benz.com via smap (V5.0) id xmaup1218; Fri, 14 Jun 02 10:49:51 +0200 Received: from DAIMLERCHRYSLER.COM (wklms01.wk.dcx.com [53.151.100.99]) by daimlerchrysler.com (iPlanet Messaging Server 5.0 Patch 3 (built Mar 23 2001)) with ESMTP id <0GXO008GNTUP5Y@wksmtphub.wk.dcx.com> for mobile-ip@sunroof.eng.sun.com; Fri, 14 Jun 2002 10:49:37 +0200 (MEST) Received: by DAIMLERCHRYSLER.COM (Soft-Switch LMS 4.1.1) with snapi via LDO id 0057440019941614; Fri, 14 Jun 2002 10:49:37 +0200 Date: Fri, 14 Jun 2002 10:49:37 +0200 Subject: [mobile-ip] RO for nodes that are not mobile? To: mobile-ip@sunroof.eng.sun.com Message-id: <0057440019941614000002L442*@MHS> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5E8nsk7006765 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, sorry for asking a newbe question, but I am not sure if I have understood well RO in MIPv6: Assume an ongoing IPv6 communication between two nodes A and B, which are not mobile, but B implements the CN function of MIPv6. A third node C is located on the path between A and B. In my impression, C could send a BU to node B for node A including an own "CoA". As far as I have understood the return routability test, a correct binding in B can be established if C can intercept all packets sent to A's address. Thus, using MIPv6 RO, all packets sent from B to A will be delivered to the "CoA" at node C. If node C removes the MH and then forwards the packets, node A may not even notice this slight modification of routing. Is this true? Or do I miss something? Thanks, Michael From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 14 06:32:17 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23992 for ; Fri, 14 Jun 2002 06:32:17 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17401; Fri, 14 Jun 2002 03:31:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12604; Fri, 14 Jun 2002 03:31:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EAUok7007107 for ; Fri, 14 Jun 2002 03:30:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EAUner007106 for mobile-ip-dist; Fri, 14 Jun 2002 03:30:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EAUkk7007099 for ; Fri, 14 Jun 2002 03:30:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01253 for ; Fri, 14 Jun 2002 03:30:50 -0700 (PDT) Received: from Mistralsoftware.com (ptil-243-146-ban.primus-india.net [203.196.146.243] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA12222 for ; Fri, 14 Jun 2002 04:30:47 -0600 (MDT) Received: from anji [192.168.15.19] by mistralsoftware.com [192.168.10.12] with SMTP (MDaemon.PRO.v5.0.0.R) for ; Fri, 14 Jun 2002 15:59:49 +0530 Message-ID: <009401c2138c$4a729e50$130fa8c0@anji> From: "Anjaneyulu" To: , "MIPWorking Group" Subject: [mobile-ip] MIPv6 Doubts!!!!! Date: Fri, 14 Jun 2002 15:44:38 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0091_01C213BA.64094890" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.15.19 X-Return-Path: anjaneyulu@mistralsoftware.com X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0091_01C213BA.64094890 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Doubt1 =3D=3D=3D=3D=3D When the Mobile Node is in the Home Network, which routers will it = select as candidates for default router. As home agents are also candidated for default routers. I have a doubt that when the mobility feature is enabled on a = host(Mobile Node) , should he only consider entries in the home agents = list as the default router or can it also opt from default router list. Doubt2 =3D=3D=3D=3D=3D Can you give the scenario where more than one prefix is advertised to = Mobile Node having single interface??? Regards, Anj ------=_NextPart_000_0091_01C213BA.64094890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Doubt1
=3D=3D=3D=3D=3D
When the Mobile Node is in the Home = Network, which=20 routers will it select as candidates for default router.
As home agents are also candidated for = default=20 routers.
I have a doubt that when the = mobility feature=20 is enabled on a host(Mobile Node) , should he only consider entries = in the=20 home agents list as the default router or can it also opt from default = router=20 list.
 
Doubt2
=3D=3D=3D=3D=3D
Can you give the scenario where more = than one=20 prefix is advertised to Mobile Node having single = interface???
 
Regards,
Anj
------=_NextPart_000_0091_01C213BA.64094890-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 14 06:35:53 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24038 for ; Fri, 14 Jun 2002 06:35:52 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17523; Fri, 14 Jun 2002 04:36:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15340; Fri, 14 Jun 2002 03:35:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EAZ8k7007199 for ; Fri, 14 Jun 2002 03:35:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EAZ8vx007198 for mobile-ip-dist; Fri, 14 Jun 2002 03:35:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EAZ4k7007191 for ; Fri, 14 Jun 2002 03:35:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01906 for ; Fri, 14 Jun 2002 03:35:08 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23152 for ; Fri, 14 Jun 2002 04:35:07 -0600 (MDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id DAA29871; Fri, 14 Jun 2002 03:35:05 -0700 (MST)] Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id DAA28166; Fri, 14 Jun 2002 03:35:05 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (8.11.6/8.11.6) with ESMTP id g5EAYxD01016; Fri, 14 Jun 2002 05:35:00 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 65A982EC8B; Fri, 14 Jun 2002 12:34:57 +0200 (CEST) To: Cc: Subject: Re: [mobile-ip] RO for nodes that are not mobile? References: <0057440019941614000002L442*@MHS> From: Alexandru Petrescu Date: 14 Jun 2002 12:34:57 +0200 In-Reply-To: <0057440019941614000002L442*@MHS> Message-ID: Lines: 22 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: writes: > Assume an ongoing IPv6 communication between two nodes A and B, which are not > mobile, but B implements the CN function of MIPv6. A third node C is located on > the path between A and B. In my impression, C could send a BU to node B for > node A including an own "CoA". As far as I have understood the return > routability test, a correct binding in B can be established if C can intercept > all packets sent to A's address. Thus, using MIPv6 RO, all packets sent from B > to A will be delivered to the "CoA" at node C. If node C removes the MH and > then forwards the packets, node A may not even notice this slight modification > of routing. Hey Michael, how are you. I think you forgot the path towards the HA. The node B will send the HoT message towards the HA of node A, and this HA is out of the path where C is found. You might worry that an attacker puts node C and C' on both A-B and B-HA paths but don't worry too much because there might be no alternative. Alex From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 14 09:20:16 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28454 for ; Fri, 14 Jun 2002 09:20:16 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21503; Fri, 14 Jun 2002 06:20:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA12149; Fri, 14 Jun 2002 06:19:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EDIjk7007807 for ; Fri, 14 Jun 2002 06:18:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EDIjZs007806 for mobile-ip-dist; Fri, 14 Jun 2002 06:18:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EDIgk7007799 for ; Fri, 14 Jun 2002 06:18:42 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28084 for ; Fri, 14 Jun 2002 06:18:47 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21012 for ; Fri, 14 Jun 2002 06:18:47 -0700 (PDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id A2D63417A; Fri, 14 Jun 2002 09:18:46 -0400 (EDT) Received: from anw.zk3.dec.com (falpha.zk3.dec.com [16.140.160.4]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 7469D1884; Fri, 14 Jun 2002 09:18:46 -0400 (EDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g5EDIkt0001562767; Fri, 14 Jun 2002 09:18:46 -0400 (EDT) Message-ID: <3D09ED35.3080300@hp.com> Date: Fri, 14 Jun 2002 09:18:45 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anjaneyulu Cc: vijayd@iprg.nokia.com, MIPWorking Group Subject: Re: [mobile-ip] MIPv6 Doubts!!!!! References: <009401c2138c$4a729e50$130fa8c0@anji> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Anjaneyulu wrote: > Hi, > > > > Doubt1 > > ===== > > When the Mobile Node is in the Home Network, which routers will it > select as candidates for default router. > > As home agents are also candidated for default routers. > > I have a doubt that when the mobility feature is enabled on a > host(Mobile Node) , should he only consider entries in the home agents > list as the default router or can it also opt from default router list. I would say that that is should consider all routers on the link that are advertising themselves as default. But that prompts another question. Does the mobile flush the default router list every time it moves? The reason I ask the question is that the default router list is bound by AdvDefaultLife and will grow while the lifetime on the default routes is valid. Once the mobile has moved on, the default routers are no longer reachable, but might still be tried by the mobile and cause fairly long delays (when a stale unreachable ND cache entry exists, ND failure takes about 10 seconds). > > > > Doubt2 > > ===== > > Can you give the scenario where more than one prefix is advertised to > Mobile Node having single interface??? 1. The whole network is multihomed. 2. A mobile subnet is multihomed -vlad +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 14 14:21:21 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09167 for ; Fri, 14 Jun 2002 14:21:21 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20979; Fri, 14 Jun 2002 11:21:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28179; Fri, 14 Jun 2002 11:20:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EII5k7009981 for ; Fri, 14 Jun 2002 11:18:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5EII5h9009980 for mobile-ip-dist; Fri, 14 Jun 2002 11:18:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EIHwk7009973 for ; Fri, 14 Jun 2002 11:17:58 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11074 for ; Fri, 14 Jun 2002 11:18:02 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18383 for ; Fri, 14 Jun 2002 11:18:01 -0700 (PDT) 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 LAA09218; Fri, 14 Jun 2002 11:18:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5EII0G01593; Fri, 14 Jun 2002 11:18:00 -0700 X-mProtect: <200206141818> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8MpHAB; Fri, 14 Jun 2002 11:17:58 PDT Message-ID: <3D0A3356.DD71B31C@iprg.nokia.com> Date: Fri, 14 Jun 2002 11:17:58 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Anjaneyulu CC: MIPWorking Group Subject: [mobile-ip] Re: MIPv6 Doubts!!!!! References: <009401c2138c$4a729e50$130fa8c0@anji> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Anjaneyulu wrote: > > Hi, > > Doubt1 > ===== > When the Mobile Node is in the Home Network, which routers will it > select as candidates for default router. > As home agents are also candidated for default routers. isnt this is a generic issue of choosing a default router when there are multiple routers on a link. just pick one. there is a new draft http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt which introduces extensions to Neighbor Discovery to make default router selection more deterministic. > I have a doubt that when the mobility feature is enabled on a > host(Mobile Node) , should he only consider entries in the home agents > list as the default router or can it also opt from default router > list. when the MN is just staying put in the home network, then the Home Agent does not come into the picture. it can pick any router on the home link as the default router. Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 14 21:25:35 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20765 for ; Fri, 14 Jun 2002 21:25:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14770; Fri, 14 Jun 2002 18:24:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18947; Fri, 14 Jun 2002 18:24:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5F1NFk7011806 for ; Fri, 14 Jun 2002 18:23:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5F1NFua011805 for mobile-ip-dist; Fri, 14 Jun 2002 18:23:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5F1NCk7011798 for ; Fri, 14 Jun 2002 18:23:12 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA08297 for ; Fri, 14 Jun 2002 18:23:16 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14371 for ; Fri, 14 Jun 2002 19:23:15 -0600 (MDT) From: Masataka Ohta Message-Id: <200206150103.KAA05086@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA05086; Sat, 15 Jun 2002 10:03:01 +0900 Subject: [mobile-ip] any deployment? To: mobile-ip@sunroof.eng.sun.com Date: Sat, 15 Jun 2002 10:03:00 +0859 () X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, Are there any commercial mobile IP services, other than ours? Masataka Ohta Mobile Internet Services, Inc. From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 15 18:36:22 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15947 for ; Sat, 15 Jun 2002 18:36:22 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20984; Sat, 15 Jun 2002 15:35:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24659; Sat, 15 Jun 2002 15:35:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5FMYOk7015983 for ; Sat, 15 Jun 2002 15:34:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5FMYOJT015982 for mobile-ip-dist; Sat, 15 Jun 2002 15:34:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5FMYLk7015975 for ; Sat, 15 Jun 2002 15:34:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24546 for ; Sat, 15 Jun 2002 15:34:25 -0700 (PDT) Received: from c001.snv.cp.net (h000.c001.snv.cp.net [209.228.32.114]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA20677 for ; Sat, 15 Jun 2002 16:34:24 -0600 (MDT) Received: (cpmta 13237 invoked from network); 15 Jun 2002 13:21:51 -0700 Received: from 68.100.176.78 (HELO VAIO) by smtp.register-admin.com (209.228.32.114) with SMTP; 15 Jun 2002 13:21:51 -0700 X-Sent: 15 Jun 2002 20:21:51 GMT Message-ID: <040301c214aa$473581c0$0400a8c0@VAIO> From: "Qiang Zhang" To: "Masataka Ohta" , References: <200206150103.KAA05086@necom830.hpcl.titech.ac.jp> Subject: Re: [mobile-ip] any deployment? Date: Sat, 15 Jun 2002 16:21:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, Masataka, Do you mind provide some insight what commercial service you provide? Q ----- Original Message ----- From: "Masataka Ohta" To: Sent: Friday, June 14, 2002 9:04 PM Subject: [mobile-ip] any deployment? > Hi, > > Are there any commercial mobile IP services, other than ours? > > Masataka Ohta > Mobile Internet Services, Inc. > From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 15 21:43:15 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17362 for ; Sat, 15 Jun 2002 21:43:15 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14785; Sat, 15 Jun 2002 18:42:37 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10133; Sat, 15 Jun 2002 18:42:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5G1fNk7016457 for ; Sat, 15 Jun 2002 18:41:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5G1fNX4016456 for mobile-ip-dist; Sat, 15 Jun 2002 18:41:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5G1fJk7016449 for ; Sat, 15 Jun 2002 18:41:20 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13079 for ; Sat, 15 Jun 2002 18:41:24 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21425 for ; Sat, 15 Jun 2002 19:41:23 -0600 (MDT) From: Masataka Ohta Message-Id: <200206160123.KAA09702@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA09702; Sun, 16 Jun 2002 10:23:27 +0900 Subject: Re: [mobile-ip] any deployment? In-Reply-To: <040301c214aa$473581c0$0400a8c0@VAIO> from Qiang Zhang at "Jun 15, 2002 04:21:47 pm" To: Qiang Zhang Date: Sun, 16 Jun 2002 10:23:27 +0859 () CC: mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Qiang; > Do you mind provide some insight what commercial service you provide? The primary commercial service of MIS is wireless internet access on top of IEEE 802.11b with packet-wise cryptographical security. However, without mobile IP support in mind, such a service is meaningless (I'm saying business models of hot spot services are broken). So, the secondary commercial service of MIS is mobile IP of RFC2002. So, my question is, can we say "MIS is the first, and currently the only, ISP commercialy offering mobile IP". I'm preparing I-Ds on interaction between WLAN and MIP. Some information on MIS in English can be found at: http://www.miserv.net/miserv-new/english_new/ Masataka Ohta PS MIS is considering to offer free trial account to participants of Yokohama IETF. From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 16 18:10:18 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08596 for ; Sun, 16 Jun 2002 18:10:17 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29698; Sun, 16 Jun 2002 15:10:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00944; Sun, 16 Jun 2002 15:09:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5GM8mk7019057 for ; Sun, 16 Jun 2002 15:08:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5GM8l5S019056 for mobile-ip-dist; Sun, 16 Jun 2002 15:08:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5GM8ik7019049 for ; Sun, 16 Jun 2002 15:08:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00817 for ; Sun, 16 Jun 2002 15:08:49 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14217 for ; Sun, 16 Jun 2002 16:10:48 -0600 (MDT) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id SAA20869 for ; Sun, 16 Jun 2002 18:08:48 -0400 (EDT) From: "Dr. Subrata Goswami" To: Subject: RE: [mobile-ip] any deployment? Date: Sun, 16 Jun 2002 15:11:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <200206160123.KAA09702@necom830.hpcl.titech.ac.jp> Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Qiang, I am not aware of any deployment of Mobile-IP. But I have heard that Winphoria (www.winphoria.com) has demonstrated mobility between WLAN and 3G networks - which would imply they have something similar to Mobile-IP in their WMS-5000 MSC. There is the possibility that they have a pure Layer-2 solution. Anyone with better visibility please confirm or deny. Subrata -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Masataka Ohta Sent: Saturday, June 15, 2002 6:24 PM To: Qiang Zhang Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] any deployment? Qiang; > Do you mind provide some insight what commercial service you provide? The primary commercial service of MIS is wireless internet access on top of IEEE 802.11b with packet-wise cryptographical security. However, without mobile IP support in mind, such a service is meaningless (I'm saying business models of hot spot services are broken). So, the secondary commercial service of MIS is mobile IP of RFC2002. So, my question is, can we say "MIS is the first, and currently the only, ISP commercialy offering mobile IP". I'm preparing I-Ds on interaction between WLAN and MIP. Some information on MIS in English can be found at: http://www.miserv.net/miserv-new/english_new/ Masataka Ohta PS MIS is considering to offer free trial account to participants of Yokohama IETF. From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 17 09:37:45 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02236 for ; Mon, 17 Jun 2002 09:37:45 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00207; Mon, 17 Jun 2002 07:37:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04093; Mon, 17 Jun 2002 06:37:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HDaLk7021047 for ; Mon, 17 Jun 2002 06:36:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HDaLZP021046 for mobile-ip-dist; Mon, 17 Jun 2002 06:36:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HDaIk7021039 for ; Mon, 17 Jun 2002 06:36:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03878 for ; Mon, 17 Jun 2002 06:36:23 -0700 (PDT) Received: from atlhpmx4.nextel.com (unknown-73-245-115.nextel.com [168.73.245.115]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20501 for ; Mon, 17 Jun 2002 07:38:24 -0600 (MDT) Received: from atlntgw01.nextel.com (atlntgw01.nextel.com [10.8.79.187]) by atlhpmx4.nextel.com (8.11.1/8.11.1) with ESMTP id g5HDaLJ26040 for ; Mon, 17 Jun 2002 09:36:21 -0400 (EDT) Received: by atlntgw01.nextel.com with Internet Mail Service (5.5.2655.55) id ; Mon, 17 Jun 2002 09:36:21 -0400 Message-ID: From: "Bui, Hung" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] any deployment? Date: Mon, 17 Jun 2002 09:36:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21603.F09BCAD0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C21603.F09BCAD0 Content-Type: text/plain; charset="ISO-8859-1" Masakata Ohta, Us too! NEXTEL has been deploying Mobile IP for over two years with over 9 millions subscribers. ______________________________________ Hung Bui NEXTEL Communications, Inc. * email: hung.bui@nextel.com ______________________________________ E The above view is of my own and may not reflect those of NEXTEL Communications, Inc. -----Original Message----- From: Masataka Ohta [ mailto:mohta@necom830.hpcl.titech.ac.jp] Sent: Friday, June 14, 2002 9:04 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] any deployment? Hi, Are there any commercial mobile IP services, other than ours? Masataka Ohta Mobile Internet Services, Inc. ------_=_NextPart_001_01C21603.F09BCAD0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Masakata = Ohta,
 
Us=20 too!
 
NEXTEL = has been=20 deploying Mobile IP for over two years with over 9 millions=20 subscribers.
 
______________________________________
Hung=20 Bui
NEXTEL=20 Communications, Inc.
*=20 email: hung.bui@nextel.com
______________________________________
E The=20 above view is of my own and may not reflect those of NEXTEL=20 Communications, Inc.

-----Original Message-----
From: Masataka Ohta = [mailto:mohta@necom830.hpcl.titech.ac.jp]
Sent:=20 Friday, June 14, 2002 9:04 PM
To: = mobile-ip@sunroof.eng.sun.com
Subject:=20 [mobile-ip] any deployment?


Hi,

Are there any = commercial=20 mobile IP services, other than=20 ours?

       =20        =20        =20        =20         Masataka=20 Ohta
       =20        =20        =20        =20         Mobile Internet Services,=20 Inc.

------_=_NextPart_001_01C21603.F09BCAD0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 17 10:24:54 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04787 for ; Mon, 17 Jun 2002 10:24:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01476; Mon, 17 Jun 2002 08:25:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09735; Mon, 17 Jun 2002 07:24:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEKak7021430 for ; Mon, 17 Jun 2002 07:20:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HEKa7n021429 for mobile-ip-dist; Mon, 17 Jun 2002 07:20:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HEKPk7021419 for ; Mon, 17 Jun 2002 07:20:26 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08511 for ; Mon, 17 Jun 2002 07:20:29 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28197 for ; Mon, 17 Jun 2002 08:20:28 -0600 (MDT) From: Masataka Ohta Message-Id: <200206171409.XAA18335@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id XAA18335; Mon, 17 Jun 2002 23:08:50 +0859 Subject: Re: [mobile-ip] any deployment? In-Reply-To: from "Bui, Hung" at "Jun 17, 2002 09:36:09 am" To: "Bui, Hung" Date: Mon, 17 Jun 2002 23:08:50 +0859 () CC: mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hung Bui; > Us too! > > NEXTEL has been deploying Mobile IP for over two years with over 9 millions > subscribers. Do you really mean "Mobile IP", meaning of which should be obvious in this mobile-ip ML? I'm afraid that, so called "wireless Internet solution" is to offer WWW/Email access over a mobile L2 technology, neither of which has anything to do with IP. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 17 11:37:56 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07982 for ; Mon, 17 Jun 2002 11:37:55 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03263; Mon, 17 Jun 2002 09:40:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06087; Mon, 17 Jun 2002 08:37:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HFask7021870 for ; Mon, 17 Jun 2002 08:36:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HFasS1021869 for mobile-ip-dist; Mon, 17 Jun 2002 08:36:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HFapk7021862 for ; Mon, 17 Jun 2002 08:36:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05659 for ; Mon, 17 Jun 2002 08:36:55 -0700 (PDT) Received: from atlhpmx4.nextel.com (unknown-73-245-115.nextel.com [168.73.245.115]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA17610 for ; Mon, 17 Jun 2002 09:36:47 -0600 (MDT) Received: from atlntgw01.nextel.com (atlntgw01.nextel.com [10.8.79.187]) by atlhpmx4.nextel.com (8.11.1/8.11.1) with ESMTP id g5HFagJ16109; Mon, 17 Jun 2002 11:36:43 -0400 (EDT) Received: by atlntgw01.nextel.com with Internet Mail Service (5.5.2655.55) id ; Mon, 17 Jun 2002 11:36:42 -0400 Message-ID: From: "Bui, Hung" To: "'Masataka Ohta'" , "Bui, Hung" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] any deployment? Date: Mon, 17 Jun 2002 11:36:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21614.C3FD4E70" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C21614.C3FD4E70 Content-Type: text/plain; charset="ISO-8859-1" Dear Masakata San, Yes: our wireless IP is RFC2002 compliant. Hung Bui -----Original Message----- From: Masataka Ohta [ mailto:mohta@necom830.hpcl.titech.ac.jp ] Sent: Monday, June 17, 2002 10:10 AM To: Bui, Hung Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] any deployment? Do you really mean "Mobile IP", meaning of which should be obvious in this mobile-ip ML? I'm afraid that, so called "wireless Internet solution" is to offer WWW/Email access over a mobile L2 technology, neither of which has anything to do with IP. Masataka Ohta ------_=_NextPart_001_01C21614.C3FD4E70 Content-Type: text/html; charset="ISO-8859-1"

Dear Masakata San,

Yes: our wireless IP is RFC2002 compliant.

Hung Bui

-----Original Message-----
From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp]
Sent: Monday, June 17, 2002 10:10 AM
To: Bui, Hung
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] any deployment?



Do you really mean "Mobile IP", meaning of which should be
obvious in this mobile-ip ML?

I'm afraid that, so called "wireless Internet solution" is
to offer WWW/Email access over a mobile L2 technology,
neither of which has anything to do with IP.

                                                Masataka Ohta

------_=_NextPart_001_01C21614.C3FD4E70-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 17 11:46:29 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08307 for ; Mon, 17 Jun 2002 11:46:28 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02829; Mon, 17 Jun 2002 08:46:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08580; Mon, 17 Jun 2002 08:45:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HFisk7022017 for ; Mon, 17 Jun 2002 08:44:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HFirsp022016 for mobile-ip-dist; Mon, 17 Jun 2002 08:44:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HFiok7022009 for ; Mon, 17 Jun 2002 08:44:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07935 for ; Mon, 17 Jun 2002 08:44:54 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17502 for ; Mon, 17 Jun 2002 09:44:51 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g5HFiYv03675; Mon, 17 Jun 2002 18:44:34 +0300 Date: Mon, 17 Jun 2002 18:44:34 +0300 (EEST) From: Pekka Savola To: "Bui, Hung" cc: "'Masataka Ohta'" , Subject: RE: [mobile-ip] any deployment? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Mon, 17 Jun 2002, Bui, Hung wrote: > Dear Masakata San, > > Yes: our wireless IP is RFC2002 compliant. Could you please elaborate a bit? btw, your initial statement: "NEXTEL has been deploying Mobile IP for over two years with over 9 millions subscribers." Could probably have already been read that NEXTEL has 9 million customers and has been using Mobile IP for over two years, but I didn't see the definite connection that all of those 9 million subscribers would be using mobile IP. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 17 11:58:05 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08667 for ; Mon, 17 Jun 2002 11:58:04 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16265; Mon, 17 Jun 2002 10:00:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12886; Mon, 17 Jun 2002 08:58:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HFvDk7022165 for ; Mon, 17 Jun 2002 08:57:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HFvDmh022164 for mobile-ip-dist; Mon, 17 Jun 2002 08:57:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HFv9k7022157 for ; Mon, 17 Jun 2002 08:57:09 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09186 for ; Mon, 17 Jun 2002 08:57:14 -0700 (PDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09753 for ; Mon, 17 Jun 2002 08:57:14 -0700 (PDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5HFvAp00015 for ; Mon, 17 Jun 2002 11:57:10 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA06598; Mon, 17 Jun 2002 17:57:08 +0200 (MET DST) To: , , , , , , , , , , , Received: from ouranos by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA06555; Mon, 17 Jun 2002 17:56:49 +0200 (MET DST) Message-ID: <01de01c21617$a602b790$9981cdd4@ouranos> Reply-To: "Nikos A. Nikolaou" From: "Nikos A. Nikolaou" Original-To: , , , , , , , , , , , Subject: [mobile-ip] CFP: Special Issue in IEEE Network on Network Management Date: Mon, 17 Jun 2002 18:57:04 +0300 Organization: Lucent Technologies MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit My apologies if you receive multiple copies of this. A pdf version of this CFP will be available soon at http://www.comsoc.org/pubs/net/ntwrk/special.html Kind regards, Nikos A. Nikolaou ------------------------------------------------------------------------------- Call For Papers IEEE Network Magazine Special Issue on Network Management of Multi-service, Multimedia, IP-based Networks Guest Editors Dr. Nikolaos Nikolaou Dr. Theodore Zahariadis Lucent Technologies Networking & Multimedia Systems Bell Labs - AT, EMEA Ellemedia Technologies Botterstraat 45 Syggrou 223, 1270 AA, Huizen, 171 21, Athens The Netherlands Greece Tel: +31 - 35 - 687 5302 Tel: +30 - 10 - 937 3097 Email: nikolaou@lucent.com Email: zahariad@ellemedia.com Prof. Joan Serrat Dr. Bharat Doshi Telecommunication Engineering Lucent Technologies Universitat Politecnica de Catalunya Bell Labs Sor Eulalia d'Anzizu, s/n, 101 Crawfords Corner Rd, 08034, Barcelona, Holmdel, NJ 07733 Spain USA Tel: +34 - 93 - 401 6786 Tel: +1732 949 0823 Email: serrat@tsc.upc.es Email: bdoshi@lucent.com Objectives During the last decade, innovations concerning optical networking technology, as well as advances in digital compression and transmission over copper and cable have dramatically increased the capabilities and the efficiency of existing and imminent access-, metropolitan- and core-networks. A major breakthrough in communications was the fast deployment of cellular systems. Currently, 3G wireless systems, targeting the transmission of voice, video and high-speed data, are already under preliminary deployment. Furthermore, researchers and vendors are expressing a growing interest in 4G wireless systems that will support even higher rates and cater for global roaming across multiple wireless networks. Meanwhile, based on the TCP/IP protocol suite, the Internet has evolved from a research network, targeting a limited audience of academic and military users, to a huge and commercially operated network. Next-generation IP technology has the potential to prevail, both in the access and in the core, as we are moving toward a worldwide, multi-service, multimedia and high-speed networking environment. The explosion of IP-based multimedia applications led to an exponential growth of IP traffic and initiated a number of research activities that would allow efficient Quality of Service (QoS) support. Additionally, the issue of security became more important and acquired considerable attention owing to the proliferation of IP-based Virtual Private Networks (VPNs). However, apart from efficient compression, sophisticated transmission schemes and support for QoS, mobility and security, contemporary networking applications require significant functionality for management operations, ensuring that the underlining network is both available and capable of supporting the service uninterruptedly. Configuration, performance and fault management over heterogeneous underlying technologies and multi-layered networks, along with end-to-end QoS, traffic management, service control platforms, billing and mobility management are also crucial components of multi-service and high-speed IP-based networks. The goal of this special issue in IEEE Network Magazine is to present to the magazine's audience (1) a comprehensive study of the design, performance and deployment issues and solutions of end-to-end network management over multi-domain, multi-technology, IP-based networks, and (2) a consolidated insight into ongoing research, development and trials' evaluation of network management technologies and platforms, broadening future research directions. To achieve this goal, this special issue seeks for original papers with strong tutorial and/or survey perspective that will consolidate and present the leading-edge research prototype development, trials and early deployment and performance studies in Network Management of multi-service, multimedia, IP-based networks. Topics In particular, focused tutorial and survey contributions are solicited on (but not restricted to) the following areas: * End-to-end IP multimedia network and service management * VoIP, IP Video, streaming, interactive video service management * Provisioning of multimedia networks and services * Wireless LAN and 3G/4G mobile multimedia network management * Management of terminal and network mobility * Inter-domain IP over WDM multimedia network management * Network management models and architectures * Management issues for billing and security for IP multimedia services * Multi-domain, multi-point, multicast services management * Policy-based management for multimedia services * Performance and Fault Management of Multi-layered Networks * QoS management * Multimedia traffic management * Active multimedia network management * Middleware support for management Manuscript Submission Interested authors should submit an electronic version of the manuscript, in either Postscript or PDF format, as an email attachment to one of the guest editors. Additional information including "Guidelines for authors" is available at the IEEE Network Website: http://www.comsoc.org/pubs/net/ntwrk/authors.html Important Dates Submission Deadline: October 1, 2002 Notification of Acceptance: December 21, 2002 Final Manuscript Due: March 1, 2003 Publication Date: May/June 2003 ------------------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 17 12:12:18 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09454 for ; Mon, 17 Jun 2002 12:12:17 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19710; Mon, 17 Jun 2002 09:12:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18996; Mon, 17 Jun 2002 09:12:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HGAwk7022303 for ; Mon, 17 Jun 2002 09:10:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HGAwnc022302 for mobile-ip-dist; Mon, 17 Jun 2002 09:10:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HGAtk7022295 for ; Mon, 17 Jun 2002 09:10:55 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13409 for ; Mon, 17 Jun 2002 09:10:59 -0700 (PDT) Received: from atlhpmx4.nextel.com (unknown-73-245-115.nextel.com [168.73.245.115]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05649 for ; Mon, 17 Jun 2002 10:10:59 -0600 (MDT) Received: from atlntgw01.nextel.com (atlntgw01.nextel.com [10.8.79.187]) by atlhpmx4.nextel.com (8.11.1/8.11.1) with ESMTP id g5HGAnJ28056; Mon, 17 Jun 2002 12:10:49 -0400 (EDT) Received: by atlntgw01.nextel.com with Internet Mail Service (5.5.2655.55) id ; Mon, 17 Jun 2002 12:10:49 -0400 Message-ID: From: "Bui, Hung" To: "'Pekka Savola'" Cc: "'Masataka Ohta'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] any deployment? Date: Mon, 17 Jun 2002 12:10:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21619.870413A0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C21619.870413A0 Content-Type: text/plain; charset="ISO-8859-1" Dear Pekka, Thank you for your interest. Here are a bit more details on the NEXTEL's mobile IP implementation: 1. Nextel's network uses Motorola's iDEN technology which includes support for a native packet service, not PPP over cellular. 2. Mobile IP is used to provide macro mobility. iDEN technology handles the cell to cell handover, Mobile IP is used for "Location Area" handovers as well as inter-market roaming. 3. A standard Mobile IP home agent is used. 4. All "+" phones have Mobile IP client stack functionality built in. 5. All addressing is static. 6. The implementation is nearly standards compliant with RFC 2002, but some modifications were made to the advertisement algorithms minimize the over the air traffic. 7. The service has been commercially available for over two years. Please check www.nextel.com for more information on services and products. BTW, I do not have the specific '+' phones deployed but should be over few millions. Regards, - Hung Bui -----Original Message----- From: Pekka Savola [ mailto:pekkas@netcore.fi] Sent: Monday, June 17, 2002 11:45 AM To: Bui, Hung Cc: 'Masataka Ohta'; mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] any deployment? On Mon, 17 Jun 2002, Bui, Hung wrote: > Dear Masakata San, > > Yes: our wireless IP is RFC2002 compliant. Could you please elaborate a bit? btw, your initial statement: "NEXTEL has been deploying Mobile IP for over two years with over 9 millions subscribers." Could probably have already been read that NEXTEL has 9 million customers and has been using Mobile IP for over two years, but I didn't see the definite connection that all of those 9 million subscribers would be using mobile IP. ------_=_NextPart_001_01C21619.870413A0 Content-Type: text/html; charset="ISO-8859-1"
Dear Pekka,
 
Thank you for your interest.  Here are a bit more details on the NEXTEL's mobile IP implementation:

1. Nextel's network uses Motorola's iDEN technology which includes support for a native packet service, not PPP over cellular.

2. Mobile IP is used to provide macro mobility. iDEN technology handles the cell to cell handover, Mobile IP is used for "Location Area" handovers as well as

inter-market roaming.

3. A standard Mobile IP home agent is used.

4. All "+" phones have Mobile IP client stack functionality built in.

5. All addressing is static.

6. The implementation is nearly standards compliant with RFC 2002, but some modifications were made to the advertisement algorithms minimize the over the air traffic.

7. The service has been commercially available for over two years.

Please check www.nextel.com for more information on services and products.
 
BTW, I do not have the specific '+' phones deployed but should be over few millions.
 
Regards,
- Hung Bui
 

-----Original Message-----
From: Pekka Savola [mailto:pekkas@netcore.fi]
Sent: Monday, June 17, 2002 11:45 AM
To: Bui, Hung
Cc: 'Masataka Ohta'; mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] any deployment?


On Mon, 17 Jun 2002, Bui, Hung wrote:
> Dear Masakata San,
>
> Yes: our wireless IP is RFC2002 compliant.

Could you please elaborate a bit?


btw, your initial statement:

"NEXTEL has been deploying Mobile IP for over two years with over 9
millions subscribers."

Could probably have already been read that NEXTEL has 9 million customers
and has been using Mobile IP for over two years, but I didn't see the
definite connection that all of those 9 million subscribers would be using
mobile IP.

------_=_NextPart_001_01C21619.870413A0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 17 17:04:11 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19871 for ; Mon, 17 Jun 2002 17:04:10 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21751; Mon, 17 Jun 2002 15:06:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08504; Mon, 17 Jun 2002 14:04:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HL35k7022732 for ; Mon, 17 Jun 2002 14:03:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HL34TY022729 for mobile-ip-dist; Mon, 17 Jun 2002 14:03:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HL2rkX022690 for ; Mon, 17 Jun 2002 14:02:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25089 for ; Mon, 17 Jun 2002 09:40:40 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22468 for ; Mon, 17 Jun 2002 10:40:38 -0600 (MDT) From: Masataka Ohta Message-Id: <200206171630.BAA18816@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA18816; Tue, 18 Jun 2002 01:30:05 +0900 Subject: Re: [mobile-ip] any deployment? In-Reply-To: from "Bui, Hung" at "Jun 17, 2002 12:10:41 pm" To: "Bui, Hung" Date: Tue, 18 Jun 2002 01:30:04 +0859 () CC: "'Pekka Savola'" , mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Dear Hung Bui; > 2. Mobile IP is used to provide macro mobility. iDEN technology handles the > cell to cell handover, Mobile IP is used for "Location Area" handovers as > well as inter-market roaming. Very interesting. Are you giving direct internet connectivity to your users with global IP addresses? Do you use mobile IP even for voice services? > Please check www.nextel.com for more information on > services and products. I checked it only to find that it never says "mobile IP". Does your marketing people think "mobile IP" something immoral? :-) Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 17 17:29:44 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20570 for ; Mon, 17 Jun 2002 17:29:44 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05146; Mon, 17 Jun 2002 15:32:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05914; Mon, 17 Jun 2002 14:29:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HLSRk9023178 for ; Mon, 17 Jun 2002 14:28:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HLJ6Vf023065 for mobile-ip-dist; Mon, 17 Jun 2002 14:19:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HLFCkR023015 for ; Mon, 17 Jun 2002 14:19:00 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16760 for ; Mon, 17 Jun 2002 13:07:12 -0700 (PDT) Received: from atlhpmx4.nextel.com (unknown-73-245-115.nextel.com [168.73.245.115]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29698 for ; Mon, 17 Jun 2002 14:07:12 -0600 (MDT) Received: from atlntgw01.nextel.com (atlntgw01.nextel.com [10.8.79.187]) by atlhpmx4.nextel.com (8.11.1/8.11.1) with ESMTP id g5HK6vJ14607; Mon, 17 Jun 2002 16:06:58 -0400 (EDT) Received: by atlntgw01.nextel.com with Internet Mail Service (5.5.2655.55) id ; Mon, 17 Jun 2002 16:06:57 -0400 Message-ID: From: "Bui, Hung" To: "'Masataka Ohta'" Cc: "'Pekka Savola'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] any deployment? Date: Mon, 17 Jun 2002 16:06:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2163A.830F08B0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C2163A.830F08B0 Content-Type: text/plain; charset="ISO-8859-1" Dear Masataka Ohta San, Thank you again for your interest. Yes, you can have connectivity to the Internet. You can either tether a PC to one of our '+' phone or via the iDEN iM1100 modem, please see: http://www.nextel.com/services/nextelonline/index.shtml Regards, - Hung -----Original Message----- From: Masataka Ohta [ mailto:mohta@necom830.hpcl.titech.ac.jp] Sent: Monday, June 17, 2002 12:31 PM To: Bui, Hung Cc: 'Pekka Savola'; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] any deployment? Dear Hung Bui; Are you giving direct internet connectivity to your users with global IP addresses? ------_=_NextPart_001_01C2163A.830F08B0 Content-Type: text/html; charset="ISO-8859-1"
Dear Masataka Ohta San,
 
Thank you again for your interest.
 
Yes, you can have connectivity to the Internet.  You can either tether a PC to one of our '+' phone or via the iDEN iM1100 modem, please see:
 
 
 
Regards,
- Hung

-----Original Message-----
From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp]
Sent: Monday, June 17, 2002 12:31 PM
To: Bui, Hung
Cc: 'Pekka Savola'; mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] any deployment?


Dear Hung Bui;

Are you giving direct internet connectivity to your users with
global IP addresses?

------_=_NextPart_001_01C2163A.830F08B0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 17 17:35:00 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20761 for ; Mon, 17 Jun 2002 17:35:00 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18366; Mon, 17 Jun 2002 15:35:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20509; Mon, 17 Jun 2002 14:35:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HLXxk7023389 for ; Mon, 17 Jun 2002 14:33:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HLXwu1023384 for mobile-ip-dist; Mon, 17 Jun 2002 14:33:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HLXqkD023369 for ; Mon, 17 Jun 2002 14:33:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06525 for ; Mon, 17 Jun 2002 13:59:13 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18578 for ; Mon, 17 Jun 2002 15:01:15 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5HL2cj27703 for ; Mon, 17 Jun 2002 16:02:39 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 17 Jun 2002 15:59:09 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 17 Jun 2002 15:58:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] Draft Agenda for MIP WG @ IETF54 Date: Mon, 17 Jun 2002 15:58:59 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12F68@daebe007.NOE.Nokia.com> Thread-Topic: Draft Agenda for MIP WG @ IETF54 Thread-Index: AcIWQc1Lsx1Z7Rd3TA2URj9sMxQFxQ== To: X-OriginalArrivalTime: 17 Jun 2002 20:58:59.0961 (UTC) FILETIME=[CDB40E90:01C21641] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5HLXsk7023376 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, Following is the draft agenda for the Mobile IP WG meeting at IETF54. The MIP WG meeting is currently scheduled for Monday, July 15th from 1930-2200. Agenda bashing 5 min WG Document update 10 min Mobile IP v6 60 min draft-ietf-mobileip-ipv6-18.txt Jari Arkko Fast handoff in v6 20 min draft-ietf-mobileip-fast-mipv6-05.txt Rajeev Koodli VPN traversal requirements 5 min draft-ietf-mobileip-vpn-problem-statement-00.txt Phil Roberts Limited Private Address Support 10 Mins draft-chakrabarti-mobileip-privaddr-00.txt Gabriel Montenegro Mobile IPv4 Regional Registration 5 Mins draft-ietf-mobileip-reg-tunnel-06.txt Phil Roberts LMM Requirements 5 min draft-ietf-mobileip-lmm-requirements-01.txt Carl Williams -Chairs From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 17 18:44:27 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22224 for ; Mon, 17 Jun 2002 18:44:27 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05704; Mon, 17 Jun 2002 15:44:14 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15856; Mon, 17 Jun 2002 15:43:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HMgbk7024025 for ; Mon, 17 Jun 2002 15:42:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5HMgbTu024024 for mobile-ip-dist; Mon, 17 Jun 2002 15:42:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5HMgZk7024017 for ; Mon, 17 Jun 2002 15:42:36 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA07532 for ; Mon, 17 Jun 2002 18:42:40 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g5HMgkXA000535 for ; Mon, 17 Jun 2002 18:42:46 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g5HMgj75000534 for mobile-ip@sunroof.eng.sun.com; Mon, 17 Jun 2002 18:42:45 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5EMBvk7011140 for ; Fri, 14 Jun 2002 15:11:57 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA20397 for ; Fri, 14 Jun 2002 15:12:01 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22737 for ; Fri, 14 Jun 2002 16:12:01 -0600 (MDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g5EMBxU12188 for ; Fri, 14 Jun 2002 18:11:59 -0400 Received: from scarpia.watson.ibm.com (scarpia.watson.ibm.com [9.2.9.124]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g5EMBuk50270 for ; Fri, 14 Jun 2002 18:11:58 -0400 Received: (from ayoussef@localhost) by scarpia.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id SAA50870 for mobile-ip@sunroof.eng.sun.com; Fri, 14 Jun 2002 18:11:50 -0400 Date: Fri, 14 Jun 2002 18:11:50 -0400 From: Alaa Youssef Message-Id: <200206142211.SAA50870@scarpia.watson.ibm.com> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Infocom 2003 - CFP Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: [Please accept our appologies if you receive duplicates of this announcement] ************************************************* ******* CALL FOR PAPERS ********* ************************************************* * IEEE INFOCOM 2003 * * The Conference on Computer Communications * * * * March 30 - April 3, 2003, San Francisco * * * * The 22nd Annual Joint Conference of the * * IEEE Computer and Communications Societies * * * * http://www.ieee-infocom.org/2003 * ************************************************* SCOPE ===== The major conference on computer communications and networking is celebrating its 22nd anniversary in San Francisco, California, during the week of March 30 - April 3, 2003. The conference will bring researchers and practitioners of every aspect of data communications and networks together to present the most up-to-date results and achievements in the field. Original papers are invited on recent advances in computer communications and networking. Topics of interest include, but are not limited to, the following: * Ad hoc & sensor networks * Addressing & location management * Admission control * Cellular networks * Content distribution & web caching * Flow & congestion control * Multicast * Network applications & services * Network architectures * Network control by pricing * Network design & planning * Network management & control * Optical networks * Power control * Pricing & billing mechanisms * Quality of service * Queueing/performance evaluation * Resource allocation * Routing algorithms * Scheduling & buffer management * Security & denial of service * Switches & switching * Topology inference * Traffic & performance measurement * Traffic engineering * Web performance * Wireless LANs SCHEDULE (STRICTLY ENFORCED) Full paper due July 10, 2002 Notification of acceptance October 25, 2002 Final version due December 19, 2002 CONFERENCE SCHEDULE Tutorials March 30-31, 2003 Conference April 1-3, 2003 INFORMATION ON: * Submission instructions * Program and registration * Tutorials * Workshops * Local arrangements * Student and travel grants appears at http://www.ieee-infocom.org/2003 For general information please contact the Genaral Chair, Fred Bauer (fredbauer@ieee.org) PROGRAM COMMITTEE CO-CHAIRS =========================== Jim Roberts, France Telecom R&D, France (james.roberts@francetelecom.com) Ness Shroff, Purdue University, USA (shroff@ecn.purdue.edu) From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 17 21:51:28 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25514 for ; Mon, 17 Jun 2002 21:51:28 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20632; Mon, 17 Jun 2002 18:51:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA08853; Mon, 17 Jun 2002 18:51:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5I1njk7025325 for ; Mon, 17 Jun 2002 18:49:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5I1njVt025324 for mobile-ip-dist; Mon, 17 Jun 2002 18:49:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5I1ngk7025317 for ; Mon, 17 Jun 2002 18:49:42 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA11660 for ; Mon, 17 Jun 2002 18:49:46 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07747 for ; Mon, 17 Jun 2002 19:49:45 -0600 (MDT) From: Masataka Ohta Message-Id: <200206180139.KAA21234@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA21234; Tue, 18 Jun 2002 10:39:17 +0900 Subject: Re: [mobile-ip] any deployment? In-Reply-To: from "Bui, Hung" at "Jun 17, 2002 04:06:48 pm" To: "Bui, Hung" Date: Tue, 18 Jun 2002 10:39:16 +0859 () CC: "'Pekka Savola'" , mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5I1ngk7025318 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hung Bui; > Yes, you can have connectivity to the Internet. You can either tether a PC > to one of our '+' phone or via the iDEN iM1100 modem, please see: > > http://www.nextel.com/services/nextelonline/index.shtml > It is still obscure. "packetstream service" in the page is explained: Use your existing applications. Use the same email, browser, and other web-enabled applications that are available to you ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in the office. Works especially well with various Wireless Business Solutions and third-party applications. that I have an impression that you are using NAT. Explanation on "Packetstream Gold service" is same. However, terms and conditions in iM1100 users' guide says: : 21. NEXTEL WIRELESS WEB gGOLDh SERVICES - Nextel Wireless : Web gGoldh Services are those Internet and data Services offered in : conjunction with a Service plan using the suffix gGoldh; e.g. PacketStream : Gold or PowerApps Gold. Company may charge an activation fee for each : IP address for these Services. These services may be used only with mobile : clients for Internet/intranet access and Internet e-mail via a standard HTML : browser (e.g., Netscape Navigator or Communicator, Microsoft Internet : Explorer, etc.) or proprietary client software for Public Online Service : Providers (e.g., AOL, CompuServe, ProdigyInternetTM), and related : mail clients. It may also be used with software for proxy applications (e.g., : Citrix), for dispatch applications, for POP3 email access, and for other use : specifically approved by Nextel. These Internet and data Services may not : be substituted for a private line or frame relay connection, or be used for : streaming data feeds. Company reserves the right to deny service, without : notice, to any Customer whose usage adversely impacts Companyfs : network, Systems or other subscribersf use of Services. that I'm totally confused. Is "Glod" service somewhat different? I understand that, at the speed of 56Kbps of "Gold" service, nextel is afraid that users may use Internet telephony without paying phone bill. "for other use specifically approved by Nextel" seems to mean that you had better use NAT. Still, contract is meaningful, though not so effective, to suppress such things as "IP over HTTP". But, it is equally possible that you give global addresses to ("Gold" or all) subscribers. Can you clarify? Or, can someone living in regions where nextel service is offerred clarify? Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 18 06:00:24 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11207 for ; Tue, 18 Jun 2002 06:00:23 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA22987; Tue, 18 Jun 2002 03:00:11 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29738; Tue, 18 Jun 2002 02:59:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5I9w7k7027781 for ; Tue, 18 Jun 2002 02:58:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5I9w64Z027780 for mobile-ip-dist; Tue, 18 Jun 2002 02:58:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5I9w4k7027773 for ; Tue, 18 Jun 2002 02:58:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA01949 for ; Tue, 18 Jun 2002 02:58:09 -0700 (PDT) From: Srinivasan.Damodaran@lntinfotech.com Received: from ltitlout.lntinfotech.com ([203.199.54.8]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04400 for ; Tue, 18 Jun 2002 03:58:08 -0600 (MDT) Received: from Bangalore.lntinfotech.com ([172.29.4.3]) by ltitlout.lntinfotech.com (Lotus Domino Release 5.0.9) with ESMTP id 2002061815444197:16856 ; Tue, 18 Jun 2002 15:44:41 +0530 Subject: [mobile-ip] Sub: Identifying link changes To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 18 Jun 2002 15:25:03 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 06/18/2002 03:25:06 PM, Itemize by SMTP Server on LTITLOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 06/18/2002 03:44:42 PM, Serialize by Router on LTITLOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 06/18/2002 03:44:45 PM, Serialize complete at 06/18/2002 03:44:45 PM Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi all, Consider the case where MN is in a foreign network, which has 2 default routers. Each router, advertises 2 global unicast address prefixes. Hence there are 4 global networks on a single link. Consider that one of the default router becomes unreachable. So, MN switches to the next default router. Here, MN considers the router change as network change and sends BU to the Previous network's HA, which is nothing but the HA in the same link as MN is currently in. This BU will be sent with 'D' bit set. HA will perform DAD which will be a problem since MN is also on the same network. Is there any other way of identifying the link changes, to avoid sending BU to HA on the same link where MN is currently in. Thanks Srinivasan From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 18 07:10:48 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12204 for ; Tue, 18 Jun 2002 07:10:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01049; Tue, 18 Jun 2002 05:11:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22588; Tue, 18 Jun 2002 04:10:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IB9sk7028222 for ; Tue, 18 Jun 2002 04:09:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5IB9sov028221 for mobile-ip-dist; Tue, 18 Jun 2002 04:09:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IB9pk7028214 for ; Tue, 18 Jun 2002 04:09:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA11810 for ; Tue, 18 Jun 2002 04:09:55 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15489 for ; Tue, 18 Jun 2002 05:11:59 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 6083F6A904; Tue, 18 Jun 2002 14:09:51 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 515336A901; Tue, 18 Jun 2002 14:09:48 +0300 (EEST) Message-ID: <3D0F1550.4070103@kolumbus.fi> Date: Tue, 18 Jun 2002 14:11:12 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Srinivasan.Damodaran@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Sub: Identifying link changes References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Srinivasan.Damodaran@lntinfotech.com wrote: > Consider the case where MN is in a foreign network, which has 2 default > routers. > Each router, advertises 2 global unicast address prefixes. Hence there are > 4 global networks on a single link. > > Consider that one of the default router becomes unreachable. So, MN > switches to the next default router. Here, MN considers the router change > as network change and sends BU to the Previous network's HA, which is > nothing but the HA in the same link as MN is currently in. This BU will be > sent with 'D' bit set. HA will perform DAD which will be a problem since MN > is also on the same network. > > Is there any other way of identifying the link changes, to avoid sending BU > to HA on the same link where MN is currently in. First, is this a legal or useful scenario? Since the MN is still on the link, it would be receiving packets destined to it even at the old care-of address. Of course, if the old router does not work at all any more, then the MN would not get its packets. But if it doesn't work e.g. due to a connectivity failure, wouldn't it also be unable to forward the packets using MIPv6? But if this is a useful scenarion, then the MN could leave the D bit to zero. There is no text in the current draft, however, to describe this particular reason for leaving it to zero. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 18 08:41:59 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14999 for ; Tue, 18 Jun 2002 08:41:59 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24227; Tue, 18 Jun 2002 05:41:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA02873; Tue, 18 Jun 2002 05:41:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ICeZk7028765 for ; Tue, 18 Jun 2002 05:40:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5ICeZ7F028764 for mobile-ip-dist; Tue, 18 Jun 2002 05:40:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ICeWk7028757 for ; Tue, 18 Jun 2002 05:40:32 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA14143 for ; Tue, 18 Jun 2002 05:40:37 -0700 (PDT) From: Srinivasan.Damodaran@lntinfotech.com Received: from ltitlout.lntinfotech.com ([203.199.54.8]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12398 for ; Tue, 18 Jun 2002 06:40:35 -0600 (MDT) Received: from Bangalore.lntinfotech.com ([172.29.4.3]) by ltitlout.lntinfotech.com (Lotus Domino Release 5.0.9) with ESMTP id 2002061818271059:18242 ; Tue, 18 Jun 2002 18:27:10 +0530 Subject: Re: [mobile-ip] Sub: Identifying link changes To: Jari Arkko Cc: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 18 Jun 2002 18:07:32 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 06/18/2002 06:07:33 PM, Itemize by SMTP Server on LTITLOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 06/18/2002 06:27:10 PM, Serialize by Router on LTITLOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 06/18/2002 06:27:14 PM, Serialize complete at 06/18/2002 06:27:14 PM Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > First, is this a legal or useful scenario? Let me explain the scenario clearly: MN is in a foreign network, which has 2 default routers (which are Home Agents also). Each default router, advertises 2 global unicast address prefixes. Hence there are 4 global networks on a single link. MN has selected one default router on that link and registered its primary CoA. Now the selected router turns to Host, by advertising with router lifetime set to Zero. But the router is still advertising the prefixes for autoconfiguration (not acting as default router). MN selects the next default router in the same link. But MN is unaware a router change or network change in the same link or a different link. So it forms primary care-of address and registers with Previous HA (Smooth Handoff). In this case, the BU with 'D' bit set is sent to HA in the same link. Now, when HA performs DAD, DAD fails, since MN defends the addres. MN is notified of DAD failure. So, MN deletes the entry from the BUL assuming to go without smooth handoff. But the address configured by MN are still valid. Hence, MN can receive the packets sent by any nodes directly in that link (Indirectly Smooth handoff is taken care). > Since the MN is still on the link, it would be receiving packets destined to it even at the old care-of > address. I fully agree with this. > But if this is a useful scenarion, then the MN could leave the D bit to zero. > There is no text in the current draft, however, to describe this particular > reason for leaving it to zero. When u set D bit to zero, HA will start perform proxy for a MN which is also on the same link. IMHO, this is incorrect. Is there any other way of identifying the link changes in an IPv6 network, so that MN can avoid sending a BU to Previous HA when there is no link change. Srinivasan.D, From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 18 15:26:07 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01499 for ; Tue, 18 Jun 2002 15:26:07 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12586; Tue, 18 Jun 2002 13:24:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18305; Tue, 18 Jun 2002 12:24:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IJN7k7000355 for ; Tue, 18 Jun 2002 12:23:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5IJN6EI000354 for mobile-ip-dist; Tue, 18 Jun 2002 12:23:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IJN1k7000347 for ; Tue, 18 Jun 2002 12:23:02 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17945 for ; Tue, 18 Jun 2002 12:23:07 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09673 for ; Tue, 18 Jun 2002 12:23:06 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01366; Tue, 18 Jun 2002 15:22:27 -0400 (EDT) Message-Id: <200206181922.PAA01366@ietf.org> To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: The IESG Subject: [mobile-ip] Last Call: Mobile IP NAT/NAPT Traversal using UDP Tunnelling to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 18 Jun 2002 15:22:27 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The IESG has received a request from the IP Routing for Wireless/Mobile Hosts Working Group to consider Mobile IP NAT/NAPT Traversal using UDP Tunnelling as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 2, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-04.txt From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 18 16:31:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03925 for ; Tue, 18 Jun 2002 16:31:52 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26363; Tue, 18 Jun 2002 14:34:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16842; Tue, 18 Jun 2002 13:31:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IKUVk7000616 for ; Tue, 18 Jun 2002 13:30:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5IKUVgb000615 for mobile-ip-dist; Tue, 18 Jun 2002 13:30:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5IKUSk7000608 for ; Tue, 18 Jun 2002 13:30:28 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.4+Sun/8.12.4) with SMTP id g5IKUXK4550884; Tue, 18 Jun 2002 13:30:34 -0700 (PDT) Message-Id: <200206182030.g5IKUXK4550884@jurassic.eng.sun.com> Date: Tue, 18 Jun 2002 13:33:03 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Sub: Identifying link changes To: Srinivasan.Damodaran@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LOzkNWtHRatj/2PlJxChow== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Let me explain the scenario clearly: > > MN is in a foreign network, which has 2 default routers (which are Home > Agents also). Each default router, advertises 2 global unicast address > prefixes. Hence there are 4 global networks on a single link. MN has > selected one default router on that link and registered its primary CoA. > OK. This is regular IPv6 protocol. Here MN is using one of it's auto-conf addresses as primary COA in the foreign network. > Now the selected router turns to Host, by advertising with router lifetime > set to Zero. But the router is still advertising the prefixes for > autoconfiguration (not acting as default router). > MN selects the next default router in the same link. But MN is unaware a > router change or network change in the same link or a different link. So it > forms primary care-of address and registers with Previous HA (Smooth > Handoff). In this case, the BU with 'D' bit set is sent to HA in the same > link. > How do you mean by "previous" HA ? Why does it need to change HA ? Your scenario does not describe that. How do you mean by "HA in the same link" ? > Now, when HA performs DAD, DAD fails, since MN defends the addres. MN is > notified of DAD failure. So, MN deletes the entry from the BUL assuming to > go without smooth handoff. But the address configured by MN are still > valid. Hence, MN can receive the packets sent by any nodes directly in that > link (Indirectly Smooth handoff is taken care). > > Since the MN is still on the link, it would be receiving packets destined > to it even at the old care-of > > address. > The above scenario does not seem to be valid. DAD is performed on the home-address by the home-agent on the home-link. The assumption is home-link is separate from the foreign link. -Samita From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 19 00:30:06 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13867 for ; Wed, 19 Jun 2002 00:30:05 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18916; Tue, 18 Jun 2002 21:29:52 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06972; Tue, 18 Jun 2002 21:29:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J4Rlk7001575 for ; Tue, 18 Jun 2002 21:27:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5J4RluC001574 for mobile-ip-dist; Tue, 18 Jun 2002 21:27:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J4Rhk7001567 for ; Tue, 18 Jun 2002 21:27:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06554 for ; Tue, 18 Jun 2002 21:27:48 -0700 (PDT) From: Srinivasan.Damodaran@lntinfotech.com Received: from ltitlout.lntinfotech.com ([203.199.54.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA18471 for ; Tue, 18 Jun 2002 22:27:46 -0600 (MDT) Received: from Bangalore.lntinfotech.com ([172.29.4.3]) by ltitlout.lntinfotech.com (Lotus Domino Release 5.0.9) with ESMTP id 2002061910143120:21629 ; Wed, 19 Jun 2002 10:14:31 +0530 Subject: [mobile-ip] Sub: Identifying link changes To: jari.arkko@kolumbus.fi Cc: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 19 Jun 2002 09:54:43 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 06/19/2002 09:54:45 AM, Itemize by SMTP Server on LTITLOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 06/19/2002 10:14:31 AM, Serialize by Router on LTITLOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 06/19/2002 10:14:34 AM, Serialize complete at 06/19/2002 10:14:34 AM Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Now the selected router turns to Host, by advertising with router lifetime > > set to Zero. But the router is still advertising the prefixes for > > autoconfiguration (not acting as default router). > > MN selects the next default router in the same link. But MN is unaware a > > router change or network change in the same link or a different link. So it > > forms primary care-of address and registers with Previous HA (Smooth > > Handoff). In this case, the BU with 'D' bit set is sent to HA in the same > > link. Samita wrote : > How do you mean by "previous" HA ? Why does it need to change HA ? > Your scenario does not describe that. How do you mean by "HA in the > same link" ? Probably, I may not have explained it properly in my previous mail. __ -- |MN| -- |R1|----------------------------- |R2| -- (Foreign Link) | -- 3ffe:1::0 -- 2ffe:1::0 3ffe:2::0 |HA| 2ffe:2::0 -- Assume that MN has selected R1, has default router which advertises the prefixes, 3ffe:1::0, 3ffe:2::0. Now, this has changed to Host. So, MN is switching to another default router on the same link which is advertising with 2ffe:1::0, 2ffe:2::0. As far as MN is concerned, it is unaware whether it is a router change from the same link or from a different link. MN forms primary care-of address and registers with HA in its Home link (which performs DAD on the Home link for its Home addresses, not shown in the diagram). Since, the prefixes are different there is a network change. Hence MN will send a BU to previous network HA (which is in our case, nothing but the HA in the same link as the MN is currently in). My question is, can MN avoid sending BU to HA when there is no link change? If so, how to identify the link changes? > The above scenario does not seem to be valid. > DAD is performed on the home-address by the home-agent on the home-link. The > assumption is home-link is separate from the foreign link. Is DAD, not performed by the HA in the foreign link? Srinivasan From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 19 03:47:00 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10255 for ; Wed, 19 Jun 2002 03:46:59 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28027; Wed, 19 Jun 2002 00:46:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA22548; Wed, 19 Jun 2002 00:46:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J7imk7002117 for ; Wed, 19 Jun 2002 00:44:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5J7im2l002116 for mobile-ip-dist; Wed, 19 Jun 2002 00:44:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5J7iik7002109 for ; Wed, 19 Jun 2002 00:44:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA13437 for ; Wed, 19 Jun 2002 00:44:48 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA27432 for ; Wed, 19 Jun 2002 01:44:47 -0600 (MDT) From: Masataka Ohta Message-Id: <200206190734.QAA28281@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA28281; Wed, 19 Jun 2002 16:34:00 +0900 Subject: Re: [mobile-ip] Draft Agenda for MIP WG @ IETF54 In-Reply-To: <697DAA22C5004B4596E033803A7CEF44A12F68@daebe007.NOE.Nokia.com> from "Basavaraj.Patil@nokia.com" at "Jun 17, 2002 03:58:59 pm" To: Basavaraj.Patil@nokia.com Date: Wed, 19 Jun 2002 16:33:58 +0859 () CC: mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Dear Chairs; > Following is the draft agenda for the Mobile IP WG meeting at > IETF54. The MIP WG meeting is currently scheduled for Monday, July > 15th from 1930-2200. I'd like to be assigned a slot (10 minuites, hopefully) for presentation on the attached draft: Smooth Handover over IEEE 802.11 Wireless LAN It basically states a well know fact for PHS industry that completely smooth handover is possible almost purely by end systems without introducing inteligent intermediate entities in the network. I'm still revising the draft that the first section will be editted a lot reflecting the recent exchanges of deployment information. I will also add explanations on how time requiredd for frequency scanning of IEEE 802.11 can be minimized. > Agenda bashing 5 min > > WG Document update 10 min > > Mobile IP v6 60 min > draft-ietf-mobileip-ipv6-18.txt Jari Arkko > > Fast handoff in v6 20 min > draft-ietf-mobileip-fast-mipv6-05.txt Rajeev Koodli > > VPN traversal requirements 5 min > draft-ietf-mobileip-vpn-problem-statement-00.txt Phil Roberts > > Limited Private Address Support 10 Mins > draft-chakrabarti-mobileip-privaddr-00.txt Gabriel Montenegro > > Mobile IPv4 Regional Registration 5 Mins > draft-ietf-mobileip-reg-tunnel-06.txt Phil Roberts > > LMM Requirements 5 min > draft-ietf-mobileip-lmm-requirements-01.txt Carl Williams > > -Chairs > > --- INTERNET DRAFT M. Ohta draft-ohta-smooth-handover-wlan-00.txt Tokyo Institute of Technology June 2002 Smooth Handover over IEEE 802.11 Wireless LAN Status of this Memo This document is an Internet-Draft and is subject to 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright (C) The Internet Society (June/15/2002). All Rights Reserved. Abstract This memo describes, based on the experience of MIS (Mobile Internet Services, Inc.) for commercial mobile IP service over IEEE 802.11b based wireless LAN environment, how smooth handover between access points is implemented. The major obstacle for the smooth handover is time required to scan frequency bands and latency of mobile registration is not so much a problem, both of which is solved with terminals having two transceivers. 1. Introduction MIS (Mobile Internet Services, Inc.) is the first, and currently the only, ISP in the world to commercially provide mobile IP service. M. Ohta Expires on December 15, 2002 [Page 1] INTERNET DRAFT Smooth Handover over WLAN June 2002 MIS uses IEEE 802.11b based wireless LAN infrastructure and puts a lot of wireless LAN access points to let its subscribers move around with IP mobility. MIS started public field trial in August 2001 and started commercial service in April 2002. During the trial, a possible problem of the wireless LAN became apparent that it takes considerable amount of time, often more than a second, to scan all the possible frequency bands, which is required upon handover to find the next access point better than the current. For some applications such as web browsing, it is not a problem. However, for streaming applications such as Internet telephony, smooth handover with little or no service interruption is strongly desired. The problem is solved by terminals having two wireless transceivers. 2. Smooth Handover with Two Transceivers To prevent the service interruption, it is necessary that a terminal, which is expected to run service-interruption-sensitive applications, should have two wireless LAN transceivers, one for keeping connection to the the current access point and another for scanning frequency bands to search alternative ones. 3. Smoother Handover with Two Transceivers With the elimination of service interruption for frequency band scanning, there still is a smaller amount of service interruption for mobility registration, which can also be eliminated. With two wireless LAN transceivers, just after one transceiver find a new access point better than the current, a new connection to the new access point should be established through the transceiver. Then, mobility registration for the new access point should be initiated. Still, another transceiver should keep connecting to the current access point. A while after the terminal confirms a successful mobility registration, the terminal should terminate the connection to the old access point and, as described in section 2, start scanning newer access points. M. Ohta Expires on December 15, 2002 [Page 2] INTERNET DRAFT Smooth Handover over WLAN June 2002 During mobile registration, 4. Applications of the Technique The technique described in sections 2 and 3 was deployed in recent PHS (personal handy phone, 32Kbps mobile telephone system available in Japan and other countries) service, only after which, PHS can support stable and smooth handover. In general, the technique requires two sets of transceivers, which increases the cost of terminals, which is welcome to wireless LAN chip vendors, it also reduce the cost of network by eliminating intelligent intermediate entities for half-hearted smooth mobility. Note that a CDMA based wireless transceiver can simultaneously use two access points with different code without additional RF modules. 5. Security Considerations To prevent anonymous and/or unpaid access to the Internet, access points of MIS have packet-wise cryptographical authentication mechanism to disallow unauthorized access to the Internet. To prevent subscribers share a single subscriber ID with single payment, the mechanism disallows multiple terminals with a single subscriber ID simultaneously use access points. As a side effect, the mechanism, basically, disallows a terminal simultaneously use multiple access points. However, to allow for the smooth handover, a terminal is allowed to simultaneously use access points with overlapping service area. 6. Author's Address Masataka Ohta Graduate School of Information Science and Engineering, Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku Tokyo 152-8552, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3299 EMail: mohta@necom830.hpcl.titech.ac.jp M. Ohta Expires on December 15, 2002 [Page 3] INTERNET DRAFT Smooth Handover over WLAN June 2002 7. Full Copyright Statement "Copyright (C) The Internet Society (June/15/2002). 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. M. Ohta Expires on December 15, 2002 [Page 4] From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 19 11:07:59 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22038 for ; Wed, 19 Jun 2002 11:07:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13988; Wed, 19 Jun 2002 09:10:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22714; Wed, 19 Jun 2002 08:08:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JF5jk7003076 for ; Wed, 19 Jun 2002 08:05:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JF5j2Q003075 for mobile-ip-dist; Wed, 19 Jun 2002 08:05:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JF5gk7003068 for ; Wed, 19 Jun 2002 08:05:42 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13184 for ; Wed, 19 Jun 2002 08:05:46 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24574 for ; Wed, 19 Jun 2002 09:05:45 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5JF5iRb007478 for ; Wed, 19 Jun 2002 17:05:44 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Jun 2002 17:05:44 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F075F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] confusion about prefix sol/adv Date: Wed, 19 Jun 2002 17:05:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: After some off-list discussion with a few people, I'm getting quite confused about the reason for having the mobile prefix sol and adv. I know this was done a long time ago, but we were discussing some security issues and then I couldn't help but ask: why do we need these messages at all? To be able to send these messages, the MN needs to have the HA's address. If it knows that, then it knows its home address.... Do we need to complicate things and have another message pair, that are sent with different src addresses, and cannot be secured? Can't the HA just include some prefix options in the BA ? or even BR ....or whatever message that can be secured with the MN - HA SA? (not relying on dynamic SAs would be an advantage of course, for obvious reasons). Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 19 11:08:24 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22073 for ; Wed, 19 Jun 2002 11:08:24 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14363; Wed, 19 Jun 2002 09:10:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17231; Wed, 19 Jun 2002 08:08:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JF7ck7003096 for ; Wed, 19 Jun 2002 08:07:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JF7ciE003095 for mobile-ip-dist; Wed, 19 Jun 2002 08:07:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JF7Yk7003078 for ; Wed, 19 Jun 2002 08:07:34 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13678 for ; Wed, 19 Jun 2002 08:07:38 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20547 for ; Wed, 19 Jun 2002 08:07:38 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id CBA796A904; Wed, 19 Jun 2002 18:07:26 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A84886A901; Wed, 19 Jun 2002 18:07:24 +0300 (EEST) Message-ID: <3D109E81.9000406@kolumbus.fi> Date: Wed, 19 Jun 2002 18:08:49 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Alexandru Petrescu Cc: Michael.Scharf@daimlerchrysler.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RO for nodes that are not mobile? References: <0057440019941614000002L442*@MHS> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > writes: > >>Assume an ongoing IPv6 communication between two nodes A and B, which are not >>mobile, but B implements the CN function of MIPv6. A third node C is located on >>the path between A and B. In my impression, C could send a BU to node B for >>node A including an own "CoA". As far as I have understood the return >>routability test, a correct binding in B can be established if C can intercept >>all packets sent to A's address. Thus, using MIPv6 RO, all packets sent from B >>to A will be delivered to the "CoA" at node C. If node C removes the MH and >>then forwards the packets, node A may not even notice this slight modification >>of routing. >> > > Hey Michael, how are you. > > I think you forgot the path towards the HA. The node B will send the > HoT message towards the HA of node A, and this HA is out of the path > where C is found. > > You might worry that an attacker puts node C and C' on both A-B and > B-HA paths but don't worry too much because there might be no > alternative. Don't know if there is an alternative or not. But in any case an attacker who is on the path between the home and the CN is already today able to do a lot of damage, e.g. by modifying or blocking packets. (There are a few minor differences relating to the time that you have to be on the link vs. the effect of the attack, which I think we have covered by limiting the lifetimes. There's also been a debate on what happens if "today"'s security situation in the Internet is changed. But for now, RR appears quite sufficient for the security of CN binding updates.) For additional reading, see http://www.piuha.net./~jarkko/publications/mipv6/security-considerations-new.txt http://www.piuha.net./~jarkko/publications/mipv6/Residual_Threats.txt Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 19 11:38:55 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23886 for ; Wed, 19 Jun 2002 11:38:55 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11992; Wed, 19 Jun 2002 09:39:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26703; Wed, 19 Jun 2002 08:39:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JFaek7003399 for ; Wed, 19 Jun 2002 08:36:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JFaeCp003398 for mobile-ip-dist; Wed, 19 Jun 2002 08:36:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JFaak7003391 for ; Wed, 19 Jun 2002 08:36:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28861 for ; Wed, 19 Jun 2002 08:36:33 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02858 for ; Wed, 19 Jun 2002 09:38:42 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id AB1706A904; Wed, 19 Jun 2002 18:36:25 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 02D386A901; Wed, 19 Jun 2002 18:36:24 +0300 (EEST) Message-ID: <3D10A54C.4020706@kolumbus.fi> Date: Wed, 19 Jun 2002 18:37:48 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Luis Miguel Oliveira Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MN source address in MIPv6 References: <006601c21166$ebf8c240$eb5c88c1@loliveira> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Luis Miguel Oliveira wrote: > I'm studding mobile IPv6 in transition scenarios (IPv4 /IPv6). When MN > way from home network it uses the CoAddr as source address to avoid > triangle routing and its home address are sent in one of destination > option. These comportment is problematic when we try to use transitions > mechanisms (like NAT-PT, TRT) to connect to IPv4 CN. > > It is possible to disable IPv6 Binding mechanisms under these situations? In the current design you have to handle at least the first situation below. You may handle the second situation, if you want to: 1. Route optimization is not used. Then all packets in both directions go through the HA. I would assume the translation device has to reside between the HA and the CN. In this case there's really no difference whatsoever to regular IPv6 communications, so it should work. 2. Route optimization is used. Then all packets in both directions go straight to the CN. Or the translation device at least. If the translation device for some reason can't handle this, it could presumably drop all MH packets, causing the mobile node to fail in setting up route optimization even if it tried to. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 19 12:17:22 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25307 for ; Wed, 19 Jun 2002 12:17:21 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22349; Wed, 19 Jun 2002 09:17:08 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16750; Wed, 19 Jun 2002 09:16:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JGDbk7003549 for ; Wed, 19 Jun 2002 09:13:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JGDbTp003548 for mobile-ip-dist; Wed, 19 Jun 2002 09:13:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JGDYk7003541 for ; Wed, 19 Jun 2002 09:13:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09622 for ; Wed, 19 Jun 2002 09:13:39 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA15279 for ; Wed, 19 Jun 2002 10:13:37 -0600 (MDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5JGH4j04991 for ; Wed, 19 Jun 2002 11:17:05 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Jun 2002 11:13:29 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 19 Jun 2002 11:13:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Draft Agenda for MIP WG @ IETF54 Date: Wed, 19 Jun 2002 11:13:02 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44096984@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] Draft Agenda for MIP WG @ IETF54 Thread-Index: AcIXZTAh8tZCCT8GTo62KNNYYymFtQAQ2DPA To: Cc: X-OriginalArrivalTime: 19 Jun 2002 16:13:03.0281 (UTC) FILETIME=[3059F210:01C217AC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5JGDYk7003542 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Masataka, IETF Working group meetings are NOT the place for making presentations. WG meetings are focused on discussing issues pertinent to the ongoing work and also other relevant topics that are within the scope of the charter. However with respect to the *relevant topics*, there needs to be a considerable amount of interest shown by the WG members in order to have an agenda item for discussion. We normally view the discussions on the mailing list to determine the level of interest in a topic. The Smooth handoff work is obviously a work item in the Mobile IP WG and we currently have two WG I-Ds dealing with MIPv4 and MIPv6. Your draft does not propose any enhancements to Mobile IP itself in order to enable smooth HO. The solution you describe does not make use of MIP to enhance the performance of HOs. I agree that the solution is quite valid for the WLAN environment but fail to understand what the MIP WG would have to do with it. Hence, I do not see any need for using up WG time at IETF54 to present this solution. Of course if there is WG interest in the approach proposed by you and issues relevant to this WG, we can always add it to the agenda. If we see more discussion in terms of impacts/changes required to MIP on the MN or FA/AR or HA, with the availability of dual WLAN interfaces, that would be a more relevant topic for discussion. -Basavaraj > Dear Chairs; > > > Following is the draft agenda for the Mobile IP WG meeting at > > IETF54. The MIP WG meeting is currently scheduled for Monday, July > > 15th from 1930-2200. > > I'd like to be assigned a slot (10 minuites, hopefully) for > presentation on the attached draft: > > Smooth Handover over IEEE 802.11 Wireless LAN > > It basically states a well know fact for PHS industry that completely > smooth handover is possible almost purely by end systems without > introducing inteligent intermediate entities in the network. > > I'm still revising the draft that the first section will be editted > a lot reflecting the recent exchanges of deployment information. > I will also add explanations on how time requiredd for frequency > scanning of IEEE 802.11 can be minimized. > > > Agenda bashing 5 min > > > > WG Document update 10 min > > > > Mobile IP v6 60 min > > draft-ietf-mobileip-ipv6-18.txt Jari Arkko > > > > Fast handoff in v6 20 min > > draft-ietf-mobileip-fast-mipv6-05.txt Rajeev Koodli > > > > VPN traversal requirements 5 min > > draft-ietf-mobileip-vpn-problem-statement-00.txt Phil Roberts > > > > Limited Private Address Support 10 Mins > > draft-chakrabarti-mobileip-privaddr-00.txt Gabriel Montenegro > > > > Mobile IPv4 Regional Registration 5 Mins > > draft-ietf-mobileip-reg-tunnel-06.txt Phil Roberts > > > > LMM Requirements 5 min > > draft-ietf-mobileip-lmm-requirements-01.txt Carl Williams > > > > -Chairs > > > > > > --- > > > > > > INTERNET DRAFT > M. Ohta > draft-ohta-smooth-handover-wlan-00.txt Tokyo Institute of > Technology > > June 2002 > > Smooth Handover over IEEE 802.11 Wireless LAN > From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 19 12:42:33 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26214 for ; Wed, 19 Jun 2002 12:42:33 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09632; Wed, 19 Jun 2002 09:42:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01812; Wed, 19 Jun 2002 09:42:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JGdXk7003684 for ; Wed, 19 Jun 2002 09:39:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JGdXAu003683 for mobile-ip-dist; Wed, 19 Jun 2002 09:39:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JGdTk7003676 for ; Wed, 19 Jun 2002 09:39:29 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20343 for ; Wed, 19 Jun 2002 09:39:34 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26420 for ; Wed, 19 Jun 2002 10:39:34 -0600 (MDT) 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 JAA15758; Wed, 19 Jun 2002 09:39:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5JGdTJ08314; Wed, 19 Jun 2002 09:39:29 -0700 X-mProtect: <200206191639> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpdqeh5la; Wed, 19 Jun 2002 09:39:26 PDT Message-ID: <3D10B3BF.18E0B5EC@kniveton.com> Date: Wed, 19 Jun 2002 09:39:27 -0700 From: "T.J. Kniveton" Organization: NOKIA Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] confusion about prefix sol/adv References: <4DA6EA82906FD511BE2F00508BCF0538044F075F@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Hesham Soliman (ERA)" wrote: > > After some off-list discussion with a few people, > I'm getting quite confused about the reason > for having the mobile prefix sol and adv. > I know this was done a long time ago, but we > were discussing some security issues and then > I couldn't help but ask: why do we need these > messages at all? > > To be able to send these messages, the MN needs > to have the HA's address. If it knows that, then it > knows its home address.... > Do we need to complicate things and have another > message pair, that are sent with different src > addresses, and cannot be secured? > > Can't the HA just include some prefix options in > the BA ? or even BR ....or whatever message that > can be secured with the MN - HA SA? > (not relying on dynamic SAs would be an advantage > of course, for obvious reasons). > > Hesham Hi Hesham, I am guilty of writing these sections into the MIPv6 draft, so I guess I should answer your query. :-) The mobile prefix solicitation and advertisement were added to the draft for a couple of reasons, which I will detail. They grew out of the "tunneled router solicitation/advertisement," which were in the draft previously, but insufficient to meet all the requirements, and had some problems. I don't have the draft on hand at the moment, but let me address your question from memory and others can add more if necessary. The main reasons why MPS/MPA are in the draft are twofold: 1. Bootstrapping. When a MN is starting up, it needs to know about prefixes on its home network so it can construct an appropriate CoA(s). There may be many HAs on the home network servicing multiple prefixes. Any HA which receives an MPS should respond with a list of prefixes served by HAs on the home network. This step is similar to non-mobile address autoconfiguration, where an IPv6 node will send a router solicitation and receive a (solicited) router advertisement with information about the router and characteristics of the link, including available prefixes. 2. Maintenance. When a router senses that prefixes have been added, removed, refreshed, etc., the HA will send a MPA to MNs registered with it that are affected by the change (or to all MNs registered). This step is similar to non-mobile periodic unsolicited router advertisements sent by a router to refresh prefix information on a link. 3. Renumbering. This is a special case, where the prefixes in use for a network hierarchy become deprecated when new prefixes are available (e.g. when switching ISPs), and then disappear entirely. If a MN is registered during the period of a renumbering event (typically it should take days or weeks), it will receive information about the new prefix(es). Without this information, it would not know about the new prefix(es), and potentially could lose contact with its home network entirely. This step is similar to non-mobile unsolicited router advertisements being sent during renumbering as described in the neighbor discovery draft RFC 2461, starting on page 78. It may be possible to operate a mobile node without MPSs and MPAs, in the same way it is possible to operate a fixed node without neighbor discovery messages. But that would require a level of static configuration that seems avoidable. As to the questions people have posed about security associations, it is desirable to use them at all times possible. And in our conversation off-list I mentioned that the intent is to use them whenever possible (i.e. in step 2 and possibly 3 above); however, the SAs are dependent on having a home address configured, and when MPS/MPA are used, that might not always be the case (i.e. step 1). It is not entirely clear how to secure messages between a HA and a MN when the MN is discovering who its HA is, and defining its own home address. This is easily avoidable when static configurations are used (and thus not an issue at all), but the design philosophy of IPv6 seems to encourage creating networks starting with nothing or very little. As I also mentioned in the e-mail conversation, I would like to clarify the cases when MPS and MPA would be protected by e.g. an AH, and would welcome suggestions on precisely how to word the clarification. If you are interested on more information about MPS and MPA, check out the list archives from around May 2001. When writing these sections, I consciously tried to reduce as much complexity as possible from Tunneled RS/RA to ease implementation and fix some problems. Of course, it may be possible to simplify them even more while preserving functionality. -TJ -- T.J. Kniveton Communications Systems Lab Nokia Research Center From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 19 12:45:38 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26387 for ; Wed, 19 Jun 2002 12:45:38 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00642; Wed, 19 Jun 2002 10:46:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29348; Wed, 19 Jun 2002 09:45:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JGiKk7003751 for ; Wed, 19 Jun 2002 09:44:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JGiK0N003750 for mobile-ip-dist; Wed, 19 Jun 2002 09:44:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JGiHk7003743 for ; Wed, 19 Jun 2002 09:44:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02567 for ; Wed, 19 Jun 2002 09:44:22 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28505 for ; Wed, 19 Jun 2002 10:44:21 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 442E46A905; Wed, 19 Jun 2002 19:44:15 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 665A16A904; Wed, 19 Jun 2002 19:43:58 +0300 (EEST) Message-ID: <3D10B523.9010903@kolumbus.fi> Date: Wed, 19 Jun 2002 19:45:23 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Srinivasan.Damodaran@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: Sub: Identifying link changes References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Srinivasan.Damodaran@lntinfotech.com wrote: > Probably, I may not have explained it properly in my previous mail. > __ > -- |MN| -- > |R1|----------------------------- |R2| > -- (Foreign Link) | -- > 3ffe:1::0 -- 2ffe:1::0 > 3ffe:2::0 |HA| 2ffe:2::0 > -- > > Assume that MN has selected R1, has default router which advertises the > prefixes, > 3ffe:1::0, 3ffe:2::0. Now, this has changed to Host. So, MN is switching to > another default router on the same link which is advertising with > 2ffe:1::0, > 2ffe:2::0. As far as MN is concerned, it is unaware whether it is a router > change > from the same link or from a different link. Ah, OK, now I see... > MN forms primary care-of address and registers with HA in its Home link > (which performs DAD on the Home link for its Home addresses, not shown > in the diagram). > > Since, the prefixes are different there is a network change. Hence MN will > send > a BU to previous network HA (which is in our case, nothing but the HA in > the same > link as the MN is currently in). > > My question is, can MN avoid sending BU to HA when there is no link change? > If so, how to identify the link changes? I'm still not sure there's a problem. Let's discuss two cases: 1. R1 turns into a real host. In other words, it no longer sends any Router Advertisements. It will therefore not answer any Binding Updates or defend anyone's addresses either. In this case the end result is similar to the case when R1 would simply die. The old CoA becomes unavailable. The MN would use a new one. If there were packets on their way to R1 from the CNs, those will be dropped. 2. R1 declares that it is no longer a default router. It will still be a router, and send Router Advertisements. Is this harmful? Only if (a) R1 performs DAD and (b) MN answers the DAD. But how can we get into such a situation? R1 will of course perform DAD if it still works as a home agent, and the Binding Update has the 'D' bit on. But why would the MN answer DAD? If the MN believes it is on foreign link, why would it respond to a DAD on an old CoA? Come to think of it, I'm not even sure why the MN would respond to NS on its own HoA before it has determined that it is on the home link (11.6.7). In conclusion I think we should state the following in the specification. The MN SHOULD NOT respond to NS on its home address until it has determined that it is on the home link and has successfully deregistered its binding from the home agent. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 19 14:13:56 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29751 for ; Wed, 19 Jun 2002 14:13:55 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06273; Wed, 19 Jun 2002 11:13:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27499; Wed, 19 Jun 2002 11:13:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JIBik7004099 for ; Wed, 19 Jun 2002 11:11:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JIBit1004098 for mobile-ip-dist; Wed, 19 Jun 2002 11:11:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JIBek7004091 for ; Wed, 19 Jun 2002 11:11:41 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09256 for ; Wed, 19 Jun 2002 11:11:45 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05052 for ; Wed, 19 Jun 2002 11:11:44 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 2DB066A904; Wed, 19 Jun 2002 21:11:38 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 754326A901; Wed, 19 Jun 2002 21:11:36 +0300 (EEST) Message-ID: <3D10C9AC.5050607@kolumbus.fi> Date: Wed, 19 Jun 2002 21:13:00 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Vijay Devarapalli , Vladislav Yasevich , "Hesham Soliman (ERA)" Subject: [mobile-ip] Resolution to issue 37, defending only link local addresses Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm trying to close the issue 37. After some off-link discussion with folks, I wonder if the following proposal would work. Let us know if you have views on this. Jari ---- Background: Hesham Soliman writes: Fifth bullet in 10.2: Shouldn't DAD be done for all addresses? RFC 3041 might be a problem here if we only do DAD on link-local addresses. Proposal: Vijay Devaparalli and Vladislav Yasevich have proposed that a new 'L' bit is needed. If the 'L' bit is set, it means both the MN's link local address and home address have the same interface id. The 'L' and 'S' bits are used when defending addresses i.e. when answering Neighbor Soliciations. The following addresses are defended: - S=0 & L=0 => Defend all global unicast addresses possible on link. - S=0 & L=1 => Semantics of S=0 above + the derived link-local. - S=1 & L=0 => Defend the given address. - S=1 & L=1 => Defend the given global unicast (home) address + the derived link-local. If the home address was generated using RFC 3041, then there is no corresponding link local address. Accordingly the MN SHOULD NOT set the 'L' bit. The Home Agent SHOULD perform Duplicated Address detection on every address it is defending on behalf of the mobile node. From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 19 15:11:32 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01266 for ; Wed, 19 Jun 2002 15:11:31 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02151; Wed, 19 Jun 2002 13:12:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05485; Wed, 19 Jun 2002 12:11:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JJ9Ek7004464 for ; Wed, 19 Jun 2002 12:09:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JJ9ExL004463 for mobile-ip-dist; Wed, 19 Jun 2002 12:09:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JJ9Ak7004456 for ; Wed, 19 Jun 2002 12:09:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28853 for ; Wed, 19 Jun 2002 12:09:11 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20835 for ; Wed, 19 Jun 2002 13:09:10 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 224DA6A904; Wed, 19 Jun 2002 22:09:03 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 066F66A901; Wed, 19 Jun 2002 22:09:00 +0300 (EEST) Message-ID: <3D10D721.8060800@kolumbus.fi> Date: Wed, 19 Jun 2002 22:10:25 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "T.J. Kniveton" Cc: "Hesham Soliman (ERA)" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] confusion about prefix sol/adv References: <4DA6EA82906FD511BE2F00508BCF0538044F075F@Esealnt861.al.sw.ericsson.se> <3D10B3BF.18E0B5EC@kniveton.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit T.J. Kniveton wrote: > As I also mentioned in the e-mail conversation, I would like to clarify the > cases when MPS and MPA would be protected by e.g. an AH, and would welcome > suggestions on precisely how to word the clarification. One potential modification to the current text relates to securing NS. It seems to me that it _is_ possible to secure this with AH/ESP even if the MN does not yet have an address. Basically, we could have a _single_ SA shared by the HA and all the mobile nodes that can be used to send ICMP messages to the HA. This SA has to be dependent on the destination address per IPsec rules. But it does not have to be dependent on the source address. (On the advertisement message the situation is of course reversed.) Alternatively, IKE-based security could perhaps be applied. Another modification to the text would talk more about the specific security policy entries that are needed for the protection. A potential third modification would improve the security of the first (unprotected) MPA by adding a cookie in the MPS that would be returned by the MPA. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 19 17:23:14 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03995 for ; Wed, 19 Jun 2002 17:23:14 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15083; Wed, 19 Jun 2002 15:22:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01167; Wed, 19 Jun 2002 14:22:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JLLCk7004861 for ; Wed, 19 Jun 2002 14:21:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JLLCOZ004860 for mobile-ip-dist; Wed, 19 Jun 2002 14:21:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JLL8k7004853 for ; Wed, 19 Jun 2002 14:21:09 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12131 for ; Wed, 19 Jun 2002 14:21:13 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03974 for ; Wed, 19 Jun 2002 15:21:12 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g5JLL8P06075; Wed, 19 Jun 2002 16:21:09 -0500 (CDT) Message-ID: <3D10F5E0.4010106@alcatel.com> Date: Wed, 19 Jun 2002 16:21:36 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Masataka Ohta CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] any deployment? References: <200206180139.KAA21234@necom830.hpcl.titech.ac.jp> Content-Type: multipart/alternative; boundary="------------030700020503000105020709" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------030700020503000105020709 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hello Masataka, What about your (MIS) deployment of MIP? Can you tell us more about it? Are you using public addresses with MIPv4 as you mentioned RFC2002? What is RGW2400? One comment on your draft, on page 3, you started During mobile registration, and nothing followed it? Regards, Masataka Ohta wrote: >Hung Bui; > >>Yes, you can have connectivity to the Internet. You can either tether a PC >>to one of our '+' phone or via the iDEN iM1100 modem, please see: >> >>http://www.nextel.com/services/nextelonline/index.shtml >> >> > >It is still obscure. > >"packetstream service" in the page is explained: > > Use your existing applications. Use the same email, browser, > and other web-enabled applications that are available to you > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > in the office. Works especially well with various Wireless > Business Solutions and third-party applications. > >that I have an impression that you are using NAT. > >Explanation on "Packetstream Gold service" is same. > >However, terms and conditions in iM1100 users' guide says: > >: 21. NEXTEL WIRELESS WEB ?gGOLD?h SERVICES - Nextel Wireless >: Web ?gGold?h Services are those Internet and data Services offered in >: conjunction with a Service plan using the suffix ?gGold?h; e.g. PacketStream >: Gold or PowerApps Gold. Company may charge an activation fee for each >: IP address for these Services. These services may be used only with mobile >: clients for Internet/intranet access and Internet e-mail via a standard HTML >: browser (e.g., Netscape Navigator or Communicator, Microsoft Internet >: Explorer, etc.) or proprietary client software for Public Online Service >: Providers (e.g., AOL, CompuServe, ProdigyInternetTM), and related >: mail clients. It may also be used with software for proxy applications (e.g., >: Citrix), for dispatch applications, for POP3 email access, and for other use >: specifically approved by Nextel. These Internet and data Services may not >: be substituted for a private line or frame relay connection, or be used for >: streaming data feeds. Company reserves the right to deny service, without >: notice, to any Customer whose usage adversely impacts Company?fs >: network, Systems or other subscribers?f use of Services. > >that I'm totally confused. > >Is "Glod" service somewhat different? > >I understand that, at the speed of 56Kbps of "Gold" service, nextel >is afraid that users may use Internet telephony without paying >phone bill. > >"for other use specifically approved by Nextel" seems to mean that >you had better use NAT. > >Still, contract is meaningful, though not so effective, to suppress >such things as "IP over HTTP". > >But, it is equally possible that you give global addresses to ("Gold" >or all) subscribers. > >Can you clarify? > >Or, can someone living in regions where nextel service is offerred >clarify? > > Masataka Ohta > -- Behcet --------------030700020503000105020709 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hello Masataka,
  What about your (MIS) deployment of MIP? Can you tell us more about it? Are you using public addresses with MIPv4 as you mentioned RFC2002?
What is RGW2400?
  One comment on your draft, on page 3, you started
During mobile registration,

and nothing followed it?
  Regards,

Masataka Ohta wrote:
Hung Bui;

Yes, you can have connectivity to the Internet.  You can either tether a PC
to one of our '+' phone or via the iDEN iM1100 modem, please see:
 
http://www.nextel.com/services/nextelonline/index.shtml
<http://www.nextel.com/services/nextelonline/index.shtml> 

It is still obscure.

"packetstream service" in the page is explained:

	Use your existing applications. Use the same email, browser,
	and other web-enabled applications that are available to you
	    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	in the office. Works especially well with various Wireless
	Business Solutions and third-party applications.

that I have an impression that you are using NAT.

Explanation on "Packetstream Gold service" is same.

However, terms and conditions in iM1100 users' guide says:

: 21. NEXTEL WIRELESS WEB ?gGOLD?h SERVICES - Nextel Wireless
: Web ?gGold?h Services are those Internet and data Services offered in
: conjunction with a Service plan using the suffix ?gGold?h; e.g. PacketStream
: Gold or PowerApps Gold. Company may charge an activation fee for each
: IP address for these Services. These services may be used only with mobile
: clients for Internet/intran
et access and Internet e-mail via a standard HTML
: browser (e.g., Netscape Navigator or Communicator, Microsoft Internet
: Explorer, etc.) or proprietary client software for Public Online Service
: Providers (e.g., AOL, CompuServe, ProdigyInternetTM), and related
: mail clients. It may also be used with software for proxy applications (e.g.,
: Citrix), for dispatch applications, for POP3 email access, and for other use
: specifically approved by Nextel. These Internet and data Services may not
: be substituted for a private line or frame relay connection, or be used for
: streaming data feeds. Company reserves the right to deny service, without
: notice, to any Customer whose usage adversely impacts Company?fs
: network, Systems or other subscribers?f use of Services.

that I'm totally confused.

Is "Glod" service somewhat different?

I understand that, at the speed of 56Kbps of "Gold" service, nextel
is afraid that users ma
y use Internet telephony without paying
phone bill.

"for other use specifically approved by Nextel" seems to mean that
you had better use NAT.

Still, contract is meaningful, though not so effective, to suppress
such things as "IP over HTTP".

But, it is equally possible that you give global addresses to ("Gold"
or all) subscribers.

Can you clarify?

Or, can someone living in regions where nextel service is offerred
clarify?

						Masataka Ohta


-- 
Behcet

--------------030700020503000105020709-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 19 19:21:44 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06148 for ; Wed, 19 Jun 2002 19:21:44 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20751; Wed, 19 Jun 2002 16:21:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21687; Wed, 19 Jun 2002 16:21:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JNKCk7005229 for ; Wed, 19 Jun 2002 16:20:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JNKCtY005228 for mobile-ip-dist; Wed, 19 Jun 2002 16:20:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JNK9k7005221 for ; Wed, 19 Jun 2002 16:20:09 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.4+Sun/8.12.4) with SMTP id g5JNKEPC305065; Wed, 19 Jun 2002 16:20:14 -0700 (PDT) Message-Id: <200206192320.g5JNKEPC305065@jurassic.eng.sun.com> Date: Wed, 19 Jun 2002 16:22:45 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Sub: Identifying link changes To: Srinivasan.Damodaran@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: WLtKdHj85Y2GATJFKHXE9A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > Probably, I may not have explained it properly in my previous mail. > __ > -- |MN| -- > |R1|----------------------------- |R2| > -- (Foreign Link) | -- > 3ffe:1::0 -- 2ffe:1::0 > 3ffe:2::0 |HA| 2ffe:2::0 > -- > > Assume that MN has selected R1, has default router which advertises the > prefixes, > 3ffe:1::0, 3ffe:2::0. Now, this has changed to Host. So, MN is switching to > another default router on the same link which is advertising with > 2ffe:1::0, > 2ffe:2::0. As far as MN is concerned, it is unaware whether it is a router > change > from the same link or from a different link. > > MN forms primary care-of address and registers with HA in its Home link > (which performs DAD on the Home link for its Home addresses, not shown > in the diagram). > > Since, the prefixes are different there is a network change. Hence MN will > send > a BU to previous network HA (which is in our case, nothing but the HA in > the same > link as the MN is currently in). > > My question is, can MN avoid sending BU to HA when there is no link change? > If so, how to identify the link changes? > As per section 11.4 (movement detection) when a MN changes it's default-router and acquire a new primary COA, it indicates that MN may send a binding update. If the previous default router still stays as a router, MN would still continue to receive packets from CN. If that router dies or becomes a non-router, then MN will have to send BU to stay connected. While MN is on the link, it should receive both prefixes from both the routers and it already keeps track of list of COAs and default routers on the network. But it selects one of them as it's primary default router and it also selects a corresponding COA. So, when it switches to the backup router it should know that there is no change in link has happened. > > The above scenario does not seem to be valid. > > DAD is performed on the home-address by the home-agent on the home-link. > The > > assumption is home-link is separate from the foreign link. > > Is DAD, not performed by the HA in the foreign link? No, assuming your HA link is separate than the foreign link. -Samita From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 19 19:40:18 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06348 for ; Wed, 19 Jun 2002 19:40:18 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08405; Wed, 19 Jun 2002 17:40:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01529; Wed, 19 Jun 2002 16:40:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JNdYk7005362 for ; Wed, 19 Jun 2002 16:39:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5JNdY8q005361 for mobile-ip-dist; Wed, 19 Jun 2002 16:39:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5JNdVk7005354 for ; Wed, 19 Jun 2002 16:39:31 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29198 for ; Wed, 19 Jun 2002 16:39:37 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14261 for ; Wed, 19 Jun 2002 16:39:36 -0700 (PDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5JNh5j04333 for ; Wed, 19 Jun 2002 18:43:05 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Jun 2002 18:39:35 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 19 Jun 2002 18:39:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] confusion about prefix sol/adv Date: Wed, 19 Jun 2002 18:39:30 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12FB0@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] confusion about prefix sol/adv Thread-Index: AcIXxSwjpsx6GUl8Rmij+epoT9aRGwAJVhYA To: , Cc: , X-OriginalArrivalTime: 19 Jun 2002 23:39:31.0195 (UTC) FILETIME=[8F313CB0:01C217EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5JNdVk7005355 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit >> As I also mentioned in the e-mail conversation, I would like to clarify the >> cases when MPS and MPA would be protected by e.g. an AH, and would welcome >> suggestions on precisely how to word the clarification. > What is the security risk associated with not securing the MPS and MPA? I think we could leave the MPS and MPA unsecured. I believe there has been previous discussion on this topic and the conclusion is to use a cookie mechanism. If the issue is related to the MNs being sent unsolicited MPAs (DoS attack), the MN can send an MPS as a result of receiving an unsolicited MPA and only act if it receives an MPA as a response from its HA. I do not believe there are any security issues related to the HA receiving MPS messages. If the concern is an HA being flooded with MPS', rate limiting techniques or simply ignoring these messages can be adopted. I do not believe we need to have IPsec based security for MPS and MPA. >One potential modification to the current text relates to securing NS. It >seems to me that it _is_ possible to secure this with AH/ESP even if the >MN does not yet have an address. Basically, we could have a _single_ SA >shared by the HA and all the mobile nodes that can be used to send ICMP >messages to the HA. This SA has to be dependent on the destination address >per IPsec rules. But it does not have to be dependent on the source address. >(On the advertisement message the situation is of course reversed.) >Alternatively, IKE-based security could perhaps be applied. > >Another modification to the text would talk more about the specific >security policy entries that are needed for the protection. > >A potential third modification would improve the security of the first >(unprotected) MPA by adding a cookie in the MPS that would be returned >by the MPA. The above (third) modification is the only mechanism that needs to be applied to MPS, MPA (IMO). > >Jari -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 19 20:24:45 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06792 for ; Wed, 19 Jun 2002 20:24:44 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18884; Wed, 19 Jun 2002 17:24:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19314; Wed, 19 Jun 2002 17:24:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5K0NLk7005553 for ; Wed, 19 Jun 2002 17:23:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5K0NLaC005552 for mobile-ip-dist; Wed, 19 Jun 2002 17:23:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5K0NIk7005545 for ; Wed, 19 Jun 2002 17:23:18 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18884 for ; Wed, 19 Jun 2002 17:23:24 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03380 for ; Wed, 19 Jun 2002 17:23:23 -0700 (PDT) From: Masataka Ohta Message-Id: <200206200003.JAA00512@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA00512; Thu, 20 Jun 2002 09:03:40 +0900 Subject: Re: [mobile-ip] Draft Agenda for MIP WG @ IETF54 In-Reply-To: <697DAA22C5004B4596E033803A7CEF44096984@daebe007.NOE.Nokia.com> from "(env:" "Basavaraj.Patil@nokia.com)" at "Jun 19, 2002 11:13:02 am" To: Basavaraj.Patil@nokia.com Date: Thu, 20 Jun 2002 09:03:33 +0859 () CC: mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Basavaraj; > IETF Working group meetings are NOT the place for making > presentations. WG meetings are focused on discussing issues > pertinent to the ongoing work and also other relevant topics > that are within the scope of the charter. However with respect > to the *relevant topics*, there needs to be a considerable > amount of interest shown by the WG members in order to have > an agenda item for discussion. We normally view the discussions > on the mailing list to determine the level of interest in a > topic. Your misunderstanding is that "discussion" includes to recognize some existing topics irrlevant. > I > agree that the solution is quite valid for the WLAN environment Even if my draft were valid on WLAN environment only, it follows the current work iten of: - Documenting any requirements specific to cellular/wireless networks. that there is no requirement of smooth handover by the network. Moreover, you obvviously ignoreing my draft stating: : 4. Applications of the Technique : : The technique described in sections 2 and 3 was deployed in recent : PHS (personal handy phone, 32Kbps mobile telephone system available : in Japan and other countries) service, only after which, PHS can : support stable and smooth handover. : : In general, the technique requires two sets of transceivers, which : increases the cost of terminals, which is welcome to wireless LAN : chip vendors, it also reduce the cost of network by eliminating : intelligent intermediate entities for half-hearted smooth mobility. : : Note that a CDMA based wireless transceiver can simultaneously use : two access points with different code without additional RF modules. that the solution is proven to valid for the PHS environment and is more easily depolyable for CDMA environment. > but fail to understand what the MIP WG would have to do with it. Stop attempting to work on smooth handover in any environment. > Of course if there is WG interest in the approach proposed by > you and issues relevant to this WG, we can always add it to the > agenda. If we see more discussion in terms of impacts/changes > required to MIP on the MN or FA/AR or HA, with the availability > of dual WLAN interfaces, that would be a more relevant topic for > discussion. Another relevant protocol topic is in the security section: : 5. Security Considerations : : To prevent anonymous and/or unpaid access to the Internet, access : points of MIS have packet-wise cryptographical authentication : mechanism to disallow unauthorized access to the Internet. : : To prevent subscribers share a single subscriber ID with single : payment, the mechanism disallows multiple terminals with a single : subscriber ID simultaneously use access points. : : As a side effect, the mechanism, basically, disallows a terminal : simultaneously use multiple access points. : : However, to allow for the smooth handover, a terminal is allowed to : simultaneously use access points with overlapping service area. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 19 20:33:53 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06912 for ; Wed, 19 Jun 2002 20:33:53 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29626; Wed, 19 Jun 2002 18:34:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA23838; Wed, 19 Jun 2002 17:34:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5K0XJk7005659 for ; Wed, 19 Jun 2002 17:33:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5K0XJlf005658 for mobile-ip-dist; Wed, 19 Jun 2002 17:33:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5K0XGk7005651 for ; Wed, 19 Jun 2002 17:33:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18971 for ; Wed, 19 Jun 2002 17:33:20 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01138 for ; Wed, 19 Jun 2002 18:35:31 -0600 (MDT) From: Masataka Ohta Message-Id: <200206200013.JAA00714@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA00714; Thu, 20 Jun 2002 09:13:32 +0900 Subject: Re: [mobile-ip] any deployment? In-Reply-To: <3D10F5E0.4010106@alcatel.com> from Behcet Sarikaya at "Jun 19, 2002 04:21:36 pm" To: Behcet Sarikaya Date: Thu, 20 Jun 2002 09:13:32 +0859 () CC: mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Behcet; > What about your (MIS) deployment of MIP? Can you tell us more about it? OK. > Are you using public addresses with MIPv4 as you mentioned RFC2002? Yes. > What is RGW2400? RGW2400 (not a product of MIS) is a router between Ether and 802.11b, running NetBSD. MIS installed security module on it. With MIS service, FA is collocated with MN that wireless routers are not dependent on any mobility protocols. > One comment on your draft, on page 3, you started > During mobile registration, > > and nothing followed it? Thanks. I was adding inessential explanation During mobile registration, packets from CH comes from either of the access points. As the terminal recieves packets from both access points, there is no packet loss caused by the latency of the registration. I will add it to the next version. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 02:42:36 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20960 for ; Thu, 20 Jun 2002 02:42:35 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA19821; Wed, 19 Jun 2002 23:42:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04480; Wed, 19 Jun 2002 23:42:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5K6fKk7006609 for ; Wed, 19 Jun 2002 23:41:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5K6fKXi006608 for mobile-ip-dist; Wed, 19 Jun 2002 23:41:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5K6fHk7006601 for ; Wed, 19 Jun 2002 23:41:17 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA28817 for ; Wed, 19 Jun 2002 23:41:20 -0700 (PDT) From: Srinivasan.Damodaran@lntinfotech.com Received: from ltitlout.lntinfotech.com ([203.199.54.8]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA19411 for ; Wed, 19 Jun 2002 23:41:18 -0700 (PDT) Received: from Bangalore.lntinfotech.com ([172.29.4.3]) by ltitlout.lntinfotech.com (Lotus Domino Release 5.0.9) with ESMTP id 2002062012272587:7086 ; Thu, 20 Jun 2002 12:27:25 +0530 Subject: [mobile-ip] Sub: Identifying link changes To: jari.arkko@kolumbus.fi, Samita Chakrabarti Cc: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 20 Jun 2002 12:08:13 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 06/20/2002 12:08:15 PM, Itemize by SMTP Server on LTITLOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 06/20/2002 12:27:25 PM, Serialize by Router on LTITLOUT/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 06/20/2002 12:27:30 PM, Serialize complete at 06/20/2002 12:27:30 PM Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jari wrote: > 2. R1 declares that it is no longer a default router. It will still > be a router, and send Router Advertisements. > Is this harmful? Only if (a) R1 performs DAD and (b) MN answers > the DAD. But how can we get into such a situation? R1 will of > course perform DAD if it still works as a home agent, and the > Binding Update has the 'D' bit on. But why would the MN answer > DAD? If the MN believes it is on foreign link, why would it > respond to a DAD on an old CoA? In this case, R1 performs DAD for link-local address of MN also. Is this assumption right? If yes, Should MN respond for NS on its link-local address or not? If no, and if MN is not responding for these NS's (for old CoA's of MN), DAD will be successful. R1 will perfrom HA functionality i.e, will proxy for MN's old CoA's which is still directly reachable for the router R1. The packet is tunneled to MN's New primary CoA. IMHO, this is not required > Come to think of it, I'm not even sure why the MN would > respond to NS on its own HoA before it has determined that > it is on the home link (11.6.7). Yes, this is clearly mentioned in the returning home case. Is this conditions, apply to foreign link CoA's also? Samita wrote: >As per section 11.4 (movement detection) when a MN changes it's default-router >and acquire a new primary COA, it indicates that MN may send a binding update. >If the previous default router still stays as a router, MN would still continue >to receive packets from CN. If that router dies or becomes a non-router, then >MN will have to send BU to stay connected. >While MN is on the link, it >should receive both prefixes from both the routers and it already keeps track >of list of COAs and default routers on the network. But it selects one of them >as it's primary default router and it also selects a corresponding COA. >So, when it switches to the backup router it should know that there is no >change in link has happened. The idea of sending BU, is to maintain connection. So, there is no need for sending a BU when the old router (though not acting as default router but performs HA & router functionality) is still reachable. I fully agree with this. Even, my earlier question was how to avoid sending BU to previous router? In order to do this, should MN maintain info about these routers also (which are no longer default router)? In section 11.4.1.(Movement Detection), it has been mentioned that MN maintains or keeps track of only its default routers. Now, if MN needs to check the reachability of this router(which is no longer a default router), should it also maintain info about these routers which are turning from default routers to router. In this case, how long we maintain these entries? Can MN have its own local policy for doing this? Is this conclusion right? Srinivasan.D From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 06:32:37 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23678 for ; Thu, 20 Jun 2002 06:32:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18118; Thu, 20 Jun 2002 04:33:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25885; Thu, 20 Jun 2002 03:32:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KAUtk7007100 for ; Thu, 20 Jun 2002 03:30:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KAUtaN007099 for mobile-ip-dist; Thu, 20 Jun 2002 03:30:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KAUlk7007089 for ; Thu, 20 Jun 2002 03:30:49 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14189 for ; Thu, 20 Jun 2002 03:30:51 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17339 for ; Thu, 20 Jun 2002 04:30:50 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5KAUjrU011910; Thu, 20 Jun 2002 12:30:45 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 12:30:45 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF05380498C8AF@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Jari Arkko , Krishna Kumar Cc: Basavaraj.Patil@nokia.com, PRoberts@megisto.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: MIPv6 - 17 Review (Fixed tabs, please ignore earlier mail) Date: Thu, 20 Jun 2002 12:30:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > 19. Section 10.2 : The para about : > > "- The Refresh field MUST be set to a value less than or equal to" > > Is Refresh useful at all ? I don't believe it is. It seems to imply that it > helps in the case of the Home Agent crashing and has only a volatile storage > for the binding cache. But if the Home Agent crashed before the Refresh > interval is over, the behaviour is identical to the case where the Refresh > field contains the same value as Lifetime. > > It will be useful only if the HA crashed after the Refresh interval but before > the Lifetime interval. Hence it is completely useless in most situations. > > If this can be removed safely, all references need to be removed in the > draft and the Format of the BU section (6.1.8) needs to reflect this. How do others feel about this? Assigned a separate issue #43. => Jari, I completely agree with Krishna. After a second quick review, I wanted to raise this, but luckily I'm reading old emails first! I don't see the value of the refresh field. In our very first implementation, this feature was configurable (X % of BU lifetime), with a set default value in the implementation. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 07:44:22 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23690 for ; Thu, 20 Jun 2002 06:32:38 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18155; Thu, 20 Jun 2002 04:33:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25960; Thu, 20 Jun 2002 03:33:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KAUrk7007097 for ; Thu, 20 Jun 2002 03:30:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KAUqDD007096 for mobile-ip-dist; Thu, 20 Jun 2002 03:30:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KAUjk7007082 for ; Thu, 20 Jun 2002 03:30:46 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14134 for ; Thu, 20 Jun 2002 03:30:48 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12516 for ; Thu, 20 Jun 2002 03:30:47 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5KAUgrU011879; Thu, 20 Jun 2002 12:30:43 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 12:30:42 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF05380498C8B1@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Srinivasan.Damodaran@lntinfotech.com, jari.arkko@kolumbus.fi Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Sub: Identifying link changes Date: Thu, 20 Jun 2002 12:30:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Do we know how to secure a BU to a random AR? Is the assumption that we will use RR for this? If the answer is no to either question, then this scenario should not exist. Hesham > -----Original Message----- > From: Srinivasan.Damodaran@lntinfotech.com > [mailto:Srinivasan.Damodaran@lntinfotech.com] > Sent: Wednesday, June 19, 2002 6:25 AM > To: jari.arkko@kolumbus.fi > Cc: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Sub: Identifying link changes > > > > > Now the selected router turns to Host, by advertising > with router > lifetime > > > set to Zero. But the router is still advertising the > prefixes for > > > autoconfiguration (not acting as default router). > > > MN selects the next default router in the same link. > But MN is unaware > a > > > router change or network change in the same link or a > different link. > So it > > > forms primary care-of address and registers with > Previous HA (Smooth > > > Handoff). In this case, the BU with 'D' bit set is sent > to HA in the > same > > > link. > > Samita wrote : > > > How do you mean by "previous" HA ? Why does it need to change HA ? > > Your scenario does not describe that. How do you mean by > "HA in the > > same link" ? > > Probably, I may not have explained it properly in my previous mail. > __ > -- |MN| -- > |R1|----------------------------- |R2| > -- (Foreign Link) | -- > 3ffe:1::0 -- 2ffe:1::0 > 3ffe:2::0 |HA| 2ffe:2::0 > -- > > Assume that MN has selected R1, has default router which > advertises the > prefixes, > 3ffe:1::0, 3ffe:2::0. Now, this has changed to Host. So, MN > is switching to > another default router on the same link which is advertising with > 2ffe:1::0, > 2ffe:2::0. As far as MN is concerned, it is unaware whether > it is a router > change > from the same link or from a different link. > > MN forms primary care-of address and registers with HA in > its Home link > (which performs DAD on the Home link for its Home > addresses, not shown > in the diagram). > > Since, the prefixes are different there is a network > change. Hence MN will > send > a BU to previous network HA (which is in our case, nothing > but the HA in > the same > link as the MN is currently in). > > My question is, can MN avoid sending BU to HA when there is > no link change? > If so, how to identify the link changes? > > > The above scenario does not seem to be valid. > > DAD is performed on the home-address by the home-agent on > the home-link. > The > > assumption is home-link is separate from the foreign link. > > Is DAD, not performed by the HA in the foreign link? > > Srinivasan > From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 08:54:21 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27957 for ; Thu, 20 Jun 2002 08:54:21 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27009; Thu, 20 Jun 2002 06:57:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA03826; Thu, 20 Jun 2002 05:54:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KCrck7007729 for ; Thu, 20 Jun 2002 05:53:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KCrcf5007728 for mobile-ip-dist; Thu, 20 Jun 2002 05:53:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KCrZk7007721 for ; Thu, 20 Jun 2002 05:53:35 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA03584 for ; Thu, 20 Jun 2002 05:53:39 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10097 for ; Thu, 20 Jun 2002 06:53:37 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5KCrZrV028500; Thu, 20 Jun 2002 14:53:35 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 14:53:35 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0768@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Basavaraj.Patil@nokia.com'" , jari.arkko@kolumbus.fi, tj@kniveton.com Cc: "Hesham Soliman (ERA)" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] confusion about prefix sol/adv Date: Thu, 20 Jun 2002 14:53:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > >> As I also mentioned in the e-mail conversation, I would > like to clarify the > >> cases when MPS and MPA would be protected by e.g. an AH, > and would welcome > >> suggestions on precisely how to word the clarification. > > > > What is the security risk associated with not securing the MPS and > MPA? I think we could leave the MPS and MPA unsecured. => One attack mentioned by Jari in earlier discussions was to deprecate a lifetime of a prefix, or swap lifetimes....etc This is effectively a DoS attack. The difference I see between this and other DoS attacks is that an attacker can deny any communication with any CN (by making the MN choose the wrong address) while not located on the path between the CN and the MN. But I still think we're jumping too far. I doubt that security will be an issue if we send these messages _after_ the BU is sent to the HA... It's pretty easy to secure the message after that. I'll reply to TJ's email shortly. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 09:07:36 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28474 for ; Thu, 20 Jun 2002 09:07:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17053; Thu, 20 Jun 2002 07:08:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA09145; Thu, 20 Jun 2002 06:07:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KD6ok7007844 for ; Thu, 20 Jun 2002 06:06:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KD6oUO007843 for mobile-ip-dist; Thu, 20 Jun 2002 06:06:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KD6lk7007836 for ; Thu, 20 Jun 2002 06:06:47 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29498 for ; Thu, 20 Jun 2002 06:06:52 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00760 for ; Thu, 20 Jun 2002 06:06:51 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5KD6mRc012134; Thu, 20 Jun 2002 15:06:48 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 15:06:48 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0769@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'T.J. Kniveton'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] confusion about prefix sol/adv Date: Thu, 20 Jun 2002 15:06:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi TJ, > The main reasons why MPS/MPA are in the draft are twofold: > 1. Bootstrapping. When a MN is starting up, it needs to > know about prefixes on > its home network so it can construct an appropriate CoA(s). => You mean HoA(s) ? I don't think it's needed for CoA construction. > There may be many > HAs on the home network servicing multiple prefixes. Any HA > which receives an > MPS should respond with a list of prefixes served by HAs on > the home network. > This step is similar to non-mobile address > autoconfiguration, where an IPv6 > node will send a router solicitation and receive a > (solicited) router > advertisement with information about the router and > characteristics of the > link, including available prefixes. => Sure, but my point was that somehow the MN must already know the HA's address. Or to be exact, it needs to know the HA's anycast address. So if it knows that it can perform DAAD, then MPS? I really don't see the need. If the MN knows the home link's prefix (from the HA's anycast address) then it has already one home address (since it knows its own iid... So why can't the MN send a BU _first_, _then_ send an MPS and receive MPA, to get the rest of the prefixes? > > 2. Maintenance. When a router senses that prefixes have > been added, removed, > refreshed, etc., the HA will send a MPA to MNs registered > with it that are > affected by the change (or to all MNs registered). > This step is similar to non-mobile periodic unsolicited > router advertisements > sent by a router to refresh prefix information on a link. > > 3. Renumbering. This is a special case, where the prefixes > in use for a network > hierarchy become deprecated when new prefixes are available > (e.g. when > switching ISPs), and then disappear entirely. If a MN is > registered during the > period of a renumbering event (typically it should take > days or weeks), it will > receive information about the new prefix(es). Without this > information, it > would not know about the new prefix(es), and potentially > could lose contact > with its home network entirely. => I'm fine with all of the above, I only object to the order in which these messages are sent. I don't see a reason for this order. We wouldn't need to talk about how to secure them, if they were simply sent after the first BU. > This step is similar to non-mobile unsolicited router > advertisements being > sent during renumbering as described in the neighbor > discovery draft RFC 2461, > starting on page 78. > =>Agreed. > > It may be possible to operate a mobile node without MPSs > and MPAs, in the same > way it is possible to operate a fixed node without neighbor > discovery messages. > But that would require a level of static configuration that > seems avoidable. => But you already need to statically configure something. You can do DHAAD if you don't know the HA's anycast address. Knowing that seems the same as knowing one home address, unless you're worried about storing another 64 bits :) > As to the questions people have posed about security > associations, it is > desirable to use them at all times possible. And in our > conversation off-list I > mentioned that the intent is to use them whenever possible > (i.e. in step 2 and > possibly 3 above); however, the SAs are dependent on having > a home address > configured, and when MPS/MPA are used, that might not > always be the case (i.e. > step 1). It is not entirely clear how to secure messages > between a HA and a MN > when the MN is discovering who its HA is, and defining its > own home address. => Exactly! so why can't we send them after the BU? Alternatively you can secure the messages before that if the HA knows the MN's public key. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 10:27:16 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01286 for ; Thu, 20 Jun 2002 10:27:16 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28681; Thu, 20 Jun 2002 08:27:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20165; Thu, 20 Jun 2002 07:27:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KEQck7008109 for ; Thu, 20 Jun 2002 07:26:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KEQcpO008108 for mobile-ip-dist; Thu, 20 Jun 2002 07:26:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KEQZk7008101 for ; Thu, 20 Jun 2002 07:26:35 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19837 for ; Thu, 20 Jun 2002 07:26:39 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12964 for ; Thu, 20 Jun 2002 08:26:37 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 2C9316A904; Thu, 20 Jun 2002 17:26:37 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 409676A905; Thu, 20 Jun 2002 17:26:35 +0300 (EEST) Message-ID: <3D11D4A9.10402@kolumbus.fi> Date: Thu, 20 Jun 2002 16:12:09 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Hesham Soliman (ERA)" Cc: Srinivasan.Damodaran@lntinfotech.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Sub: Identifying link changes References: <4DA6EA82906FD511BE2F00508BCF05380498C8B1@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham Soliman (ERA) wrote: > Do we know how to secure a BU to a random AR? > Is the assumption that we will use RR for this? The spec says the temporary HA should be treated as a regular HA. In other words, either you have security associations, can establish them on the fly, or you don't do this. > If the answer is no to either question, then this > scenario should not exist. Yes. (But we are also discussion other ways to avoid this scenario.) Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 10:28:49 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01382 for ; Thu, 20 Jun 2002 10:28:49 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18350; Thu, 20 Jun 2002 08:31:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26959; Thu, 20 Jun 2002 07:29:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KESJk7008136 for ; Thu, 20 Jun 2002 07:28:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KESJHm008135 for mobile-ip-dist; Thu, 20 Jun 2002 07:28:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KESGk7008128 for ; Thu, 20 Jun 2002 07:28:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26653 for ; Thu, 20 Jun 2002 07:28:19 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17659 for ; Thu, 20 Jun 2002 08:30:33 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g5KESEP00806; Thu, 20 Jun 2002 09:28:14 -0500 (CDT) Message-ID: <3D11E69C.60602@alcatel.com> Date: Thu, 20 Jun 2002 09:28:44 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Masataka Ohta CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] any deployment? References: <200206200013.JAA00714@necom830.hpcl.titech.ac.jp> Content-Type: multipart/alternative; boundary="------------020801050405020807050400" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------020801050405020807050400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Masataka, Thanks for the info. I am glad to hear that MIPv4 is being deployed. Two transceivers (which emulate cellular networks' use of multiple physical channels) on each MN might cause interference, more so if so many are placed in the same cell. Do you agree with this? Regards, Masataka Ohta wrote: >Behcet; > >>What about your (MIS) deployment of MIP? Can you tell us more about it? >> > >OK. > >>Are you using public addresses with MIPv4 as you mentioned RFC2002? >> > >Yes. > >>What is RGW2400? >> > >RGW2400 (not a product of MIS) is a router between Ether and 802.11b, >running NetBSD. MIS installed security module on it. > >With MIS service, FA is collocated with MN that wireless routers are >not dependent on any mobility protocols. > >>One comment on your draft, on page 3, you started >>During mobile registration, >> >>and nothing followed it? >> > >Thanks. I was adding inessential explanation > > During mobile registration, packets from CH comes from either > of the access points. As the terminal recieves packets from > both access points, there is no packet loss caused by > the latency of the registration. > >I will add it to the next version. > Masataka Ohta > -- Behcet --------------020801050405020807050400 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Masataka,
  Thanks for the info. I am glad to hear that MIPv4 is being deployed.
Two transceivers (which emulate cellular networks' use of multiple physical channels) on each MN might cause interference, more so if so many are placed in the same cell. Do you agree with this?
    Regards,

Masataka Ohta wrote:
Behcet;

What about your (MIS) deployment of MIP? Can you tell us more about it?

OK.

Are you using public addresses with MIPv4 as you mentioned RFC2002?

Yes.

What is RGW2400?

RGW2400 (not a product of MIS) is a router between Ether and 802.11b,
running NetBSD. MIS installed security module on it.

With MIS service, FA is collocated with MN that wireless routers are
not dependent on any mobility protocols.

One comment on your draft, on page 3, you started
During mobile registration,

and nothing followed it?

Thanks. I was adding inessential explanation

	During mobile registration, packets from CH comes from either
	of the access points. As the terminal recieves packets from
	both access points, there is no packet loss caused by
	the latency of the registration.

I will add it to the next version.
						Masataka Ohta

-- 
Behcet

--------------020801050405020807050400-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 11:43:33 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03688 for ; Thu, 20 Jun 2002 11:43:32 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02105; Thu, 20 Jun 2002 08:43:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14947; Thu, 20 Jun 2002 08:43:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KFgTk7008460 for ; Thu, 20 Jun 2002 08:42:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KFgTwO008459 for mobile-ip-dist; Thu, 20 Jun 2002 08:42:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KFgQk7008450 for ; Thu, 20 Jun 2002 08:42:26 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15060 for ; Thu, 20 Jun 2002 08:42:30 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08001 for ; Thu, 20 Jun 2002 09:42:29 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5KFgPRb016327; Thu, 20 Jun 2002 17:42:25 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 17:42:25 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0774@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Jari Arkko'" , "Hesham Soliman (ERA)" Cc: Srinivasan.Damodaran@lntinfotech.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Sub: Identifying link changes Date: Thu, 20 Jun 2002 17:42:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Do we know how to secure a BU to a random AR? > > Is the assumption that we will use RR for this? > > > The spec says the temporary HA should be treated as > a regular HA. In other words, either you have security > associations, can establish them on the fly, or you > don't do this. => So is the approach to not mention what mechanisms should be used (for the 'on-the-fly' case) and leave it FFS? Because the preconfigured cases are probably not likely to exist. So I'm wondering whether we should keep it. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 12:03:52 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04536 for ; Thu, 20 Jun 2002 12:03:51 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24419; Thu, 20 Jun 2002 10:04:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22855; Thu, 20 Jun 2002 09:04:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KG32k7008601 for ; Thu, 20 Jun 2002 09:03:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KG326W008600 for mobile-ip-dist; Thu, 20 Jun 2002 09:03:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KG2xk7008593 for ; Thu, 20 Jun 2002 09:02:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22546 for ; Thu, 20 Jun 2002 09:03:04 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19878 for ; Thu, 20 Jun 2002 10:05:17 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 044EE6A901; Thu, 20 Jun 2002 19:02:57 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4F33B6A904; Thu, 20 Jun 2002 19:02:55 +0300 (EEST) Message-ID: <3D11F3CB.8050700@kolumbus.fi> Date: Thu, 20 Jun 2002 18:24:59 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Srinivasan.Damodaran@lntinfotech.com Cc: Samita Chakrabarti , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Sub: Identifying link changes References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Srinivasan.Damodaran@lntinfotech.com wrote: > Jari wrote: > > >>2. R1 declares that it is no longer a default router. It will still >> be a router, and send Router Advertisements. >> > >> Is this harmful? Only if (a) R1 performs DAD and (b) MN answers >> the DAD. But how can we get into such a situation? R1 will of >> course perform DAD if it still works as a home agent, and the >> Binding Update has the 'D' bit on. But why would the MN answer >> DAD? If the MN believes it is on foreign link, why would it >> respond to a DAD on an old CoA? >> > > In this case, R1 performs DAD for link-local address of MN also. > > Is this assumption right? > > If yes, Should MN respond for NS on its link-local address or not? I suppose it has to be responding on the link-local address, as it would be the same even under the new router. > The idea of sending BU, is to maintain connection. So, there is no need for > sending a BU when the old router (though not acting as default router but > performs HA & router functionality) is still reachable. > > I fully agree with this. Even, my earlier question was how to avoid sending > BU to previous router? > In order to do this, should MN maintain info about these routers also > (which are no longer default router)? > > In section 11.4.1.(Movement Detection), it has been mentioned that MN > maintains or keeps track of only its default routers. Now, if MN needs to > check the reachability of this router(which is no longer a default router), > should it also maintain info about these routers which are turning from > default > routers to router. I suppose there'd be three ways out of this. 1) Make the forwarding-from-previous-coa work well. That is, we'd need to solve the DAD problem. Apperently it is not enough to not respond to NSes on the old coa, because of the link local problem you described above. Could we use the 'L' to let the home agent know that it should not do DAD on the link-local address in this case? 2) Have the MN keep track of the situation well enough so that it would know it is still on the same link. This would involve keeping information about non-default routers as well. 3) Forbid the possibility of a router to become a non-default router and still continue to act as a home agent. If we do this, then the BU sent for forwarding-from-previous-coa will fail. But that's allright because the CN's packets will end up in this LAN regardless. Other options? Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 12:43:53 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05909 for ; Thu, 20 Jun 2002 12:43:52 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17041; Thu, 20 Jun 2002 10:46:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12654; Thu, 20 Jun 2002 09:44:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KGhBk7008749 for ; Thu, 20 Jun 2002 09:43:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KGhBSe008748 for mobile-ip-dist; Thu, 20 Jun 2002 09:43:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KGh8k7008741 for ; Thu, 20 Jun 2002 09:43:08 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07267 for ; Thu, 20 Jun 2002 09:43:12 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22643 for ; Thu, 20 Jun 2002 10:43:12 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g5KGgbP12180; Thu, 20 Jun 2002 11:42:37 -0500 (CDT) Message-ID: <3D12061A.20300@alcatel.com> Date: Thu, 20 Jun 2002 11:43:06 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Henrik Levkowetz CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Feedback on draft-ietf-mobileip-nat-traversal-04.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Henrik, I think there was a last call on this draft from IESG but I could find the mail so I am writing to the list: On page 17 you said: A foreign agent using MIP UDP tunnelling to a home agent because **it** is situated behind a NAT may be configured to encourage reverse tunnelling, or be neutral about it, depending on the characteristics of the NAT. the it above, does it refer to HA or FA? I think it is HA, and not FA. Therefore my suggestion is to replace the it by HA to make it specific and clear. Sorry if this mail came to late to change things. Regards, Henrik Levkowetz wrote: --behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 12:45:58 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05993 for ; Thu, 20 Jun 2002 12:45:58 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24601; Thu, 20 Jun 2002 10:46:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13560; Thu, 20 Jun 2002 09:46:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KGjMk7008781 for ; Thu, 20 Jun 2002 09:45:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KGjL5W008779 for mobile-ip-dist; Thu, 20 Jun 2002 09:45:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KGjIk7008772 for ; Thu, 20 Jun 2002 09:45:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13100 for ; Thu, 20 Jun 2002 09:45:23 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17550 for ; Thu, 20 Jun 2002 10:47:36 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id A76426A904; Thu, 20 Jun 2002 19:45:21 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id DF06B6A901; Thu, 20 Jun 2002 19:45:19 +0300 (EEST) Message-ID: <3D1206F4.6010902@kolumbus.fi> Date: Thu, 20 Jun 2002 19:46:44 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Hesham Soliman (ERA)" Cc: Srinivasan.Damodaran@lntinfotech.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Sub: Identifying link changes References: <4DA6EA82906FD511BE2F00508BCF0538044F0774@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham Soliman (ERA) wrote: > > > Do we know how to secure a BU to a random AR? > > > Is the assumption that we will use RR for this? > > > > > > The spec says the temporary HA should be treated as > > a regular HA. In other words, either you have security > > associations, can establish them on the fly, or you > > don't do this. > > => So is the approach to not mention what mechanisms > should be used (for the 'on-the-fly' case) and leave > it FFS? > Because the preconfigured cases are probably not > likely to exist. So I'm wondering whether we should keep it. I believe the assumption has been that you could use the same mechanisms as for MN-HA security, i.e. IPsec. If manual keying is out of the question, you could use IKE to establish SAs. I'd be interested in seeing the necessary SPD entries to find out if there's anything unexpected. Has someone implemented forwarding-from-previous-coa, with security? Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 13:08:01 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06971 for ; Thu, 20 Jun 2002 13:08:01 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24118; Thu, 20 Jun 2002 10:08:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19836; Thu, 20 Jun 2002 10:07:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KH6Vk7009023 for ; Thu, 20 Jun 2002 10:06:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KH6VrR009022 for mobile-ip-dist; Thu, 20 Jun 2002 10:06:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KH6Rk7009015 for ; Thu, 20 Jun 2002 10:06:27 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17131 for ; Thu, 20 Jun 2002 10:06:33 -0700 (PDT) Received: from rajma.kniveton.com (adsl-209-204-158-88.sonic.net [209.204.158.88]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28592 for ; Thu, 20 Jun 2002 10:06:32 -0700 (PDT) Received: from [192.168.1.42] (atlantis.kniveton.com [192.168.1.42]) by rajma.kniveton.com (8.12.3/8.11.1) with ESMTP id g5KH7EJU058978; Thu, 20 Jun 2002 10:07:14 -0700 (PDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.0.4 Date: Thu, 20 Jun 2002 10:06:29 -0700 Subject: Re: [mobile-ip] Draft Agenda for MIP WG @ IETF54 From: "T.J. Kniveton" To: Masataka Ohta CC: Message-ID: In-Reply-To: <200206200003.JAA00512@necom830.hpcl.titech.ac.jp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >: 5. Security Considerations >: To prevent anonymous and/or unpaid access to the Internet, access >: points of MIS have packet-wise cryptographical authentication >: mechanism to disallow unauthorized access to the Internet. >: To prevent subscribers share a single subscriber ID with single >: payment, the mechanism disallows multiple terminals with a single >: subscriber ID simultaneously use access points. Content-Transfer-Encoding: 7bit What about the same subscriber ID on the same access point? What if I am sitting with 10 of my friends and we all decide to use my subscriber ID? Will that work? > : > : As a side effect, the mechanism, basically, disallows a terminal > : simultaneously use multiple access points. > : > : However, to allow for the smooth handover, a terminal is allowed to > : simultaneously use access points with overlapping service area. > > Masataka Ohta > From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 13:13:41 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07149 for ; Thu, 20 Jun 2002 13:13:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03532; Thu, 20 Jun 2002 10:13:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26537; Thu, 20 Jun 2002 10:13:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KHCek7009112 for ; Thu, 20 Jun 2002 10:12:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KHCeW9009111 for mobile-ip-dist; Thu, 20 Jun 2002 10:12:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KHCbk7009101 for ; Thu, 20 Jun 2002 10:12:37 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26230 for ; Thu, 20 Jun 2002 10:12:42 -0700 (PDT) Received: from chardonnay.levkowetz.com (h224n1fls32o89.telia.com [213.66.61.224]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10597 for ; Thu, 20 Jun 2002 11:12:37 -0600 (MDT) Received: from [127.0.0.1] (helo=chardonnay) by chardonnay.levkowetz.com with smtp (Exim 4.02) id GY0L4V-0001BS-00; Thu, 20 Jun 2002 19:12:31 +0200 From: "Henrik Levkowetz" To: "Behcet Sarikaya" Cc: Subject: RE: [mobile-ip] Feedback on draft-ietf-mobileip-nat-traversal-04.txt Date: Thu, 20 Jun 2002 19:12:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) In-Reply-To: <3D12061A.20300@alcatel.com> Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bechet, Thanks, you are right, this should be clarified. 'it' in the text you quote actually refers to the FA being situated behind a NAT. The last call period is till July 2nd, so there should be no problem incorporating this clarification. Best regards, Henrik On Thursday, 20 June 2002, Behcet Sarikaya wrote: > > > Henrik, > I think there was a last call on this draft from IESG but I could find > the mail so I am writing to the list: > On page 17 you said: > A foreign agent using MIP UDP tunnelling to a home agent because **it** > is situated behind a NAT may be configured to encourage reverse > tunnelling, or be neutral about it, depending on the characteristics > of the NAT. > > the it above, does it refer to HA or FA? > I think it is HA, and not FA. > Therefore my suggestion is to replace the it by HA to make it specific > and clear. > Sorry if this mail came to late to change things. > > Regards, > > > Henrik Levkowetz wrote: > > > --behcet > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 13:15:12 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07199 for ; Thu, 20 Jun 2002 13:15:12 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04504; Thu, 20 Jun 2002 10:15:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20633; Thu, 20 Jun 2002 10:15:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KHEIk7009146 for ; Thu, 20 Jun 2002 10:14:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KHEInK009145 for mobile-ip-dist; Thu, 20 Jun 2002 10:14:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KHEEk7009135 for ; Thu, 20 Jun 2002 10:14:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23091 for ; Thu, 20 Jun 2002 10:14:18 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03829 for ; Thu, 20 Jun 2002 10:14:18 -0700 (PDT) Message-ID: <007b01c2187d$a1c42480$4f6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , , Cc: References: <4DA6EA82906FD511BE2F00508BCF05380498C8B1@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] Sub: Identifying link changes Date: Thu, 20 Jun 2002 10:12:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Do we know how to secure a BU to a random AR? > Is the assumption that we will use RR for this? > > If the answer is no to either question, then this > scenario should not exist. > I think the answer is, in fact, no. In MIP, the AR functions as an "on-link home agent" if it is processing BUs. Thus, I think we need to consider security that is at least as good as that with the home agent. Unlike the CN, the BU will be forwarding traffic to the MN, and thus in the perfect position to act as a man in the middle if security is compromised. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 13:32:49 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07792 for ; Thu, 20 Jun 2002 13:32:48 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17109; Thu, 20 Jun 2002 11:35:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27781; Thu, 20 Jun 2002 10:32:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KHUvk7009347 for ; Thu, 20 Jun 2002 10:30:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KHUvrV009346 for mobile-ip-dist; Thu, 20 Jun 2002 10:30:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KHUrk7009339 for ; Thu, 20 Jun 2002 10:30:53 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28984 for ; Thu, 20 Jun 2002 10:30:57 -0700 (PDT) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07779 for ; Thu, 20 Jun 2002 10:30:57 -0700 (PDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id NAA24286 for ; Thu, 20 Jun 2002 13:30:56 -0400 (EDT) From: "Dr. Subrata Goswami" Cc: Subject: RE: [mobile-ip] Feedback on draft-ietf-mobileip-nat-traversal-04.txt Date: Thu, 20 Jun 2002 10:33:42 -0700 Message-ID: <000e01c21880$9f848d60$6701a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: <3D11F3CB.8050700@kolumbus.fi> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit The following are some questions I have. 3.1) .....This specification also permits the movement without obtaining a new CoA, when a valid CoA cannot be obtained from the new AR (i.e, the mobile node uses the old CoA). What would this happen at all ? What are a few example scenarios in which handover without an nCoA would be usefull? 3.1.2) In Figure 2 should not the PrRtAdv be sent from the oAR after the HACK has been received? Is there a timer associated with HACK in the oAR ? 3.1.6) In Figure 3 should not the PrRtAdv be sent from the oAR after the HACK has been received ? Is there a timer associated with HACK in the oAR ? 3.1.8) ... The typical form of such a positive indication is a F-BU sent from the oAR to the MN; if the MN expects but does not receive the acknowledgement, then it MUST resend the F-BU one more time. Is the oAR sending out F-BU or F-BACK ? 3.1.8) ... If the MN has not yet received a F-BU from the oAR, then the MN SHOULD arrange for oAR to receive an appropriate F-BU associating the MN's oCoA to its nCoA. ???? From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 13:32:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07805 for ; Thu, 20 Jun 2002 13:32:52 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17155; Thu, 20 Jun 2002 11:35:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29809; Thu, 20 Jun 2002 10:33:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KHWEk7009364 for ; Thu, 20 Jun 2002 10:32:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KHW9hv009363 for mobile-ip-dist; Thu, 20 Jun 2002 10:32:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KHW6k7009356 for ; Thu, 20 Jun 2002 10:32:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29430 for ; Thu, 20 Jun 2002 10:32:09 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16402 for ; Thu, 20 Jun 2002 11:34:23 -0600 (MDT) Message-ID: <00e101c21880$252b7240$4f6015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" , "Hesham Soliman \(ERA\)" Cc: , References: <4DA6EA82906FD511BE2F00508BCF0538044F0774@Esealnt861.al.sw.ericsson.se> <3D1206F4.6010902@kolumbus.fi> Subject: Re: [mobile-ip] Sub: Identifying link changes Date: Thu, 20 Jun 2002 10:30:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Hesham Soliman (ERA) wrote: > > > > > Do we know how to secure a BU to a random AR? > > > > Is the assumption that we will use RR for this? > > > > > > > > > The spec says the temporary HA should be treated as > > > a regular HA. In other words, either you have security > > > associations, can establish them on the fly, or you > > > don't do this. > > > > => So is the approach to not mention what mechanisms > > should be used (for the 'on-the-fly' case) and leave > > it FFS? > > Because the preconfigured cases are probably not > > likely to exist. So I'm wondering whether we should keep it. > > > I believe the assumption has been that you could use the > same mechanisms as for MN-HA security, i.e. IPsec. If > manual keying is out of the question, you could use IKE > to establish SAs. I'd be interested in seeing the necessary > SPD entries to find out if there's anything unexpected. > Has someone implemented forwarding-from-previous-coa, with > security? > > Since the AR is, after all, a router, doesn't this have some connection with the SEND BOF? That is, if general Neighbor Discovery is secured in some way that has security properties equivalent to an IPsec security association (perhaps it even is an IPsec SA), then couldn't that be leveraged for "on link HA" security? jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 14:07:17 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08913 for ; Thu, 20 Jun 2002 14:07:17 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28358; Thu, 20 Jun 2002 11:07:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12692; Thu, 20 Jun 2002 11:07:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KI61k7009691 for ; Thu, 20 Jun 2002 11:06:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KI61ku009690 for mobile-ip-dist; Thu, 20 Jun 2002 11:06:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KI5vk7009683 for ; Thu, 20 Jun 2002 11:05:58 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11733 for ; Thu, 20 Jun 2002 11:06:01 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27661 for ; Thu, 20 Jun 2002 11:06:00 -0700 (PDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5KI9Tj09350 for ; Thu, 20 Jun 2002 13:09:30 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Jun 2002 13:05:57 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 20 Jun 2002 13:04:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Draft Agenda for MIP WG @ IETF54 Date: Thu, 20 Jun 2002 13:04:38 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12FBD@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] Draft Agenda for MIP WG @ IETF54 Thread-Index: AcIX8LFvtLbEIkDwQ8+0PGx65flgBQAlDNcA To: Cc: X-OriginalArrivalTime: 20 Jun 2002 18:04:39.0364 (UTC) FILETIME=[F1F0E040:01C21884] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5KI5wk7009684 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Masataka, >Basavaraj; > >> IETF Working group meetings are NOT the place for making >> presentations. WG meetings are focused on discussing issues >> pertinent to the ongoing work and also other relevant topics >> that are within the scope of the charter. However with respect >> to the *relevant topics*, there needs to be a considerable >> amount of interest shown by the WG members in order to have >> an agenda item for discussion. We normally view the discussions >> on the mailing list to determine the level of interest in a >> topic. > >Your misunderstanding is that "discussion" includes to recognize >some existing topics irrlevant. I am not categorizing your proposal as *irrelevant* to this WG. But if you read what I said above "with respect to the *relevant topics*, there needs to be a considerable amount of interest shown by the WG members in order to have an agenda item for discussion" From the current discussion on the mailing list w.r.t this topic, I do not see a strong interest yet. > >> I >> agree that the solution is quite valid for the WLAN environment > >Even if my draft were valid on WLAN environment only, it follows >the current work iten of: > > - Documenting any requirements specific to cellular/wireless networks. > >that there is no requirement of smooth handover by the network. > I think the requirement which you are deriving as "smooth HO is not required" simply because you recommend terminals to have two transceivers is not sufficient. For terminals that do have two transceivers, they may choose not to implement MIP based smooth HO. But that is only one class of terminals and does not cover the entire spectrum. >Moreover, you obvviously ignoreing my draft stating: > >: 4. Applications of the Technique >: >: The technique described in sections 2 and 3 was deployed in recent >: PHS (personal handy phone, 32Kbps mobile telephone system available >: in Japan and other countries) service, only after which, PHS can >: support stable and smooth handover. >: >: In general, the technique requires two sets of transceivers, which >: increases the cost of terminals, which is welcome to wireless LAN >: chip vendors, it also reduce the cost of network by eliminating >: intelligent intermediate entities for half-hearted smooth mobility. >: >: Note that a CDMA based wireless transceiver can simultaneously use >: two access points with different code without additional RF modules. > >that the solution is proven to valid for the PHS environment and is >more easily depolyable for CDMA environment. I am not sure if you have taken into consideration that in CDMA environments the MN is incapable of listening to the paging channel information when in an active call. So even though you are taking into consideration the soft HO capability of CDMA, the model that you describe in your draft would not be applicable in certain conditions (such as when you have to perform a hard HO, i.e to an access point served by a different FA/AR). > >> but fail to understand what the MIP WG would have to do with it. > >Stop attempting to work on smooth handover in any environment. I disagree. Smooth HO is required in certain environments. Your "one-model" (dual transceiver approach) fits all solution is not globally applicable. The point is, Smooth HO (in the MIP WG) is a network layer approach to performing HOs. What you are suggesting in your draft is essentially a lower layer method. HOs are a common aspect of wireless/cellular networks, the difference here is the layer at which the HO is being done. > >> Of course if there is WG interest in the approach proposed by >> you and issues relevant to this WG, we can always add it to the >> agenda. If we see more discussion in terms of impacts/changes >> required to MIP on the MN or FA/AR or HA, with the availability >> of dual WLAN interfaces, that would be a more relevant topic for >> discussion. > >Another relevant protocol topic is in the security section: Its up to you to convince the WG about the relevance of the security method. Access control is more of a AAA WG topic. > >: 5. Security Considerations >: >: To prevent anonymous and/or unpaid access to the Internet, access >: points of MIS have packet-wise cryptographical authentication >: mechanism to disallow unauthorized access to the Internet. >: >: To prevent subscribers share a single subscriber ID with single >: payment, the mechanism disallows multiple terminals with a single >: subscriber ID simultaneously use access points. >: >: As a side effect, the mechanism, basically, disallows a terminal >: simultaneously use multiple access points. >: >: However, to allow for the smooth handover, a terminal is allowed to >: simultaneously use access points with overlapping service area. > > Masataka Ohta -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 14:10:34 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09097 for ; Thu, 20 Jun 2002 14:10:34 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00389; Thu, 20 Jun 2002 11:10:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14756; Thu, 20 Jun 2002 11:10:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KI9Uk7009756 for ; Thu, 20 Jun 2002 11:09:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KI9Ue7009755 for mobile-ip-dist; Thu, 20 Jun 2002 11:09:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KI9Qk7009748 for ; Thu, 20 Jun 2002 11:09:26 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13973 for ; Thu, 20 Jun 2002 11:09:30 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12305 for ; Thu, 20 Jun 2002 12:09:29 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 1989F6A904; Thu, 20 Jun 2002 21:09:23 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6667B6A901; Thu, 20 Jun 2002 21:09:20 +0300 (EEST) Message-ID: <3D121AA5.40400@kolumbus.fi> Date: Thu, 20 Jun 2002 21:10:45 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Hesham Soliman (ERA)" Cc: "'Basavaraj.Patil@nokia.com'" , tj@kniveton.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] confusion about prefix sol/adv References: <4DA6EA82906FD511BE2F00508BCF0538044F0768@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham Soliman (ERA) wrote: > => One attack mentioned by Jari in earlier discussions > was to deprecate a lifetime of a prefix, or swap lifetimes....etc > This is effectively a DoS attack. The difference I see between > this and other DoS attacks is that an attacker can deny any > communication with any CN (by making the MN choose the > wrong address) while not located on the path between > the CN and the MN. Some further notes. An attacker can't force the MN to go all the way in picking a wrong address. The HA would refuse to accept such an address. What they can do, however, is to reduce the number of (valid) addresses on the prefix list, or make the lifetimes smaller. By replacing a valid prefix with an invalid one, you can get the MN give up a valid address and try to get a a bad address accepted -- this will lead to the MN having no valid home addresses to communicate with. However, as TJ pointed out the current spec requires IPsec on all MPS messages, except the first one. On the first one these attacks are still possible, but the attacker would have to pick the right to for the attack, i.e. between the MN coming up and successfully performing the MPA-MPS procedure. Interestingly, section 11.3.4. requires the IPsec SA to provide replay protection, which it generally speaking can't do without automatic key management. (Assuming key management exists, we could perhaps require all ICMPv6 traffic to be secured. That would solve the problem even with the first MPS & MPA. The question is, what is mandatory to implement?) Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 14:20:57 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09381 for ; Thu, 20 Jun 2002 14:20:56 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15868; Thu, 20 Jun 2002 12:23:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19409; Thu, 20 Jun 2002 11:21:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KIJsk7009916 for ; Thu, 20 Jun 2002 11:19:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KIJsQi009915 for mobile-ip-dist; Thu, 20 Jun 2002 11:19:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KIJok7009908 for ; Thu, 20 Jun 2002 11:19:50 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18813 for ; Thu, 20 Jun 2002 11:19:54 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18456 for ; Thu, 20 Jun 2002 12:19:54 -0600 (MDT) 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 LAA26920; Thu, 20 Jun 2002 11:19:53 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5KIJrT01516; Thu, 20 Jun 2002 11:19:53 -0700 X-mProtect: <200206201819> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8AYkUf; Thu, 20 Jun 2002 11:19:50 PDT Message-ID: <3D121CC6.8EA76181@iprg.nokia.com> Date: Thu, 20 Jun 2002 11:19:50 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: "Hesham Soliman (ERA)" , "'Basavaraj.Patil@nokia.com'" , tj@kniveton.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] confusion about prefix sol/adv References: <4DA6EA82906FD511BE2F00508BCF0538044F0768@Esealnt861.al.sw.ericsson.se> <3D121AA5.40400@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Interestingly, section 11.3.4. requires the IPsec SA to > provide replay protection, which it generally speaking can't > do without automatic key management. (Assuming key management > exists, we could perhaps require all ICMPv6 traffic to be > secured. I am not sure if we should do it this way. I agree with Raj. lets go with your cookies approach. and when the MN gets an unsolicited MPA, instead of using the information, sends an MPS. Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 14:39:20 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09923 for ; Thu, 20 Jun 2002 14:39:20 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26772; Thu, 20 Jun 2002 11:39:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25977; Thu, 20 Jun 2002 11:39:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KIcGk7010066 for ; Thu, 20 Jun 2002 11:38:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KIcGPv010065 for mobile-ip-dist; Thu, 20 Jun 2002 11:38:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KIcDk7010058 for ; Thu, 20 Jun 2002 11:38:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25430 for ; Thu, 20 Jun 2002 11:38:17 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03846 for ; Thu, 20 Jun 2002 12:38:13 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id C69C46A904; Thu, 20 Jun 2002 21:38:08 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 551DE6A901; Thu, 20 Jun 2002 21:38:07 +0300 (EEST) Message-ID: <3D122164.90006@kolumbus.fi> Date: Thu, 20 Jun 2002 21:39:32 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: "Hesham Soliman (ERA)" , "'Basavaraj.Patil@nokia.com'" , tj@kniveton.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] confusion about prefix sol/adv References: <4DA6EA82906FD511BE2F00508BCF0538044F0768@Esealnt861.al.sw.ericsson.se> <3D121AA5.40400@kolumbus.fi> <3D121CC6.8EA76181@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > I am not sure if we should do it this way. I agree with Raj. > lets go with your cookies approach. and when the MN gets an > unsolicited MPA, instead of using the information, sends an > MPS. How about the above + note in the spec that you MAY implement automatic key management to secure the whole thing if you want to? Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 14:41:09 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09974 for ; Thu, 20 Jun 2002 14:41:09 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27921; Thu, 20 Jun 2002 11:41:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27049; Thu, 20 Jun 2002 11:41:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KIeGk7010098 for ; Thu, 20 Jun 2002 11:40:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KIeG6A010097 for mobile-ip-dist; Thu, 20 Jun 2002 11:40:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KIeDk7010090 for ; Thu, 20 Jun 2002 11:40:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04083 for ; Thu, 20 Jun 2002 11:40:17 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27221 for ; Thu, 20 Jun 2002 11:40:16 -0700 (PDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g5KIdkh28445; Thu, 20 Jun 2002 13:39:46 -0500 (CDT) Message-ID: <3D12218E.3000807@alcatel.com> Date: Thu, 20 Jun 2002 13:40:14 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Henrik Levkowetz CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Feedback on draft-ietf-mobileip-nat-traversal-04.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Henrik, Oh, really. I think stating that A foreign agent situated behind a NAT is out of scope or is NP-hard problem or an immediate version-up is recommended would be better. Regards, Henrik Levkowetz wrote: >Bechet, > > Thanks, you are right, this should be clarified. > > 'it' in the text you quote actually refers to the FA being >situated behind a NAT. > > The last call period is till July 2nd, so there should be >no problem incorporating this clarification. > > Best regards, > Henrik > >On Thursday, 20 June 2002, Behcet Sarikaya wrote: > >> >>Henrik, >> I think there was a last call on this draft from IESG but I could find >>the mail so I am writing to the list: >>On page 17 you said: >>A foreign agent using MIP UDP tunnelling to a home agent because **it** >> is situated behind a NAT may be configured to encourage reverse >> tunnelling, or be neutral about it, depending on the characteristics >> of the NAT. >> >>the it above, does it refer to HA or FA? >>I think it is HA, and not FA. >>Therefore my suggestion is to replace the it by HA to make it specific >>and clear. >> Sorry if this mail came to late to change things. >> >>Regards, >> >> >>Henrik Levkowetz wrote: >> >> >>--behcet >> From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 14:44:35 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10060 for ; Thu, 20 Jun 2002 14:44:34 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04586; Thu, 20 Jun 2002 12:45:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06082; Thu, 20 Jun 2002 11:44:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KIi3k7010280 for ; Thu, 20 Jun 2002 11:44:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KIi3r0010279 for mobile-ip-dist; Thu, 20 Jun 2002 11:44:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KIi0k7010270 for ; Thu, 20 Jun 2002 11:44:00 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05704 for ; Thu, 20 Jun 2002 11:44:04 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19627 for ; Thu, 20 Jun 2002 11:44:04 -0700 (PDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5KIlXj15645 for ; Thu, 20 Jun 2002 13:47:33 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Jun 2002 13:44:02 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 20 Jun 2002 13:43:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] confusion about prefix sol/adv Date: Thu, 20 Jun 2002 13:43:42 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12FC5@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] confusion about prefix sol/adv Thread-Index: AcIYiaUxt/fQq3lQRyGzoJGPC7Gd1QAAJhwA To: , Cc: , , X-OriginalArrivalTime: 20 Jun 2002 18:43:42.0793 (UTC) FILETIME=[66BBC390:01C2188A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5KIi0k7010273 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit > > Vijay Devarapalli wrote: > > > > I am not sure if we should do it this way. I agree with Raj. > > lets go with your cookies approach. and when the MN gets an > > unsolicited MPA, instead of using the information, sends an > > MPS. > > How about the above + note in the spec that you MAY implement > automatic key management to secure the whole thing if you want > to? Optionally, yes. > > Jari > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 14:53:18 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10296 for ; Thu, 20 Jun 2002 14:53:18 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04423; Thu, 20 Jun 2002 12:56:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10505; Thu, 20 Jun 2002 11:53:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KIqck7010413 for ; Thu, 20 Jun 2002 11:52:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KIqbdh010412 for mobile-ip-dist; Thu, 20 Jun 2002 11:52:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KIqYk7010405 for ; Thu, 20 Jun 2002 11:52:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10060 for ; Thu, 20 Jun 2002 11:52:38 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11928 for ; Thu, 20 Jun 2002 12:52:35 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 277D66A904; Thu, 20 Jun 2002 21:52:34 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7977F6A901; Thu, 20 Jun 2002 21:52:32 +0300 (EEST) Message-ID: <3D1224C4.9030304@kolumbus.fi> Date: Thu, 20 Jun 2002 21:53:56 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf Cc: "Hesham Soliman (ERA)" , Srinivasan.Damodaran@lntinfotech.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Sub: Identifying link changes References: <4DA6EA82906FD511BE2F00508BCF0538044F0774@Esealnt861.al.sw.ericsson.se> <3D1206F4.6010902@kolumbus.fi> <00e101c21880$252b7240$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > Since the AR is, after all, a router, doesn't this have some connection > with the SEND BOF? That is, if general Neighbor Discovery is secured in > some way that has security properties equivalent to an IPsec security > association (perhaps it even is an IPsec SA), then couldn't that be > leveraged for "on link HA" security? Answer #1: No, because while on link we don't need the security and when we do, we are no longer on link. (The on-link previous coa is kind of a special case.) Answer #2: OTOH, some SEND schemes could probably be applied here. Say, if we end up with an IPsec SA based on something, or verify the CGA property of the local router, we could use the same keys later to establish an on-the-fly SA from another location back to this HA. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 15:27:45 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11186 for ; Thu, 20 Jun 2002 15:27:44 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28380; Thu, 20 Jun 2002 13:28:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17545; Thu, 20 Jun 2002 12:28:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KJR5k7010601 for ; Thu, 20 Jun 2002 12:27:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KJR5bH010600 for mobile-ip-dist; Thu, 20 Jun 2002 12:27:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KJR1k7010593 for ; Thu, 20 Jun 2002 12:27:01 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15828 for ; Thu, 20 Jun 2002 12:27:06 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24450 for ; Thu, 20 Jun 2002 13:27:05 -0600 (MDT) 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 MAA00966; Thu, 20 Jun 2002 12:27:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5KJR3O22887; Thu, 20 Jun 2002 12:27:03 -0700 X-mProtect: <200206201927> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQkpd2E; Thu, 20 Jun 2002 12:27:01 PDT Message-ID: <3D122C86.C46EA27A@iprg.nokia.com> Date: Thu, 20 Jun 2002 12:27:02 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: "Hesham Soliman (ERA)" , "'Basavaraj.Patil@nokia.com'" , tj@kniveton.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] confusion about prefix sol/adv References: <4DA6EA82906FD511BE2F00508BCF0538044F0768@Esealnt861.al.sw.ericsson.se> <3D121AA5.40400@kolumbus.fi> <3D121CC6.8EA76181@iprg.nokia.com> <3D122164.90006@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Vijay Devarapalli wrote: > > > I am not sure if we should do it this way. I agree with Raj. > > lets go with your cookies approach. and when the MN gets an > > unsolicited MPA, instead of using the information, sends an > > MPS. > > How about the above + note in the spec that you MAY implement > automatic key management to secure the whole thing if you want > to? it is tough to do this. this also has a side-effect of having to secure all ICMPv6 traffic between the MN and the HA. on top of that you say 'MAY'. so, who is going to implement it? but, go ahead if you feel it is necessary. Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 18:01:28 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13970 for ; Thu, 20 Jun 2002 18:01:28 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06966; Thu, 20 Jun 2002 15:01:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14196; Thu, 20 Jun 2002 15:01:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KM0Ik7010898 for ; Thu, 20 Jun 2002 15:00:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KM0Ito010897 for mobile-ip-dist; Thu, 20 Jun 2002 15:00:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KM0Fk7010890 for ; Thu, 20 Jun 2002 15:00:15 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11550 for ; Thu, 20 Jun 2002 15:00:19 -0700 (PDT) Received: from mail2.hd.intel.com (hdfdns02.hd.intel.com [192.52.58.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06286 for ; Thu, 20 Jun 2002 15:00:18 -0700 (PDT) Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by mail2.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g5KM0H710443 for ; Thu, 20 Jun 2002 22:00:18 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002062015001730561 ; Thu, 20 Jun 2002 15:00:17 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Jun 2002 15:00:16 -0700 Message-ID: From: "Adrangi, Farid" To: "'Tessier, Serge'" , mobile-ip@sunroof.eng.sun.com Cc: "Adrangi, Farid" , Alpesh , "Iyer, Prakash" , Joe Lau , Kent Leung , Milind Kulkarn , Qiang Zhang Subject: RE: [mobile-ip] [mobile-IP]: Comments on draft-ietf-mobileip-vpn- problem-statemen t-00 Date: Thu, 20 Jun 2002 15:00:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Serge, Thanks for your reply. I removed the parts that we are in agreement. And please see my comments marked by "Farid Writes>" Best regards, Farid > > > e. Page 5: (..) > Farid Writes > In my mind, the draft should not suggest any > tunneling order > - > this falls into the solution space. Agree/Disagre? Serge Writes> Of course I agree but then why do you want to state again (I quote the text you proposed in your reply) "This also implies that the MIPv4 traffic destined to the home network has to run inside an IPsec tunnel (..)" ? Farid Writes> Consider an MN that wants to connect to its home network protected by the VPN gateway. The first thing that MN needs to do is to establish an IPsec tunnel to the VPN gateway. Agree/Disagree? If yes, in order for the MN to register with its home agent inside the VPN domain, the MN is forced to send the MIP packet inside the IPsec tunnel -- because, the MN's home agent will not directly be reachable from the outside. Agree/Disagree? If you disagree, please explain us how a node outside the VPN domain can communicate with a node in the home network protected by the VPN gateway, without sending the traffic inside the IPsec tunnel established between the MN and the VPN gateway. Also, maybe the proposed text should be modified to : "This also implies that the MIPv4 traffic destined to the home network is FORCED to run inside an IPsec tunnel (..)". We should solicit other people's opinion on this too. Maybe,I am missing your point here -- if so, my apologies. BTW, I removed your remark on page 7. Figure 6.1b because it refers to the same problem. From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 18:32:11 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14436 for ; Thu, 20 Jun 2002 18:32:11 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24568; Thu, 20 Jun 2002 16:32:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24254; Thu, 20 Jun 2002 15:32:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KMVQk7011113 for ; Thu, 20 Jun 2002 15:31:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KMVPoM011112 for mobile-ip-dist; Thu, 20 Jun 2002 15:31:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KMVMk7011105 for ; Thu, 20 Jun 2002 15:31:22 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25271 for ; Thu, 20 Jun 2002 15:31:27 -0700 (PDT) Received: from chardonnay.levkowetz.com (h224n1fls32o89.telia.com [213.66.61.224]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00902 for ; Thu, 20 Jun 2002 15:31:25 -0700 (PDT) Received: from [127.0.0.1] (helo=chardonnay) by chardonnay.levkowetz.com with smtp (Exim 4.02) id GY0ZWA-000118-00; Fri, 21 Jun 2002 00:31:22 +0200 From: "Henrik Levkowetz" To: "Behcet Sarikaya" Cc: Subject: RE: [mobile-ip] Feedback on draft-ietf-mobileip-nat-traversal-04.txt Date: Fri, 21 Jun 2002 00:31:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) In-Reply-To: <3D12218E.3000807@alcatel.com> Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Bechet, The draft deals with both MN behind NAT and FA behind NAT. Regarding FAs, this is from section 4.5: "The UDP Tunnel Request Extension MAY be used by a foreign agent when it is forwarding a Mobile IP Registration Request to a home agent, when the foreign agent is situated behind a NAT or has some other compelling reason to require MIP UDP tunnelling. What I propose to do to clarify the text you originally commented on is to replace 'it' with 'the FA'. Maybe I don't quite understand your most recent question below? Henrik On Thursday, 20 June 2002, Behcet Sarikaya wrote: > > > Henrik, > Oh, really. I think stating that > A foreign agent > situated behind a NAT > is out of scope > or > is NP-hard problem > or > an immediate version-up is recommended > > would be better. > > Regards, > > > Henrik Levkowetz wrote: > > >Bechet, > > > > Thanks, you are right, this should be clarified. > > > > 'it' in the text you quote actually refers to the FA being > >situated behind a NAT. > > > > The last call period is till July 2nd, so there should be > >no problem incorporating this clarification. > > > > Best regards, > > Henrik > > > >On Thursday, 20 June 2002, Behcet Sarikaya wrote: > > > >> > >>Henrik, > >> I think there was a last call on this draft from IESG but I could find > >>the mail so I am writing to the list: > >>On page 17 you said: > >>A foreign agent using MIP UDP tunnelling to a home agent because **it** > >> is situated behind a NAT may be configured to encourage reverse > >> tunnelling, or be neutral about it, depending on the characteristics > >> of the NAT. > >> > >>the it above, does it refer to HA or FA? > >>I think it is HA, and not FA. > >>Therefore my suggestion is to replace the it by HA to make it specific > >>and clear. > >> Sorry if this mail came to late to change things. > >> > >>Regards, > >> > >> > >>Henrik Levkowetz wrote: > >> > > >> > >>--behcet > >> > From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 18:38:09 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14549 for ; Thu, 20 Jun 2002 18:38:09 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08764; Thu, 20 Jun 2002 16:38:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16821; Thu, 20 Jun 2002 15:38:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KMbck7011208 for ; Thu, 20 Jun 2002 15:37:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KMbbWf011205 for mobile-ip-dist; Thu, 20 Jun 2002 15:37:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KMbYk7011197 for ; Thu, 20 Jun 2002 15:37:34 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25974 for ; Thu, 20 Jun 2002 15:37:39 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03727 for ; Thu, 20 Jun 2002 15:37:39 -0700 (PDT) Message-ID: <01a401c218aa$07d34b30$8b6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Jari Arkko" , "James Kempf" Cc: "Hesham Soliman \(ERA\)" , , References: <4DA6EA82906FD511BE2F00508BCF0538044F0774@Esealnt861.al.sw.ericsson.se> <3D1206F4.6010902@kolumbus.fi> <00e101c21880$252b7240$4f6015ac@T23KEMPF> <3D1224C4.9030304@kolumbus.fi> Subject: Re: [mobile-ip] Sub: Identifying link changes Date: Thu, 20 Jun 2002 15:30:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > James Kempf wrote: > > > > Since the AR is, after all, a router, doesn't this have some connection > > with the SEND BOF? That is, if general Neighbor Discovery is secured in > > some way that has security properties equivalent to an IPsec security > > association (perhaps it even is an IPsec SA), then couldn't that be > > leveraged for "on link HA" security? > > > Answer #1: No, because while on link we don't need the security and when > we do, we are no longer on link. (The on-link previous coa is kind of a > special case.) > > Answer #2: OTOH, some SEND schemes could probably be applied here. Say, > if we end up with an IPsec SA based on something, or verify the CGA > property of the local router, we could use the same keys later to establish > an on-the-fly SA from another location back to this HA. This is clearly different discussion than the original e-mail that started the thread. Nevertheless... I agree that an access router that performs forwarding from previous care-of address should be treated just like a Home Agent. (actually, now it is a home agent when we start using the old CoA as MN's home address). Therefore IPsec should be used for securing BUs. And this requires a security association between the MN and this particular AR. If the MN had this pre-configured (just like we assume for the root Home Agent), then there is no problem. If MN doesn't have this SA pre-configured, or it cannot dynamically create one, then it cannot use forwarding from previous care-of address with that particular AR. Simple... And as for creating this SA dynamically, one can rely on bootstraping using link-layer authentication (not favorable), or network layer authentication (e.g., PANA), or some infrastructureless method. This part of the problem is equivalent to what SEND has to do for building a SA to secure neighbor discovery between MN(host) and AR (router). I think this SA must be built while MN is still connected to the AR, not after it disconnected. my 0.02 cents. alper From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 18:47:51 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14690 for ; Thu, 20 Jun 2002 18:47:51 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08543; Thu, 20 Jun 2002 15:47:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01200; Thu, 20 Jun 2002 15:47:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KMkkk7011326 for ; Thu, 20 Jun 2002 15:46:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5KMkkOm011325 for mobile-ip-dist; Thu, 20 Jun 2002 15:46:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5KMkhk7011318 for ; Thu, 20 Jun 2002 15:46:43 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29180 for ; Thu, 20 Jun 2002 15:46:48 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07841 for ; Thu, 20 Jun 2002 15:46:47 -0700 (PDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g5KMkGP10853; Thu, 20 Jun 2002 17:46:16 -0500 (CDT) Message-ID: <3D125B53.4020209@alcatel.com> Date: Thu, 20 Jun 2002 17:46:43 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Henrik Levkowetz CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Feedback on draft-ietf-mobileip-nat-traversal-04.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Henrik, As far as I know there has been no interoperability tests on this part of the draft. If there is enough evidence that it can be made work, then let's keep it. Regards, Henrik Levkowetz wrote: >Bechet, > > The draft deals with both MN behind NAT and FA behind >NAT. Regarding FAs, this is from section 4.5: > > "The UDP Tunnel Request Extension MAY be used by a foreign agent when > it is forwarding a Mobile IP Registration Request to a home agent, > when the foreign agent is situated behind a NAT or has some other > compelling reason to require MIP UDP tunnelling. > >What I propose to do to clarify the text you originally commented on is >to replace 'it' with 'the FA'. > >Maybe I don't quite understand your most recent question below? > > Henrik > >On Thursday, 20 June 2002, Behcet Sarikaya wrote: > >> >>Henrik, >> Oh, really. I think stating that >>A foreign agent >> situated behind a NAT >>is out of scope >>or >>is NP-hard problem >>or >>an immediate version-up is recommended >> >>would be better. >> >>Regards, >> >> >>Henrik Levkowetz wrote: >> >>>Bechet, >>> >>> Thanks, you are right, this should be clarified. >>> >>> 'it' in the text you quote actually refers to the FA being >>>situated behind a NAT. >>> >>> The last call period is till July 2nd, so there should be >>>no problem incorporating this clarification. >>> >>> Best regards, >>> Henrik >>> >>>On Thursday, 20 June 2002, Behcet Sarikaya wrote: >>> >>>>Henrik, >>>> I think there was a last call on this draft from IESG but I could find >>>>the mail so I am writing to the list: >>>>On page 17 you said: >>>>A foreign agent using MIP UDP tunnelling to a home agent because **it** >>>> is situated behind a NAT may be configured to encourage reverse >>>> tunnelling, or be neutral about it, depending on the characteristics >>>> of the NAT. >>>> >>>>the it above, does it refer to HA or FA? >>>>I think it is HA, and not FA. >>>>Therefore my suggestion is to replace the it by HA to make it specific >>>>and clear. >>>> Sorry if this mail came to late to change things. >>>> >>>>Regards, >>>> >>>> >>>>Henrik Levkowetz wrote: >>>> >>>>--behcet >>>> From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 21:04:42 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17212 for ; Thu, 20 Jun 2002 21:04:38 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06790; Thu, 20 Jun 2002 18:04:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA15242; Thu, 20 Jun 2002 18:04:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L13Yk7011884 for ; Thu, 20 Jun 2002 18:03:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L13XXL011883 for mobile-ip-dist; Thu, 20 Jun 2002 18:03:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L13Uk7011876 for ; Thu, 20 Jun 2002 18:03:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA09435 for ; Thu, 20 Jun 2002 18:03:35 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10715 for ; Thu, 20 Jun 2002 18:03:34 -0700 (PDT) From: Masataka Ohta Message-Id: <200206210046.JAA03474@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA03474; Fri, 21 Jun 2002 09:46:10 +0900 Subject: [mobile-ip] Interference? with Smooth Handover? In-Reply-To: <3D11E69C.60602@alcatel.com> from Behcet Sarikaya at "Jun 20, 2002 09:28:44 am" To: Behcet Sarikaya Date: Fri, 21 Jun 2002 09:46:09 +0859 () CC: mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Behcet > Thanks for the info. I am glad to hear that MIPv4 is being deployed. I'm glad too to deploy it on the commercial Internet. > Two transceivers (which emulate cellular networks' use of multiple > physical channels) on each MN might cause interference, more so if so > many are placed in the same cell. Do you agree with this? I'm not sure what is your issue. Just as two (or more) hosts on a single 10base 5 cable interfere each other, when they simultaneously transmit, two (or more ) MNs on a single WLAN with a certain frequence/code interfere. CSMA/CD and CSMA/CA are the technology to suppress the simultaneous transmittion, even if the number of hosts is large. So, the number of MNs in a same cell is irrelevent, though expected share of bandwidth to each host is, of course, reduced accordingly. In addition, WLAN has a mechanism of ACK and retransmission, to reduce the effect of interference from other hosts using other frequency bands, for which CSMA/CA may not work so efficiently. OK? Then, with the proposed smooth handover solution with WLAN, two transceivers are considered to be, at the link layer, two hosts using different frequency bands to be taken care of by the existing mechanisms of WLAN. On PHS, two transceivers use different physical channels. It's a difference between best effort WLAN and QoS assured PHS. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 20 21:42:38 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17711 for ; Thu, 20 Jun 2002 21:42:38 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20167; Thu, 20 Jun 2002 18:42:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18701; Thu, 20 Jun 2002 18:42:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L1fYk7012077 for ; Thu, 20 Jun 2002 18:41:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L1fYEi012076 for mobile-ip-dist; Thu, 20 Jun 2002 18:41:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L1fVk7012069 for ; Thu, 20 Jun 2002 18:41:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA22111 for ; Thu, 20 Jun 2002 18:41:35 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA09475 for ; Thu, 20 Jun 2002 19:41:32 -0600 (MDT) From: Masataka Ohta Message-Id: <200206210126.KAA03599@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA03599; Fri, 21 Jun 2002 10:26:30 +0900 Subject: Re: [mobile-ip] Draft Agenda for MIP WG @ IETF54 In-Reply-To: <697DAA22C5004B4596E033803A7CEF44A12FBD@daebe007.NOE.Nokia.com> from "(env:" "Basavaraj.Patil@nokia.com)" at "Jun 20, 2002 01:04:38 pm" To: Basavaraj.Patil@nokia.com Date: Fri, 21 Jun 2002 10:26:30 +0859 () CC: mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Basavaraj; > I am not categorizing your proposal as *irrelevant* to this WG. But if > you read what I said above > "with respect to the *relevant topics*, there needs to be a > considerable amount of interest shown by the WG members in order to > have an agenda item for discussion" I or you can see no difficulty that the topic of smooth handover already get considerable amount of interest shown by the WG members. For the topic of smooth handover, I have a proposal for presentation. > >> IETF Working group meetings are NOT the place for making > >> presentations. Presentation (and counter presentation) is essential to initiate (or terminate) a pointed discussion. You may remember that, Steve Deering made a presentation in last SEAMOBY meeting, to deny the WG. > >that there is no requirement of smooth handover by the network. > > > > I think the requirement which you are deriving as "smooth HO is not > required" simply because you recommend terminals to have two > transceivers is not sufficient. I never said "smooth HO is not required". My point is that, if smooth HO is required, it is offerred by end systems by themselves. Smooth HO by the network is not required. > I think the requirement which you are deriving as "smooth HO is not > required" simply because you recommend terminals to have two > transceivers is not sufficient. For terminals that do have two > transceivers, they may choose not to implement MIP based smooth > HO. But that is only one class of terminals and does not cover the > entire spectrum. That is not an issue of terminals but networks. As a commecial operater of mobile IP, MIS do not want to complicate its network with intermediate intelligent entities for not-so-smooth handover and let end systems solve the issue, which is the end to end principle. That's a feedback from the real world. If there are other operators of mobile IP, I'm interested in their opinion. That MIP based smooth HO may be used by someone is not a valid argument to develop useful protocols. > >that the solution is proven to valid for the PHS environment and is > >more easily depolyable for CDMA environment. > > I am not sure if you have taken into consideration that in CDMA > environments the MN is incapable of listening to the paging channel > information when in an active call. You are assuming a network, a terminal of which, when in an active call, can not receive packets unrelated to the call. That is an extremely poor network to connect terminals with various processes are working. I, for example, want to have an active voice call with someone and, simultaneously, have text-based chat with someone else. > consideration the soft HO capability of CDMA, the model that you > describe in your draft would not be applicable in certain conditions > (such as when you have to perform a hard HO, i.e to an access point > served by a different FA/AR). Even in such poor networks, my proposal works with two transceivers (and attenna, if you so wish). > I disagree. Smooth HO is required in certain environments. Your > "one-model" (dual transceiver approach) fits all solution is not > globally applicable. You have failed to show it. > The point is, Smooth HO (in the MIP WG) is a network layer approach to > performing HOs. Mine is a network layer approach. It relies on network layer mobile registration. It even works for transition between wired ethernet and WLAN that it can not be a lower layer method. > >Another relevant protocol topic is in the security section: > > Its up to you to convince the WG about the relevance of the security > method. Access control is more of a AAA WG topic. Interaction between smooth HO and the access control do have the relevance to MIP WG. > >: To prevent anonymous and/or unpaid access to the Internet, access > >: points of MIS have packet-wise cryptographical authentication > >: mechanism to disallow unauthorized access to the Internet. > >: > >: To prevent subscribers share a single subscriber ID with single > >: payment, the mechanism disallows multiple terminals with a single > >: subscriber ID simultaneously use access points. > >: > >: As a side effect, the mechanism, basically, disallows a terminal > >: simultaneously use multiple access points. > >: > >: However, to allow for the smooth handover, a terminal is allowed to > >: simultaneously use access points with overlapping service area. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 21 04:15:09 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04229 for ; Fri, 21 Jun 2002 04:15:08 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00869; Fri, 21 Jun 2002 02:15:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA16414; Fri, 21 Jun 2002 01:15:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L8Dhk7013389 for ; Fri, 21 Jun 2002 01:13:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5L8DhsA013388 for mobile-ip-dist; Fri, 21 Jun 2002 01:13:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5L8Ddk7013381 for ; Fri, 21 Jun 2002 01:13:39 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA00498 for ; Fri, 21 Jun 2002 01:13:40 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA28697 for ; Fri, 21 Jun 2002 02:13:40 -0600 (MDT) From: Masataka Ohta Message-Id: <200206210801.RAA05443@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA05443; Fri, 21 Jun 2002 17:01:40 +0900 Subject: Re: [mobile-ip] Draft Agenda for MIP WG @ IETF54 In-Reply-To: from "T.J. Kniveton" at "Jun 20, 2002 10:06:29 am" To: "T.J. Kniveton" Date: Fri, 21 Jun 2002 17:01:39 +0859 () CC: mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: T.J. Kniveton; > > : 5. Security Considerations > > : > > : To prevent anonymous and/or unpaid access to the Internet, access > > : points of MIS have packet-wise cryptographical authentication > > : mechanism to disallow unauthorized access to the Internet. > > : > > : To prevent subscribers share a single subscriber ID with single > > : payment, the mechanism disallows multiple terminals with a single > > : subscriber ID simultaneously use access points. > > What about the same subscriber ID on the same access point? What if I am > sitting with 10 of my friends and we all decide to use my subscriber ID? > Will that work? On our access points, it's configurable. As I asked our operation staff, they say they are fobidding it. However, for a mobile operator, there is no point to forbid co-moving hosts access the Internet with just a single account. As the hosts must have unique home addresses, we can charge for home agent service. If we forbid or charge a lot, it will promote NAT. Or, it is also possible that a mobile host acts as a FA to other co-moving hosts, if a user runs his own HA. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 21 11:59:19 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18866 for ; Fri, 21 Jun 2002 11:59:19 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10061; Fri, 21 Jun 2002 09:59:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11074; Fri, 21 Jun 2002 08:59:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LFwTk7014623 for ; Fri, 21 Jun 2002 08:58:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LFwT72014622 for mobile-ip-dist; Fri, 21 Jun 2002 08:58:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LFwQk7014615 for ; Fri, 21 Jun 2002 08:58:26 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16177 for ; Fri, 21 Jun 2002 08:58:32 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22200 for ; Fri, 21 Jun 2002 08:58:31 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5LFwim14418; Fri, 21 Jun 2002 10:58:44 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Jun 2002 10:58:30 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF264@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip'" Cc: "'Luca Salgarelli'" , "Pierre Boulos" Subject: [mobile-ip] New Draft: draft-muhanna-mobileip-compat-00.txt Date: Fri, 21 Jun 2002 10:58:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2193C.7BFC2710" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C2193C.7BFC2710 Content-Type: text/plain; charset="iso-8859-1" Hello all, In response to the need of a dynamic mechanism as part of Mobile IPv4 registration to synchronize the version of the standards used by all Mobile IPv4 entities, I have submitted a new draft to the Mobile IP WG with the following abstract: Abstract Mobile-IP, together with several other supporting standards such as Reverse Tunneling and the Challenge-Response extensions, have all been recently revised. Although such revisions are for the most part backward compatible with the original versions, sometimes static configuration of Mobile Nodes and Mobility Agents is required to ensure smooth transition and avoid any possible conflict between different standard versions implemented by already-deployed equipment. In this draft we define compatibility extensions for Mobile-IP Agent Advertisement, Registration Request and Registration Reply messages that allow all Mobile-IPv4 entities to dynamically synchronize their "compatibility versions", defined as the versions of the Mobile-IP standards that a particular node is able to support. This solution offers a dynamic mechanism which informs all entities involved in a Mobile-IP exchange of the version of the standard they support, therefore reducing the need to statically configure such information at Mobile Nodes or Mobility Agents. Until it shows up in the drafts directory, it is on the co-author Luca Salgarelli web page. To get to it, please use the following link: http://www.bell-labs.com/user/salga/doc/draft-muhanna-mobileip-compat-00.txt Regards; Ahmad Muhanna ------_=_NextPart_001_01C2193C.7BFC2710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New Draft: draft-muhanna-mobileip-compat-00.txt

Hello all,

In response to the need of a dynamic mechanism as = part of Mobile IPv4
registration to synchronize the version of the = standards used by all
Mobile IPv4 entities, I have submitted a new draft = to the Mobile IP
WG with the following abstract:

Abstract

   Mobile-IP, together with several other = supporting standards such
   as Reverse Tunneling and the = Challenge-Response extensions, have
   all been recently revised.  = Although such revisions are for the
   most part backward compatible with the = original versions,
   sometimes static configuration of = Mobile Nodes and Mobility Agents
   is required to ensure smooth transition = and avoid any possible
   conflict between different standard = versions implemented by
   already-deployed equipment.  In = this draft we define compatibility
   extensions for Mobile-IP Agent = Advertisement, Registration Request
   and Registration Reply messages that = allow all Mobile-IPv4
   entities to dynamically synchronize = their "compatibility
   versions", defined as the versions = of the Mobile-IP standards that
   a particular node is able to = support.  This solution offers a
   dynamic mechanism which informs all = entities involved in a
   Mobile-IP exchange of the version of = the standard they support,
   therefore reducing the need to = statically configure such
   information at Mobile Nodes or Mobility = Agents.


Until it shows up in the drafts directory, it is on = the co-author Luca Salgarelli web
page. To get to it, please use the following = link:

http://www.bell-labs.com/user/salga/doc/draft-muhanna-= mobileip-compat-00.txt


Regards;
Ahmad Muhanna

------_=_NextPart_001_01C2193C.7BFC2710-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 21 12:17:31 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20343 for ; Fri, 21 Jun 2002 12:17:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04663; Fri, 21 Jun 2002 10:18:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17367; Fri, 21 Jun 2002 09:17:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LGGOk7014761 for ; Fri, 21 Jun 2002 09:16:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LGGO53014760 for mobile-ip-dist; Fri, 21 Jun 2002 09:16:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LGGLk7014753 for ; Fri, 21 Jun 2002 09:16:21 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16873 for ; Fri, 21 Jun 2002 09:16:27 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02700 for ; Fri, 21 Jun 2002 09:16:24 -0700 (PDT) Message-ID: <005901c2193e$b68ee500$4f6015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" Cc: "Hesham Soliman \(ERA\)" , , References: <4DA6EA82906FD511BE2F00508BCF0538044F0774@Esealnt861.al.sw.ericsson.se> <3D1206F4.6010902@kolumbus.fi> <00e101c21880$252b7240$4f6015ac@T23KEMPF> <3D1224C4.9030304@kolumbus.fi> Subject: Re: [mobile-ip] Sub: Identifying link changes Date: Fri, 21 Jun 2002 09:14:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Answer #1: No, because while on link we don't need the security and when > we do, we are no longer on link. (The on-link previous coa is kind of a > special case.) > I guess I don't understand this response. Suppose, for the sake of argument (but yet to be established if it is technicallly realistic) an IPsec SA is set up to secure ND. My understanding is that the SA is bidirectional, and identifies the hosts involved by their IP address and, optionally, port number if a particular protocol is being protocted (this wouldn't apply to ICMP however). Since the host will maintain the old CoA when it moves to the new link (that is, after all, the problem that forwarding from previous care of address is trying to solve), then wouldn't this be sufficient to maintain the security association? > Answer #2: OTOH, some SEND schemes could probably be applied here. Say, > if we end up with an IPsec SA based on something, or verify the CGA > property of the local router, we could use the same keys later to establish > an on-the-fly SA from another location back to this HA. > Setting up a new SA sounds pretty time consuming. Some people want to use forwarding from previous care of address for fast handover, and I believe there are currently commercial products which use forwarding from previous foreign agent for that purpose in MIPv4. Presumably, there would be some interest to continue doing so for MIPv6. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 21 12:56:42 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22047 for ; Fri, 21 Jun 2002 12:56:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27985; Fri, 21 Jun 2002 10:57:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10431; Fri, 21 Jun 2002 09:57:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LGu6k7015093 for ; Fri, 21 Jun 2002 09:56:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LGu6Vu015092 for mobile-ip-dist; Fri, 21 Jun 2002 09:56:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LGu2k7015083 for ; Fri, 21 Jun 2002 09:56:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19556 for ; Fri, 21 Jun 2002 09:56:08 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10784 for ; Fri, 21 Jun 2002 10:57:43 -0600 (MDT) Message-ID: <00e501c21944$324ca6f0$4f6015ac@T23KEMPF> From: "James Kempf" To: "Masataka Ohta" , Cc: References: <200206210126.KAA03599@necom830.hpcl.titech.ac.jp> Subject: Re: [mobile-ip] Draft Agenda for MIP WG @ IETF54 Date: Fri, 21 Jun 2002 09:53:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > If there are other operators of mobile IP, I'm interested in their > opinion. Welll, Docomo is certainly interested in the ongoing work to standardize fast and smooth handover for Mobile IP that is being pursued in the MIP WG. Depending on particular Layer 2 solutions for particular link layers such as WLAN, like using dual channels, is not acceptable. Currently, as far as I know, there is only one 802.11 card that supports dual channel handover and that is only available in Japan. I can't see that as being an acceptable solution for an Internet (== worldwide) standard. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 21 14:46:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26666 for ; Fri, 21 Jun 2002 14:46:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12868; Fri, 21 Jun 2002 12:49:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28552; Fri, 21 Jun 2002 11:46:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LIjpk7015507 for ; Fri, 21 Jun 2002 11:45:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LIjov6015506 for mobile-ip-dist; Fri, 21 Jun 2002 11:45:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LIjlk7015499 for ; Fri, 21 Jun 2002 11:45:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04275 for ; Fri, 21 Jun 2002 11:45:52 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11996 for ; Fri, 21 Jun 2002 12:48:10 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g5LIjkp09820; Fri, 21 Jun 2002 13:45:46 -0500 (CDT) Message-ID: <3D137476.8090908@alcatel.com> Date: Fri, 21 Jun 2002 13:46:14 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Ahmad Muhanna CC: "'mobile-ip'" Subject: Re: [mobile-ip] New Draft: draft-muhanna-mobileip-compat-00.txt References: <6B49EDFE974BD51197D70002A56079D803ECF264@zrc2c013.us.nortel.com> Content-Type: multipart/alternative; boundary="------------090907050004050501000703" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------090907050004050501000703 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ahmad, I have not read your draft but from the abstract this sounds like something that can be done with MIB, although it would probably be static. Have you formulated the change as a modified MIB? Then SNMP would solve your problem. If you are proposing further changes to MIPv4 then this might take us into a backward compatibility loop. Regards, Ahmad Muhanna wrote: > Hello all, > > In response to the need of a dynamic mechanism as part of Mobile IPv4 > registration to synchronize the version of the standards used by all > Mobile IPv4 entities, I have submitted a new draft to the Mobile IP > WG with the following abstract: > > Abstract > > Mobile-IP, together with several other supporting standards such > as Reverse Tunneling and the Challenge-Response extensions, have > all been recently revised. Although such revisions are for the > most part backward compatible with the original versions, > sometimes static configuration of Mobile Nodes and Mobility Agents > is required to ensure smooth transition and avoid any possible > conflict between different standard versions implemented by > already-deployed equipment. In this draft we define compatibility > extensions for Mobile-IP Agent Advertisement, Registration Request > and Registration Reply messages that allow all Mobile-IPv4 > entities to dynamically synchronize their "compatibility > versions", defined as the versions of the Mobile-IP standards that > a particular node is able to support. This solution offers a > dynamic mechanism which informs all entities involved in a > Mobile-IP exchange of the version of the standard they support, > therefore reducing the need to statically configure such > information at Mobile Nodes or Mobility Agents. > > > Until it shows up in the drafts directory, it is on the co-author Luca > Salgarelli web > page. To get to it, please use the following link: > > http://www.bell-labs.com/user/salga/doc/draft-muhanna-mobileip-compat-00.txt > > > > Regards; > Ahmad Muhanna > -- Behcet --------------090907050004050501000703 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ahmad,
  I have not read your draft but from the abstract this sounds like something that can be done with MIB, although it would probably be static. Have you formulated the change as a modified MIB? Then SNMP would solve your problem.
  If you are proposing further changes to MIPv4 then this might take us into a backward compatibility loop.
Regards,

Ahmad Muhanna wrote:
New Draft: draft-muhanna-mobileip-compat-00.txt

Hello all,

In response to the need of a dynamic mechanism as part of Mobile IPv4
registration to synchronize the version of the standards used by all
Mobile IPv4 entities, I have submitted a new draft to the Mobile IP
WG with the following abstract:

Abstract

   Mobile-IP, together with several other supporting standards such
   as Reverse Tunneling and the Challenge-Response extensions, have
   all been recently revised.  Although such revisions are for the
   most part backward compatible with the original versions,
   sometimes static configuration of Mobile Nodes and Mobility Agents
   is required to ensure smooth transition and avoid any possible
   conflict between different standard versions implemented by
   already-deployed equipment.  In this draft we define compatibility
   extensions for Mobile-IP Agent Advertisement, Registration Request
   and Registration Reply messages that allow all Mobile-IPv4
   entities to dynamically synchronize their "compatibility
   versions", defined as the versions of the Mobile-IP standards that
   a particular node is able to support.  This solution offers a
   dynamic mechanism which informs all entities involved in a
   Mobile-IP exchange of the version of the standard they support,
   therefore reducing the need to statically configure such
   information at Mobile Nodes or Mobility Agents.


Until it shows up in the drafts directory, it is on the co-author Luca Salgarelli web
page. To get to it, please use the following link:

http://www.bell-labs.com/user/salga/doc/draft-muhanna-mobileip-compat-00.txt


Regards;
Ahmad Muhanna


-- 
Behcet

--------------090907050004050501000703-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 21 14:48:52 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26796 for ; Fri, 21 Jun 2002 14:48:52 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29414; Fri, 21 Jun 2002 12:49:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05465; Fri, 21 Jun 2002 11:49:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LImMk7015581 for ; Fri, 21 Jun 2002 11:48:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5LImM81015580 for mobile-ip-dist; Fri, 21 Jun 2002 11:48:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5LImIk7015570 for ; Fri, 21 Jun 2002 11:48:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19550 for ; Fri, 21 Jun 2002 11:48:24 -0700 (PDT) Received: from dumburken.it.kth.se (dumburken.it.kth.se [130.237.212.157]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13590 for ; Fri, 21 Jun 2002 12:50:41 -0600 (MDT) Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id UAA10555; Fri, 21 Jun 2002 20:48:18 +0200 (MET DST) Date: Fri, 21 Jun 2002 20:48:18 +0200 (MET DST) Message-Id: <200206211848.UAA10555@dumburken.it.kth.se> X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f From: Gerald Maguire To: mohta@necom830.hpcl.titech.ac.jp CC: behcet.sarikaya@alcatel.com, mobile-ip@sunroof.eng.sun.com In-reply-to: <200206210046.JAA03474@necom830.hpcl.titech.ac.jp> (message from Masataka Ohta on Fri, 21 Jun 2002 09:46:09 +0859 ()) Subject: Re: [mobile-ip] Interference? with Smooth Handover? References: <200206210046.JAA03474@necom830.hpcl.titech.ac.jp> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Masataka Ohta said: ... Then, with the proposed smooth handover solution with WLAN, two transceivers are considered to be, at the link layer, two hosts using different frequency bands to be taken care of by the existing mechanisms of WLAN. On PHS, two transceivers use different physical channels. It's a difference between best effort WLAN and QoS assured PHS. There are really several cases: 1. a mobile equipped with two WLAN interfaces which are using different "channels" (this could be different spreading codes, different frequencies, hoping sequences etc.) In this case they are two independent interfaces with very little interference with each other. With different spreading codes, but in the same frequency band - the transmission by one will probably wipe out the reception by the other - because unless you have a very wide dynamic range receiver the AGC will be saturated by the tranmission by the near by transmitter. When in different frequency bands, there will be some interference because the tail of the one band may leak power into the adjacent channel. When using different hopping sequences they will occasionally hop to the same frequency and thus interfere with each other. When one is hopping and the other using direct sequence spread spectrum (DSSS), the hopper will interfere when it hops into the the DSSS interface's channel and the DSSS can interfere with many of the channels the hopper can hop to. Note in the case of 801.11 if you have several DSSS systems operating so that you are operating in all the 2.4 GHz channels, then the hopper will always be interfering with one of them. 2. a mobile equipped with two WLAN interfaces which are using the same "channels", but associated with different access points. They will compete for the channel as usual -- since there is only one channel. 3. there is a chance that both interfaces could be searching for a new AP at the same time and both pick the same new "channel" and AP -- in which case they can interfere as per item 2 above. So you need some way to prevent them from both going to the same channel. An interesting device is a two way WLAN interface + a receive only WLAN interface - the later can be used to identify new potential APs while you continue to use the two way interface for communication. Authentication, Registration, ... could be done with a new AP via the existing AP and the other WLAN interface - through the fixed network. However, it is clear that because of the effects of 1, 2, and 3 you would want to have the drivers for two WLAN interfaces communicating with each other - rather than having them completely independent. Consider the case where you have already given a number of packets to the driver for transmission, if this interface is no longer able to deliver frames to the old AP - then if the new AP interface is up and on the same subnet it may be feasible to simply move all the IP packets over to the outgoing queue for the new interface. Unless you have integrated the drivers you will not be able to do this optimization since the packets are already below the IP layer. Is this case likely? Yes, I think that if we look at current campus and many single operator settings the adjacent cells are often on the same subnet. {You can already see this sort of behavior if you force a mobile to switch between the two interfaces of an Orinoco Wavepoint II AP - the AP will actually output the frames on the other interface when it sees the mobile appear on its other WLAN interface.} Chip From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 21 20:04:21 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04806 for ; Fri, 21 Jun 2002 20:04:20 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09449; Fri, 21 Jun 2002 18:05:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01692; Fri, 21 Jun 2002 17:04:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5M03hk7016317 for ; Fri, 21 Jun 2002 17:03:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5M03hMa016316 for mobile-ip-dist; Fri, 21 Jun 2002 17:03:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5M03dk7016309 for ; Fri, 21 Jun 2002 17:03:39 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA16135 for ; Fri, 21 Jun 2002 17:03:46 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA17504 for ; Fri, 21 Jun 2002 17:03:45 -0700 (PDT) From: Masataka Ohta Message-Id: <200206212343.IAA01618@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA01618; Sat, 22 Jun 2002 08:43:26 +0900 Subject: Re: [mobile-ip] Draft Agenda for MIP WG @ IETF54 In-Reply-To: <00e501c21944$324ca6f0$4f6015ac@T23KEMPF> from James Kempf at "Jun 21, 2002 09:53:41 am" To: James Kempf Date: Sat, 22 Jun 2002 08:43:25 +0859 () CC: Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: jak; > > If there are other operators of mobile IP, I'm interested in their > > opinion. > > Welll, Docomo is certainly interested in the ongoing work to standardize > fast and smooth handover for Mobile IP that is being pursued in the MIP > WG. Depending on particular Layer 2 solutions for particular link layers > such as WLAN, like using dual channels, is not acceptable. Just FYI, Docomo, in Japan, is operating PHS with smooth handover capability with two receivers (two receivers are enough, if transmitting frequency can be changed quickly). Thank you for demonstrating that you lack experience on mobile operations. If there are operators of mobile IP, I'm interested in their opinion. It is not link specific. It is not even mobile protocol specific. It just works with the existing Internet. On the other hand, solutions requiring intermediate intelligent entities depends on particular mobility protocol and link layers that it is not acceptable on the global Internet. > Currently, as > far as I know, there is only one 802.11 card that supports dual channel > handover and that is only available in Japan. Huh? A terminal with two 802.11 cards works just fine. Though we experimentally produced a PCMCIA card with dual 802.11 transceivers, to be used with PCs with a single PCMCIA slot, PCs are not interesting devices for mobile use. > I can't see that as being > an acceptable solution for an Internet (== worldwide) standard. What is not acceptable to the Internet is proposals requiring intermediate intelligent entities, such as micro mobility agents. You may use them in your private IP network, though. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 21 20:54:14 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05589 for ; Fri, 21 Jun 2002 20:54:14 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23573; Fri, 21 Jun 2002 18:54:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27692; Fri, 21 Jun 2002 17:54:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5M0rkk7016467 for ; Fri, 21 Jun 2002 17:53:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5M0rkmG016466 for mobile-ip-dist; Fri, 21 Jun 2002 17:53:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5M0rgk7016459 for ; Fri, 21 Jun 2002 17:53:43 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27566 for ; Fri, 21 Jun 2002 17:53:47 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09579 for ; Fri, 21 Jun 2002 18:53:47 -0600 (MDT) From: Masataka Ohta Message-Id: <200206220033.JAA01985@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA01985; Sat, 22 Jun 2002 09:32:46 +0859 Subject: Re: [mobile-ip] Interference? with Smooth Handover? In-Reply-To: <200206211848.UAA10555@dumburken.it.kth.se> from Gerald Maguire at "Jun 21, 2002 08:48:18 pm" To: Gerald Maguire Date: Sat, 22 Jun 2002 09:32:46 +0859 () CC: behcet.sarikaya@alcatel.com, mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Chip; > With different spreading codes, but in the same frequency band - > the transmission by one will probably wipe out the reception by the > other - because unless you have a very wide dynamic range receiver > the AGC will be saturated by the tranmission by the near by > transmitter. The most serious interference occurs if a packet arrives to a terminal, while the terminal is transmitting, which is usual with plain WLAN without smooth handover or mobility. So, WLAN is designed to tolerate interferences. > 2. a mobile equipped with two WLAN interfaces which are using > the same "channels", but associated with different access points. > They will compete for the channel as usual -- since there is only > one channel. That is a degenerate case, where just a single transciever is necessary. Actually, our trial in early days use a single channel that this is the case. The downside is that we can not utilize all the bandwidth allocated to WLAN and that we can not modify a band of an access point to avoid noise frequencies local to the access point. > 3. there is a chance that both interfaces could be searching for a new > AP at the same time and both pick the same new "channel" and AP -- > in which case they can interfere as per item 2 above. So you need > some way to prevent them from both going to the same channel. MIS does not use L2 functionalities of WLAN for beacon generation or frequency scanning, because these L2 functinalities, contrary to naive expectations, increases handover latency even on terminals with only one transceiver, explanation of which is being added to the draft. So, almost evenrything is controlled by the terminal L3 software and L2 is mostly for CSMA/CA. > An interesting device is a two way WLAN interface + a receive only > WLAN interface - the later can be used to identify new potential APs A problem is that it takes considerable amount of time to set transmission frequency band and to reset to the original with currently available WLAN NIC, during which receiving is not possible, which is why MIS use two transmitters. > Consider the case where you have already given a number of packets to > the driver for transmission, if this interface is no longer able to > deliver frames to the old AP - then if the new AP interface is up and > on the same subnet it may be feasible to simply move all the IP packets > over to the outgoing queue for the new interface. Unless you have > integrated the drivers you will not be able to do this optimization > since the packets are already below the IP layer. Is this case likely? With a single receiver, handover is initiated only after signal quality from the current AP considerably degrade, in which case, it may be too late to push all the packets in buffer to the current AP. With dual receivers, handover is initiated if signal quality from the current AP considerably weaker than a new AP. With slightly overlapping areas of APs, it is expected that a handover is initiated long before the communication with the current AP become impossible (even if you are moving at 60Km/h, you move 16.6m/s). Assuming effective speed of 11M WLAN is 5M, 5 mega bits of buffer is drained in a second that your case is unlikely. > Yes, I think that if we look at current campus and many single > operator settings the adjacent cells are often on the same subnet. > {You can already see this sort of behavior if you force a mobile to > switch between the two interfaces of an Orinoco Wavepoint II AP - the > AP will actually output the frames on the other interface when it sees > the mobile appear on its other WLAN interface.} Link layer is an intermediate entity between end systems. An AP is an intermediate entity between end systems. Thus, too much link layer or AP intelligence is against the end to end principle and is harmful to the Internet. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 21 21:08:46 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05789 for ; Fri, 21 Jun 2002 21:08:46 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12020; Fri, 21 Jun 2002 18:08:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA20849; Fri, 21 Jun 2002 18:08:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5M17gk7016615 for ; Fri, 21 Jun 2002 18:07:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5M17gn0016614 for mobile-ip-dist; Fri, 21 Jun 2002 18:07:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5M17dk7016607 for ; Fri, 21 Jun 2002 18:07:39 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA00637 for ; Fri, 21 Jun 2002 18:07:44 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA13759 for ; Fri, 21 Jun 2002 19:07:43 -0600 (MDT) From: Masataka Ohta Message-Id: <200206220054.JAA02089@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA02089; Sat, 22 Jun 2002 09:54:40 +0900 Subject: Re: [mobile-ip] any deployment? In-Reply-To: <3D139BA1.7080000@alcatel.com> from Vinod Kumar Choyi at "Jun 21, 2002 04:33:21 pm" To: vinod.choyi@alcatel.com Date: Sat, 22 Jun 2002 09:54:39 +0859 () CC: Behcet Sarikaya , mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: vinod; > Hi Hi. > How long does your battery last ? Our trial is using PCs (we admit PCs are not appropriate for mobile use) that it depends on PCs. Power consumption by WLAN transceivers is negligible. > or how much more power is required > compared to using only one transreceiver ? With our current implementation, twice, as there is no attempt to suppress power consumption. Power save functionality of 802.11 is not supported by most, if not all, WLAN NIC, yet. But, industry is now aware that power is a probelm of PDA that there is a CF-slot WLAN card which consumes several times less power than existing ones. The secondary transceiver must be supplied power only during frequency scanning (for receiving only) and handover period (mostly for receiving only, except for sending (and resending) link/mobile registration packts), that, ultimately, the power consumption is expected to be about the same as with a single transceiver. If you need more concret evidences, that battery of PHS devices lasts a lot might help. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 21 21:44:49 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06433 for ; Fri, 21 Jun 2002 21:44:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06811; Fri, 21 Jun 2002 19:45:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25323; Fri, 21 Jun 2002 18:45:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5M1hYk7016751 for ; Fri, 21 Jun 2002 18:43:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5M1hYpq016750 for mobile-ip-dist; Fri, 21 Jun 2002 18:43:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5M1hUk7016743 for ; Fri, 21 Jun 2002 18:43:31 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA29512 for ; Fri, 21 Jun 2002 18:43:36 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20727 for ; Fri, 21 Jun 2002 18:43:36 -0700 (PDT) Message-ID: <00ba01c2198d$fb5af300$8f6015ac@T23KEMPF> From: "James Kempf" To: "Masataka Ohta" Cc: , References: <200206212343.IAA01618@necom830.hpcl.titech.ac.jp> Subject: Re: [mobile-ip] Draft Agenda for MIP WG @ IETF54 Date: Fri, 21 Jun 2002 18:41:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > > If there are other operators of mobile IP, I'm interested in their > > > opinion. > > > > Welll, Docomo is certainly interested in the ongoing work to standardize > > fast and smooth handover for Mobile IP that is being pursued in the MIP > > WG. Depending on particular Layer 2 solutions for particular link layers > > such as WLAN, like using dual channels, is not acceptable. > > Just FYI, Docomo, in Japan, is operating PHS with smooth handover > capability with two receivers (two receivers are enough, if > transmitting frequency can be changed quickly). > The fact that Docomo operates a network having a particular Layer 2 does not mean that this solution should apply to all Layer 2s. The FOMA network doesn't use two receivers, it uses a single receiver and soft handover. Packet PDC uses hard handover. It is not acceptable for IETF to specify a particular Layer 2 technology for Mobile IP. IETF can state what requirements would be optimal from the Layer 3 standpoint, or it could specify standards for carrying Layer 2 information, but it can't specify standards that only run on a particular Layer 2. Check RFC 1958. > Thank you for demonstrating that you lack experience on mobile > operations. > I never claimed to be an expert in the operation of mobile networks. I'm certainly always open to learning more, thanx for the info on PHS. But you asked for an opinion from an operator, and so I gave one. > > Currently, as > > far as I know, there is only one 802.11 card that supports dual channel > > handover and that is only available in Japan. > > Huh? A terminal with two 802.11 cards works just fine. > See Chip Maquire's email on interference effects. > What is not acceptable to the Internet is proposals requiring > intermediate intelligent entities, such as micro mobility agents. > Exactly which drafts are you referring to here? Neither draft-ietf-mobileip-fast-mipv6-xx.txt nor draft-ietf-mobileip-lowlatency-handoffs-v4-xx.txt depend on intermediate agents. They just require that the access routers support extensions to mobile IP and routing protocols. jak From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 22 06:24:28 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23322 for ; Sat, 22 Jun 2002 06:24:27 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00321; Sat, 22 Jun 2002 04:25:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25997; Sat, 22 Jun 2002 03:24:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5MANSk7017332 for ; Sat, 22 Jun 2002 03:23:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5MANSZs017331 for mobile-ip-dist; Sat, 22 Jun 2002 03:23:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5MANPk7017324 for ; Sat, 22 Jun 2002 03:23:25 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA07757 for ; Sat, 22 Jun 2002 03:23:29 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA05412 for ; Sat, 22 Jun 2002 03:23:28 -0700 (PDT) From: Masataka Ohta Message-Id: <200206221008.TAA03083@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA03083; Sat, 22 Jun 2002 19:08:08 +0900 Subject: Re: [mobile-ip] Draft Agenda for MIP WG @ IETF54 In-Reply-To: <00ba01c2198d$fb5af300$8f6015ac@T23KEMPF> from James Kempf at "Jun 21, 2002 06:41:48 pm" To: James Kempf Date: Sat, 22 Jun 2002 19:08:07 +0859 () CC: Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: jak; > > > Welll, Docomo is certainly interested in the ongoing work to > standardize > > > fast and smooth handover for Mobile IP that is being pursued in the > MIP > > > WG. Depending on particular Layer 2 solutions for particular link > layers > > > such as WLAN, like using dual channels, is not acceptable. > > > > Just FYI, Docomo, in Japan, is operating PHS with smooth handover > > capability with two receivers (two receivers are enough, if > > transmitting frequency can be changed quickly). > The fact that Docomo operates a network having a particular Layer 2 does > not mean that this solution should apply to all Layer 2s. The FOMA The fact is that Docomo operates a PHS network NOT having a particular L2 functionality and still support smooth handover. PHS, in early days, has poor handover capability, because of its L2. Then, one day, with terminals with two receivers, without modifying the problematic L2, smooth handover became possible. Smooth handover of PHS is NOT offered by L2, which still poorly support handover. Smooth handover with two transceivers (receivers) works with PHS, simple plain WLAN or simple plain wired ethernet. > It is not acceptable for IETF > to specify a particular Layer 2 technology for Mobile IP. Welcome to IETF. > IETF can state > what requirements would be optimal from the Layer 3 standpoint, or it > could specify standards for carrying Layer 2 information, but it can't > specify standards that only run on a particular Layer 2. Check RFC 1958. Just as an evidence that I thoroughly checked RFC 1958, you can check the RFC stating: : Acknowledgements : : This document is a collective work of the Internet community, : published by the Internet Architecture Board. Special thanks to Fred : Baker, Noel Chiappa, Donald Eastlake, Frank Kastenholz, Neal : McBurnett, Masataka Ohta, Jeff Schiller and Lansing Sloan. the RFC, in addition, states: : The Internet level protocol must be independent of the hardware : medium and hardware addressing. This approach allows the Internet to : exploit any new digital transmission technology of any kind, and to : decouple its addressing mechanisms from the hardware. It allows the : Internet to be the easy way to interconect fundamentally different : transmission media, My proposal works independent of the hardware medium and hardware addressing. Which particular layer 2 technology, are you saying, is necessary to support smooth handover with two receivers? There is none and it works with any layer 2 technologies. > > Thank you for demonstrating that you lack experience on mobile > > operations. > I never claimed to be an expert in the operation of mobile networks. I'm > certainly always open to learning more, thanx for the info on PHS. > > But you asked for an opinion from an operator, and so I gave one. What I asked is an opinion from mobile IP operators, : If there are other operators of mobile IP, I'm interested in their : opinion. though opinions from anyone could have been useful. > > > Currently, as > > > far as I know, there is only one 802.11 card that supports dual > channel > > > handover and that is only available in Japan. > > > > Huh? A terminal with two 802.11 cards works just fine. > See Chip Maquire's email on interference effects. And the interference is no problem. You need information not only on PHS but also on WLAN. > > What is not acceptable to the Internet is proposals requiring > > intermediate intelligent entities, such as micro mobility agents. > > > > Exactly which drafts are you referring to here? Neither > draft-ietf-mobileip-fast-mipv6-xx.txt nor > draft-ietf-mobileip-lowlatency-handoffs-v4-xx.txt depend on intermediate > agents. They just require that the access routers support extensions to > mobile IP and routing protocols. Unnecessarily complex routing protocol is intelligence in the network. You can check RFC 1958 to understand that routing should not do much job. The access router supporting the unnecessarily complex routing is an intermediate intelligent entity. In general, functionality in a network substitutable by functionality on end systems, are not allowed by the end to end principle. A foreign agent in a network, which MIS decided not to have ( FA is collocated on MN), is an intermediate intelligent entity. That you do it at higher layers does not make it unintelligent. E.g. NAT or an application layer gateway operating at layers of IP and above is an intermediate intelligent entity. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 22 19:53:38 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06176 for ; Sat, 22 Jun 2002 19:53:35 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18571; Sat, 22 Jun 2002 16:53:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20243; Sat, 22 Jun 2002 16:52:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5MNpZk7018176 for ; Sat, 22 Jun 2002 16:51:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5MNpZFx018175 for mobile-ip-dist; Sat, 22 Jun 2002 16:51:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5MNpVk7018168 for ; Sat, 22 Jun 2002 16:51:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20117 for ; Sat, 22 Jun 2002 16:51:37 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12924 for ; Sat, 22 Jun 2002 17:51:36 -0600 (MDT) 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 QAA17060; Sat, 22 Jun 2002 16:51:35 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5MNpX212545; Sat, 22 Jun 2002 16:51:33 -0700 X-mProtect: <200206222351> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdiLndoc; Sat, 22 Jun 2002 16:51:31 PDT Message-ID: <3D150D84.E8C0DDC4@iprg.nokia.com> Date: Sat, 22 Jun 2002 16:51:32 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Krishna Kumar CC: PRoberts@megisto.com, jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com Subject: Issue #43 (was, Re: [mobile-ip] Re: MIPv6 - 17 Review) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Krishna, The Binding Refresh Request message is useful for cases where the Lifetime is 10 times or dozens of times larger than the expected Refresh interval. The idea was to avoid having the availability of nonvolatile storage at the home agent be a factor when choosing a value for the Lifetime. Thus I think it is useful, but I really think that we will have to wait and see to be sure. Furthermore, if people think that it is useful for only a small percentage of the total number of Binding Updates, then we could reorganize the feature as controlled by an option instead of a field that is present in all Binding Update messages. If this is preferred, I'd like to find out immediately so that we can fix the specification before the deadline. Regards, Charlie P. > 19. Section 10.2 : The para about : > > "- The Refresh field MUST be set to a value less than or equal to" > > Is Refresh useful at all ? I don't believe it is. It seems to imply that > it > helps in the case of the Home Agent crashing and has only a volatile > storage > for the binding cache. But if the Home Agent crashed before the Refresh > > interval is over, the behaviour is identical to the case where the > Refresh > field contains the same value as Lifetime. > > It will be useful only if the HA crashed after the Refresh interval but > before > the Lifetime interval. Hence it is completely useless in most > situations. > > If this can be removed safely, all references need to be removed in the > draft and the Format of the BU section (6.1.8) needs to reflect this. From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 23 13:24:25 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01628 for ; Sun, 23 Jun 2002 13:24:24 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16603; Sun, 23 Jun 2002 11:24:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02839; Sun, 23 Jun 2002 10:24:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5NHNYk7019167 for ; Sun, 23 Jun 2002 10:23:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5NHNYKC019166 for mobile-ip-dist; Sun, 23 Jun 2002 10:23:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5NHNUk7019159 for ; Sun, 23 Jun 2002 10:23:31 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26365 for ; Sun, 23 Jun 2002 10:23:35 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16405 for ; Sun, 23 Jun 2002 11:23:30 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g5NHNRd10242 for ; Sun, 23 Jun 2002 19:23:27 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA21957 for ; Sun, 23 Jun 2002 19:23:28 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g5NHNRGF000587 for ; Sun, 23 Jun 2002 19:23:28 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200206231723.g5NHNRGF000587@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] draft-dupont-transient-pseudonat-00.txt Date: Sun, 23 Jun 2002 19:23:27 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I've just submitted an I-D about the "transient pseudo-NAT" attack which was already discussed in this list (and the NAT traversal I-D, draft-ietf-mobileip-nat-traversal-04.txt, takes it into account). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 23 17:55:17 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05161 for ; Sun, 23 Jun 2002 17:55:16 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23480; Sun, 23 Jun 2002 15:55:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25527; Sun, 23 Jun 2002 14:55:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5NLsRk7019535 for ; Sun, 23 Jun 2002 14:54:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5NLsRgZ019534 for mobile-ip-dist; Sun, 23 Jun 2002 14:54:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5NLsOk7019527 for ; Sun, 23 Jun 2002 14:54:24 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00278 for ; Sun, 23 Jun 2002 14:54:28 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23189 for ; Sun, 23 Jun 2002 15:54:27 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 45F306A904; Mon, 24 Jun 2002 00:54:10 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 62FE66A901 for ; Mon, 24 Jun 2002 00:54:08 +0300 (EEST) Message-ID: <3D1643D7.1010207@kolumbus.fi> Date: Mon, 24 Jun 2002 00:55:35 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] new state machines Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I'm working on the text related to issue #32 (http://www.piuha.net./~jarkko/publications/mipv6/issues/issue32.txt) This issue is about the simplification of the state machine. I have now made the following modifications to draft 17 state machine: - Took in account that when running the RR procedure, we may or may not have an existing binding. - Separated the details of the actual return routability procedure from the management of bindings. This resulted in the main state machine and the "sub-state machine" for the return routability messaging. - For brevity, assumed that acknowledgements are always required. - Condensed the descriptions by removing those lines from the tables that did not have any action and which did not change the current state. The new state machine descriptins can be found from the below URLs. Comments are appreciated, as are suggestions for further simplification (the first item above offset some of the simplification that three other items brought). http://www.piuha.net./~jarkko/publications/mipv6/new-statemachine.txt http://www.piuha.net./~jarkko/publications/mipv6/new-statemachine-rr.txt Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 07:47:48 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00393 for ; Mon, 24 Jun 2002 07:47:48 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA20391; Mon, 24 Jun 2002 04:47:50 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19982; Mon, 24 Jun 2002 04:47:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OBkKk7020652 for ; Mon, 24 Jun 2002 04:46:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OBkKZe020651 for mobile-ip-dist; Mon, 24 Jun 2002 04:46:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OBkGk7020644 for ; Mon, 24 Jun 2002 04:46:17 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19747 for ; Mon, 24 Jun 2002 04:46:21 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23319 for ; Mon, 24 Jun 2002 05:46:20 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id E5A6E6A905; Mon, 24 Jun 2002 14:46:19 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BF7646A904 for ; Mon, 24 Jun 2002 14:46:13 +0300 (EEST) Message-ID: <3D1706DD.6000007@kolumbus.fi> Date: Mon, 24 Jun 2002 14:47:41 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] new state machines References: <3D1643D7.1010207@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I made some further simplifications by combining 'movement' and 'route optimization desired/not desired'... these can be modelled by the same events relating to movement and returning home. Updated state machines at: http://www.piuha.net./~jarkko/publications/mipv6/new-statemachine.txt http://www.piuha.net./~jarkko/publications/mipv6/new-statemachine-rr.txt Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 07:48:51 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00741 for ; Mon, 24 Jun 2002 07:48:51 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12835; Mon, 24 Jun 2002 05:49:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19601; Mon, 24 Jun 2002 04:49:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OBmGk7020681 for ; Mon, 24 Jun 2002 04:48:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OBmGrK020680 for mobile-ip-dist; Mon, 24 Jun 2002 04:48:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OBmCk7020673 for ; Mon, 24 Jun 2002 04:48:12 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19479 for ; Mon, 24 Jun 2002 04:48:17 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19522 for ; Mon, 24 Jun 2002 04:48:16 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00308; Mon, 24 Jun 2002 07:47:33 -0400 (EDT) Message-Id: <200206241147.HAA00308@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-muhanna-mobileip-compat-00.txt Date: Mon, 24 Jun 2002 07:47:32 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IPv4 Compatibility Extensions Author(s) : A. Muhanna, L. Salgarelli, P. Boulos Filename : draft-muhanna-mobileip-compat-00.txt Pages : 10 Date : 21-Jun-02 Mobile-IP, together with several other supporting standards such as Reverse Tunneling and the Challenge-Response extensions, have all been recently revised. Although such revisions are for the most part backward compatible with the original versions, sometimes static configuration of Mobile Nodes and Mobility Agents is required to ensure smooth transition and avoid any possible conflict between different standard versions implemented by already-deployed equipment. In this draft we define compatibility extensions for Mobile-IP Agent Advertisement, Registration Request and Registration Reply messages that allow all Mobile-IPv4 entities to dynamically synchronize their 'compatibility versions', defined as the versions of the Mobile-IP standards that a particular node is able to support. This solution offers a dynamic mechanism which informs all entities involved in a Mobile-IP exchange of the version of the standard they support, therefore reducing the need to statically configure such information at Mobile Nodes or Mobility Agents A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-muhanna-mobileip-compat-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-muhanna-mobileip-compat-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-muhanna-mobileip-compat-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: <20020621121814.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-muhanna-mobileip-compat-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-muhanna-mobileip-compat-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020621121814.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 08:21:41 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02801 for ; Mon, 24 Jun 2002 08:21:40 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02852; Mon, 24 Jun 2002 05:21:50 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24725; Mon, 24 Jun 2002 05:21:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OCKWk7020892 for ; Mon, 24 Jun 2002 05:20:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OCKWWB020891 for mobile-ip-dist; Mon, 24 Jun 2002 05:20:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OCKSk7020884 for ; Mon, 24 Jun 2002 05:20:28 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA25822 for ; Mon, 24 Jun 2002 05:20:34 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02999 for ; Mon, 24 Jun 2002 05:20:33 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5OCKNrU024604; Mon, 24 Jun 2002 14:20:23 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 14:20:23 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F077B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charles E. Perkins'" , Krishna Kumar Cc: PRoberts@megisto.com, jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com Subject: RE: Issue #43 (was, Re: [mobile-ip] Re: MIPv6 - 17 Review) Date: Mon, 24 Jun 2002 14:20:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > The Binding Refresh Request message is useful for cases > where the Lifetime is 10 times or dozens of times larger > than the expected Refresh interval. The idea was to avoid > having the availability of nonvolatile storage at the > home agent be a factor when choosing a value for the Lifetime. => So couldn't we set the lifetime to what was meant to be a refresh time? doesn't this have the same effect? > > Thus I think it is useful, but I really think that we will > have to wait and see to be sure. Furthermore, if people > think that it is useful for only a small percentage of the > total number of Binding Updates, then we could reorganize > the feature as controlled by an option instead of a field > that is present in all Binding Update messages. If this is > preferred, I'd like to find out immediately so that we can > fix the specification before the deadline. > => I think this would be better. The MH would be better aligned without that row anyway.So it would be goo to send it when needed. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 08:40:40 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03855 for ; Mon, 24 Jun 2002 08:40:39 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11472; Mon, 24 Jun 2002 05:40:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA28746; Mon, 24 Jun 2002 05:40:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OCdkk7021019 for ; Mon, 24 Jun 2002 05:39:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OCdjTR021018 for mobile-ip-dist; Mon, 24 Jun 2002 05:39:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OCdgk7021011 for ; Mon, 24 Jun 2002 05:39:43 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA16662 for ; Mon, 24 Jun 2002 05:39:48 -0700 (PDT) Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16262 for ; Mon, 24 Jun 2002 06:39:47 -0600 (MDT) Received: from ipunplugged.com (echo.local.ipunplugged.com [192.168.4.74]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with ESMTP id g5OCeJUg007035; Mon, 24 Jun 2002 14:40:20 +0200 Message-ID: <3D1712AE.90601@ipunplugged.com> Date: Mon, 24 Jun 2002 14:38:06 +0200 From: =?ISO-8859-1?Q?Hans_Sj=F6strand?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tessier, Serge" CC: mobile-ip Subject: [mobile-ip] benafits and drawbacks with nat traversal References: <200206211136.HAA07988@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Serge, Could you explain why implementing NAT traversal with "UDP Encapsulation of IPsec Packets" is an benafit while implementing it with "Mobile IP NAT/NAPT Traversal using UDP Tunnelling" is a drawback? From draft-tessier-mobileip-ipsec-00.txt > Figure 1: Mobile IP tunnel in IPSec VPN tunnel > > While the drawbacks are: > - Since local networks use usually private addresses, NAPT is a > major problem. A solution like the one described in [7] needs > to be applied > > Figure 2: IPSec VPN tunnel in Mobile IP tunnel > > The benefits are: > - NAPT is not a problem for Mobile IP since it is solved by the > IPSec tunnel > Regards /// Hasse From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 10:23:09 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08408 for ; Mon, 24 Jun 2002 10:23:09 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08133; Mon, 24 Jun 2002 08:23:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09895; Mon, 24 Jun 2002 07:23:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OELpk7021351 for ; Mon, 24 Jun 2002 07:21:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OELpsA021350 for mobile-ip-dist; Mon, 24 Jun 2002 07:21:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OELkk7021343 for ; Mon, 24 Jun 2002 07:21:46 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14394 for ; Mon, 24 Jun 2002 07:21:50 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00634 for ; Mon, 24 Jun 2002 07:21:50 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5OEM2a17813; Mon, 24 Jun 2002 09:22:02 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 09:21:47 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF272@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Behcet Sarikaya'" , "'mobile-ip'" Cc: "'Luca Salgarelli'" , "Pierre Boulos" Subject: RE: [mobile-ip] New Draft: draft-muhanna-mobileip-compat-00.txt Date: Mon, 24 Jun 2002 09:21:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21B8A.747C5FA0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C21B8A.747C5FA0 Content-Type: text/plain; charset="iso-8859-1" Hello Behcet; Thanks a lot for your comment. Some times reading the abstract alone does not help in getting the whole picture. I hardly can see how it would be solvable with SNMP MIB's. I really appreciate it if you allocate some of your time to read the draft. Thanks a lot in advance. Regards; Ahmad Muhanna -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Friday, June 21, 2002 1:46 PM To: Muhanna, Ahmad [RICH1:2Q20:EXCH] Cc: 'mobile-ip' Subject: Re: [mobile-ip] New Draft: draft-muhanna-mobileip-compat-00.txt Ahmad, I have not read your draft but from the abstract this sounds like something that can be done with MIB, although it would probably be static. Have you formulated the change as a modified MIB? Then SNMP would solve your problem. If you are proposing further changes to MIPv4 then this might take us into a backward compatibility loop. Regards, Ahmad Muhanna wrote: Hello all, In response to the need of a dynamic mechanism as part of Mobile IPv4 registration to synchronize the version of the standards used by all Mobile IPv4 entities, I have submitted a new draft to the Mobile IP WG with the following abstract: Abstract Mobile-IP, together with several other supporting standards such as Reverse Tunneling and the Challenge-Response extensions, have all been recently revised. Although such revisions are for the most part backward compatible with the original versions, sometimes static configuration of Mobile Nodes and Mobility Agents is required to ensure smooth transition and avoid any possible conflict between different standard versions implemented by already-deployed equipment. In this draft we define compatibility extensions for Mobile-IP Agent Advertisement, Registration Request and Registration Reply messages that allow all Mobile-IPv4 entities to dynamically synchronize their "compatibility versions", defined as the versions of the Mobile-IP standards that a particular node is able to support. This solution offers a dynamic mechanism which informs all entities involved in a Mobile-IP exchange of the version of the standard they support, therefore reducing the need to statically configure such information at Mobile Nodes or Mobility Agents. Until it shows up in the drafts directory, it is on the co-author Luca Salgarelli web page. To get to it, please use the following link: http://www.bell-labs.com/user/salga/doc/draft-muhanna-mobileip-compat-00.txt Regards; Ahmad Muhanna -- Behcet ------_=_NextPart_001_01C21B8A.747C5FA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] New Draft: = draft-muhanna-mobileip-compat-00.txt

Hello Behcet;
Thanks a lot for your comment.

Some times reading the abstract alone does not help = in getting the
whole picture. I hardly can see how it would be = solvable with SNMP MIB's.

I really appreciate it if you allocate some of your = time to read the draft.
Thanks a lot in advance.

Regards;
Ahmad Muhanna


-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcat= el.com]
Sent: Friday, June 21, 2002 1:46 PM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
Cc: 'mobile-ip'
Subject: Re: [mobile-ip] New Draft: = draft-muhanna-mobileip-compat-00.txt


Ahmad,
  I have not read your draft but from the = abstract this sounds like something that can be done with MIB, although = it would probably be static. Have you formulated the change as a = modified MIB? Then SNMP would solve your problem.

  If you are proposing further changes to MIPv4 = then this might take us into a backward compatibility loop.
Regards,

Ahmad Muhanna wrote:

Hello all,
In response to the need of a dynamic mechanism as = part of Mobile IPv4
registration to synchronize the version of the = standards used by all
Mobile IPv4 entities, I have submitted a new draft = to the Mobile IP
WG with the following abstract:
Abstract
   Mobile-IP, together with several other = supporting standards such
   as Reverse Tunneling and the = Challenge-Response extensions, have
   all been recently revised.  = Although such revisions are for the
   most part backward compatible with the = original versions,
   sometimes static configuration of = Mobile Nodes and Mobility Agents
   is required to ensure smooth transition = and avoid any possible
   conflict between different standard = versions implemented by
   already-deployed equipment.  In = this draft we define compatibility
   extensions for Mobile-IP Agent = Advertisement, Registration Request
   and Registration Reply messages that = allow all Mobile-IPv4
   entities to dynamically synchronize = their "compatibility
   versions", defined as the versions = of the Mobile-IP standards that
   a particular node is able to = support.  This solution offers a
   dynamic mechanism which informs all = entities involved in a
   Mobile-IP exchange of the version of = the standard they support,
   therefore reducing the need to = statically configure such
   information at Mobile Nodes or Mobility = Agents.


Until it shows up in the drafts directory, it is on = the co-author Luca Salgarelli web
page. To get to it, please use the following = link:
http://www.bell-labs.com/user/salga/doc/draft-muhanna-= mobileip-compat-00.txt


Regards;
Ahmad Muhanna


--
Behcet

------_=_NextPart_001_01C21B8A.747C5FA0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 10:38:28 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09507 for ; Mon, 24 Jun 2002 10:38:28 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17920; Mon, 24 Jun 2002 08:39:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17857; Mon, 24 Jun 2002 07:38:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OEblk7021531 for ; Mon, 24 Jun 2002 07:37:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OEblBA021530 for mobile-ip-dist; Mon, 24 Jun 2002 07:37:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OEbhk7021523 for ; Mon, 24 Jun 2002 07:37:44 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5OEbjb06284; Mon, 24 Jun 2002 16:37:45 +0200 (MEST) Date: Mon, 24 Jun 2002 16:36:27 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] confusion about prefix sol/adv To: "Hesham Soliman (ERA)" Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF0538044F075F@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > To be able to send these messages, the MN needs > to have the HA's address. If it knows that, then it > knows its home address.... > Do we need to complicate things and have another > message pair, that are sent with different src > addresses, and cannot be secured? Presumably the IPsec SA used to secure the home BUs could also be applied to the prefix sol/adv messages. But perhaps the spec doesn't say this. Should it? Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 10:43:08 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09775 for ; Mon, 24 Jun 2002 10:43:07 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20669; Mon, 24 Jun 2002 08:43:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18725; Mon, 24 Jun 2002 07:43:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OEgik7021652 for ; Mon, 24 Jun 2002 07:42:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OEgiSc021651 for mobile-ip-dist; Mon, 24 Jun 2002 07:42:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OEgek7021644 for ; Mon, 24 Jun 2002 07:42:41 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5OEggb07181; Mon, 24 Jun 2002 16:42:42 +0200 (MEST) Date: Mon, 24 Jun 2002 16:41:23 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Resolution to issue 37, defending only link local addresses To: Jari Arkko Cc: "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli , Vladislav Yasevich , "Hesham Soliman (ERA)" In-Reply-To: "Your message with ID" <3D10C9AC.5050607@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Editorial nits - I haven't figured out if we know what the right thing(tm) is for mobile nodes returning home. > Proposal: Vijay Devaparalli and Vladislav Yasevich have proposed that > a new 'L' bit is needed. If the 'L' bit is set, it means both the MN's > link local address and home address have the same interface id. > > The 'L' and 'S' bits are used when defending addresses i.e. when > answering Neighbor Soliciations. The following addresses are defended: > > - S=0 & L=0 => Defend all global unicast addresses possible on link. s/global/non-link-local/ in order to say the right thing for site-locals. > - S=0 & L=1 => Semantics of S=0 above + the derived link-local. > > - S=1 & L=0 => Defend the given address. > > - S=1 & L=1 => Defend the given global unicast (home) address + > the derived link-local. s/global/non-link-local/ > If the home address was generated using RFC 3041, then there is no > corresponding link local address. Accordingly the MN SHOULD NOT set > the 'L' bit. > > The Home Agent SHOULD perform Duplicated Address detection on every > address it is defending on behalf of the mobile node. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 11:00:09 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10518 for ; Mon, 24 Jun 2002 11:00:09 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14626; Mon, 24 Jun 2002 09:00:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22980; Mon, 24 Jun 2002 08:00:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OExJk7021823 for ; Mon, 24 Jun 2002 07:59:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OExITS021822 for mobile-ip-dist; Mon, 24 Jun 2002 07:59:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OExFk7021815 for ; Mon, 24 Jun 2002 07:59:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26230 for ; Mon, 24 Jun 2002 07:59:20 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11070; Mon, 24 Jun 2002 08:59:17 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5OExGRb024102; Mon, 24 Jun 2002 16:59:16 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 16:59:16 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0780@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , "Hesham Soliman (ERA)" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] confusion about prefix sol/adv Date: Mon, 24 Jun 2002 16:59:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > To be able to send these messages, the MN needs > > to have the HA's address. If it knows that, then it > > knows its home address.... > > Do we need to complicate things and have another > > message pair, that are sent with different src > > addresses, and cannot be secured? > > Presumably the IPsec SA used to secure the home BUs could also be > applied to the prefix sol/adv messages. But perhaps the > spec doesn't say this. > Should it? => That was exactly what I was asking for. If we simply re-order the events so that the MN sends a BU first, then the same IPsec SA can be used to secure MPS and MPA. I think this should work fairly well, andavoid any additional security mechanisms, which will not be as strong as the existing IPsec SA. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 11:10:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11088 for ; Mon, 24 Jun 2002 11:10:37 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08795; Mon, 24 Jun 2002 09:11:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29684; Mon, 24 Jun 2002 08:11:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFA5k7021969 for ; Mon, 24 Jun 2002 08:10:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OFA5Ne021968 for mobile-ip-dist; Mon, 24 Jun 2002 08:10:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFA2k7021961 for ; Mon, 24 Jun 2002 08:10:02 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23374 for ; Mon, 24 Jun 2002 08:10:07 -0700 (PDT) Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20614 for ; Mon, 24 Jun 2002 09:10:05 -0600 (MDT) Received: from ipunplugged.com (echo.local.ipunplugged.com [192.168.4.74]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with ESMTP id g5OFAcUg010865; Mon, 24 Jun 2002 17:10:38 +0200 Message-ID: <3D1735E9.7030107@ipunplugged.com> Date: Mon, 24 Jun 2002 17:08:25 +0200 From: =?ISO-8859-1?Q?Hans_Sj=F6strand?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tessier, Serge" CC: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: AW: benafits and drawbacks with nat traversal References: <73D3E97F639DD5119642000347055F0503EB126F@G9JNS.mgb01.telekom.de> Content-Type: multipart/alternative; boundary="------------000509020808010808050403" X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------000509020808010808050403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Serge, With regards to NAT traversal scheme I think they are pretty equal. I have seen the mobile IP version from inside now for almost a year and actually know very little about the ipsec one,so I guess I'm also quite biased. The only noticable difference is that the Mobile IP NAT traversal is a more mature draft-whise and has gone further in the RFC process (at IETF last call). So, the RFC is most likely to happen before the IPsec counterpart. But thats neglectable when it comes to implementation. The major IPsec vendors have also had propriatory mechanisms for IPsec NAT traversal in their products for some time. I'd say a draw, both are bound to occure since they come from different vendors addressing different needs. But I thought your benafit/drawback approach was a little "over the top" which seamed more aimed to get a favourable ratio ;-) I apprechiated your draft which was a good and clear one. The thing about it for my perspective is that the requirement for seamless mobility is "non-negotiable", a MUST. Then we find a technical solution to that problem. I also think that the FA is a good thing, it speeds up handover and provides access control with AAA in a scalable manner. Additionally I think that you have some misunderstandings in your "3.1. IPSec tunnel inside the Mobile IP tunnel" section. You seam to try to go inside the ip-ip tunnel with your VPN firewall which I don't understand how you do it. Thats also why you get kind of contradictions like "It prevents integration of Mobile IP in already existing IPSec-based VPN products" Also, the statement "- In the case where FA care-of-address is used, security association needs to be hop-by-hop established" is not valid for the same reason. The scenario (which corresponds to the scenario "3.2 Mobile IP home agent in DMZ" in draft-sjostrand-mobileip-vpn-problem-stat-00.txt) is more like this; First you have a IPsec tunnel MN<->VPN GW, THEN you put that into an outer Mobile IP tunnel MN<=>HA (or FA<=>HA in case 2). <---------Internet--------> <--DMZ--> <--Intranet--> 1. MN[(====================)HA---]VPN GW .........CN 2. MN[----------FA(========)HA---]VPN GW .........CN [--] IPSec tunnel (==) MIP tunnel .... traffic in clear The Mobile IP tunnel provides you with a stable IP address from which you setup your IPsec SA. Regardless how you move, if you use CCOA or FA, the IPsec SA stays up on the stable IP. There could be a bundled SA between MN<->CN but thats beond this discussion and doesn't add any complexity. Regards /// Hasse Tessier, Serge wrote: >Hasse, > >NAT is anyway a problem but in the first case ("Mobile IP tunnel in IPSec VPN tunnel") it must be solved by an new solution specific to Mobile IP usage scenario i.e. draft-ietf-mobileip-nat-traversal-04.txt, while in the second case, ("IPSec VPN tunnel in Mobile IP tunnel") it is supposed to be solved by a solution specific to IPSec, i.e. draft-ietf-ipsec-udp-encaps-03.txt. > >To summarize: In order to do NAT traversal, you have two solutions: IPSec NAT traversal or Mobile IP NAT traversal. The criteria according to which you will choose between both solution depends on the tunneling order (IPsec in Mobile IP or vice-versa) that is, in turn, left to the fantasy of protocols' users. >Benefits and drawbacks are here written with regard to Mobile IP. I omited any consideration regarding IPSec NAT traversal problem. It is a subjective approach, which pertinence is debatable. > >Do you have any idea, if a solution is 'better' (more likely to occur, more scalable, etc.) than the other one? > >Regards >-Serge > > > >>-----Ursprüngliche Nachricht----- >>Von: Hans Sjöstrand [mailto:hans@ipunplugged.com] >>Gesendet: Montag, 24. Juni 2002 14:38 >>An: Tessier, Serge >>Cc: mobile-ip >>Betreff: benafits and drawbacks with nat traversal >> >> >>Serge, >> >>Could you explain why implementing NAT traversal with "UDP >>Encapsulation >>of IPsec Packets" is an benafit while implementing it with "Mobile IP >>NAT/NAPT Traversal using UDP Tunnelling" is a drawback? >> >> From draft-tessier-mobileip-ipsec-00.txt >> >> >> >>> Figure 1: Mobile IP tunnel in IPSec VPN tunnel >>> >>> While the drawbacks are: >>> - Since local networks use usually private addresses, NAPT is a >>> major problem. A solution like the one described in [7] needs >>> to be applied >>> >>> >>> >>> Figure 2: IPSec VPN tunnel in Mobile IP tunnel >>> >>> The benefits are: >>> - NAPT is not a problem for Mobile IP since it is solved by the >>> IPSec tunnel >>> >>> >>> >>Regards >>/// Hasse >> >> >> >> > > > --------------000509020808010808050403 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Serge,

With regards to NAT traversal  scheme I think they are pretty equal. I have seen the mobile IP version from inside now for almost a year and actually know very little about the ipsec one,so I guess I'm also quite biased. The only noticable difference is that the Mobile IP NAT traversal is a more mature draft-whise and has gone further in the RFC process (at IETF last call). So, the RFC is most likely to happen before the IPsec counterpart. But thats neglectable when it comes to implementation. The major IPsec vendors have also had propriatory mechanisms for IPsec NAT traversal in their products for some time. I'd say a draw, both are bound to occure since they come from different vendors addressing different needs.

But I thought your benafit/drawback approach was a little "over the top" which seamed more aimed to get a favourable ratio ;-)

I apprechiated your draft which was a good and clear one. The thing about it for my perspective is that the requirement for seamless mobility is "non-negotiable", a MUST. Then we find a technical solution to that problem. I also think that the FA is a good thing, it speeds up handover and provides access control with AAA in a scalable manner.

Additionally I think that you have some misunderstandings in your "3.1. IPSec tunnel inside the Mobile IP tunnel" section. You seam to try to go inside the ip-ip tunnel with your VPN firewall which I don't understand how you do it. Thats also why you get kind of contradictions like "It prevents integration of Mobile IP in already existing IPSec-based VPN products"

Also, the statement
"- In the case where FA care-of-address is used, security association needs to be hop-by-hop established"
is not valid for the same reason. The scenario (which corresponds to the scenario "3.2 Mobile IP home agent in DMZ" in  draft-sjostrand-mobileip-vpn-problem-stat-00.txt) is more like this;
First you have a IPsec tunnel MN<->VPN GW, THEN you put that into an outer Mobile IP tunnel MN<=>HA (or FA<=>HA in case 2). 
                   
   <---------Internet--------> <--DMZ--> <--Intranet--> 
                   
   1. MN[(====================)HA---]VPN GW .........CN 
   2. MN[----------FA(========)HA---]VPN GW .........CN 
                   
     [--] IPSec tunnel    (==) MIP tunnel    .... traffic in clear
The Mobile IP tunnel provides you with a stable IP address from which you setup your IPsec SA. Regardless how you move, if you use CCOA or FA, the IPsec SA stays up on the stable IP. There could be a bundled SA between MN<->CN but thats beond this discussion and doesn't add any complexity.

Regards
/// Hasse

Tessier, Serge wrote:
Hasse,

NAT is anyway a problem but in the first case ("Mobile IP tunnel in IPSec VPN tunnel") it must be solved by an new solution specific to Mobile IP usage scenario i.e. draft-ietf-mobileip-nat-traversal-04.txt, while in the second case, ("IPSec VPN tunnel in Mobile IP tunnel") it is supposed to be solved by a solution specific to IPSec, i.e. draft-ietf-ipsec-udp-encaps-03.txt.

To summarize: In order to do NAT traversal, you have two solutions: IPSec NAT traversal or Mobile IP NAT traversal. The criteria according to which you will choose between both solution depends on the tunneling order (IPsec in Mobile IP or vice-versa) that is, in turn, left to the fantasy of protocols' users.
Benefits and drawbacks are here written with regard to Mobile IP. I omited any consideration regarding IPSec NAT traversal problem. It is a subjective approach, which pertinence is debatable.

Do you have any idea, if a solution is 'better' (more likely to occur, more scalable, etc.) than the other one?

Regards
-Serge

  
-----Ursprüngliche Nachricht-----
Von: Hans Sjöstrand [mailto:hans@ipunplugged.com]
Gesendet: Montag, 24. Juni 2002 14:38
An: Tessier, Serge
Cc: mobile-ip
Betreff: benafits and drawbacks with nat traversal


Serge,

Could you explain why implementing NAT traversal with "UDP 
Encapsulation 
of IPsec Packets" is an benafit while implementing it with "Mobile IP 
NAT/NAPT Traversal using UDP Tunnelling" is a drawback?

 From draft-tessier-mobileip-ipsec-00.txt

    
  Figure 1: Mobile IP tunnel in IPSec VPN tunnel 

  While the drawbacks are: 
  - Since local networks use usually private addresses, NAPT is a 
    major problem. A solution like the one described in [7] needs 
    to be applied 

      
  Figure 2: IPSec VPN tunnel in Mobile IP tunnel   
                  
  The benefits are:
  - NAPT is not a problem for Mobile IP since it is solved by the
    IPSec tunnel  

      
Regards
/// Hasse


--------------000509020808010808050403-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 11:28:50 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11998 for ; Mon, 24 Jun 2002 11:28:49 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10916; Mon, 24 Jun 2002 08:28:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04486; Mon, 24 Jun 2002 08:28:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFRuk7022181 for ; Mon, 24 Jun 2002 08:27:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OFRu2t022180 for mobile-ip-dist; Mon, 24 Jun 2002 08:27:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFRrk7022173 for ; Mon, 24 Jun 2002 08:27:53 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28660 for ; Mon, 24 Jun 2002 08:27:58 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01768 for ; Mon, 24 Jun 2002 09:27:57 -0600 (MDT) Message-ID: <001f01c21b93$720778f0$4f6015ac@T23KEMPF> From: "James Kempf" To: "Masataka Ohta" Cc: , References: <200206221008.TAA03083@necom830.hpcl.titech.ac.jp> Subject: Re: [mobile-ip] Draft Agenda for MIP WG @ IETF54 Date: Mon, 24 Jun 2002 08:26:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Which particular layer 2 technology, are you saying, is necessary > to support smooth handover with two receivers? > > There is none and it works with any layer 2 technologies. > I'm sorry, Ohta-san, but it does not. It does not work with cdma2000 and it does not work with wCDMA. If you think this is so, then please point to the paragraphs in the spec that say it will. These protocols are designed to use soft handover with a single Rake receiver on the mobile station. They are not designed to use two receivers. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 11:33:22 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12234 for ; Mon, 24 Jun 2002 11:33:21 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05448; Mon, 24 Jun 2002 09:34:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01385; Mon, 24 Jun 2002 08:33:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFX1k7022308 for ; Mon, 24 Jun 2002 08:33:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OFX1lX022307 for mobile-ip-dist; Mon, 24 Jun 2002 08:33:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFWxk7022300 for ; Mon, 24 Jun 2002 08:33:00 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15725 for ; Mon, 24 Jun 2002 11:33:04 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g5OFXAXA003206 for ; Mon, 24 Jun 2002 11:33:10 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g5OFXA31003205 for mobile-ip@sunroof.eng.sun.com; Mon, 24 Jun 2002 11:33:10 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5NJIRk7019381; Sun, 23 Jun 2002 12:18:27 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01458; Sun, 23 Jun 2002 12:18:32 -0700 (PDT) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23483; Sun, 23 Jun 2002 13:18:31 -0600 (MDT) Received: from 3gwireless.com ([66.122.212.148]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GY6000UJANXO1@mta7.pltn13.pbi.net>; Sun, 23 Jun 2002 12:18:31 -0700 (PDT) Date: Sun, 23 Jun 2002 12:17:59 -0700 From: "3Gwireless'2003" Subject: [mobile-ip] Call for Submission of 2003 World Wireless Congress (3Gwireless'2003) Message-id: <3D161EE7.E209860C@3gwireless.com> MIME-version: 1.0 X-Mailer: Mozilla 4.78 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Sorry for multiple copies of this message. Thanks for your support in promotion of education, research, development and business of emerging wireless communications] Dear Fellow Wireless Colleagues: 2002 World Wireless Congress (WWC02) - the official framework of 3Gwireless'2002 has been extremely successful and productive. To continue this great effort and expect much more authoritative in the next year, the 2003 World Wireless Congress (WWC03) will be a very big bang in helping set the standard of performance, innovation and quality of emerging wireless communications focusing on 3G and 4G mobile technologies and business. WWC'03 will continue to be the best global platform of industry-driven, academia-enriched, development-oriented and business-targeted, and demand very high standard of technical leadership as well as professional excellence. The Call-for-Submission (including technical papers, tutorials, industry forums, panels, etc) is available now at the congress website. The submission will be very busy in the coming months, and the space is very limited. Please act ASAP to submit your leadership and innovation as per the guidelines listed in the web. The website of 2003 World Wireless Congress (3Gwireless'2003) is at: http://wirelesscongress.com or http://3gwireless.com The very successful story of 2002 World Wireless Congress (3Gwireless'2002) is at: http://delson.org/wwc02 This congress at news can be found at: http://www.wirelessweek.com/index.asp?layout=story&articleId=CA220172&stt=001 For sponsorship or exhibition opportunities, please contact janny@delson.org. For technical leadership issues, please contact the chair at: wwlu@ieee.org Thank you for your time in advance. With best wishes! Office of 2003 World Wireless Congress http://wirelesscongress.com or http://3gwireless.com [This is only one-time educational message. Thanks for your support.] From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 11:35:39 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12374 for ; Mon, 24 Jun 2002 11:35:39 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15629; Mon, 24 Jun 2002 08:35:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02362; Mon, 24 Jun 2002 08:35:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFYgk7022373 for ; Mon, 24 Jun 2002 08:34:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OFYf68022372 for mobile-ip-dist; Mon, 24 Jun 2002 08:34:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFYdk7022356 for ; Mon, 24 Jun 2002 08:34:39 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16221 for ; Mon, 24 Jun 2002 11:34:44 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g5OFYoXA003211 for ; Mon, 24 Jun 2002 11:34:50 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g5OFYo7f003210 for mobile-ip@sunroof.eng.sun.com; Mon, 24 Jun 2002 11:34:50 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5O8JBk7020366 for ; Mon, 24 Jun 2002 01:19:11 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA18762 for ; Mon, 24 Jun 2002 01:19:17 -0700 (PDT) Received: from mx2.iat.cnr.it (mx2.iat.cnr.it [146.48.65.89]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA29332 for ; Mon, 24 Jun 2002 01:19:16 -0700 (PDT) Received: from CONVERSION.MAIL.IAT.CNR.IT by mail.iat.cnr.it (PMDF V6.1-1 #40166) id <01KJB084EXDC90NHS2@mail.iat.cnr.it> for mobile-ip@sunroof.eng.sun.com; Mon, 24 Jun 2002 10:18:14 +0200 (MET DST) Received: from [146.48.82.112] (e-dcp.cnuce.cnr.it [146.48.82.112]) by mail.iat.cnr.it (PMDF V6.1-1 #40166) with ESMTP id <01KJB08487BA90NLPB@mail.iat.cnr.it> for mobile-ip@sunroof.eng.sun.com; Mon, 24 Jun 2002 10:18:14 +0200 (MET DST) Date: Mon, 24 Jun 2002 10:14:45 +0200 From: Marco Conti Subject: [mobile-ip] ACM WoWMoM2002 -- deadline is approaching X-Sender: man@pop.cnuce.cnr.it To: mobile-ip@sunroof.eng.sun.com Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_R0URmeZDbYDQTL51fqdqBw)" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --Boundary_(ID_R0URmeZDbYDQTL51fqdqBw) Content-type: text/plain; charset="us-ascii" CALL FOR PAPERS WoWMoM 2002 The Fifth ACM International Workshop on WIRELESS MOBILE MULTIMEDIA September 28, 2002 - Atlanta, Georgia (in conjunction with MobiCom'2002) http://www.ing.unipi.it/wowmom2002 WoWMoM is the premier international forum, sponsored by ACM SIGMOBILE, for discussions between researchers, practitioners and students interested in the symbiosis of mobile computers, wireless networks, and multimedia systems. WoWMoM 2002 is the fifth workshop of this series, and is sponsored by ACM SIGMOBILE. The WoWMoM 2002 technical program committee is soliciting papers describing original, previously unpublished, completed or on-going research, on topics including, but not limited to, the following: - Mobile Web Access - Mobile and Wireless Multimedia Applications - Pervasive computing - Mobile and Wireless Multimedia Networks - IP-based Mobile Networks - Mobility Management - QoS in the Mobile and Wireless Networks - Caching and delivery of streaming media - Delay and Jitter Management for Multimedia Services - Real-time voice/video over mobile and wireless networks - Multicasting in Wireless Services - Performance evaluation of wireless and mobile multimedia systems - Ad hoc sensor networks - Mobile ad hoc networks - Wireless BAN, PAN and LAN - Third and Fourth Generation Systems - 3G/WLAN internetworking - Energy-efficient Protocols and Power Management PAPER SUBMISSION AND PUBLICATION ================================= Papers should neither have been published elsewhere nor currently under review by another conference or journal. For paper submission, please follow the submission instructions at: http://www.ing.unipi.it/wowmom2002 All papers will be reviewed by the program committee members. Accepted papers will appear in the workshop proceedings published by ACM. IMPORTANT DATES ============== Full papers due: June 25, 2002 Notification: July 25, 2002 Camera Ready due: August 5, 2002 GENERAL Chair: Sajal K. Das, The University of Texas at Arlington, USA GENERAL Vice-Chair: Kalyan Basu, The University of Texas at Arlington, USA TECHNICAL PROGRAM Co-chairs: Marco Conti, National Research Council, Italy Dipankar Raychaudhuri WINLAB/Rutgers University, USA PUBLICITY Co-chairs: Jiannong Cao, Hong Kong Polytechnic University, Hong Kong Andrea Passarella, University of Pisa, Italy Gergely Zaruba, The University of Texas at Arlington, USA STEERING COMMITTEE Members: Ian F. Akyildiz, Georgia Institute of Technology, USA Kalyan Basu, The University of Texas at Arlington, USA Imrich Chlamtac, The University of Texas at Dallas, USA Sajal K. Das, The University of Texas at Arlington, USA (Chair) Randy Katz, University of California at Berkeley, USA Mahmoud Naghshineh, IBM T.J. Watson Research Center, USA Christopher Rose, Rutgers University, USA Satish K. Tripathi, University of California at Riverside, USA TECHNICAL PROGRAM COMMITTEE Members: Arup Acharya, IBM TJ Watson Research, USA Sudhir Aggarwal, Lucent Technologies, USA Giuseppe Anastasi, University of Pisa, Italy Stefano Basagni, Northeastern University, USA Chatschik Bisdikian, IBM T.J. Watson Research Center, USA Andrew T. Campbell, Columbia University, USA Erdal Cayirci, Georgia Institute of Technology, USA Subir Das, Telcordia Technologies, USA Silvia Giordano, EPFL, Lausanne, Switzerland Philippe Jacquet, INRIA, France Mohan Kumar, University of Texas at Arlington, USA Giridhar Mandyam, Nokia Research, USA Archan Misra IBM T.J. Watson Research Center, USA Hiroyuki Morikawa, University of Tokyo, Japan Sumit Roy, University of Washington, USA Elizabeth M. Belding-Royer, UC Santa Barbara, USA Paul Sanjoy, Bell Laboratories, USA Satish K. Tripathi, University of California at Riverside, USA Andras Valko, Ericsson, Hungary Adam Wolisz, Technical University Berlin, Germany Hee Yong Youn, Sungkyunkwan University, Korea --Boundary_(ID_R0URmeZDbYDQTL51fqdqBw) Content-type: text/enriched; charset="us-ascii"
CALL FOR PAPERS WoWMoM 2002 The Fifth ACM International Workshop on WIRELESS MOBILE MULTIMEDIA September 28, 2002 - Atlanta, Georgia (in conjunction with MobiCom'2002) http://www.ing.unipi.it/wowmom2002
WoWMoM is the premier international forum, sponsored by ACM SIGMOBILE, for discussions between researchers, practitioners and students interested in the symbiosis of mobile computers, wireless networks, and multimedia systems. WoWMoM 2002 is the fifth workshop of this series, and is sponsored by ACM SIGMOBILE. The WoWMoM 2002 technical program committee is soliciting papers describing original, previously unpublished, completed or on-going research, on topics including, but not limited to, the following: - Mobile Web Access - Mobile and Wireless Multimedia Applications - Pervasive computing - Mobile and Wireless Multimedia Networks - IP-based Mobile Networks - Mobility Management - QoS in the Mobile and Wireless Networks - Caching and delivery of streaming media - Delay and Jitter Management for Multimedia Services - Real-time voice/video over mobile and wireless networks - Multicasting in Wireless Services - Performance evaluation of wireless and mobile multimedia systems - Ad hoc sensor networks - Mobile ad hoc networks - Wireless BAN, PAN and LAN - Third and Fourth Generation Systems - 3G/WLAN internetworking - Energy-efficient Protocols and Power Management PAPER SUBMISSION AND PUBLICATION ================================= Papers should neither have been published elsewhere nor currently under review by another conference or journal. For paper submission, please follow the submission instructions at: http://www.ing.unipi.it/wowmom2002 All papers will be reviewed by the program committee members. Accepted papers will appear in the workshop proceedings published by ACM. IMPORTANT DATES ============== Full papers due: June 25, 2002 Notification: July 25, 2002 Camera Ready due: August 5, 2002 GENERAL Chair: Sajal K. Das, The University of Texas at Arlington, USA GENERAL Vice-Chair: Kalyan Basu, The University of Texas at Arlington, USA TECHNICAL PROGRAM Co-chairs: Marco Conti, National Research Council, Italy Dipankar Raychaudhuri WINLAB/Rutgers University, USA PUBLICITY Co-chairs: Jiannong Cao, Hong Kong Polytechnic University, Hong Kong Andrea Passarella, University of Pisa, Italy Gergely Zaruba, The University of Texas at Arlington, USA STEERING COMMITTEE Members: Ian F. Akyildiz, Georgia Institute of Technology, USA Kalyan Basu, The University of Texas at Arlington, USA Imrich Chlamtac, The University of Texas at Dallas, USA Sajal K. Das, The University of Texas at Arlington, USA (Chair) Randy Katz, University of California at Berkeley, USA Mahmoud Naghshineh, IBM T.J. Watson Research Center, USA Christopher Rose, Rutgers University, USA Satish K. Tripathi, University of California at Riverside, USA TECHNICAL PROGRAM COMMITTEE Members: Arup Acharya, IBM TJ Watson Research, USA Sudhir Aggarwal, Lucent Technologies, USA Giuseppe Anastasi, University of Pisa, Italy Stefano Basagni, Northeastern University, USA Chatschik Bisdikian, IBM T.J. Watson Research Center, USA Andrew T. Campbell, Columbia University, USA Erdal Cayirci, Georgia Institute of Technology, USA Subir Das, Telcordia Technologies, USA Silvia Giordano, EPFL, Lausanne, Switzerland Philippe Jacquet, INRIA, France Mohan Kumar, University of Texas at Arlington, USA Giridhar Mandyam, Nokia Research, USA Archan Misra IBM T.J. Watson Research Center, USA Hiroyuki Morikawa, University of Tokyo, Japan Sumit Roy, University of Washington, USA Elizabeth M. Belding-Royer, UC Santa Barbara, USA Paul Sanjoy, Bell Laboratories, USA Satish K. Tripathi, University of California at Riverside, USA Andras Valko, Ericsson, Hungary Adam Wolisz, Technical University Berlin, Germany Hee Yong Youn, Sungkyunkwan University, Korea --Boundary_(ID_R0URmeZDbYDQTL51fqdqBw)-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 11:46:36 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12905 for ; Mon, 24 Jun 2002 11:46:35 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04467; Mon, 24 Jun 2002 09:47:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04805; Mon, 24 Jun 2002 08:44:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFhjk7022719 for ; Mon, 24 Jun 2002 08:43:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OFhjKe022718 for mobile-ip-dist; Mon, 24 Jun 2002 08:43:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OFhhk7022711 for ; Mon, 24 Jun 2002 08:43:44 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18366 for ; Mon, 24 Jun 2002 11:43:48 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g5OFhsXA003221 for ; Mon, 24 Jun 2002 11:43:54 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g5OFhs3g003220 for mobile-ip@sunroof.eng.sun.com; Mon, 24 Jun 2002 11:43:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5ODZvk7021235 for ; Mon, 24 Jun 2002 06:35:58 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29798 for ; Mon, 24 Jun 2002 06:36:04 -0700 (PDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06773 for ; Mon, 24 Jun 2002 06:36:02 -0700 (PDT) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 24 Jun 2002 15:34:53 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 15:35:44 +0200 Message-Id: <73D3E97F639DD5119642000347055F0503EB126F@G9JNS.mgb01.telekom.de> From: "Tessier, Serge" To: hans@ipunplugged.com Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] AW: benafits and drawbacks with nat traversal Date: Mon, 24 Jun 2002 15:35:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g5ODZwk7021236 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hasse, NAT is anyway a problem but in the first case ("Mobile IP tunnel in IPSec VPN tunnel") it must be solved by an new solution specific to Mobile IP usage scenario i.e. draft-ietf-mobileip-nat-traversal-04.txt, while in the second case, ("IPSec VPN tunnel in Mobile IP tunnel") it is supposed to be solved by a solution specific to IPSec, i.e. draft-ietf-ipsec-udp-encaps-03.txt. To summarize: In order to do NAT traversal, you have two solutions: IPSec NAT traversal or Mobile IP NAT traversal. The criteria according to which you will choose between both solution depends on the tunneling order (IPsec in Mobile IP or vice-versa) that is, in turn, left to the fantasy of protocols' users. Benefits and drawbacks are here written with regard to Mobile IP. I omited any consideration regarding IPSec NAT traversal problem. It is a subjective approach, which pertinence is debatable. Do you have any idea, if a solution is 'better' (more likely to occur, more scalable, etc.) than the other one? Regards -Serge -----UrsprB8ngliche Nachricht----- Von: Hans SjK4. Juni 2002 14:38 An: Tessier, Serge Cc: mobile-ip Betreff: benafits and drawbacks with nat traversal Serge, Could you explain why implementing NAT traversal with "UDP Encapsulation of IPsec Packets" is an benafit while implementing it with "Mobile IP NAT/NAPT Traversal using UDP Tunnelling" is a drawback? From draft-tessier-mobileip-ipsec-00.txt Figure 1: Mobile IP tunnel in IPSec VPN tunnel While the drawbacks are: - Since local networks use usually private addresses, NAPT is a major problem. A solution like the one described in [7] needs to be applied Figure 2: IPSec VPN tunnel in Mobile IP tunnel The benefits are: - NAPT is not a problem for Mobile IP since it is solved by the IPSec tunnel Regards /// Hasse From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 12:18:30 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15283 for ; Mon, 24 Jun 2002 12:18:29 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04785; Mon, 24 Jun 2002 10:19:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21684; Mon, 24 Jun 2002 09:18:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OGHvk7023061 for ; Mon, 24 Jun 2002 09:17:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OGHu0o023060 for mobile-ip-dist; Mon, 24 Jun 2002 09:17:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OGHrk7023053 for ; Mon, 24 Jun 2002 09:17:53 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21251 for ; Mon, 24 Jun 2002 09:17:59 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12449 for ; Mon, 24 Jun 2002 09:17:58 -0700 (PDT) From: Masataka Ohta Message-Id: <200206241607.BAA16323@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA16323; Tue, 25 Jun 2002 01:07:02 +0900 Subject: Re: [mobile-ip] Draft Agenda for MIP WG @ IETF54 In-Reply-To: <001f01c21b93$720778f0$4f6015ac@T23KEMPF> from James Kempf at "Jun 24, 2002 08:26:00 am" To: James Kempf Date: Tue, 25 Jun 2002 01:07:01 +0859 () CC: Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: jak; > > Which particular layer 2 technology, are you saying, is necessary > > to support smooth handover with two receivers? > > > > There is none and it works with any layer 2 technologies. > I'm sorry, Ohta-san, but it does not. It does not work with cdma2000 and > it does not work with wCDMA. If you think this is so, then please point > to the paragraphs in the spec that say it will. These protocols are > designed to use soft handover with a single Rake receiver on the mobile > station. They are not designed to use two receivers. Huh? W.r.t CDMA, I stated in my draft that: : Note that a CDMA based wireless transceiver can simultaneously use : two access points with different code without additional RF modules. What are you trying to deny? Can you please point to the paragraphs in the spec that say it will need multiple RF modules? > These protocols are > designed to use soft handover As is stated in RFC 1958, : 2.3 It is also generally felt that end-to-end functions can best be : realised by end-to-end protocols. : To quote from [Saltzer], "The function in question can completely and : correctly be implemented only with the knowledge and help of the : application standing at the endpoints of the communication system. : Therefore, providing that questioned function as a feature of the : communication system itself is not possible. (Sometimes an incomplete : version of the function provided by the communication system may be : useful as a performance enhancement.") that some link layer has link specific functionality (such as link soft handover of some CDMA link layer) may be useful as a incomplete performance enchancement (though, in general, performance rather degrades), it is merely allowed as an exception. IP layer solutions can ignore that some link protocol is designed to use soft handover. That CDMA has an imcomplete L2 function does not mean we should not have a complete version at L3. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 12:22:29 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15501 for ; Mon, 24 Jun 2002 12:22:29 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28503; Mon, 24 Jun 2002 10:23:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17039; Mon, 24 Jun 2002 09:21:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OGKkk7023120 for ; Mon, 24 Jun 2002 09:20:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OGKkU0023119 for mobile-ip-dist; Mon, 24 Jun 2002 09:20:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OGKgk7023112 for ; Mon, 24 Jun 2002 09:20:43 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22465 for ; Mon, 24 Jun 2002 09:20:48 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14513 for ; Mon, 24 Jun 2002 09:20:48 -0700 (PDT) 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 JAA20990; Mon, 24 Jun 2002 09:20:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5OGKk124054; Mon, 24 Jun 2002 09:20:46 -0700 X-mProtect: <200206241620> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpd8NPyUa; Mon, 24 Jun 2002 09:20:44 PDT Message-ID: <3D1746DC.8924A227@kniveton.com> Date: Mon, 24 Jun 2002 09:20:44 -0700 From: "T.J. Kniveton" Organization: NOKIA Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: "Hesham Soliman (ERA)" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] confusion about prefix sol/adv References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > > To be able to send these messages, the MN needs > > to have the HA's address. If it knows that, then it > > knows its home address.... > > Do we need to complicate things and have another > > message pair, that are sent with different src > > addresses, and cannot be secured? > > Presumably the IPsec SA used to secure the home BUs could also be > applied to the prefix sol/adv messages. But perhaps the spec doesn't say this. > Should it? > > Erik OK, This is already done. Here is from the description of MPS/MPA on page 63: : If a Security Association for the IP Authentication Header : exists between the sender and the destination address, then the : sender SHOULD include this header. [subject to change] and on p 65: : An AH header MUST be included unless the mobile node has yet to : configure a home address. and on p 103: : To avoid possible security attacks from forged Mobile Prefix : Advertisements all such Advertisements must be authenticated to the : mobile node by its home agent using IPsec [14, 12, 13] if a security : associate exists (i.e. unless the mobile node does not yet have a : home address configured). If someone wants to use IPsex SAs, that's fine..but they have a limitation in selecting the right kind of traffic. As Vijay pointed out, an implementor would probably have to secure ALL ICMP traffic. The alternative is to create a new mobility header type, which it seems too late to do now. The spec, as written, will work fine. If someone wants to send unsecured MPS, the HA can decide its security policy as to whether to respond to an unauthenticated host. If an MN wants to configure its HA and *then* send an MPS, it is free to do this as well, just like Hesham suggested. In this case, the MN might not want to send an MPS, and just be content to know only one prefix. That is a valid choice as well (though it may get unsolicited MPAs and must know how to process them). -- T.J. Kniveton Communications Systems Lab Nokia Research Center From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 12:57:29 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17515 for ; Mon, 24 Jun 2002 12:57:29 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08262; Mon, 24 Jun 2002 09:57:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06651; Mon, 24 Jun 2002 09:57:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OGu9k7023355 for ; Mon, 24 Jun 2002 09:56:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OGu97C023354 for mobile-ip-dist; Mon, 24 Jun 2002 09:56:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OGu5k7023347 for ; Mon, 24 Jun 2002 09:56:05 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06249 for ; Mon, 24 Jun 2002 09:56:11 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05838 for ; Mon, 24 Jun 2002 09:56:10 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA26055 for ; Mon, 24 Jun 2002 09:56:10 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA14844 for ; Mon, 24 Jun 2002 09:56:10 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 24 Jun 2002 11:56:10 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Masataka Ohta'" , James Kempf Cc: Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Draft Agenda for MIP WG @ IETF54 Date: Mon, 24 Jun 2002 11:56:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Masatak-san, Sorry for jumping in the middle. Please find my in-line reply. regards, ajoy -----Original Message----- From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] Sent: Monday, June 24, 2002 11:08 AM To: James Kempf Cc: Basavaraj.Patil@nokia.com; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Draft Agenda for MIP WG @ IETF54 jak; > > Which particular layer 2 technology, are you saying, is necessary > > to support smooth handover with two receivers? > > > > There is none and it works with any layer 2 technologies. > I'm sorry, Ohta-san, but it does not. It does not work with cdma2000 and > it does not work with wCDMA. If you think this is so, then please point > to the paragraphs in the spec that say it will. These protocols are > designed to use soft handover with a single Rake receiver on the mobile > station. They are not designed to use two receivers. Huh? W.r.t CDMA, I stated in my draft that: : Note that a CDMA based wireless transceiver can simultaneously use : two access points with different code without additional RF modules. What are you trying to deny? Ajoy-> CDMA does not provide multiple simultaneous IP accesses. In soft-handoff, a terminal sends multiple copies of same radio frame to the selector via different base stations. The selector chooses the best frame from the multiple copies of the received frame. Can you please point to the paragraphs in the spec that say it will need multiple RF modules? > These protocols are > designed to use soft handover As is stated in RFC 1958, : 2.3 It is also generally felt that end-to-end functions can best be : realised by end-to-end protocols. : To quote from [Saltzer], "The function in question can completely and : correctly be implemented only with the knowledge and help of the : application standing at the endpoints of the communication system. : Therefore, providing that questioned function as a feature of the : communication system itself is not possible. (Sometimes an incomplete : version of the function provided by the communication system may be : useful as a performance enhancement.") that some link layer has link specific functionality (such as link soft handover of some CDMA link layer) may be useful as a incomplete performance enchancement (though, in general, performance rather degrades), it is merely allowed as an exception. Ajoy-> Could you please elaborate how soft-handoff degrades the performance? IP layer solutions can ignore that some link protocol is designed to use soft handover. Ajoy-> I guess IP layer solution must not assume that a terminal will always have multiple transmitters/receivers. This may work in your case, but will not work in most of the cases where no such provision is available. That CDMA has an imcomplete L2 function does not mean we should not have a complete version at L3. Ajoy-> What do you mean? Could you please elaborate? Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 14:24:36 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22599 for ; Mon, 24 Jun 2002 14:24:35 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01201; Mon, 24 Jun 2002 11:24:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01881; Mon, 24 Jun 2002 11:24:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OIN5k7023663 for ; Mon, 24 Jun 2002 11:23:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OIN5ri023662 for mobile-ip-dist; Mon, 24 Jun 2002 11:23:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OIN2k7023655 for ; Mon, 24 Jun 2002 11:23:02 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01476 for ; Mon, 24 Jun 2002 11:23:06 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16715 for ; Mon, 24 Jun 2002 12:23:06 -0600 (MDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5OILcoP049344; Mon, 24 Jun 2002 14:21:38 -0400 Received: from d03nm801.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g5OILaN86006; Mon, 24 Jun 2002 12:21:36 -0600 Subject: Re: Issue #43 (was, Re: [mobile-ip] Re: MIPv6 - 17 Review) To: "Charles E. Perkins" Cc: charliep@darkstar.iprg.nokia.com, jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com, PRoberts@megisto.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Mon, 24 Jun 2002 11:17:50 -0700 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 5.0.10 |March 22, 2002) at 06/24/2002 12:21:36 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Charlie, I feel that if the availability of nonvolatile storage should be a factor in determining the lifetime, the following method would work better : If non-volatile storage is available, use a large value for lifetime (which is the same as described in the draft, eg something in the range of many hours). Otherwise use smaller values (eg something in the range of many minutes). Keeping a Refresh value is simulating the above algo by giving lower values for a refresh if there is no non-volatile storage , and higher values (full lifetime) if there is a non-volatile storage. Why not remove the field completely and just use the values based on type of storage, and get the same characteristics ? I think that Refresh is not needed for the above mentioned reason, but if the community feels otherwise, I feel an option might make it more cumbersome. In that case it might be better to preserve this field in the BA, instead of making significant changes. Thanks, - KK "Charles E. Perkins" cc: PRoberts@MEGISTO.com, jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com Sent by: Subject: Issue #43 (was, Re: [mobile-ip] Re: MIPv6 - 17 Review) charliep@darkstar.ipr g.nokia.com 06/22/2002 04:51 PM Hello Krishna, The Binding Refresh Request message is useful for cases where the Lifetime is 10 times or dozens of times larger than the expected Refresh interval. The idea was to avoid having the availability of nonvolatile storage at the home agent be a factor when choosing a value for the Lifetime. Thus I think it is useful, but I really think that we will have to wait and see to be sure. Furthermore, if people think that it is useful for only a small percentage of the total number of Binding Updates, then we could reorganize the feature as controlled by an option instead of a field that is present in all Binding Update messages. If this is preferred, I'd like to find out immediately so that we can fix the specification before the deadline. Regards, Charlie P. > 19. Section 10.2 : The para about : > > "- The Refresh field MUST be set to a value less than or equal to" > > Is Refresh useful at all ? I don't believe it is. It seems to imply that > it > helps in the case of the Home Agent crashing and has only a volatile > storage > for the binding cache. But if the Home Agent crashed before the Refresh > > interval is over, the behaviour is identical to the case where the > Refresh > field contains the same value as Lifetime. > > It will be useful only if the HA crashed after the Refresh interval but > before > the Lifetime interval. Hence it is completely useless in most > situations. > > If this can be removed safely, all references need to be removed in the > draft and the Format of the BU section (6.1.8) needs to reflect this. From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 14:58:56 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24682 for ; Mon, 24 Jun 2002 14:58:55 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19284; Mon, 24 Jun 2002 11:59:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28036; Mon, 24 Jun 2002 11:59:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OIvnk7023862 for ; Mon, 24 Jun 2002 11:57:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OIvnVV023861 for mobile-ip-dist; Mon, 24 Jun 2002 11:57:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OIvkk7023854 for ; Mon, 24 Jun 2002 11:57:46 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27509 for ; Mon, 24 Jun 2002 11:57:51 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18538 for ; Mon, 24 Jun 2002 11:57:51 -0700 (PDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5OIvff25601; Mon, 24 Jun 2002 14:57:42 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Jun 2002 14:57:41 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD34716727@zcard0ka.ca.nortel.com> From: "Hongyi Li" To: "'Masataka Ohta'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Draft Agenda for MIP WG @ IETF54 Date: Mon, 24 Jun 2002 14:57:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21BB0.FE1F6B82" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C21BB0.FE1F6B82 Content-Type: text/plain; charset="iso-8859-1" Hi Ohta-san, Apart from intra-WLAN handoff, I do see some value of using two active transceivers to smooth handoffs especially in Inter-technology handoffs such as CDMA2000<->WLAN and UMTS<->WLAN or some new radio technologies like Flash-OFDM. Then, could you please highlight what exactly do you want to standardize and what change is required to existing MIP protocols or MIP can support it by nature. Thanks Hongyi ------_=_NextPart_001_01C21BB0.FE1F6B82 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Draft Agenda for MIP WG @ IETF54

Hi Ohta-san,
  Apart from intra-WLAN handoff, I do see some value of using two active
transceivers to smooth handoffs especially in Inter-technology handoffs
such as CDMA2000<->WLAN and UMTS<->WLAN or some new radio technologies
like Flash-OFDM. Then, could you please highlight what exactly do you
want to standardize and what change is required to existing MIP protocols or
MIP can support it by nature.

Thanks

Hongyi

------_=_NextPart_001_01C21BB0.FE1F6B82-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 24 15:57:04 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27196 for ; Mon, 24 Jun 2002 15:57:04 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04745; Mon, 24 Jun 2002 13:57:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07002; Mon, 24 Jun 2002 12:57:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OJtlk7024009 for ; Mon, 24 Jun 2002 12:55:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5OJtlK4024008 for mobile-ip-dist; Mon, 24 Jun 2002 12:55:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5OJthk7024001 for ; Mon, 24 Jun 2002 12:55:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21794 for ; Mon, 24 Jun 2002 12:55:49 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03439 for ; Mon, 24 Jun 2002 13:55:48 -0600 (MDT) Message-ID: <025201c21bb8$e868a620$4f6015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] Alternative BU Security Protocol Date: Mon, 24 Jun 2002 12:54:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, This weekend, we submited a draft defining an alternative BU security protocol. The protocol uses identity-based cryptography. If you want an early look, the draft can be found at: http://www.nttmcl.com/sec/MobileIP/draft-okazaki-mobileip-abk-00.txt This protocol is intended to be a used as an alternative, and not a replacement, for RR. We believe the performance characteristics are somewhat better than RR and the scalability characteristics are somewhat better than using standard public key cryptography. This draft is an initial version, we have some updates planned but could not get them in prior to the deadline. The protocol has IPR on it, but the IPR is license free for those who play by the rules (essentially the same license as the IBM Photuris protocol which was incorporated into IKE). Thus, it can be implemented Open Source. To that end, if anybody wants to implement it on Linux, you may want to check out Ben Lynn's web site, http://crypto.stanford.edu, which contains an Open Source portable library for id-crypto. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 01:57:56 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14509 for ; Tue, 25 Jun 2002 01:57:55 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11867; Mon, 24 Jun 2002 22:58:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA03568; Mon, 24 Jun 2002 22:58:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5P5uwk7025114 for ; Mon, 24 Jun 2002 22:56:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5P5uwkb025113 for mobile-ip-dist; Mon, 24 Jun 2002 22:56:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5P5usk7025106 for ; Mon, 24 Jun 2002 22:56:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA03375 for ; Mon, 24 Jun 2002 22:57:00 -0700 (PDT) Received: from windass.com ([61.165.80.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA00654 for ; Mon, 24 Jun 2002 23:56:51 -0600 (MDT) Date: Mon, 24 Jun 2002 23:56:51 -0600 (MDT) Message-Id: <200206250556.XAA00654@lukla.Sun.COM> Received: from Egqpugd [192.168.0.30] by windass.com [192.168.0.240] with SMTP (MDaemon.v3.5.3.R) for ; Tue, 25 Jun 2002 09:13:02 +0800 From: pcalhoun To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] ͬÒâ²»µÃתÔر¾ÍøÕ¾Ö®ËùÓÐÕÐƸÐÅÏ¢¼°×÷Æ· MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=TM238zh6476NQ08P9zmCpL5c X-MDRemoteIP: 192.168.0.30 X-Return-Path: liugexiao@windass.com X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --TM238zh6476NQ08P9zmCpL5c-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 02:25:17 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23935 for ; Tue, 25 Jun 2002 02:25:17 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28484; Tue, 25 Jun 2002 00:25:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA14516; Mon, 24 Jun 2002 23:25:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5P6OQk7025323 for ; Mon, 24 Jun 2002 23:24:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5P6OQOm025322 for mobile-ip-dist; Mon, 24 Jun 2002 23:24:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5P6OMk7025315 for ; Mon, 24 Jun 2002 23:24:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04924 for ; Mon, 24 Jun 2002 23:24:28 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA10369 for ; Tue, 25 Jun 2002 00:24:27 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5P6ONrU009529; Tue, 25 Jun 2002 08:24:23 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Jun 2002 08:24:23 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0789@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'T.J. Kniveton'" , Erik Nordmark Cc: "Hesham Soliman (ERA)" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] confusion about prefix sol/adv Date: Tue, 25 Jun 2002 08:24:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Presumably the IPsec SA used to secure the home BUs could also be > > applied to the prefix sol/adv messages. But perhaps the > spec doesn't say this. > > Should it? > > > Here is from the description of MPS/MPA on page 63: > > : If a Security Association for the IP Authentication Header > : exists between the sender and the destination > address, then the > : sender SHOULD include this header. [subject to change] > > and on p 65: > > : An AH header MUST be included unless the mobile > node has yet to > : configure a home address. => This is where I don't think the sentence makes sense. How is it possible that the MN does not have a home address, but somehow knows the HA's address? Can someone please explain? Otherwise, I think the rest is fine, use the existing IPsec SA...simple. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 05:22:47 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27396 for ; Tue, 25 Jun 2002 05:22:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03869; Tue, 25 Jun 2002 03:23:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26182; Tue, 25 Jun 2002 02:23:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5P9MPk7025744 for ; Tue, 25 Jun 2002 02:22:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5P9MPMu025743 for mobile-ip-dist; Tue, 25 Jun 2002 02:22:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5P9MMk7025736 for ; Tue, 25 Jun 2002 02:22:22 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA16691 for ; Tue, 25 Jun 2002 02:22:28 -0700 (PDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09320; Tue, 25 Jun 2002 02:22:26 -0700 (PDT) Received: from PTHUBERTW2K2 (dhcp-nic-val-26-104.cisco.com [64.103.26.104]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id LAA09539; Tue, 25 Jun 2002 11:22:15 +0200 (MET DST) From: "Pascal Thubert" To: "Hesham Soliman \(ERA\)" , "'T.J. Kniveton'" , "Erik Nordmark" Cc: Subject: RE: [mobile-ip] confusion about prefix sol/adv Date: Tue, 25 Jun 2002 11:17:57 +0200 Message-ID: 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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0789@Esealnt861.al.sw.ericsson.se> Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Hesham => This is where I don't think the sentence makes sense. How is it possible that the MN does not have a home address, but somehow knows the HA's address? Can someone please explain? - In IPv4, we use the NAI feature to perform a DHCP-like function. I believe this can be extended to v6 in a different draft. Now, it could be possible to use the NAI to index the SA on the HA side, in which case AH is still possible and even required, IMHO Pascal -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Hesham Soliman (ERA) Sent: Tuesday, June 25, 2002 8:24 AM To: 'T.J. Kniveton'; Erik Nordmark Cc: Hesham Soliman (ERA); mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] confusion about prefix sol/adv > > Presumably the IPsec SA used to secure the home BUs could also be > > applied to the prefix sol/adv messages. But perhaps the > spec doesn't say this. > > Should it? > > > Here is from the description of MPS/MPA on page 63: > > : If a Security Association for the IP Authentication Header > : exists between the sender and the destination > address, then the > : sender SHOULD include this header. [subject to change] > > and on p 65: > > : An AH header MUST be included unless the mobile > node has yet to > : configure a home address. => This is where I don't think the sentence makes sense. How is it possible that the MN does not have a home address, but somehow knows the HA's address? Can someone please explain? Otherwise, I think the rest is fine, use the existing IPsec SA...simple. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 05:22:48 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27398 for ; Tue, 25 Jun 2002 05:22:47 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09311; Tue, 25 Jun 2002 02:22:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09535; Tue, 25 Jun 2002 02:22:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5P9LDk7025727 for ; Tue, 25 Jun 2002 02:21:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5P9LDks025726 for mobile-ip-dist; Tue, 25 Jun 2002 02:21:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5P9L9k7025719 for ; Tue, 25 Jun 2002 02:21:09 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5P9LAb15983; Tue, 25 Jun 2002 11:21:10 +0200 (MEST) Date: Tue, 25 Jun 2002 11:19:49 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] confusion about prefix sol/adv To: "T.J. Kniveton" Cc: Erik Nordmark , "Hesham Soliman (ERA)" , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3D1746DC.8924A227@kniveton.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > If someone wants to use IPsex SAs, that's fine..but they have a limitation in > selecting the right kind of traffic. As Vijay pointed out, an implementor > would probably have to secure ALL ICMP traffic. The alternative is to create > a new mobility header type, which it seems too late to do now. Or rely on IPsec implementations which can use the ICMP type as a selector? I don't know how many implementations do this, and I haven't thought about the interoperability issues when one of HA/MN supports it and the other does not - perhaps it could be an optional thing when the HA/MN relationship is created? Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 06:18:36 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28193 for ; Tue, 25 Jun 2002 06:18:35 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15586; Tue, 25 Jun 2002 03:18:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25827; Tue, 25 Jun 2002 03:18:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PAHPk7025954 for ; Tue, 25 Jun 2002 03:17:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PAHPLr025953 for mobile-ip-dist; Tue, 25 Jun 2002 03:17:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PAHLk7025946 for ; Tue, 25 Jun 2002 03:17:21 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5PAHKb21814; Tue, 25 Jun 2002 12:17:20 +0200 (MEST) Date: Tue, 25 Jun 2002 12:16:00 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [mobile-ip] confusion about prefix sol/adv To: Pascal Thubert Cc: "Hesham Soliman (ERA)" , "'T.J. Kniveton'" , Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > - In IPv4, we use the NAI feature to perform a DHCP-like function. I believe > this can be extended to v6 in a different draft. Now, it could be possible to > use the NAI to index the SA on the HA side, in which case AH is still > possible and even required, IMHO Looking forward to your draft specifying all of this. Until then I don't see why we should let this concern clutter the spec. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 07:03:06 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29526 for ; Tue, 25 Jun 2002 07:03:06 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19458; Tue, 25 Jun 2002 05:03:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA25674; Tue, 25 Jun 2002 04:03:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PB2Vk7026110 for ; Tue, 25 Jun 2002 04:02:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PB2VRl026109 for mobile-ip-dist; Tue, 25 Jun 2002 04:02:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PB2Rk7026102 for ; Tue, 25 Jun 2002 04:02:27 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22573 for ; Tue, 25 Jun 2002 04:02:31 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18812 for ; Tue, 25 Jun 2002 05:02:31 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29228; Tue, 25 Jun 2002 07:01:47 -0400 (EDT) Message-Id: <200206251101.HAA29228@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-gwon-mobileip-efwd-fmipv6-00.txt Date: Tue, 25 Jun 2002 07:01:47 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Enhanced Forwarding From Previous Care-of Address For Fast Mobile IPv6 Handovers (eFWD) Author(s) : Y. Gwon, A. Yegin Filename : draft-gwon-mobileip-efwd-fmipv6-00.txt Pages : Date : 24-Jun-02 This document introduces a low latency and low loss handover protocol that enhances the performance of forwarding from previous care-of address for Mobile IPv6, namely eFWD. The eFWD allows a mobile node to control and initiate creation of a bi-directional tunnel between the old and the new access routers subsequent to link layer handover. The eFWD handover reduces IP handover latency by eliminating new care-of address acquisition time and by identifying new access router information in advance utilizing Candidate Access Router Information Discovery (CARID) process detailed in this document. The eFWD protocol removes extra burden on link layer by eliminating any requirement on pre-triggers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gwon-mobileip-efwd-fmipv6-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-gwon-mobileip-efwd-fmipv6-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-gwon-mobileip-efwd-fmipv6-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: <20020624143714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gwon-mobileip-efwd-fmipv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-gwon-mobileip-efwd-fmipv6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020624143714.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 07:03:32 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29640 for ; Tue, 25 Jun 2002 07:03:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19746; Tue, 25 Jun 2002 05:04:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA02698; Tue, 25 Jun 2002 04:04:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PB30k7026120 for ; Tue, 25 Jun 2002 04:03:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PB306v026119 for mobile-ip-dist; Tue, 25 Jun 2002 04:03:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PB2sk7026112 for ; Tue, 25 Jun 2002 04:02:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA25556 for ; Tue, 25 Jun 2002 04:02:58 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA28383 for ; Tue, 25 Jun 2002 05:02:57 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29318; Tue, 25 Jun 2002 07:02:14 -0400 (EDT) Message-Id: <200206251102.HAA29318@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-yegin-l2-triggers-00.txt Date: Tue, 25 Jun 2002 07:02:14 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Link-layer Triggers Protocol Author(s) : A. Yegin Filename : draft-yegin-l2-triggers-00.txt Pages : 12 Date : 24-Jun-02 Wireless and mobile hosts are subject to changing their point of attachment from one access network to another. These changes result in link-layer events such as link up and link down. Information on these events can be conveyed to interested parties in the form of link-layer triggers. Primary consumers of this information are the modules implementing mobility related network-layer protocols. When provider and consumer of this information are co-located on the same IP node, required communication can take place via internal mechanisms. But when they are separate, as in the case of networks using wired-to-wireless bridges, a transport mechanism is needed to convey link-layer triggers. This draft defines a UDP based client- server protocol for transporting link-layer triggers between two IP nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yegin-l2-triggers-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-yegin-l2-triggers-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-yegin-l2-triggers-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: <20020624143817.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yegin-l2-triggers-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-yegin-l2-triggers-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020624143817.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 07:28:16 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00644 for ; Tue, 25 Jun 2002 07:28:15 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13868; Tue, 25 Jun 2002 04:28:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05785; Tue, 25 Jun 2002 04:28:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PBR6k7026416 for ; Tue, 25 Jun 2002 04:27:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PBR6oN026415 for mobile-ip-dist; Tue, 25 Jun 2002 04:27:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PBR2k7026408 for ; Tue, 25 Jun 2002 04:27:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05591 for ; Tue, 25 Jun 2002 04:27:07 -0700 (PDT) Received: from Mistralsoftware.com (ptil-243-146-ban.primus-india.net [203.196.146.243] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA06503 for ; Tue, 25 Jun 2002 05:27:04 -0600 (MDT) Received: from anji [192.168.15.19] by mistralsoftware.com [192.168.10.12] with SMTP (MDaemon.PRO.v5.0.0.R) for ; Tue, 25 Jun 2002 17:09:54 +0530 Message-ID: <00aa01c21c3a$f2d06620$130fa8c0@anji> From: "Anjaneyulu" To: , Subject: [mobile-ip] Move Detection??????? Date: Tue, 25 Jun 2002 16:55:02 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A7_01C21C69.0C6A1DA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.15.19 X-Return-Path: anjaneyulu@mistralsoftware.com X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00A7_01C21C69.0C6A1DA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, When MN is performing Move Detection on the basis of Prefix advertised = by the router and moves from one foreign network to new foreign network = , when he should invalidate the prefixes obtained in a particular = foreign network i.e old one???(there are more than one prefix being = advertised in a network). Can u give scenario explaining the move detection????? Regards, Anj ------=_NextPart_000_00A7_01C21C69.0C6A1DA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
When  MN is performing Move = Detection on the=20 basis of Prefix advertised by the router and moves from one foreign=20 network to new foreign network , when he should invalidate the = prefixes obtained in a particular foreign network i.e old one???(there = are more=20 than one prefix being advertised in a network).
 
Can u give scenario explaining the move = detection?????
 
Regards,
Anj
 
 
------=_NextPart_000_00A7_01C21C69.0C6A1DA0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 08:37:49 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02910 for ; Tue, 25 Jun 2002 08:37:49 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00276; Tue, 25 Jun 2002 06:38:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA15490; Tue, 25 Jun 2002 05:38:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PCb6k7026671 for ; Tue, 25 Jun 2002 05:37:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PCb6UG026670 for mobile-ip-dist; Tue, 25 Jun 2002 05:37:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PCb2k7026663 for ; Tue, 25 Jun 2002 05:37:03 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA19100 for ; Tue, 25 Jun 2002 05:37:07 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27659 for ; Tue, 25 Jun 2002 06:37:06 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id B7C186A905; Tue, 25 Jun 2002 15:36:59 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B501D6A904; Tue, 25 Jun 2002 15:36:57 +0300 (EEST) Message-ID: <3D186441.3030409@kolumbus.fi> Date: Tue, 25 Jun 2002 15:38:25 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Anjaneyulu Cc: mobile-ip@sunroof.eng.sun.com, vijayd@iprg.nokia.com Subject: Re: [mobile-ip] Move Detection??????? References: <00aa01c21c3a$f2d06620$130fa8c0@anji> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.5 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,SUBJ_HAS_Q_MARK,TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: * Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Anjaneyulu wrote: > When MN is performing Move Detection on the basis of Prefix advertised > by the router and moves from one foreign network to new foreign > network , when he should invalidate the prefixes obtained in a > particular foreign network i.e old one???(there are more than one prefix > being advertised in a network). Immediately, if the the MN does not establish forwarding from a previous care-of address. The spec doesn't say what lifetime to assume when the MN does establish such forwarding. However, the BA message received as a response from the temporary HA has a Lifetime field, which the HA is expected to fill with a reasonable value. In any case, forwarding from a previous care-of address has a limited usefulness period, far smaller than typical prefix lifetimes. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 09:35:48 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05224 for ; Tue, 25 Jun 2002 09:35:47 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24558; Tue, 25 Jun 2002 06:35:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23679; Tue, 25 Jun 2002 06:35:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PDYEk7026883 for ; Tue, 25 Jun 2002 06:34:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PDYDcv026882 for mobile-ip-dist; Tue, 25 Jun 2002 06:34:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PDYAk7026875 for ; Tue, 25 Jun 2002 06:34:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23272 for ; Tue, 25 Jun 2002 06:34:15 -0700 (PDT) Received: from Mistralsoftware.com (ptil-243-146-ban.primus-india.net [203.196.146.243] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24146 for ; Tue, 25 Jun 2002 07:34:12 -0600 (MDT) Received: from anji [192.168.15.19] by mistralsoftware.com [192.168.10.12] with SMTP (MDaemon.PRO.v5.0.0.R) for ; Tue, 25 Jun 2002 19:17:29 +0530 Message-ID: <00c701c21c4c$c579eef0$130fa8c0@anji> From: "Anjaneyulu" To: "Jari Arkko" Cc: , References: <00aa01c21c3a$f2d06620$130fa8c0@anji> <3D186441.3030409@kolumbus.fi> Subject: Re: [mobile-ip] Move Detection??????? Date: Tue, 25 Jun 2002 19:02:37 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.15.19 X-Return-Path: anjaneyulu@mistralsoftware.com X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, But how to distinguish between the prefixes advertised i.e. whether they are received in the same foreign network or different???? Case1 ====== MN really moved to new FN but there are already some prefixes and default routers (detected in old FN). In the new FN, the old default routers are invalid. So how to detect which one to invalidate. Case 2 ===== MN is in same FN and receives a new prefix and default router. Then all the other entries belonging to that FN are valid. ----- Original Message ----- From: "Jari Arkko" To: "Anjaneyulu" Cc: ; Sent: Tuesday, June 25, 2002 6:08 PM Subject: Re: [mobile-ip] Move Detection??????? > Anjaneyulu wrote: > > > > When MN is performing Move Detection on the basis of Prefix advertised > > by the router and moves from one foreign network to new foreign > > network , when he should invalidate the prefixes obtained in a > > particular foreign network i.e old one???(there are more than one prefix > > being advertised in a network). > > > Immediately, if the the MN does not establish forwarding from > a previous care-of address. > > The spec doesn't say what lifetime to assume when the MN does > establish such forwarding. However, the BA message received > as a response from the temporary HA has a Lifetime field, > which the HA is expected to fill with a reasonable value. > > In any case, forwarding from a previous care-of address has > a limited usefulness period, far smaller than typical prefix > lifetimes. > > Jari > > From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 10:07:26 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06319 for ; Tue, 25 Jun 2002 10:07:25 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11554; Tue, 25 Jun 2002 07:07:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00485; Tue, 25 Jun 2002 07:07:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PE67k7027012 for ; Tue, 25 Jun 2002 07:06:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PE67Mr027011 for mobile-ip-dist; Tue, 25 Jun 2002 07:06:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PE63k7027004 for ; Tue, 25 Jun 2002 07:06:03 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06406 for ; Tue, 25 Jun 2002 07:06:07 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09429 for ; Tue, 25 Jun 2002 08:06:04 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id XAA23553; Tue, 25 Jun 2002 23:04:50 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id XAA01215; Tue, 25 Jun 2002 23:04:49 +0900 (JST) Date: Tue, 25 Jun 2002 23:03:48 +0900 (JST) Message-Id: <20020625.230348.83112376.keiichi@iij.ad.jp> To: anjaneyulu@mistralsoftware.com Cc: jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com, vijayd@iprg.nokia.com Subject: Re: [mobile-ip] Move Detection??????? From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <00c701c21c4c$c579eef0$130fa8c0@anji> References: <00aa01c21c3a$f2d06620$130fa8c0@anji> <3D186441.3030409@kolumbus.fi> <00c701c21c4c$c579eef0$130fa8c0@anji> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Anjaneyulu, From "Anjaneyulu" > But how to distinguish between the prefixes advertised i.e. whether they are > received in the same foreign network or different???? > Case1 > ====== > MN really moved to new FN but there are already some prefixes and default > routers (detected in old FN). In the new FN, the old default routers are > invalid. So how to detect which one to invalidate. > > Case 2 > ===== > MN is in same FN and receives a new prefix and default router. Then all the > other entries belonging to that FN are valid. One example: In our IPv6 implementation, we hold the prefix information with the list of routers which advertises the prefix. If we have really moved to another network, the old routers become unreach. The prefixes which have no routers reachble become DETACHED (this is our term, which means that the prefix is no more usable because there is no routers which advertises the prefix). The addresses which have a DETACHED prefix are less preferable than other addresses. We detect movement if the old CoA becomes DETACHED and there are another CoA available. Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 10:56:28 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08744 for ; Tue, 25 Jun 2002 10:56:28 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07552; Tue, 25 Jun 2002 08:57:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23719; Tue, 25 Jun 2002 07:56:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PEtvk7027218 for ; Tue, 25 Jun 2002 07:55:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PEtvDH027217 for mobile-ip-dist; Tue, 25 Jun 2002 07:55:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PEtsk7027210 for ; Tue, 25 Jun 2002 07:55:54 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12673 for ; Tue, 25 Jun 2002 07:55:58 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21712 for ; Tue, 25 Jun 2002 07:55:58 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5PEu9g07944; Tue, 25 Jun 2002 09:56:10 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Jun 2002 09:55:55 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E045ABC48@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Behcet Sarikaya , "Ahmad Muhanna" Cc: "'mobile-ip'" Subject: RE: [mobile-ip] New Draft: draft-muhanna-mobileip-compat-00.txt Date: Tue, 25 Jun 2002 09:55:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21C58.65977640" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C21C58.65977640 Content-Type: text/plain; charset="iso-8859-1" Behcet, Thanks for the initial comment but the ID is intended to address some of the backward compatibility loop issues when the tag length value extension mechanism becomes too cumbersome or results in excessive bloat. The version extension allows the values of tags to change over versions as well as tags to be re-used when obsoleted. The version can also be used to set rules for specific tags that are compatible with a particular version. I'm not sure if SNMP can achieve the same thing but after you have read the draft, please detail how SNMP could be used to achieve the same functions if you still believe it is a workable solution. Note that in some form-factor nodes the use of SNMP is not warranted or desireable. Thanks again, Glenn -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Friday, June 21, 2002 1:46 PM To: Muhanna, Ahmad [RICH1:2Q20:EXCH] Cc: 'mobile-ip' Subject: Re: [mobile-ip] New Draft: draft-muhanna-mobileip-compat-00.txt Ahmad, I have not read your draft but from the abstract this sounds like something that can be done with MIB, although it would probably be static. Have you formulated the change as a modified MIB? Then SNMP would solve your problem. If you are proposing further changes to MIPv4 then this might take us into a backward compatibility loop. Regards, Ahmad Muhanna wrote: Hello all, In response to the need of a dynamic mechanism as part of Mobile IPv4 registration to synchronize the version of the standards used by all Mobile IPv4 entities, I have submitted a new draft to the Mobile IP WG with the following abstract: Abstract Mobile-IP, together with several other supporting standards such as Reverse Tunneling and the Challenge-Response extensions, have all been recently revised. Although such revisions are for the most part backward compatible with the original versions, sometimes static configuration of Mobile Nodes and Mobility Agents is required to ensure smooth transition and avoid any possible conflict between different standard versions implemented by already-deployed equipment. In this draft we define compatibility extensions for Mobile-IP Agent Advertisement, Registration Request and Registration Reply messages that allow all Mobile-IPv4 entities to dynamically synchronize their "compatibility versions", defined as the versions of the Mobile-IP standards that a particular node is able to support. This solution offers a dynamic mechanism which informs all entities involved in a Mobile-IP exchange of the version of the standard they support, therefore reducing the need to statically configure such information at Mobile Nodes or Mobility Agents. Until it shows up in the drafts directory, it is on the co-author Luca Salgarelli web page. To get to it, please use the following link: http://www.bell-labs.com/user/salga/doc/draft-muhanna-mobileip-compat-00.txt Regards; Ahmad Muhanna -- Behcet ------_=_NextPart_001_01C21C58.65977640 Content-Type: text/html; charset="iso-8859-1" New Draft: draft-muhanna-mobileip-compat-00.txt
Behcet,
 
Thanks for the initial comment but the ID is intended to address some of the backward compatibility loop issues when the tag length value extension mechanism becomes too cumbersome or results in excessive bloat. The version extension allows the values of tags to change over versions as well as tags to be re-used when obsoleted. The version can also be used to set rules for specific tags that are compatible with a particular version.  I'm not sure if SNMP can achieve the same thing but after you have read the draft, please detail how SNMP could be used to achieve the same functions if you still believe it is a workable solution. Note that in some form-factor nodes the use of SNMP is not warranted or desireable.
 
Thanks again,
 
Glenn
-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Friday, June 21, 2002 1:46 PM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
Cc: 'mobile-ip'
Subject: Re: [mobile-ip] New Draft: draft-muhanna-mobileip-compat-00.txt

Ahmad,
  I have not read your draft but from the abstract this sounds like something that can be done with MIB, although it would probably be static. Have you formulated the change as a modified MIB? Then SNMP would solve your problem.
  If you are proposing further changes to MIPv4 then this might take us into a backward compatibility loop.
Regards,

Ahmad Muhanna wrote:

Hello all,

In response to the need of a dynamic mechanism as part of Mobile IPv4
registration to synchronize the version of the standards used by all
Mobile IPv4 entities, I have submitted a new draft to the Mobile IP
WG with the following abstract:

Abstract

   Mobile-IP, together with several other supporting standards such
   as Reverse Tunneling and the Challenge-Response extensions, have
   all been recently revised.  Although such revisions are for the
   most part backward compatible with the original versions,
   sometimes static configuration of Mobile Nodes and Mobility Agents
   is required to ensure smooth transition and avoid any possible
   conflict between different standard versions implemented by
   already-deployed equipment.  In this draft we define compatibility
   extensions for Mobile-IP Agent Advertisement, Registration Request
   and Registration Reply messages that allow all Mobile-IPv4
   entities to dynamically synchronize their "compatibility
   versions", defined as the versions of the Mobile-IP standards that
   a particular node is able to support.  This solution offers a
   dynamic mechanism which informs all entities involved in a
   Mobile-IP exchange of the version of the standard they support,
   therefore reducing the need to statically configure such
   information at Mobile Nodes or Mobility Agents.


Until it shows up in the drafts directory, it is on the co-author Luca Salgarelli web
page. To get to it, please use the following link:

http://www.bell-labs.com/user/salga/doc/draft-muhanna-mobileip-compat-00.txt


Regards;
Ahmad Muhanna


-- 
Behcet

------_=_NextPart_001_01C21C58.65977640-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 10:58:30 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08896 for ; Tue, 25 Jun 2002 10:58:30 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14682; Tue, 25 Jun 2002 08:59:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24538; Tue, 25 Jun 2002 07:59:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PEwAk7027277 for ; Tue, 25 Jun 2002 07:58:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PEwADD027276 for mobile-ip-dist; Tue, 25 Jun 2002 07:58:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PEw6k7027263 for ; Tue, 25 Jun 2002 07:58:06 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13530 for ; Tue, 25 Jun 2002 07:58:10 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08361 for ; Tue, 25 Jun 2002 08:58:10 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g5PEw5P16798; Tue, 25 Jun 2002 09:58:05 -0500 (CDT) Message-ID: <3D18851C.3080506@alcatel.com> Date: Tue, 25 Jun 2002 09:58:36 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Scott Bradner , Allison Mankin , Carl Williams , Phil Neumiller Subject: Re: [mobile-ip] I-D ACTION:draft-yegin-l2-triggers-00.txt References: <200206251102.HAA29318@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit This draft is within the scope of Layer 2 Triggers BOF (l2tg). Please see the present and draft charter for this proposed work at: http://pages.sbcglobal.net/bsarikaya/publications/l2triggers.txt Regards, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Link-layer Triggers Protocol > Author(s) : A. Yegin > Filename : draft-yegin-l2-triggers-00.txt > Pages : 12 > Date : 24-Jun-02 > >Wireless and mobile hosts are subject to changing their point of >attachment from one access network to another. These changes result >in link-layer events such as link up and link down. Information on >these events can be conveyed to interested parties in the form of >link-layer triggers. Primary consumers of this information are the >modules implementing mobility related network-layer protocols. When >provider and consumer of this information are co-located on the same >IP node, required communication can take place via internal >mechanisms. But when they are separate, as in the case of networks >using wired-to-wireless bridges, a transport mechanism is needed to >convey link-layer triggers. This draft defines a UDP based client- >server protocol for transporting link-layer triggers between two IP >nodes. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-yegin-l2-triggers-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-yegin-l2-triggers-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-yegin-l2-triggers-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. > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 12:10:56 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12762 for ; Tue, 25 Jun 2002 12:10:55 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08891; Tue, 25 Jun 2002 09:11:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07339; Tue, 25 Jun 2002 09:10:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PG9ok7027546 for ; Tue, 25 Jun 2002 09:09:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PG9oNi027545 for mobile-ip-dist; Tue, 25 Jun 2002 09:09:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PG9lk7027538 for ; Tue, 25 Jun 2002 09:09:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12068 for ; Tue, 25 Jun 2002 09:09:52 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08034 for ; Tue, 25 Jun 2002 09:09:48 -0700 (PDT) Message-ID: <00b301c21c62$5d35b9d0$4f6015ac@T23KEMPF> From: "James Kempf" To: "Pascal Thubert" , "Hesham Soliman \(ERA\)" , "'T.J. Kniveton'" , "Erik Nordmark" Cc: References: Subject: Re: [mobile-ip] confusion about prefix sol/adv Date: Tue, 25 Jun 2002 09:07:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > => This is where I don't think the sentence makes sense. How is it possible that > the MN does not have a home address, but somehow knows the HA's address? Can > someone please explain? If it knows the subnet prefix, it can use the HA anycast address for the subnet. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 12:23:03 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13449 for ; Tue, 25 Jun 2002 12:23:02 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01628; Tue, 25 Jun 2002 10:22:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11332; Tue, 25 Jun 2002 09:22:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PGL8k7027674 for ; Tue, 25 Jun 2002 09:21:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PGL8td027673 for mobile-ip-dist; Tue, 25 Jun 2002 09:21:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PGL4k7027666 for ; Tue, 25 Jun 2002 09:21:04 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16343 for ; Tue, 25 Jun 2002 09:21:10 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15381 for ; Tue, 25 Jun 2002 09:21:09 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 458246A905; Tue, 25 Jun 2002 19:21:02 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 892A36A904; Tue, 25 Jun 2002 19:20:45 +0300 (EEST) Message-ID: <3D1898B5.4050206@kolumbus.fi> Date: Tue, 25 Jun 2002 19:22:13 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Krishna Kumar Cc: charliep@darkstar.iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, PRoberts@megisto.com Subject: Re: Issue #43 (was, Re: [mobile-ip] Re: MIPv6 - 17 Review) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Krishna Kumar wrote: > Hi Charlie, > > I feel that if the availability of nonvolatile storage should be a factor > in determining the lifetime, the following method would work better : > > If non-volatile storage is available, use a large value for > lifetime (which is the same as described in the draft, eg > something in the range of many hours). > Otherwise use smaller values (eg something in the range > of many minutes). > > Keeping a Refresh value is simulating the above algo by giving lower > values for a refresh if there is no non-volatile storage , and higher > values (full lifetime) if there is a non-volatile storage. Why not remove > the field completely and just use the values based on type of storage, > and get the same characteristics ? I agree. > I think that Refresh is not needed for the above mentioned reason, but > if the community feels otherwise, I feel an option might make it more > cumbersome. In that case it might be better to preserve this field in the > BA, instead of making significant changes. I agree here as well. My suggestion is that we remove the field. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 12:24:20 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13520 for ; Tue, 25 Jun 2002 12:24:18 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17343; Tue, 25 Jun 2002 09:24:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29911; Tue, 25 Jun 2002 09:24:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PGNQk7027715 for ; Tue, 25 Jun 2002 09:23:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PGNQ76027714 for mobile-ip-dist; Tue, 25 Jun 2002 09:23:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PGNNk7027705 for ; Tue, 25 Jun 2002 09:23:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11788 for ; Tue, 25 Jun 2002 09:23:28 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19736 for ; Tue, 25 Jun 2002 10:23:26 -0600 (MDT) From: Masataka Ohta Message-Id: <200206251558.AAA23213@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA23213; Wed, 26 Jun 2002 00:58:27 +0900 Subject: Re: [mobile-ip] Draft Agenda for MIP WG @ IETF54 In-Reply-To: from Singh Ajoy-ASINGH1 at "Jun 24, 2002 11:56:09 am" To: Singh Ajoy-ASINGH1 Date: Wed, 26 Jun 2002 00:58:26 +0859 () CC: James Kempf , Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: ajoy; > Sorry for jumping in the middle. > Please find my in-line reply. You are welcome. > W.r.t CDMA, I stated in my draft that: > > : Note that a CDMA based wireless transceiver can simultaneously use > : two access points with different code without additional RF modules. > > What are you trying to deny? > > Ajoy-> CDMA does not provide multiple simultaneous IP > accesses. Nor WLAN does, because of interference. But, terminals on the Internet tolerate some packet losses. Moreover, as is written in RFC1958: : (Sometimes an incomplete : version of the function provided by the communication system may be : useful as a performance enhancement.") just as WLAN, a CDMA link layer may deploy CSMA/CA or something like that to reduce probability of packet losses. > In soft-handoff, a terminal sends multiple copies of same > radio frame to the selector via different base stations. > The selector chooses the best frame from the multiple copies > of the received frame. If you are using phone, it is two way streaming communication so that it is OK to asume you have something to send frequently enough. However, if you are receiving voice, music or video stream, there is nothing for the terminal to send so frequently. Of course, terminals without data can generate beacon frames, but, it is a waste of bandwidth. > that some link layer has link specific functionality (such as link > soft handover of some CDMA link layer) may be useful as a incomplete > performance enchancement (though, in general, performance rather > degrades), it is merely allowed as an exception. > > Ajoy-> Could you please elaborate how soft-handoff degrades the performance? It is a generic statement not necessarily applicable to soft-handoff of your CDMA. However, see above. > IP layer solutions can ignore that some link protocol is designed > to use soft handover. > > Ajoy-> I guess IP layer solution must not assume that a > terminal will always have multiple transmitters/receivers. Just as an IP layer solution assume that a terminal has at least one transmitters/receivers, it can assume that a terminal has more than one transmitters/receivers. For example, ICMP redirect assumes that a default router has multiple interfaces. It has nothing to do with whether the solution is at IP or other layer. > This may work in your case, but will not work in most of the cases > where no such provision is available. Assume that a network with no such provision as selector is available, which is the Internet today. If base stations are connected by a private IP network, you can put selectors whereever you wish. But, it is not the case with the Internet. > That CDMA has an imcomplete L2 function does not mean we should > not have a complete version at L3. > > Ajoy-> What do you mean? Could you please elaborate? According to your explanation: > In soft-handoff, a terminal sends multiple copies of same > radio frame to the selector via different base stations. > The selector chooses the best frame from the multiple copies > of the received frame. you assume IP packets to the selector is sent via different base stations. Then, you are assuming that link layer between the selector and the base stations has special L2 header with signal quality information. You also assume terminals have something to send frequently to the selector. That is, your soft-handover is an imcomplete L2 function. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 12:54:39 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15375 for ; Tue, 25 Jun 2002 12:54:39 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24737; Tue, 25 Jun 2002 10:55:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01397; Tue, 25 Jun 2002 09:55:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PGrck7027927 for ; Tue, 25 Jun 2002 09:53:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PGrcOv027926 for mobile-ip-dist; Tue, 25 Jun 2002 09:53:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PGrYk7027919 for ; Tue, 25 Jun 2002 09:53:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00970 for ; Tue, 25 Jun 2002 09:53:40 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28902 for ; Tue, 25 Jun 2002 10:53:39 -0600 (MDT) From: Masataka Ohta Message-Id: <200206251638.BAA23378@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA23378; Wed, 26 Jun 2002 01:38:41 +0900 Subject: Re: [mobile-ip] Draft Agenda for MIP WG @ IETF54 In-Reply-To: <3549C09B853DD5119B540002A52CDD34716727@zcard0ka.ca.nortel.com> from Hongyi Li at "Jun 24, 2002 02:57:31 pm" To: Hongyi Li Date: Wed, 26 Jun 2002 01:38:40 +0859 () CC: mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hongyi; > Hi Ohta-san, Hi, > Apart from intra-WLAN handoff, I do see some value of using two active > transceivers to smooth handoffs especially in Inter-technology handoffs > such as CDMA2000<->WLAN and UMTS<->WLAN or some new radio technologies > like Flash-OFDM. Good point. We actually experimentalily using handover between PHS (in Japan, there is a nation-wide flat-rated PHS service, even though it is at 128Kbps and charged a lot) and WLAN. > Then, could you please highlight what exactly do you > want to standardize and what change is required to existing MIP protocols or > MIP can support it by nature. My draft is a reality check on what protocols are used by the real world with the end to end principle. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 13:02:43 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15915 for ; Tue, 25 Jun 2002 13:02:42 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00081; Tue, 25 Jun 2002 11:03:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28396; Tue, 25 Jun 2002 10:03:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PH2Ik7028035 for ; Tue, 25 Jun 2002 10:02:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PH2HSL028034 for mobile-ip-dist; Tue, 25 Jun 2002 10:02:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PH2Ek7028027 for ; Tue, 25 Jun 2002 10:02:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04398 for ; Tue, 25 Jun 2002 10:02:20 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10078 for ; Tue, 25 Jun 2002 11:02:18 -0600 (MDT) Message-ID: <012d01c21c69$d6f85d20$4f6015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] Historical Correction Date: Tue, 25 Jun 2002 10:00:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I've been informed by private email that my assertion that Photuris was incorporated into IKE was inaccurate and that a more accurate statement was the Photuris influenced the development of IKE. The statement was not meant to imply anything about the history of how IKE developed, nor about the history of the IBM patent, and I really don't want to go into any more detail about it. Suffice to say, when I inquired about the best way to deal with the demand from our IPR department for some way to file IPR on IETF work but nevertheless make it freely available (i.e. without any license) so it was acceptable for IETF standards, I was told by people familiar with IETF IPR that I should model the IPR statement on RFC 1822, which deals with Photuris, so that is what we did. That was all the statement was meant to imply. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 13:18:56 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16702 for ; Tue, 25 Jun 2002 13:18:55 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07965; Tue, 25 Jun 2002 10:19:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25481; Tue, 25 Jun 2002 10:18:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PHHnk7028182 for ; Tue, 25 Jun 2002 10:17:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PHHn0T028181 for mobile-ip-dist; Tue, 25 Jun 2002 10:17:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PHHjk7028174 for ; Tue, 25 Jun 2002 10:17:46 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05656 for ; Tue, 25 Jun 2002 10:17:49 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06975 for ; Tue, 25 Jun 2002 10:17:49 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 49CBB6A906; Tue, 25 Jun 2002 20:17:48 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1705B6A904; Tue, 25 Jun 2002 20:17:40 +0300 (EEST) Message-ID: <3D18A60C.4050702@kolumbus.fi> Date: Tue, 25 Jun 2002 20:19:08 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" , Charlie Perkins Subject: [mobile-ip] Issue 49: Got a new home address, what about the SAs to HA? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit (Originally brought up by Charlie Perkins.) Background: RFC 3041 procedures or the announcement of a new prefix may lead to the creation of a new home address for the mobile node. If the mobile node changes its home address, it has to update its security association with the home agent, as IPsec SAs are dependent on the addresses in the following way: - Home address will be the destination for HA -> MN traffic and used as an SA lookup index - Home address will be used in the SPD entry or selectors that govern the use of the MN -> HA SA. This is problematic in the sense that no such automatic modifications take place for manually configured SAs. Where IKE-based SAs are used, SAs can be renegotiated. Question: Does this need treatment in the specification. If so, what? Proposal: There seems to be multiple ways to deal with this: 1) This isn't an issue, don't use automatic prefix discovery or RFC 3041 if you have manual SAs. Duh. 2) As above, but we should document this restriction in the spec. 3) Have some functionality in the MN/HA to be able to "move" i.e. modify the old SAs to use new addresses. 4) As above, but change the keys at the same time as we move/modify the SAs. The algorithm and whatever else can remain the same, but the shared key ought to change. The new key could be: HMAC_MD5(old_key, new home address). From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 14:58:55 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22957 for ; Tue, 25 Jun 2002 14:58:55 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15227; Tue, 25 Jun 2002 12:59:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18676; Tue, 25 Jun 2002 11:59:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PIw7k7028383 for ; Tue, 25 Jun 2002 11:58:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PIw74k028382 for mobile-ip-dist; Tue, 25 Jun 2002 11:58:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PIw3k7028368 for ; Tue, 25 Jun 2002 11:58:03 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18360 for ; Tue, 25 Jun 2002 11:58:08 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14385 for ; Tue, 25 Jun 2002 12:58:07 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 3C8026A90A; Tue, 25 Jun 2002 21:57:57 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 8BF966A909; Tue, 25 Jun 2002 21:57:42 +0300 (EEST) Message-ID: <3D18BD7F.1030106@piuha.net> Date: Tue, 25 Jun 2002 21:59:11 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Erik Nordmark Cc: "Hesham Soliman (ERA)" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] confusion about prefix sol/adv References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>To be able to send these messages, the MN needs >>to have the HA's address. If it knows that, then it >>knows its home address.... >>Do we need to complicate things and have another >>message pair, that are sent with different src >>addresses, and cannot be secured? > > Presumably the IPsec SA used to secure the home BUs could also be > applied to the prefix sol/adv messages. But perhaps the spec doesn't say this. > Should it? It could. Let's see... we can't use exactly the same SA unless it is going to cover all traffic between the MN and the HA... the SPD entries couldn't deal with two protocol numbers (MH for BUs and ICMPv6 for the prefix sol/advs). So we are likely to need two SA pairs but they could of course be set up at the same time and with similar SPD entries, with the exception of the protocol number. The traffic to be secured would be [hoa -> ha: icmpv6] and [ha <- hoa: icmpv6]. > The spec, as written, will work fine. If someone wants to send unsecured MPS, > the HA can decide its security policy as to whether to respond to an > unauthenticated host. If an MN wants to configure its HA and *then* send an > MPS, it is free to do this as well, just like Hesham suggested. In this case, > the MN might not want to send an MPS, and just be content to know only one > prefix. That is a valid choice as well (though it may get unsolicited MPAs and > must know how to process them). This is all true, but I'm a bit uncomfortable with this much freedom. Can we reduce it somehow, to ensure interoperability and reduce the necessary alternative things that implementations must deal with? One thing that may be missing is stating the implied limitations. Perhaps we could state that the sol/adv MUST be secured at all times using the above schemes, which means that either (a) you must have one home address to begin with or (b) you must have key management. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 15:09:54 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23539 for ; Tue, 25 Jun 2002 15:09:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10707; Tue, 25 Jun 2002 12:10:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22772; Tue, 25 Jun 2002 12:09:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PJ8fk7028511 for ; Tue, 25 Jun 2002 12:08:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PJ8ffP028510 for mobile-ip-dist; Tue, 25 Jun 2002 12:08:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PJ8ck7028503 for ; Tue, 25 Jun 2002 12:08:38 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22538 for ; Tue, 25 Jun 2002 12:08:43 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09918; Tue, 25 Jun 2002 12:08:42 -0700 (PDT) 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 MAA01032; Tue, 25 Jun 2002 12:08:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5PJ8Yn10439; Tue, 25 Jun 2002 12:08:34 -0700 X-mProtect: <200206251908> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdR2cR4x; Tue, 25 Jun 2002 12:08:32 PDT Message-ID: <3D18BFB1.B4B6B8CF@iprg.nokia.com> Date: Tue, 25 Jun 2002 12:08:33 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: "'T.J. Kniveton'" , Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] confusion about prefix sol/adv References: <4DA6EA82906FD511BE2F00508BCF0538044F0789@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Hesham Soliman (ERA)" wrote: > Otherwise, I think the rest is fine, use the > existing IPsec SA...simple. just a clarification. there is no existing IPsec SA. this is another SA. the existing IPsec is only for protecting Mobility Header traffic between the MN and HA. there has to be a separate SA for protecting the ICMP traffic between MN and HA. Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 16:43:17 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27991 for ; Tue, 25 Jun 2002 16:43:16 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10032; Tue, 25 Jun 2002 13:43:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17260; Tue, 25 Jun 2002 13:43:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PKgGk7028681 for ; Tue, 25 Jun 2002 13:42:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PKgFH5028680 for mobile-ip-dist; Tue, 25 Jun 2002 13:42:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PKgCk7028673 for ; Tue, 25 Jun 2002 13:42:12 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16130 for ; Tue, 25 Jun 2002 13:42:18 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09342 for ; Tue, 25 Jun 2002 13:42:18 -0700 (PDT) Message-ID: <02ae01c21c88$8a4eb860$4f6015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" , , "Charlie Perkins" References: <3D18A60C.4050702@kolumbus.fi> Subject: Re: [mobile-ip] Issue 49: Got a new home address, what about the SAs to HA? Date: Tue, 25 Jun 2002 13:40:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari, IMHO, I'd say 2). We don't need to introduce any additional mechanism, but people should be warned. jak ----- Original Message ----- From: "Jari Arkko" To: ; "Charlie Perkins" Sent: Tuesday, June 25, 2002 10:19 AM Subject: [mobile-ip] Issue 49: Got a new home address, what about the SAs to HA? > (Originally brought up by Charlie Perkins.) > > Background: RFC 3041 procedures or the announcement of a new prefix > may lead to the creation of a new home address for the mobile node. > If the mobile node changes its home address, it has to update its > security association with the home agent, as IPsec SAs are dependent > on the addresses in the following way: > > - Home address will be the destination for HA -> MN traffic and > used as an SA lookup index > - Home address will be used in the SPD entry or selectors that govern > the use of the MN -> HA SA. > > This is problematic in the sense that no such automatic modifications > take place for manually configured SAs. Where IKE-based SAs are used, > SAs can be renegotiated. > > Question: Does this need treatment in the specification. If so, what? > > Proposal: There seems to be multiple ways to deal with this: > > 1) This isn't an issue, don't use automatic prefix discovery > or RFC 3041 if you have manual SAs. Duh. > > 2) As above, but we should document this restriction in the spec. > > 3) Have some functionality in the MN/HA to be able to "move" i.e. > modify the old SAs to use new addresses. > > 4) As above, but change the keys at the same time as we move/modify > the SAs. The algorithm and whatever else can remain the same, but the > shared key ought to change. The new key could be: HMAC_MD5(old_key, > new home address). > > From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 17:46:04 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00178 for ; Tue, 25 Jun 2002 17:46:04 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13699; Tue, 25 Jun 2002 15:46:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10214; Tue, 25 Jun 2002 14:46:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PLjUk7028821 for ; Tue, 25 Jun 2002 14:45:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PLjUkW028820 for mobile-ip-dist; Tue, 25 Jun 2002 14:45:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PLjRk7028813 for ; Tue, 25 Jun 2002 14:45:27 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12099 for ; Tue, 25 Jun 2002 14:45:31 -0700 (PDT) Received: from rajma.kniveton.com (adsl-209-204-158-88.sonic.net [209.204.158.88]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21340; Tue, 25 Jun 2002 15:45:30 -0600 (MDT) Received: from [192.168.1.42] (atlantis.kniveton.com [192.168.1.42]) by rajma.kniveton.com (8.12.3/8.11.1) with ESMTP id g5PLkPJU023648; Tue, 25 Jun 2002 14:46:26 -0700 (PDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.0.4 Date: Tue, 25 Jun 2002 14:45:27 -0700 Subject: Re: [mobile-ip] confusion about prefix sol/adv From: "T.J. Kniveton" To: "Hesham Soliman (ERA)" , Erik Nordmark CC: Message-ID: In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0789@Esealnt861.al.sw.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: "Hesham Soliman (ERA)" > Date: Tue, 25 Jun 2002 08:24:22 +0200 > To: "'T.J. Kniveton'" , Erik Nordmark > Cc: "Hesham Soliman (ERA)" , > mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] confusion about prefix sol/adv > > >>> Presumably the IPsec SA used to secure the home BUs could also be >>> applied to the prefix sol/adv messages. But perhaps the >> spec doesn't say this. >>> Should it? > >>> >> Here is from the description of MPS/MPA on page 63: >> >> : If a Security Association for the IP Authentication Header >> : exists between the sender and the destination >> address, then the >> : sender SHOULD include this header. [subject to change] >> >> and on p 65: >> >> : An AH header MUST be included unless the mobile >> node has yet to >> : configure a home address. > > => This is where I don't think the sentence makes > sense. How is it possible that the MN does not > have a home address, but somehow knows the > HA's address? Can someone please explain? Sure. If you have read Appendix A, or any of the MIP-list conversations about MPS/MPA and bootstrapping, then it does make sense: for any node that wants to store a minimum amount of info, it can use DNS, DHAD, and MPS to configure itself. After it has done DHAD, it knows all the home agents on the home link..but has not configured its own address. It sends an MPS with the CoA as source address. > > Otherwise, I think the rest is fine, use the > existing IPsec SA...simple. Not quite so simple -- there is no existing SA for securing ICMP traffic, so one would need to be established. It would be simpler not to use IPsec. > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 17:51:21 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00443 for ; Tue, 25 Jun 2002 17:51:20 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15740; Tue, 25 Jun 2002 14:51:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14685; Tue, 25 Jun 2002 14:51:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PLoRk7028940 for ; Tue, 25 Jun 2002 14:50:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5PLoRuG028939 for mobile-ip-dist; Tue, 25 Jun 2002 14:50:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5PLoOk7028932 for ; Tue, 25 Jun 2002 14:50:24 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14609 for ; Tue, 25 Jun 2002 14:50:28 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15240 for ; Tue, 25 Jun 2002 14:50:28 -0700 (PDT) Message-ID: <044301c21c92$12baa520$4f6015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" , Cc: "Samita Chakrabarti" , References: <3D11F3CB.8050700@kolumbus.fi> Subject: Re: [mobile-ip] Sub: Identifying link changes Date: Tue, 25 Jun 2002 14:48:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I suppose there'd be three ways out of this. > > 1) Make the forwarding-from-previous-coa work well. That is, we'd need to > solve the DAD problem. Apperently it is not enough to not respond to > NSes on the old coa, because of the link local problem you described above. > Could we use the 'L' to let the home agent know that it should > not do DAD on the link-local address in this case? > > 2) Have the MN keep track of the situation well enough so that it would > know it is still on the same link. This would involve keeping information > about non-default routers as well. > > 3) Forbid the possibility of a router to become a non-default router > and still continue to act as a home agent. If we do this, then > the BU sent for forwarding-from-previous-coa will fail. But that's > allright because the CN's packets will end up in this LAN regardless. > > Other options? > Well, this is somewhat radical (but basically an attempt to learn from the last year and a half of RO discussion). Since forwarding from previous care of address is meant to be a handover accelerating/smoothing technique, we could remove it from the base document and put it into a separate document, perhaps even the fast handover spec, so we can work out the complications without the time pressure of having to get it done immediately. In addition to the point brought up in this thread, there is also the question of how to set up an IPsec security association with a router, and I think there are probably other implications of trying to treat an access router as a home agent that really haven't been entirely thought through yet. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 23:48:57 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08858 for ; Tue, 25 Jun 2002 23:48:56 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05418; Tue, 25 Jun 2002 21:49:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA22428; Tue, 25 Jun 2002 20:49:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5Q3mMk7029401 for ; Tue, 25 Jun 2002 20:48:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5Q3mM42029400 for mobile-ip-dist; Tue, 25 Jun 2002 20:48:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5Q3mJk7029393 for ; Tue, 25 Jun 2002 20:48:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA19526 for ; Tue, 25 Jun 2002 20:48:24 -0700 (PDT) Received: from windass.com ([61.165.77.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA09407 for ; Tue, 25 Jun 2002 21:48:12 -0600 (MDT) Date: Tue, 25 Jun 2002 21:48:12 -0600 (MDT) Message-Id: <200206260348.VAA09407@lukla.Sun.COM> Received: from Muorj [192.168.0.30] by windass.com [192.168.0.240] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 26 Jun 2002 09:38:56 +0800 From: PRoberts To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Without the MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=U9d106Cq3k8b5KmnW4 X-MDRemoteIP: 192.168.0.30 X-Return-Path: liugexiao@windass.com X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --U9d106Cq3k8b5KmnW4-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 25 23:56:27 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09015 for ; Tue, 25 Jun 2002 23:56:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13787; Tue, 25 Jun 2002 20:56:37 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA23368; Tue, 25 Jun 2002 20:56:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5Q3tck7029527 for ; Tue, 25 Jun 2002 20:55:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5Q3tc9C029526 for mobile-ip-dist; Tue, 25 Jun 2002 20:55:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5Q3tZk7029519 for ; Tue, 25 Jun 2002 20:55:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA14447 for ; Tue, 25 Jun 2002 20:55:41 -0700 (PDT) Received: from windass.com ([61.165.77.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA11601 for ; Tue, 25 Jun 2002 21:55:31 -0600 (MDT) Date: Tue, 25 Jun 2002 21:55:31 -0600 (MDT) Message-Id: <200206260355.VAA11601@lukla.Sun.COM> Received: from Ayrbbiyzn [192.168.0.30] by windass.com [192.168.0.240] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 26 Jun 2002 10:02:06 +0800 From: wenzel To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Meeting notice MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=A20kwCk7h325 X-MDRemoteIP: 192.168.0.30 X-Return-Path: liugexiao@windass.com X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --A20kwCk7h325-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 26 00:02:18 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09187 for ; Wed, 26 Jun 2002 00:02:18 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA06902; Tue, 25 Jun 2002 22:02:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA24521; Tue, 25 Jun 2002 21:02:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5Q41Uk7029648 for ; Tue, 25 Jun 2002 21:01:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5Q41Ufx029647 for mobile-ip-dist; Tue, 25 Jun 2002 21:01:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5Q41Rk7029640 for ; Tue, 25 Jun 2002 21:01:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA15963 for ; Tue, 25 Jun 2002 21:01:34 -0700 (PDT) Received: from windass.com ([61.165.77.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA13213 for ; Tue, 25 Jun 2002 22:01:23 -0600 (MDT) Date: Tue, 25 Jun 2002 22:01:23 -0600 (MDT) Message-Id: <200206260401.WAA13213@lukla.Sun.COM> Received: from Nzmtjek [192.168.0.30] by windass.com [192.168.0.240] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 26 Jun 2002 10:23:47 +0800 From: gdommety To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] The copyright notice or references to the MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=XXdDB64dp10S591ed66H X-MDRemoteIP: 192.168.0.30 X-Return-Path: liugexiao@windass.com X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --XXdDB64dp10S591ed66H-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 26 04:46:22 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07990 for ; Wed, 26 Jun 2002 04:46:21 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18888; Wed, 26 Jun 2002 02:46:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA08146; Wed, 26 Jun 2002 01:46:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5Q8iwk7000073 for ; Wed, 26 Jun 2002 01:44:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5Q8iwed000072 for mobile-ip-dist; Wed, 26 Jun 2002 01:44:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5Q8itk7000065 for ; Wed, 26 Jun 2002 01:44:55 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20864 for ; Wed, 26 Jun 2002 01:45:00 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18300 for ; Wed, 26 Jun 2002 02:44:59 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5Q8iurV019148; Wed, 26 Jun 2002 10:44:56 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 10:44:56 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F078F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , "T.J. Kniveton" Cc: "Hesham Soliman (ERA)" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] confusion about prefix sol/adv Date: Wed, 26 Jun 2002 10:44:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > If someone wants to use IPsex SAs, that's fine..but they > have a limitation in > > selecting the right kind of traffic. As Vijay pointed > out, an implementor > > would probably have to secure ALL ICMP traffic. The > alternative is to create > > a new mobility header type, which it seems too late to do now. > > Or rely on IPsec implementations which can use the ICMP > type as a selector? > I don't know how many implementations do this, and I > haven't thought about > the interoperability issues when one of HA/MN supports it > and the other does > not - perhaps it could be an optional thing when the HA/MN > relationship is > created? => Another thing to add, is there any other ICMP message that is currently sent to the HA? I don't think so. So there is no harm in securing ALL ICMP messages (only 2). Note that the DHAAD is not addressed to the HA's unicast address, so it won't count. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 26 05:03:05 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08311 for ; Wed, 26 Jun 2002 05:03:04 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25249; Wed, 26 Jun 2002 02:03:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13749; Wed, 26 Jun 2002 02:03:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5Q92Dk7000195 for ; Wed, 26 Jun 2002 02:02:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5Q92Dti000194 for mobile-ip-dist; Wed, 26 Jun 2002 02:02:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5Q929k7000186 for ; Wed, 26 Jun 2002 02:02:09 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24941 for ; Wed, 26 Jun 2002 02:02:15 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA28498; Wed, 26 Jun 2002 02:02:13 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5Q92CrV025508; Wed, 26 Jun 2002 11:02:12 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 11:02:12 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0791@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'T.J. Kniveton'" , "Hesham Soliman (ERA)" , Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] confusion about prefix sol/adv Date: Wed, 26 Jun 2002 11:02:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > >> Here is from the description of MPS/MPA on page 63: > >> > >> : If a Security Association for the IP > Authentication Header > >> : exists between the sender and the destination > >> address, then the > >> : sender SHOULD include this header. [subject to change] > >> > >> and on p 65: > >> > >> : An AH header MUST be included unless the mobile > >> node has yet to > >> : configure a home address. > > > > => This is where I don't think the sentence makes > > sense. How is it possible that the MN does not > > have a home address, but somehow knows the > > HA's address? Can someone please explain? > > Sure. If you have read Appendix A, or any of the MIP-list > conversations > about MPS/MPA and bootstrapping, then it does make sense: > for any node that > wants to store a minimum amount of info, it can use DNS, > DHAD, and MPS to > configure itself. After it has done DHAD, it knows all the > home agents on > the home link..but has not configured its own address. It > sends an MPS with > the CoA as source address. => Yeah I read them at the time, I think I was one of the people that sent you comments... But, excuse me for being a bit slow, but are you saying that the MN does DHAAD, yest it still does not know _one_ of its home addresses??? Even after the supposed DNS lookup? That's what I don't understand... Here is a scenario where a MN knows _nothing_ (I think I sent the same thing before) : 1. Finds out its HoA address from the DNS 2. From that it finds the HA's anycast 3. Does DHAAD 4. Sends BU with one of the Home addresses 4. Sends MPS In this scenario, MPS and MPA can be secured with the same SA that is used for the BU. Having said that, I agree with Erik's response to Pascal, for the sake of the current spec, we can assume that the MN already knows its home address/prefix. Later we can add well studied mechanisms for complete plug n play. But either way, I think the scenario above would work. Comments? > > > > > > Otherwise, I think the rest is fine, use the > > existing IPsec SA...simple. > > Not quite so simple -- there is no existing SA for securing > ICMP traffic, so > one would need to be established. It would be simpler not > to use IPsec. => This is for you and Vijay because he made the same comment. Why can't we use the same preconfigured ( this is the current assumption) SA for the BU? All you need is to copy it and create anew SPD entry dynamically or when configuring the original SA for the BU. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 26 06:11:40 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09538 for ; Wed, 26 Jun 2002 06:11:40 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17098; Wed, 26 Jun 2002 04:12:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA24504; Wed, 26 Jun 2002 03:12:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QAB7k7000436 for ; Wed, 26 Jun 2002 03:11:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QAB7WW000435 for mobile-ip-dist; Wed, 26 Jun 2002 03:11:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QAB3k7000428 for ; Wed, 26 Jun 2002 03:11:03 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g5QAB2b24924; Wed, 26 Jun 2002 12:11:02 +0200 (MEST) Date: Wed, 26 Jun 2002 12:09:41 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] confusion about prefix sol/adv To: "T.J. Kniveton" Cc: "Hesham Soliman (ERA)" , Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Sure. If you have read Appendix A, or any of the MIP-list conversations > about MPS/MPA and bootstrapping, then it does make sense: for any node that > wants to store a minimum amount of info, it can use DNS, DHAD, and MPS to > configure itself. After it has done DHAD, it knows all the home agents on > the home link..but has not configured its own address. It sends an MPS with > the CoA as source address. But how useful is this? Is it merely a nice to have or is it a 'must' requirement? From an address space concern there should be no issue with having the MN use a fixed interface id on the home link i.e. as long as the home link doesn't renumber the MN uses a fixed HoA. And the MN presumably knows its home interface ID (in its configuration, on the Ethernet card, or in the SIM?). In fact, if the MN doesn't know its interface ID I have no idea how there could be an IPsec SA between the MN and HA for the BU that prevents a MN from injecting a bogus BU for another MN which is using the same HA. Thus as far as I can tell a fixed interface ID for the MN is required in order to bootstrap the security needed for the home registration BU. So the MN needs to know this plus the home subnet prefix; hence it needs to know a possible Home Address for itself. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 26 06:45:59 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11238 for ; Wed, 26 Jun 2002 06:45:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA09476; Wed, 26 Jun 2002 04:46:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25838; Wed, 26 Jun 2002 03:45:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QAhrk7001443 for ; Wed, 26 Jun 2002 03:43:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QAhqKd001442 for mobile-ip-dist; Wed, 26 Jun 2002 03:43:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QAhkk7001429 for ; Wed, 26 Jun 2002 03:43:46 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29784 for ; Wed, 26 Jun 2002 03:43:50 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24230 for ; Wed, 26 Jun 2002 04:43:41 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10868; Wed, 26 Jun 2002 06:42:57 -0400 (EDT) Message-Id: <200206261042.GAA10868@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-okazaki-mobileip-abk-00.txt Date: Wed, 26 Jun 2002 06:42:57 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Securing MIPv6 Binding Updates Using Address Based Keys (ABKs) Author(s) : S. Okazaki, Y. Yin, J. Kempf Filename : draft-okazaki-mobileip-abk-00.txt Pages : 14 Date : 25-Jun-02 This document outlines a method for authenticating and authorizing Mobile IPv6 [MIPv6] Binding Updates between a Correspondent Node and a Mobile Node where there exists no pre-established direct or indirect security relationship between those two entities. The method uses a new security technique called Address Based Keys. Address Based Keys are an alternative to other cryptographic address mechanisms for optimizing Binding Update security to avoid the need for Return Routability checks on each binding update. Address Based Keys use some mathematical results in identity based cryptosystems that have been known to cryptographers for some time, but have not been widely discussed in the network security community. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-okazaki-mobileip-abk-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-okazaki-mobileip-abk-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-okazaki-mobileip-abk-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: <20020625142056.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-okazaki-mobileip-abk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-okazaki-mobileip-abk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020625142056.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 26 10:24:34 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20309 for ; Wed, 26 Jun 2002 10:24:34 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06166; Wed, 26 Jun 2002 08:25:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03323; Wed, 26 Jun 2002 07:25:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QENrk7002174 for ; Wed, 26 Jun 2002 07:23:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QENrCK002173 for mobile-ip-dist; Wed, 26 Jun 2002 07:23:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QENok7002166 for ; Wed, 26 Jun 2002 07:23:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03175 for ; Wed, 26 Jun 2002 07:23:54 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12977 for ; Wed, 26 Jun 2002 07:23:54 -0700 (PDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5QENLg10848; Wed, 26 Jun 2002 10:23:22 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 10:23:21 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3471672C@zcard0ka.ca.nortel.com> From: "Hongyi Li" To: "'Masataka Ohta'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Draft Agenda for MIP WG @ IETF54 Date: Wed, 26 Jun 2002 10:23:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21D1D.038D1F34" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C21D1D.038D1F34 Content-Type: text/plain; charset="iso-8859-1" Hi Ohta-san, > > Then, could you please highlight what exactly do you > > want to standardize and what change is required to existing > MIP protocols or > > MIP can support it by nature. > > My draft is a reality check on what protocols are used by the > real world > with the end to end principle. I guess MIP can support smooth handoff with two active transceivers. But I am not 100% sure about it, that's why I asked you about the required changes to MIP. As for the E2E principle, following papers from LCS/MIT might help. http://www.ana.lcs.mit.edu/anaweb/PDF/saltzer_reed_clark_e2e.pdf - 1984 http://ana-www.lcs.mit.edu/anaweb/PDF/Rethinking_2001.pdf - 2001 Regards Hongyi ------_=_NextPart_001_01C21D1D.038D1F34 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Draft Agenda for MIP WG @ IETF54

Hi Ohta-san,

> > Then, could you please highlight what = exactly do you
> > want to standardize and what change is = required to existing
> MIP protocols or
> > MIP can support it by nature.
>
> My draft is a reality check on what protocols = are used by the
> real world
> with the end to end principle.

I guess MIP can support smooth handoff with two = active transceivers.
But I am not 100% sure about it, that's why I asked = you about the
required changes to MIP.

As for the E2E principle, following papers from = LCS/MIT
might help.

http://www.ana.lcs.mit.edu/anaweb/PDF/saltzer_reed_cla= rk_e2e.pdf - 1984

http://ana-www.lcs.mit.edu/anaweb/PDF/Rethinking_2001.= pdf - 2001

Regards

Hongyi

------_=_NextPart_001_01C21D1D.038D1F34-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 26 14:56:06 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05497 for ; Wed, 26 Jun 2002 14:56:05 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29538; Wed, 26 Jun 2002 11:56:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25156; Wed, 26 Jun 2002 11:56:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QIsxk7002721 for ; Wed, 26 Jun 2002 11:54:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QIsxtN002720 for mobile-ip-dist; Wed, 26 Jun 2002 11:54:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QIsuk7002713 for ; Wed, 26 Jun 2002 11:54:56 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24722 for ; Wed, 26 Jun 2002 11:55:01 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28921; Wed, 26 Jun 2002 11:55:00 -0700 (PDT) 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 LAA07919; Wed, 26 Jun 2002 11:54:59 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5QIswG07115; Wed, 26 Jun 2002 11:54:58 -0700 X-mProtect: <200206261854> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8eiyQI; Wed, 26 Jun 2002 11:54:55 PDT Message-ID: <3D1A0DFF.5B370C4@iprg.nokia.com> Date: Wed, 26 Jun 2002 11:54:55 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: "'T.J. Kniveton'" , Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] confusion about prefix sol/adv References: <4DA6EA82906FD511BE2F00508BCF0538044F0791@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Hesham Soliman (ERA)" wrote: > => This is for you and Vijay because he made the same > comment. Why can't we use the same preconfigured ( > this is the current assumption) SA for the BU? > All you need is to copy it and create anew SPD > entry dynamically or when configuring the original > SA for the BU. not so easy. both ends (HA and MN) have to decide on a new SPI value. you need some kind of negotiation. it is possible to come up with a derived SA from the original SA, but both ends need to do the same. anyway, you dont have to do such a thing. it is not difficult creating one more IPsec SA pair to protect all ICMP traffic. currently there are two already (1) to protect Mobility Header traffic between MN and HA (2) to protect tunneled HoTI and HoT messages. for your other question > Another thing to add, is there any other ICMP > message that is currently sent to the HA? ICMP errors?? Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 26 15:10:19 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06188 for ; Wed, 26 Jun 2002 15:10:18 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07685; Wed, 26 Jun 2002 12:10:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25262; Wed, 26 Jun 2002 12:10:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QJ9Ek7002857 for ; Wed, 26 Jun 2002 12:09:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QJ9E3a002856 for mobile-ip-dist; Wed, 26 Jun 2002 12:09:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QJ9Bk7002849 for ; Wed, 26 Jun 2002 12:09:11 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24566 for ; Wed, 26 Jun 2002 12:09:16 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06611; Wed, 26 Jun 2002 12:09:15 -0700 (PDT) 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 MAA08634; Wed, 26 Jun 2002 12:09:15 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5QJ9EK25179; Wed, 26 Jun 2002 12:09:14 -0700 X-mProtect: <200206261909> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdIRRMT7; Wed, 26 Jun 2002 12:09:11 PDT Message-ID: <3D1A1158.5A8BA557@iprg.nokia.com> Date: Wed, 26 Jun 2002 12:09:12 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Jari Arkko , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Resolution to issue 37, defending only link local addresses References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Erik, I made your suggested changes. Regards, Charlie P. Erik Nordmark wrote: > > Editorial nits - I haven't figured out if we know what the right thing(tm) > is for mobile nodes returning home. > > > Proposal: Vijay Devaparalli and Vladislav Yasevich have proposed that > > a new 'L' bit is needed. If the 'L' bit is set, it means both the MN's > > link local address and home address have the same interface id. > > > > The 'L' and 'S' bits are used when defending addresses i.e. when > > answering Neighbor Soliciations. The following addresses are defended: > > > > - S=0 & L=0 => Defend all global unicast addresses possible on link. > > s/global/non-link-local/ > in order to say the right thing for site-locals. > > > - S=0 & L=1 => Semantics of S=0 above + the derived link-local. > > > > - S=1 & L=0 => Defend the given address. > > > > - S=1 & L=1 => Defend the given global unicast (home) address + > > the derived link-local. > > s/global/non-link-local/ > > > If the home address was generated using RFC 3041, then there is no > > corresponding link local address. Accordingly the MN SHOULD NOT set > > the 'L' bit. > > > > The Home Agent SHOULD perform Duplicated Address detection on every > > address it is defending on behalf of the mobile node. > > Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 26 19:01:12 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14756 for ; Wed, 26 Jun 2002 19:01:12 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07987; Wed, 26 Jun 2002 17:01:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20857; Wed, 26 Jun 2002 16:01:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QN0Qk7003682 for ; Wed, 26 Jun 2002 16:00:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QN0Qtw003681 for mobile-ip-dist; Wed, 26 Jun 2002 16:00:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QN0Nk7003674 for ; Wed, 26 Jun 2002 16:00:23 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15298 for ; Wed, 26 Jun 2002 16:00:29 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02092 for ; Wed, 26 Jun 2002 16:00:29 -0700 (PDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id QAA07930 for ; Wed, 26 Jun 2002 16:00:28 -0700 (MST)] Received: [from il02exm02.corp.mot.com (il02exm02.corp.mot.com [10.0.100.55]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA18952 for ; Wed, 26 Jun 2002 16:00:28 -0700 (MST)] Received: by il02exm02.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 26 Jun 2002 18:00:28 -0500 Message-ID: From: Narayanan Vidya-CVN065 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Mobile IP NAI Question Date: Wed, 26 Jun 2002 17:58:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, RFC 3220 says that the home agent address in the mobile ip registration message must be non-NULL. If the mobile node knows its home address and does not know its home agent address, it can discover its home agent using subnet-directed broadcast. However, if the mobile node is using NAI to get a home address, and it doesn't know the home agent address, there is no way to do this. In such a situation, how does MIPv4 registration work? I am assuming FA CoA here. What does the FA do with a registration request that has the MIP NAI extension, and has a NULL home address and home agent address? Is this valid? Thanks, Vidya From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 26 19:37:15 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15660 for ; Wed, 26 Jun 2002 19:37:15 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18397; Wed, 26 Jun 2002 16:37:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12049; Wed, 26 Jun 2002 16:37:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QNaIk7003886 for ; Wed, 26 Jun 2002 16:36:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5QNaIvD003885 for mobile-ip-dist; Wed, 26 Jun 2002 16:36:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QNaEk7003878 for ; Wed, 26 Jun 2002 16:36:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02328 for ; Wed, 26 Jun 2002 16:36:21 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17979 for ; Wed, 26 Jun 2002 16:36:20 -0700 (PDT) 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 QAA23451; Wed, 26 Jun 2002 16:36:20 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5QNaFK06721; Wed, 26 Jun 2002 16:36:15 -0700 X-mProtect: <200206262336> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdR8s7zz; Wed, 26 Jun 2002 16:36:13 PDT Message-ID: <3D1A4FED.6CE3D007@iprg.nokia.com> Date: Wed, 26 Jun 2002 16:36:13 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko , Krishna Kumar CC: mobile-ip@sunroof.eng.sun.com Subject: Re: Issue #43 (was, Re: [mobile-ip] Re: MIPv6 - 17 Review) References: <3D1898B5.4050206@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, First, I need to clearly state that I am in the role of providing information, not crusading, because I am neutral. Having said that, I feel that there is a need to present the information about this issue so that a better informed decision can be made. I forgot who originally proposed this field (it was not me), but it was discussed more than once before, and it does not seem right to expunge it if it's not clearly understood. It is true, that mixing together lifetime issues due to two different effects (home agent volatility vs. node mobility) may invite problems in the future. Thus, I do not like the suggestion that we should make the lifetime to be the minimum of the two effects in all cases. On the other hand, we don't need to have the Refresh field in all Binding Acknowledgements, most probably. So, I will take it out. Then the question is whether we should have a option for the information. That seems to me to be the right solution, given the long history of the field. The purpose of the information is only advisory; the home agent would keep the binding current for the full lifetime of the Binding anyway, even if a new Binding Update did not arrive within Refresh seconds. If consensus is to remove the feature entirely even after understanding what it was for, then that is also O.K. with me. I would just expect that it amounts to omitting the feature entirely, not causing it to be commingled with whatever considerations cause selection of a particular Lifetime value. Regards, Charlie P. Jari Arkko wrote: > > Krishna Kumar wrote: > > > Hi Charlie, > > > > I feel that if the availability of nonvolatile storage should be a factor > > in determining the lifetime, the following method would work better : > > > > If non-volatile storage is available, use a large value for > > lifetime (which is the same as described in the draft, eg > > something in the range of many hours). > > Otherwise use smaller values (eg something in the range > > of many minutes). > > > > Keeping a Refresh value is simulating the above algo by giving lower > > values for a refresh if there is no non-volatile storage , and higher > > values (full lifetime) if there is a non-volatile storage. Why not remove > > the field completely and just use the values based on type of storage, > > and get the same characteristics ? > > I agree. > > > I think that Refresh is not needed for the above mentioned reason, but > > if the community feels otherwise, I feel an option might make it more > > cumbersome. In that case it might be better to preserve this field in the > > BA, instead of making significant changes. > > I agree here as well. > > My suggestion is that we remove the field. > > Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 26 21:53:31 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18973 for ; Wed, 26 Jun 2002 21:53:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02751; Wed, 26 Jun 2002 19:54:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13224; Wed, 26 Jun 2002 18:53:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5R1qok7004260 for ; Wed, 26 Jun 2002 18:52:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5R1qoGQ004259 for mobile-ip-dist; Wed, 26 Jun 2002 18:52:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5R1qkk7004252 for ; Wed, 26 Jun 2002 18:52:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA07446 for ; Wed, 26 Jun 2002 18:52:52 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02364 for ; Wed, 26 Jun 2002 19:52:51 -0600 (MDT) From: Masataka Ohta Message-Id: <200206270142.KAA01832@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA01832; Thu, 27 Jun 2002 10:42:00 +0900 Subject: Re: [mobile-ip] Draft Agenda for MIP WG @ IETF54 In-Reply-To: <3549C09B853DD5119B540002A52CDD3471672C@zcard0ka.ca.nortel.com> from Hongyi Li at "Jun 26, 2002 10:23:17 am" To: Hongyi Li Date: Thu, 27 Jun 2002 10:41:59 +0859 () CC: mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hongyi; > > > Then, could you please highlight what exactly do you > > > want to standardize and what change is required to existing > > MIP protocols or > > > MIP can support it by nature. > > > > My draft is a reality check on what protocols are used by the > > real world > > with the end to end principle. > > I guess MIP can support smooth handoff with two active transceivers. > But I am not 100% sure about it, that's why I asked you about the > required changes to MIP. There is no problem, except for the possible authentication gotcha documented in my draft. > As for the E2E principle, following papers from LCS/MIT > might help. > > http://www.ana.lcs.mit.edu/anaweb/PDF/saltzer_reed_clark_e2e.pdf - 1984 > > http://ana-www.lcs.mit.edu/anaweb/PDF/Rethinking_2001.pdf - 2001 An interesting observation is that all the attempts, OSI, ATM (ROLC), MPLS, PKI ... to destroy the end to end principle have been failing, both technically and commercially, dispite all the effort of IETF and industry. Another interseting observation is that the end to end solution for the smooth mobility is deployed not only by us, an ISP, but also by carriers of PHS. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 00:05:32 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21966 for ; Thu, 27 Jun 2002 00:05:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11333; Wed, 26 Jun 2002 22:06:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA28743; Wed, 26 Jun 2002 21:05:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5R44bk7004508 for ; Wed, 26 Jun 2002 21:04:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5R44bBP004507 for mobile-ip-dist; Wed, 26 Jun 2002 21:04:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5R44Xk7004500 for ; Wed, 26 Jun 2002 21:04:34 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA28541 for ; Wed, 26 Jun 2002 21:04:40 -0700 (PDT) Received: from lit.a-star.edu.sg (rodin.krdl.org.sg [192.122.139.27]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA19215 for ; Wed, 26 Jun 2002 21:04:39 -0700 (PDT) Received: from mailhost1 (localhost [127.0.0.1]) by lit.a-star.edu.sg (8.11.1/8.11.1) with ESMTP id g5R43rI19477 for ; Thu, 27 Jun 2002 12:03:53 +0800 (SGT) Received: from vsys (vsys.lit.org.sg [192.168.137.194]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 HotFix 0.5 (built Jun 7 2002)) with SMTP id <0GYC00GZKJCNRW@mailhost.lit.org.sg> for mobile-ip@sunroof.eng.sun.com; Thu, 27 Jun 2002 12:05:14 +0800 (SGT) Date: Thu, 27 Jun 2002 12:04:26 +0800 From: Vrizlynn Thing Subject: [mobile-ip] New Draft: draft-vriz-mipv6-hbhlmap-00.txt To: Mobile IP Mailing List Cc: Xu Yi , Henry Message-id: <00e901c21d8f$bcc0b570$c289a8c0@vsys> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi all, I've recently submitted "draft-vriz-mipv6-hbhlmap-00.txt" to the Mobile IP Working Group. It proposed a solution to provide support for Localized Mobility Management according to requirements set out in "draft-ietf-mobileip-lmm-requirements-01.txt" in Mobile IPv6. The detailed mechanisms and procedures are explained in the draft. Abstract: This document introduces an extension to Mobile IPv6 to provide support for Localized Mobility Management. This proposed Hop-by-Hop Local Mobility Agents Probing scheme specifies the Local Mobility Agents Discovery, Selection and Failure Detection architecture and procedures for deploying the localized mobility management, whereby the Local Mobility Agents are distributed. It reduces the amount of signalling to the home agent and correspondent nodes when mobile node moves among the subnets of the visited domain. This document can be found at the following URL: http://www.ietf.org/internet-drafts/draft-vriz-mipv6-hbhlmap-00.txt Thank you. Best Regards, Vrizlynn Thing (Ms) Vrizlynn Thing (Ms) Senior Engineer Laboratories for Information Technology 21 Heng Mui Keng Terrace Singapore 119613 Tel: +65 68746728 Fax: +65 6776 8109 Email: vriz@lit.a-star.edu.sg From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 12:24:12 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28916 for ; Thu, 27 Jun 2002 12:24:12 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29122; Thu, 27 Jun 2002 10:24:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09970; Thu, 27 Jun 2002 09:24:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RGNXk7005751 for ; Thu, 27 Jun 2002 09:23:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RGNX0V005750 for mobile-ip-dist; Thu, 27 Jun 2002 09:23:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RGNTk7005743 for ; Thu, 27 Jun 2002 09:23:29 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25484 for ; Thu, 27 Jun 2002 09:23:35 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28159 for ; Thu, 27 Jun 2002 10:23:34 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28831; Thu, 27 Jun 2002 12:22:48 -0400 (EDT) Message-Id: <200206271622.MAA28831@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-arkko-mipv6-select-hash-00.txt Date: Thu, 27 Jun 2002 12:22:47 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Selection of MIPv6 Security Level Using a Hashed Address Author(s) : J. Arkko, P. Nikander, G. Montenegro Filename : draft-arkko-mipv6-select-hash-00.txt Pages : 8 Date : 26-Jun-02 MIPv6 is being defined with a security solution called Return Routability (RR) that does not need any authentication infrastructure. Given that the solution is 'infrastructureless' in this manner, it isn't very easy to control the solution once it is widely deployed. In particular, it isn't clear how the solution could be changed to a new solution, should that ever become necessary. Peers should be able to agree about the use the new solution in a secure manner, without Man- in-the-Middle attackers from being able to mount a Bidding Down attack and downgrade the security back to the original solution. This draft specifies a simple but secure scheme which allows nodes to choose what security solution they use. One currently known drawback of this scheme is that it is based on a technology that has IPR considera¡ tions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-arkko-mipv6-select-hash-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-arkko-mipv6-select-hash-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-arkko-mipv6-select-hash-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: <20020626135105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-arkko-mipv6-select-hash-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-arkko-mipv6-select-hash-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020626135105.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 13:11:51 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01990 for ; Thu, 27 Jun 2002 13:11:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16043; Thu, 27 Jun 2002 11:12:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29919; Thu, 27 Jun 2002 10:12:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RHB3k7006026 for ; Thu, 27 Jun 2002 10:11:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RHB3Ar006025 for mobile-ip-dist; Thu, 27 Jun 2002 10:11:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RHAxk7006018 for ; Thu, 27 Jun 2002 10:10:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01760 for ; Thu, 27 Jun 2002 10:11:05 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15159 for ; Thu, 27 Jun 2002 11:11:04 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 816436A907; Thu, 27 Jun 2002 20:10:58 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 079136A906; Thu, 27 Jun 2002 20:10:54 +0300 (EEST) Message-ID: <3D1B4777.3050706@piuha.net> Date: Thu, 27 Jun 2002 20:12:23 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com, Charlie Perkins Subject: Re: [mobile-ip] Issue 49: Got a new home address, what about the SAs to HA? References: <3D18A60C.4050702@kolumbus.fi> <02ae01c21c88$8a4eb860$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > Jari, > > IMHO, I'd say 2). We don't need to introduce any additional mechanism, but people should be warned. Yes. Let's go with that. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 14:20:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06430 for ; Thu, 27 Jun 2002 14:20:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25800; Thu, 27 Jun 2002 12:21:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02395; Thu, 27 Jun 2002 11:21:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RIK8k7006398 for ; Thu, 27 Jun 2002 11:20:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RIK75c006397 for mobile-ip-dist; Thu, 27 Jun 2002 11:20:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RIK4k7006390 for ; Thu, 27 Jun 2002 11:20:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28795 for ; Thu, 27 Jun 2002 11:20:09 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29083 for ; Thu, 27 Jun 2002 12:20:08 -0600 (MDT) Message-ID: <007101c21e08$0db7dbc0$686015ac@docomocarl> From: "Carl Williams" To: Subject: [mobile-ip] LMM Requirements - both for MIPv4/MIPv6 Date: Thu, 27 Jun 2002 11:25:44 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006E_01C21DCD.6062E3F0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_006E_01C21DCD.6062E3F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I talked with James Kempf and we believe that the requirements are generic for both v4 and v6 (just scanning the list). =20 I am intending that the requirements be specified in a way that they can apply to both MIPv4 and MIPv6. =20 Carl ------=_NextPart_000_006E_01C21DCD.6062E3F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
I talked with James Kempf and we = believe=20 that
the requirements are generic for both = v4 and=20 v6
(just scanning the list).  =
 
I am intending that the requirements=20 be
specified in a way that they can apply = to=20 both
MIPv4 and MIPv6. 
 
Carl
 
------=_NextPart_000_006E_01C21DCD.6062E3F0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 14:37:49 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07740 for ; Thu, 27 Jun 2002 14:37:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16414; Thu, 27 Jun 2002 11:37:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05399; Thu, 27 Jun 2002 11:37:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RIaQk7006528 for ; Thu, 27 Jun 2002 11:36:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RIaPFX006527 for mobile-ip-dist; Thu, 27 Jun 2002 11:36:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RIaMk7006520 for ; Thu, 27 Jun 2002 11:36:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10182 for ; Thu, 27 Jun 2002 11:36:27 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04264 for ; Thu, 27 Jun 2002 12:36:26 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5RIaLrU025466; Thu, 27 Jun 2002 20:36:21 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 20:36:21 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F07A5@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Charles E. Perkins'" , Jari Arkko , Krishna Kumar Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: Issue #43 (was, Re: [mobile-ip] Re: MIPv6 - 17 Review) Date: Thu, 27 Jun 2002 20:36:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Charlie, Since the information was presented and dicussed and those who had opinions all agreed on removing this field and making it an option, I think we should go ahead with that. If we all missed some other valid reason for having it, then there is not much that we can do. OTOH, it seems like there are good reasons now for not having this field. Hesham > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Thursday, June 27, 2002 1:36 AM > To: Jari Arkko; Krishna Kumar > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: Issue #43 (was, Re: [mobile-ip] Re: MIPv6 - 17 Review) > > > Hello folks, > > First, I need to clearly state that I am in the role of providing > information, not crusading, because I am neutral. > > Having said that, I feel that there is a need to present the > information about this issue so that a better informed decision > can be made. I forgot who originally proposed this field (it was > not me), but it was discussed more than once before, and it does > not seem right to expunge it if it's not clearly understood. > > It is true, that mixing together lifetime issues due to two > different effects (home agent volatility vs. node mobility) > may invite problems in the future. Thus, I do not like the > suggestion that we should make the lifetime to be the minimum > of the two effects in all cases. > > On the other hand, we don't need to have the Refresh field > in all Binding Acknowledgements, most probably. So, I will > take it out. Then the question is whether we should have a > option for the information. That seems to me to be the right > solution, given the long history of the field. The purpose of > the information is only advisory; the home agent would keep > the binding current for the full lifetime of the Binding > anyway, even if a new Binding Update did not arrive within > Refresh seconds. > > If consensus is to remove the feature entirely even after > understanding what it was for, then that is also O.K. with me. > I would just expect that it amounts to omitting the feature > entirely, not causing it to be commingled with whatever > considerations cause selection of a particular Lifetime value. > > Regards, > Charlie P. > > > > > Jari Arkko wrote: > > > > Krishna Kumar wrote: > > > > > Hi Charlie, > > > > > > I feel that if the availability of nonvolatile storage > should be a factor > > > in determining the lifetime, the following method would > work better : > > > > > > If non-volatile storage is available, use a large > value for > > > lifetime (which is the same as described in the draft, eg > > > something in the range of many hours). > > > Otherwise use smaller values (eg something in the range > > > of many minutes). > > > > > > Keeping a Refresh value is simulating the above algo by > giving lower > > > values for a refresh if there is no non-volatile > storage , and higher > > > values (full lifetime) if there is a non-volatile > storage. Why not remove > > > the field completely and just use the values based on > type of storage, > > > and get the same characteristics ? > > > > I agree. > > > > > I think that Refresh is not needed for the above > mentioned reason, but > > > if the community feels otherwise, I feel an option > might make it more > > > cumbersome. In that case it might be better to preserve > this field in the > > > BA, instead of making significant changes. > > > > I agree here as well. > > > > My suggestion is that we remove the field. > > > > Jari > From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 14:42:58 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08124 for ; Thu, 27 Jun 2002 14:42:57 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22889; Thu, 27 Jun 2002 12:43:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13379; Thu, 27 Jun 2002 11:43:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RIgak7006644 for ; Thu, 27 Jun 2002 11:42:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RIgZPL006643 for mobile-ip-dist; Thu, 27 Jun 2002 11:42:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RIgWk7006633 for ; Thu, 27 Jun 2002 11:42:32 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20850 for ; Thu, 27 Jun 2002 11:42:37 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22365 for ; Thu, 27 Jun 2002 12:42:36 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 2301E6A907; Thu, 27 Jun 2002 21:42:30 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1D73F6A906 for ; Thu, 27 Jun 2002 21:42:28 +0300 (EEST) Message-ID: <3D1B5CED.20009@kolumbus.fi> Date: Thu, 27 Jun 2002 21:43:57 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Issue 20 (extensibility) can be closed Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I believe issue 20 -- about the extensibility of the authorization mechanism to future schemes -- can be closed with the following observation: Methods that extend RR with new mobility options can be accommodated with the inclusion of these mobility options in the HoTI and CoTI messages. A receiver that recognizes these options will return corresponding options. A receiver that does not will skip the options and behave as for RR. The sender will see this and can abort the procedure by not sending a Binding Update, if he so desires. Methods that extend RR with new message types can be accommodated, as the peer will reply with the Binding Error (2) message if it does not recognize the new message. No new text needed for this. From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 14:48:39 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08574 for ; Thu, 27 Jun 2002 14:48:38 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00430; Thu, 27 Jun 2002 11:48:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23294; Thu, 27 Jun 2002 11:48:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RIlWk7006759 for ; Thu, 27 Jun 2002 11:47:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RIlWYL006758 for mobile-ip-dist; Thu, 27 Jun 2002 11:47:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RIlSk7006751 for ; Thu, 27 Jun 2002 11:47:28 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09522 for ; Thu, 27 Jun 2002 11:47:33 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21517 for ; Thu, 27 Jun 2002 11:47:33 -0700 (PDT) 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 LAA08434; Thu, 27 Jun 2002 11:47:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5RIlWj14369; Thu, 27 Jun 2002 11:47:32 -0700 X-mProtect: <200206271847> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8lpPGS; Thu, 27 Jun 2002 11:47:31 PDT Message-ID: <3D1B5DC3.B47DE0B3@iprg.nokia.com> Date: Thu, 27 Jun 2002 11:47:31 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: Issue #43 (was, Re: [mobile-ip] Re: MIPv6 - 17 Review) References: <4DA6EA82906FD511BE2F00508BCF0538044F07A5@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, I believe your message substantially agrees with the meaning of my message which you have quoted. The field has been gone from draft-18 text now for quite a few hours :-) Regards, Charlie P. "Hesham Soliman (EAB)" wrote: > > Hi Charlie, > > Since the information was presented and dicussed > and those who had opinions all agreed on removing > this field and making it an option, I think we > should go ahead with that. If we all missed some > other valid reason for having it, then there is not > much that we can do. OTOH, it seems like there are > good reasons now for not having this field. > > Hesham > > > -----Original Message----- > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > Sent: Thursday, June 27, 2002 1:36 AM > > To: Jari Arkko; Krishna Kumar > > Cc: mobile-ip@sunroof.eng.sun.com > > Subject: Re: Issue #43 (was, Re: [mobile-ip] Re: MIPv6 - 17 Review) > > > > > > Hello folks, > > > > First, I need to clearly state that I am in the role of providing > > information, not crusading, because I am neutral. > > > > Having said that, I feel that there is a need to present the > > information about this issue so that a better informed decision > > can be made. I forgot who originally proposed this field (it was > > not me), but it was discussed more than once before, and it does > > not seem right to expunge it if it's not clearly understood. > > > > It is true, that mixing together lifetime issues due to two > > different effects (home agent volatility vs. node mobility) > > may invite problems in the future. Thus, I do not like the > > suggestion that we should make the lifetime to be the minimum > > of the two effects in all cases. > > > > On the other hand, we don't need to have the Refresh field > > in all Binding Acknowledgements, most probably. So, I will > > take it out. Then the question is whether we should have a > > option for the information. That seems to me to be the right > > solution, given the long history of the field. The purpose of > > the information is only advisory; the home agent would keep > > the binding current for the full lifetime of the Binding > > anyway, even if a new Binding Update did not arrive within > > Refresh seconds. > > > > If consensus is to remove the feature entirely even after > > understanding what it was for, then that is also O.K. with me. > > I would just expect that it amounts to omitting the feature > > entirely, not causing it to be commingled with whatever > > considerations cause selection of a particular Lifetime value. > > > > Regards, > > Charlie P. > > > > > > > > > > Jari Arkko wrote: > > > > > > Krishna Kumar wrote: > > > > > > > Hi Charlie, > > > > > > > > I feel that if the availability of nonvolatile storage > > should be a factor > > > > in determining the lifetime, the following method would > > work better : > > > > > > > > If non-volatile storage is available, use a large > > value for > > > > lifetime (which is the same as described in the draft, eg > > > > something in the range of many hours). > > > > Otherwise use smaller values (eg something in the range > > > > of many minutes). > > > > > > > > Keeping a Refresh value is simulating the above algo by > > giving lower > > > > values for a refresh if there is no non-volatile > > storage , and higher > > > > values (full lifetime) if there is a non-volatile > > storage. Why not remove > > > > the field completely and just use the values based on > > type of storage, > > > > and get the same characteristics ? > > > > > > I agree. > > > > > > > I think that Refresh is not needed for the above > > mentioned reason, but > > > > if the community feels otherwise, I feel an option > > might make it more > > > > cumbersome. In that case it might be better to preserve > > this field in the > > > > BA, instead of making significant changes. > > > > > > I agree here as well. > > > > > > My suggestion is that we remove the field. > > > > > > Jari > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 16:13:10 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13528 for ; Thu, 27 Jun 2002 16:13:09 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26548; Thu, 27 Jun 2002 14:13:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16389; Thu, 27 Jun 2002 13:13:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RKCEk7007216 for ; Thu, 27 Jun 2002 13:12:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RKCD3W007215 for mobile-ip-dist; Thu, 27 Jun 2002 13:12:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RKCAk7007208 for ; Thu, 27 Jun 2002 13:12:10 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16115 for ; Thu, 27 Jun 2002 13:12:16 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13555 for ; Thu, 27 Jun 2002 13:12:15 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id ED0D46A907; Thu, 27 Jun 2002 23:12:08 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 333506A906 for ; Thu, 27 Jun 2002 23:12:07 +0300 (EEST) Message-ID: <3D1B71F0.4090501@kolumbus.fi> Date: Thu, 27 Jun 2002 23:13:36 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] current issue situation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'd like to report on the current situation with issues in Mobile IPv6. As we are editing the final things to Draft 18 at the moment, we'd like to ensure that the issues marked as adopted really have been adopted in everyone's opinion. And are all issues accounted for, or is something missing? Also, we need to close the few remaining issues in the next day or two. More on that below, but let's look at the issue lists first. As you remember, the issue descriptions can be accessed from: http://www.piuha.net./~jarkko/publications/mipv6/MIPv6-Issues.html Issues we believe that are closed: # Status Explanation ---------------------------------------------------------------------------- 1 Adopted Suboptions on HAO 2 Adopted NVM rules for replay protection of BUs to the HA 3 Adopted BA and BR authentication mechanism with a cookie exchange? 4 Adopted Is BM authentication necessary? 5 Adopted Alternative-CoA usage rules 6 Adopted Reuse of nonces while moving fast 7 Adopted MH formatting issues 9 Adopted Terminology (option, parameter, RR procedure, ...) 11 Adopted Should HAO be used in home registrations? 12 Adopted State machines for CN/MN/HA behaviour 13 Rejected SPI field necessary? (But see a separate draft) 14 Adopted Require encryption on HA-MN tunnel for MH messages? 15 Adopted Site local HoAs and tunnel protection 16 Adopted Error message to give when receiving unrecognized MH Type 17 Adopted Editorial suggestions from Robert Chalmers 18 Open Prefix advertisement acknowledgement problem 19 Adopted Editorial and technical suggestions from Samita Chakrabarti 20 Adopted Allow non-RR authorization? 21 Adopted Cookie lifetimes, one or MIN and a MAX? 23 Rejected S-bit and link-local address creation (But see issue 24 Adopted Option Length for PadN 25 Adopted To use RH or not with BAs 26 Adopted HOT path when the CN already has a BCE 27 Adopted Should HAO be used in BUs to CNs? 28 Adopted BRR effects on routing 29 Adopted Rate limitation of BE messages 30 Rejected 'S' bit and MN returning home; DAD problems (But see issue 31 Adopted How to process HAO? 32 Adopted State machine simplification 33 Adopted BE and lack of home address 34 Rejected CoA test also for home registrations? 35 Adopted Hesham Soliman's comments 37 Adopted DAD rule in 10.2 for link-local only? 38 Adopted Is the 'S' bit needed? 39 Adopted Should the HA defend the link local address of the MN? 40 Adopted Krishna Kumar's technical comments 41 Adopted Krishna Kumar's editorial comments 42 Adopted {Min,Max}RtrAdvInterval 43 Adopted Is Refresh useful? 44 Adopted Finding HA's link-layer address 45 Adopted HAO keyword same as for RO or MUST? 46 Adopted Compress Status code values for BA? 47 Adopted Cookie explanation editorial 49 Adopted New home addresses and SAs Issues we believe are still open: # Status Explanation ---------------------------------------------------------------------------- 8 Open Bidding down protection 10 Open ESP or AH for home registrations 22 Open Route optimization SHOULD or MUST for CNs? 36 Open Prefix sol/adv security 48 Open DAD and forwarding from a previous care-of address on the same link 50 Open Lifetime issue from Hesham Soliman's comments In addition we have a few issues that have only been discussed outside the list: # Status Explanation ---------------------------------------------------------------------------- x1 Open Describe SPD entries to show how IPsec is used between HA-MN x2 Open Whether to mandate deregistration after coa becomes invalid x3 Open Add section references to all 8.x items and remove repetition? x4 Open Reserved field compression for MH messages x5 Open Can 16 bit mobile cookies be accepted to save 8 bytes in HOTI, COTI? x6 Open Can home and care-of cookies shortened to 96 bits or even shorter? Here's how we intend to deal with the open issues: 8 An ongoing security review is expected to provide information on whether this is needed or not. Draft 18 will not have it. Separate drafts have been published on this. 10 A proposal will be sent to the mailing list soon. 22 The MIPv6 draft will have only text to describe what MUST/SHOULD/MAY be implemented to support cn functionality, route optimization, ha functionality, mn functionality. Node requirements document currently being developed in ipv6 wg will specify a keyword for these groups of functionality. 36 Discussion ongoing. 48 A proposal will be sent to the mailing list soon. 50 Hesham's issues have been otherwise resolved, but we didn't find consensus on what to do with the lifetimes of RR-established BCEs. We do know x1 Text is being written. This will be posted to the list. At that point we can consider what, if anything of this should go as clarifying text to the spec. x2 A proposal will be sent to the list soon. x3 It might be clearer to make the 8.x section lists to just refer to the rest of the document, and say what MUST/SHOULD/MAY be provided. Proposed text will be sent soon. x4 Being edited in. x5 Being considered. x6 Being considered. From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 17:06:03 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15921 for ; Thu, 27 Jun 2002 17:06:02 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25712; Thu, 27 Jun 2002 15:06:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05473; Thu, 27 Jun 2002 14:06:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RL55k7007547 for ; Thu, 27 Jun 2002 14:05:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RL557I007546 for mobile-ip-dist; Thu, 27 Jun 2002 14:05:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RL50k7007539 for ; Thu, 27 Jun 2002 14:05:01 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05071 for ; Thu, 27 Jun 2002 14:05:05 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09067 for ; Thu, 27 Jun 2002 15:05:04 -0600 (MDT) 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 OAA17780 for ; Thu, 27 Jun 2002 14:05:04 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5RL53D09563; Thu, 27 Jun 2002 14:05:03 -0700 X-mProtect: <200206272105> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdl8AGTe; Thu, 27 Jun 2002 14:05:00 PDT Message-ID: <3D1B7DFC.AD167B82@iprg.nokia.com> Date: Thu, 27 Jun 2002 14:05:00 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP Working Group CC: Vijay Devarapalli Subject: [mobile-ip] SPI draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, A new draft has been submitted to the Internet Drafts directories. I have copied the document to the following URL: http://people.nokia.net/~charliep/txt/mobilespi/spi.txt Here is the abstract: This document specifies a new SPI (Security Parameters Index) option for use with the Binding Authorization Data option. The new SPI option allows for selection of a particular mobility security association to handle the case when several such security associations may exist between nodes exchanging messages containing a mobility header requiring authorization. The SPI value may be set during manual configuration of the security association between two nodes, for example a mobile node and its home agent, or between a mobile node and a favored correspondent node. Comments are welcome! Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 17:19:10 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16608 for ; Thu, 27 Jun 2002 17:19:10 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21134; Thu, 27 Jun 2002 14:19:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20823; Thu, 27 Jun 2002 14:19:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLI4k7007710 for ; Thu, 27 Jun 2002 14:18:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RLI4uN007709 for mobile-ip-dist; Thu, 27 Jun 2002 14:18:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLI1k7007702 for ; Thu, 27 Jun 2002 14:18:01 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19543 for ; Thu, 27 Jun 2002 14:18:05 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15931 for ; Thu, 27 Jun 2002 15:18:04 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 20D806A907; Fri, 28 Jun 2002 00:18:04 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 23AFC6A906 for ; Fri, 28 Jun 2002 00:17:52 +0300 (EEST) Message-ID: <3D1B8159.8090100@kolumbus.fi> Date: Fri, 28 Jun 2002 00:19:21 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] closing issue 10 (esp vs ah) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I've been thinking about this issue and I have a proposal that I hope can close this issue. There's been a debate whether ESP or AH should be used, particularly with the knowledge that some folks would like to deprecate AH or at least make it optional in the IPsec WG. I'd note first that currently BOTH protocols are mandatory for all IPv6 nodes. With this, I'd like to propose that we allow either one to be used. (This will allow IPsec folks to deprecate AH as they see fit. And due to the existing implementation requirements for IPv6, this does not add the burden for MIPv6 implementations.) In order for both AH and ESP to be a real choice, ESP needs to work as well as AH in this context. There's been another discussion about the need for a home address field in the BU packet if ESP is used. This was seen earlier as necessary since the HAO is not covered by ESP, which would allow it to be modified. I'd like claim that such field is in fact not necessary. Here's why: 1. In order for you to be able to use IPsec for multiple MNs, you have to set the SPD entries so that one SA can only be used with a particular source address. Otherwise, one MN could use its SA to transport a BU for another MN. 2. If you have such SPD entries, then the attacker could indeed modify the packet in flight, and it would still pass the MAC checks. However, no modification would pass the SPD check, so the attacker would not get anywhere. 3. If someone else tries to send a BU with my MN's HAO, he can't forge the MAC for my SA. Again, the attacker doesn't get anywhere. In conclusion, I'd like to allow both AH and ESP, and I'd like to remove the HoA field from the BU. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 17:32:17 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17485 for ; Thu, 27 Jun 2002 17:32:17 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27679; Thu, 27 Jun 2002 14:32:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14196; Thu, 27 Jun 2002 14:32:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLUdk7007900 for ; Thu, 27 Jun 2002 14:30:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RLUdX4007899 for mobile-ip-dist; Thu, 27 Jun 2002 14:30:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLUZk7007892 for ; Thu, 27 Jun 2002 14:30:35 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13503 for ; Thu, 27 Jun 2002 14:30:39 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06046 for ; Thu, 27 Jun 2002 15:30:39 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id AEC186A907; Fri, 28 Jun 2002 00:30:32 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id EAEDB6A906; Fri, 28 Jun 2002 00:30:30 +0300 (EEST) Message-ID: <3D1B8450.5050704@kolumbus.fi> Date: Fri, 28 Jun 2002 00:32:00 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" , Erik.Nordmark@eng.sun.com, Vijay Devarapalli Subject: [mobile-ip] Issue 49 (rfc 3041 or new prefixes and manual SAs) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I'm trying to write the text relating to solution #2 in this issue, i.e. to describe the limitations. In doing so have run into a new problem. (Or perhaps it's just too late evening...) I'm not sure I see how this works even when automatic keying is used. Normally, IKE-based SAs work well even if you change addresses. However, in this particular application we have the additional problem that we have to keep track of which SAs are allowed to send BUs regarding which IP addresses. A naive way to organize automatic keying is to setup one CA who signs everyone's certs and then anyone who can present the right kind of cert gets in and gets a new SA. This SA will have selectors that correspond to the particular IP addresses from whereever the IKE connection came from. However, with this setup any other legal mobile node could claim they are the node that has my home address, get an SA, and send an authenticated BU. So it seems that whatever we do, the certs have to have IP addresses that tie them to a specific address. Alternatively there has to be specific SPD entries for each mobile node in the HA. But if we use either of these two schemes, it's not going to be easy to change the address. Essentially, this prevents RFC 3041 home addresses or new prefix assignment without manual intervention. Any ideas? Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 17:43:19 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18086 for ; Thu, 27 Jun 2002 17:43:19 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14904; Thu, 27 Jun 2002 15:44:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28933; Thu, 27 Jun 2002 14:43:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLgqk7008085 for ; Thu, 27 Jun 2002 14:42:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RLgpQ8008084 for mobile-ip-dist; Thu, 27 Jun 2002 14:42:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLgmk7008077 for ; Thu, 27 Jun 2002 14:42:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17517 for ; Thu, 27 Jun 2002 14:42:52 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14397 for ; Thu, 27 Jun 2002 15:42:52 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5RLh3j25804; Thu, 27 Jun 2002 16:43:04 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Jun 2002 16:42:49 -0500 Message-ID: <23BDB0046F3ED51185CD0002A5608D2404A0CCC7@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: Narayanan Vidya-CVN065 , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Mobile IP NAI Question Date: Thu, 27 Jun 2002 16:42:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21E23.944602A0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C21E23.944602A0 Content-Type: text/plain; charset="iso-8859-1" If the MN does not know it's home agent address then it SHOULD use 255.255.255.255 or 0.0.0.0 in the HA field in the RRQ. The same applies to its home address. Hope this helps. Kuntal > -----Original Message----- > From: Narayanan Vidya-CVN065 [mailto:vidya@motorola.com] > Sent: Wednesday, June 26, 2002 5:59 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Mobile IP NAI Question > > > Hi, > RFC 3220 says that the home agent address in the mobile ip > registration > message must be non-NULL. If the mobile node knows its home > address and does > not know its home agent address, it can discover its home agent using > subnet-directed broadcast. However, if the mobile node is > using NAI to get a > home address, and it doesn't know the home agent address, > there is no way to > do this. > > In such a situation, how does MIPv4 registration work? I am > assuming FA CoA > here. What does the FA do with a registration request that > has the MIP NAI > extension, and has a NULL home address and home agent address? Is this > valid? > > Thanks, > Vidya > ------_=_NextPart_001_01C21E23.944602A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Mobile IP NAI Question

If the MN does not know it's home agent address then = it SHOULD use 255.255.255.255 or 0.0.0.0 in the HA field in the RRQ. = The same applies to its home address.

Hope this helps.
Kuntal

> -----Original Message-----
> From: Narayanan Vidya-CVN065 [mailto:vidya@motorola.com]=
> Sent: Wednesday, June 26, 2002 5:59 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: [mobile-ip] Mobile IP NAI = Question
>
>
> Hi,
> RFC 3220 says that the home agent address in = the mobile ip
> registration
> message must be non-NULL. If the mobile node = knows its home
> address and does
> not know its home agent address, it can = discover its home agent using
> subnet-directed broadcast. However, if the = mobile node is
> using NAI to get a
> home address, and it doesn't know the home = agent address,
> there is no way to
> do this.
>
> In such a situation, how does MIPv4 = registration work? I am
> assuming FA CoA
> here. What does the FA do with a registration = request that
> has the MIP NAI
> extension, and has a NULL home address and home = agent address? Is this
> valid?
>
> Thanks,
> Vidya
>

------_=_NextPart_001_01C21E23.944602A0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 17:52:21 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18496 for ; Thu, 27 Jun 2002 17:52:20 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02973; Thu, 27 Jun 2002 15:53:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02353; Thu, 27 Jun 2002 14:52:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLphk7008199 for ; Thu, 27 Jun 2002 14:51:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RLph53008198 for mobile-ip-dist; Thu, 27 Jun 2002 14:51:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLpdk7008191 for ; Thu, 27 Jun 2002 14:51:40 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02137 for ; Thu, 27 Jun 2002 14:51:44 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25917 for ; Thu, 27 Jun 2002 14:51:44 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id C357A6A907; Fri, 28 Jun 2002 00:51:37 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 014D36A906 for ; Fri, 28 Jun 2002 00:51:35 +0300 (EEST) Message-ID: <3D1B8941.2040708@kolumbus.fi> Date: Fri, 28 Jun 2002 00:53:05 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] closing issue 50 (lifetimes) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Issue 50 has been split from issue #50 as the single remaining controversial item. Hesham's original complaint dealt with the lack of justification for the 5 minutes of lifetime for the RR-based BCEs. A discussion followed, different types of attacks were discussed and no real consensus or deep results were uncovered. But I'd like to note a few facts regardless: - The longer we make the lifetime, the longer an attacker can keep a binding that he created when he visited a network and forwarded the traffic of some node in the network to himself at another location (e.g. a home server). - On a bombing attack, the actual bombing effect comes right after you establish the binding. Since an attacker can forge TCP ACKs or similar, he will be able to keep the bombing on for as long as the BCE is alive. - We do not have a good quantitative model to describe the effects of the specific times to the seriousness of attacks. That is, even if we know that a change in the times changes the effects of attacks to some direction, we do not know exactly by how much. - Creating such a model is not likely to happen in the next few days. With the above things in mind, I'd like to suggest that we accept that we have only partial information available, pick a number that does not seem too troublesome from the security point of view but allows comfortable binding lengths, and use this number. The current lifetime in the spec is 5 mins. I'd like to suggest 7 mins in Draft 18. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 17:56:21 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18721 for ; Thu, 27 Jun 2002 17:56:21 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04746; Thu, 27 Jun 2002 15:57:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21662; Thu, 27 Jun 2002 14:56:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLtdk7008291 for ; Thu, 27 Jun 2002 14:55:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RLtdbR008290 for mobile-ip-dist; Thu, 27 Jun 2002 14:55:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RLtak7008280 for ; Thu, 27 Jun 2002 14:55:36 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21414 for ; Thu, 27 Jun 2002 14:55:41 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20961 for ; Thu, 27 Jun 2002 15:55:40 -0600 (MDT) 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 OAA21346; Thu, 27 Jun 2002 14:55:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5RLtc325835; Thu, 27 Jun 2002 14:55:38 -0700 X-mProtect: <200206272155> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3cyft5; Thu, 27 Jun 2002 14:55:36 PDT Message-ID: <3D1B89D9.3227364D@iprg.nokia.com> Date: Thu, 27 Jun 2002 14:55:37 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] closing issue 10 (esp vs ah) References: <3D1B8159.8090100@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > 1. In order for you to be able to use IPsec for multiple MNs, > you have to set the SPD entries so that one SA can only be > used with a particular source address. Otherwise, one > MN could use its SA to transport a BU for another MN. > > 2. If you have such SPD entries, then the attacker could indeed > modify the packet in flight, and it would still pass the MAC > checks. However, no modification would pass the SPD check, so > the attacker would not get anywhere. > > 3. If someone else tries to send a BU with my MN's HAO, he can't > forge the MAC for my SA. Again, the attacker doesn't get anywhere. > > In conclusion, I'd like to allow both AH and ESP, and I'd like to > remove the HoA field from the BU. Agree! Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 18:13:48 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19580 for ; Thu, 27 Jun 2002 18:13:48 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06468; Thu, 27 Jun 2002 15:14:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09523; Thu, 27 Jun 2002 15:13:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RMCqk7008430 for ; Thu, 27 Jun 2002 15:12:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RMCpvm008429 for mobile-ip-dist; Thu, 27 Jun 2002 15:12:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RMCmk7008422 for ; Thu, 27 Jun 2002 15:12:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09228 for ; Thu, 27 Jun 2002 15:12:53 -0700 (PDT) Received: from multihop.net (adsl-209-204-158-88.sonic.net [209.204.158.88]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12020 for ; Thu, 27 Jun 2002 16:12:52 -0600 (MDT) Received: from [192.168.1.42] (atlantis.kniveton.com [192.168.1.42]) by multihop.net (8.12.4/8.11.1) with ESMTP id g5RMClk1003744; Thu, 27 Jun 2002 15:12:49 -0700 (PDT) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.0.4 Date: Thu, 27 Jun 2002 15:12:41 -0700 Subject: Re: [mobile-ip] confusion about prefix sol/adv From: "T.J. Kniveton" To: Erik Nordmark CC: "Hesham Soliman (ERA)" , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, sorry my response reflexes have been slow lately.. > From: Erik Nordmark > Reply-To: Erik Nordmark > Date: Wed, 26 Jun 2002 12:09:41 +0200 (CEST) > To: "T.J. Kniveton" > Cc: "Hesham Soliman (ERA)" , Erik Nordmark > , mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] confusion about prefix sol/adv > >> Sure. If you have read Appendix A, or any of the MIP-list conversations >> about MPS/MPA and bootstrapping, then it does make sense: for any node that >> wants to store a minimum amount of info, it can use DNS, DHAD, and MPS to >> configure itself. After it has done DHAD, it knows all the home agents on >> the home link..but has not configured its own address. It sends an MPS with >> the CoA as source address. > > But how useful is this? > Is it merely a nice to have or is it a 'must' requirement? I guess it depends on your point of view. Things that were architected a while back as being the "right" way to do things might need to make way for more expediency. I don't have any objection to agree with your proposition that MNs must first configure an HoA with the same prefix as the HA. I believe the intent of the original mechanisms (tunneled router advertisement) was to keep the v6 stack and autoconfiguration virtually the same as it was for a non-mobile node. Since we hope a MN will know its HoA and have an SA almost all the time, then this still leaves a lot of breathing room for MPS with SA. Assuming we can get one to cover ICMP traffic. > > From an address space concern there should be no issue with having the > MN use a fixed interface id on the home link i.e. as long as the > home link doesn't renumber the MN uses a fixed HoA. > And the MN presumably knows its home interface ID (in its configuration, > on the Ethernet card, or in the SIM?). > In fact, if the MN doesn't know its interface ID I have no idea how > there could be an IPsec SA between the MN and HA for the BU > that prevents a MN from injecting a bogus BU for another MN which is using > the same HA. Thus as far as I can tell a fixed interface ID for the MN > is required in order to bootstrap the security needed for the home > registration > BU. Yes, I can buy the tradeoff that nodes that want mobility must be "more" configured (i.e. have the IID known by the HA, and have more config about the home network). That doesn't necessarily satisfy the finicky beast called IPsec. > > So the MN needs to know this plus the home subnet prefix; hence it needs > to know a possible Home Address for itself. Well it's not just knowing the home address -- basically the node must have an SA for that home address too, right? so we are assuming we can skip steps 1,2,3... and just start with an HoA (or quickly derive one), but already have the SA..meaning deriving the HoA might be the *easy* part. > > Erik > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 18:28:44 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20157 for ; Thu, 27 Jun 2002 18:28:43 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02827; Thu, 27 Jun 2002 16:29:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00252; Thu, 27 Jun 2002 15:29:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RMS1k7008581 for ; Thu, 27 Jun 2002 15:28:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RMS0Wo008580 for mobile-ip-dist; Thu, 27 Jun 2002 15:28:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RMRvk7008573 for ; Thu, 27 Jun 2002 15:27:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14934 for ; Thu, 27 Jun 2002 15:28:03 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA03838 for ; Thu, 27 Jun 2002 16:28:00 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5RMRwLH006467; Thu, 27 Jun 2002 15:27:58 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABY67740; Thu, 27 Jun 2002 15:25:04 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA18040; Thu, 27 Jun 2002 15:27:52 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15643.37224.131596.350617@thomasm-u1.cisco.com> Date: Thu, 27 Jun 2002 15:27:52 -0700 (PDT) To: Jari Arkko Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] closing issue 10 (esp vs ah) In-Reply-To: <3D1B8159.8090100@kolumbus.fi> References: <3D1B8159.8090100@kolumbus.fi> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko writes: > I'd like claim that such field is in fact not necessary. Here's > why: > > 1. In order for you to be able to use IPsec for multiple MNs, > you have to set the SPD entries so that one SA can only be > used with a particular source address. Otherwise, one > MN could use its SA to transport a BU for another MN. Jari, I'm not sure that understand/buy this prerequisite. I should be able to have multiple addresses covered by a single SA/SPI, right? This is irrespective of binding updates, and is just a general feature of IPsec. What we clearly want to prevent is a mobile node hijacking another node's legitimate use of an IP address on that subnet. But we clearly want mobile nodes to be able to use stateless autoconf and/or rfc 3041 addresses, most likely at the same time, and we want to allow the MN to use mobility for those addresses if it so desires. Thus, it seems to me that you have a way to protect multiple addresses under a single SPI for which it should be possible to change their attachment point (ie, send a BU). So, if we don't protect the HAO it would seem to me that an attacker could mount a DoS attack with one of your legitimate, but undesired home addresses when you send a BU, right? If we peak around the forbidden corner of, say, NEMO's a bit, I think it becomes even worse, right? Am I way off here? Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 27 18:53:41 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21240 for ; Thu, 27 Jun 2002 18:53:40 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA13799; Thu, 27 Jun 2002 16:54:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25186; Thu, 27 Jun 2002 15:54:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RMr9k7008848 for ; Thu, 27 Jun 2002 15:53:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5RMr9t0008847 for mobile-ip-dist; Thu, 27 Jun 2002 15:53:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5RMr6k7008840 for ; Thu, 27 Jun 2002 15:53:06 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22179 for ; Thu, 27 Jun 2002 15:53:11 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00448 for ; Thu, 27 Jun 2002 16:53:11 -0600 (MDT) Message-ID: <01a101c21e2d$2725b760$4f6015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" , References: <3D1B5CED.20009@kolumbus.fi> Subject: Re: [mobile-ip] Issue 20 (extensibility) can be closed Date: Thu, 27 Jun 2002 15:51:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari, I'm curious about whether ABK would fit into this scheme. Basically, we see ABK as not needing either HoTI or CoTI. The MN exchanges protocol with the CN instructing the CN to load the id-crypto parameters from the HA. After the parameters are loaded, the MN can send signed BUs to the CN without having to use any other security signaling. jak ----- Original Message ----- From: "Jari Arkko" To: Sent: Thursday, June 27, 2002 11:43 AM Subject: [mobile-ip] Issue 20 (extensibility) can be closed > I believe issue 20 -- about the extensibility of the > authorization mechanism to future schemes -- can be > closed with the following observation: > > Methods that extend RR with new mobility options can be > accommodated with the inclusion of these mobility options in the > HoTI and CoTI messages. A receiver that recognizes these options > will return corresponding options. A receiver that does not will > skip the options and behave as for RR. The sender will see this > and can abort the procedure by not sending a Binding Update, if > he so desires. > > Methods that extend RR with new message types can be accommodated, > as the peer will reply with the Binding Error (2) message if it > does not recognize the new message. > > No new text needed for this. > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 28 06:40:48 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18323 for ; Fri, 28 Jun 2002 06:40:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA09775; Fri, 28 Jun 2002 04:40:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA20766; Fri, 28 Jun 2002 03:39:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SAc8k7010151 for ; Fri, 28 Jun 2002 03:38:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SAc8Kv010150 for mobile-ip-dist; Fri, 28 Jun 2002 03:38:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SAc4k7010143 for ; Fri, 28 Jun 2002 03:38:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA20703 for ; Fri, 28 Jun 2002 03:38:09 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA04660 for ; Fri, 28 Jun 2002 04:38:07 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17620; Fri, 28 Jun 2002 06:37:17 -0400 (EDT) Message-Id: <200206281037.GAA17620@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ohnishi-mobileip-v6vpngateway-00.txt Date: Fri, 28 Jun 2002 06:37:17 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IPv6 VPN using Gateway Home Agent Author(s) : H. Ohnishi, K. Suzuki, Y. Takagi Filename : draft-ohnishi-mobileip-v6vpngateway-00.txt Pages : 18 Date : 27-Jun-02 Mobile IPv6 [Mobile IPv6] provides mobility functions for IPv6. It can also be used for public mobility services. One of the most important services is the VPN service enabling users to access their Intranets from outside. Mobile IP does notwork well with VPN, however, and this issue is being discussed in the Mobile IP WG [VPN problem]. This document proposes a simple mechanism that combines VPN and Mobile IP functions. This mechanism uses a hierarchical HA architecture and includes an HA with GW functions, called a Gateway Home Agent (GHA). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ohnishi-mobileip-v6vpngateway-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ohnishi-mobileip-v6vpngateway-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-ohnishi-mobileip-v6vpngateway-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: <20020627133207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ohnishi-mobileip-v6vpngateway-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ohnishi-mobileip-v6vpngateway-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020627133207.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 28 06:42:01 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18428 for ; Fri, 28 Jun 2002 06:42:01 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10309; Fri, 28 Jun 2002 04:41:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA05302; Fri, 28 Jun 2002 03:40:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SAdYk7010168 for ; Fri, 28 Jun 2002 03:39:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SAdXec010167 for mobile-ip-dist; Fri, 28 Jun 2002 03:39:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SAdTk7010160 for ; Fri, 28 Jun 2002 03:39:29 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA20812 for ; Fri, 28 Jun 2002 03:39:34 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA09423 for ; Fri, 28 Jun 2002 04:39:33 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17996; Fri, 28 Jun 2002 06:38:46 -0400 (EDT) Message-Id: <200206281038.GAA17996@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-perkins-mobileip-spi-00.txt Date: Fri, 28 Jun 2002 06:38:46 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SPI Option for Mobile IPv6 Authentication Data Option Author(s) : C. Perkins, V. Devarapalli Filename : draft-perkins-mobileip-spi-00.txt Pages : 4 Date : 27-Jun-02 This document specifies a new SPI (Security Parameters Index) option for use with the Binding Authorization Data option. The new SPI option allows for selection of a particular mobility security association to handle the case when several such security associations may exist between nodes exchanging messages containing a mobility header requiring authorization. The SPI value may be set during manual configuration of the security association between two nodes, for example a mobile node and its home agent, or between a mobile node and a favored correspondent node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-perkins-mobileip-spi-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-perkins-mobileip-spi-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-perkins-mobileip-spi-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: <20020627133328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-perkins-mobileip-spi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-perkins-mobileip-spi-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020627133328.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 28 07:00:39 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19380 for ; Fri, 28 Jun 2002 07:00:38 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05152; Fri, 28 Jun 2002 04:00:50 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA08758; Fri, 28 Jun 2002 04:00:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SAxck7010487 for ; Fri, 28 Jun 2002 03:59:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SAxc0W010486 for mobile-ip-dist; Fri, 28 Jun 2002 03:59:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SAxZk7010479 for ; Fri, 28 Jun 2002 03:59:35 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25916 for ; Fri, 28 Jun 2002 03:59:40 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13240 for ; Fri, 28 Jun 2002 03:59:39 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id F137C6A907; Fri, 28 Jun 2002 13:59:38 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 9ED1D6A906; Fri, 28 Jun 2002 13:59:37 +0300 (EEST) Message-ID: <3D1C41F3.7030404@kolumbus.fi> Date: Fri, 28 Jun 2002 14:01:07 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue 20 (extensibility) can be closed References: <3D1B5CED.20009@kolumbus.fi> <01a101c21e2d$2725b760$4f6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > Jari, > > I'm curious about whether ABK would fit into this scheme. > > Basically, we see ABK as not needing either HoTI or CoTI. The MN exchanges protocol with the CN instructing the CN to load the > id-crypto parameters from the HA. After the parameters are loaded, the MN can send signed BUs to the CN without having to use any > other security signaling. You could add new MH Message Types for the 'instructing' and 'loading'. If the CN does not support ABK i.e. these new types, it would return a Binding Error. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 28 07:43:24 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20902 for ; Fri, 28 Jun 2002 07:43:24 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19330; Fri, 28 Jun 2002 05:43:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA29838; Fri, 28 Jun 2002 04:41:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SBeWk7010704 for ; Fri, 28 Jun 2002 04:40:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SBeWVe010703 for mobile-ip-dist; Fri, 28 Jun 2002 04:40:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SBeTk7010696 for ; Fri, 28 Jun 2002 04:40:29 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA15449 for ; Fri, 28 Jun 2002 04:40:35 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05573 for ; Fri, 28 Jun 2002 05:40:34 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 609E66A907; Fri, 28 Jun 2002 14:40:33 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F2B2E6A906; Fri, 28 Jun 2002 14:40:31 +0300 (EEST) Message-ID: <3D1C4B8A.40605@kolumbus.fi> Date: Fri, 28 Jun 2002 14:42:02 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] closing issue 10 (esp vs ah) References: <3D1B8159.8090100@kolumbus.fi> <15643.37224.131596.350617@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > I'm not sure that understand/buy this > prerequisite. I should be able to have multiple > addresses covered by a single SA/SPI, right? This > is irrespective of binding updates, and is just a > general feature of IPsec. What we clearly want to > prevent is a mobile node hijacking another node's > legitimate use of an IP address on that subnet. > But we clearly want mobile nodes to be able to use > stateless autoconf and/or rfc 3041 addresses, most > likely at the same time, and we want to allow the > MN to use mobility for those addresses if it so > desires. Thus, it seems to me that you have a way > to protect multiple addresses under a single SPI > for which it should be possible to change their > attachment point (ie, send a BU). Yes, but how? Or are you suggesting that the MIPv6 code would know through an API that the packet it got was protected by a given SA or cert? Even if we did this, how would the HA know when a BU for an address is legal? When the given address has never been used by any other node? But wouldn't that imply that we store all and every addresses and their associations to SAs in the HA for ever? Or would the addresses be usable if no one else has registered them? But if the HA reboots then I could hijack everyone's address... > So, if we don't protect the HAO it would seem to > me that an attacker could mount a DoS attack with > one of your legitimate, but undesired home > addresses when you send a BU, right? Yes. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 28 09:00:46 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24224 for ; Fri, 28 Jun 2002 09:00:45 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17822; Fri, 28 Jun 2002 07:00:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA27793; Fri, 28 Jun 2002 05:59:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SCw8k7010986 for ; Fri, 28 Jun 2002 05:58:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SCw8gc010985 for mobile-ip-dist; Fri, 28 Jun 2002 05:58:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SCw5k7010978 for ; Fri, 28 Jun 2002 05:58:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21246 for ; Fri, 28 Jun 2002 05:58:11 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06727 for ; Fri, 28 Jun 2002 06:58:06 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5SCw4Rd029446; Fri, 28 Jun 2002 14:58:05 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jun 2002 14:58:02 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F07B3@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Jari Arkko'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] closing issue 50 (lifetimes) Date: Fri, 28 Jun 2002 14:57:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Thursday, June 27, 2002 11:53 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: [mobile-ip] closing issue 50 (lifetimes) > > > Issue 50 has been split from issue #50 as the single remaining > controversial item. Hesham's original complaint dealt with the > lack of justification for the 5 minutes of lifetime for the RR-based > BCEs. > > A discussion followed, different types of attacks were discussed > and no real consensus or deep results were uncovered. > > But I'd like to note a few facts regardless: > > - The longer we make the lifetime, the longer an attacker > can keep a binding that he created when he visited a > network and forwarded the traffic of some node in the network > to himself at another location (e.g. a home server). > > - On a bombing attack, the actual bombing effect comes right > after you establish the binding. Since an attacker can forge > TCP ACKs or similar, he will be able to keep the bombing > on for as long as the BCE is alive. > > - We do not have a good quantitative model to describe the > effects of the specific times to the seriousness of attacks. > That is, even if we know that a change in the times > changes the effects of attacks to some direction, we do not > know exactly by how much. > > - Creating such a model is not likely to happen in the next > few days. > > With the above things in mind, I'd like to suggest that we > accept that we have only partial information available, pick > a number that does not seem too troublesome from the security > point of view but allows comfortable binding lengths, and > use this number. > > The current lifetime in the spec is 5 mins. I'd like to suggest > 7 mins in Draft 18. > > Jari > => OK :) Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 28 11:16:46 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00385 for ; Fri, 28 Jun 2002 11:16:45 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23221; Fri, 28 Jun 2002 09:17:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01664; Fri, 28 Jun 2002 08:16:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SFFBk7011609 for ; Fri, 28 Jun 2002 08:15:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SFFB8g011608 for mobile-ip-dist; Fri, 28 Jun 2002 08:15:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SFF8k7011601 for ; Fri, 28 Jun 2002 08:15:08 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00742 for ; Fri, 28 Jun 2002 08:15:13 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21848 for ; Fri, 28 Jun 2002 09:15:13 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5SF5Er09281; Fri, 28 Jun 2002 10:05:22 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jun 2002 10:05:00 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E046AE600@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Vrizlynn Thing , Mobile IP Mailing List Cc: Xu Yi , Henry Subject: RE: [mobile-ip] New Draft: draft-vriz-mipv6-hbhlmap-00.txt Date: Fri, 28 Jun 2002 10:04:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21EB5.2BAD5990" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C21EB5.2BAD5990 Content-Type: text/plain; charset="iso-8859-1" Why did you believe you needed a new hop by hop header option? Was the existing router alert using a new protocol value deemed insufficient for some reason? Thanks, Glenn > -----Original Message----- > From: Vrizlynn Thing [mailto:vriz@lit.a-star.edu.sg] > Sent: Wednesday, June 26, 2002 11:04 PM > To: Mobile IP Mailing List > Cc: Xu Yi; Henry > Subject: [mobile-ip] New Draft: draft-vriz-mipv6-hbhlmap-00.txt > > > Hi all, > > I've recently submitted "draft-vriz-mipv6-hbhlmap-00.txt" to > the Mobile IP > Working Group. > It proposed a solution to provide support for Localized > Mobility Management > according to > requirements set out in > "draft-ietf-mobileip-lmm-requirements-01.txt" in > Mobile IPv6. > The detailed mechanisms and procedures are explained in the draft. > > Abstract: > > This document introduces an extension to Mobile IPv6 to provide > support for Localized Mobility Management. This proposed Hop-by-Hop > Local Mobility Agents Probing scheme specifies the Local Mobility > Agents Discovery, Selection and Failure Detection architecture and > procedures for deploying the localized mobility management, whereby > the Local Mobility Agents are distributed. It reduces the amount of > signalling to the home agent and correspondent nodes when mobile > node moves among the subnets of the visited domain. > > > This document can be found at the following URL: > http://www.ietf.org/internet-drafts/draft-vriz-mipv6-hbhlmap-00.txt > > Thank you. > > Best Regards, > Vrizlynn Thing (Ms) > > > > Vrizlynn Thing (Ms) > Senior Engineer > Laboratories for Information Technology > 21 Heng Mui Keng Terrace > Singapore 119613 > Tel: +65 68746728 > Fax: +65 6776 8109 > Email: vriz@lit.a-star.edu.sg > > ------_=_NextPart_001_01C21EB5.2BAD5990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] New Draft: = draft-vriz-mipv6-hbhlmap-00.txt

Why did you believe you needed a new hop by hop = header option? Was the existing router alert using a new protocol value = deemed insufficient for some reason?

Thanks,

Glenn

> -----Original Message-----
> From: Vrizlynn Thing [mailto:vriz@lit.a-star.edu.sg= ]
> Sent: Wednesday, June 26, 2002 11:04 PM
> To: Mobile IP Mailing List
> Cc: Xu Yi; Henry
> Subject: [mobile-ip] New Draft: = draft-vriz-mipv6-hbhlmap-00.txt
>
>
> Hi all,
>
> I've recently submitted = "draft-vriz-mipv6-hbhlmap-00.txt" to
> the Mobile IP
> Working Group.
> It proposed a solution to provide support for = Localized
> Mobility Management
> according to
> requirements set out in
> = "draft-ietf-mobileip-lmm-requirements-01.txt" in
> Mobile IPv6.
> The detailed mechanisms and procedures are = explained in the draft.
>
> Abstract:
>
>    This document introduces an = extension to Mobile IPv6 to provide
>    support for Localized = Mobility Management. This proposed Hop-by-Hop
>    Local Mobility Agents Probing = scheme specifies the Local Mobility
>    Agents Discovery, Selection = and Failure Detection architecture and
>    procedures for deploying the = localized mobility management, whereby
>    the Local Mobility Agents are = distributed. It reduces the amount of
>    signalling to the home agent = and correspondent nodes when mobile
>    node moves among the subnets = of the visited domain.
>
>
> This document can be found at the following = URL:
> http://www.ietf.org/internet-drafts/draft-vriz-mipv6-h= bhlmap-00.txt
>
> Thank you.
>
> Best Regards,
> Vrizlynn Thing (Ms)
>
>
>
> Vrizlynn Thing (Ms)
> Senior Engineer
> Laboratories for Information Technology
> 21 Heng Mui Keng Terrace
> Singapore 119613
> Tel: +65 68746728
> Fax: +65 6776 8109
> Email: vriz@lit.a-star.edu.sg
>
>

------_=_NextPart_001_01C21EB5.2BAD5990-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 28 11:40:54 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01572 for ; Fri, 28 Jun 2002 11:40:53 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18059; Fri, 28 Jun 2002 08:40:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20271; Fri, 28 Jun 2002 08:38:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SFblk7011749 for ; Fri, 28 Jun 2002 08:37:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SFblkX011748 for mobile-ip-dist; Fri, 28 Jun 2002 08:37:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SFbhk7011741 for ; Fri, 28 Jun 2002 08:37:43 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19993 for ; Fri, 28 Jun 2002 08:37:49 -0700 (PDT) Received: from rigel.cs.pdx.edu (rigel.cs.pdx.edu [131.252.208.59]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19896 for ; Fri, 28 Jun 2002 09:37:49 -0600 (MDT) Received: from sirius.cs.pdx.edu (root@sirius.cs.pdx.edu [131.252.208.57]) by rigel.cs.pdx.edu (8.12.3/8.12.3) with ESMTP id g5SFbmkC029079 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 28 Jun 2002 08:37:48 -0700 (PDT) Received: from sirius.cs.pdx.edu (sashi@localhost [127.0.0.1]) by sirius.cs.pdx.edu (8.12.3/8.12.3) with ESMTP id g5SFbmSw019990 for ; Fri, 28 Jun 2002 08:37:48 -0700 (PDT) Received: from localhost (sashi@localhost) by sirius.cs.pdx.edu (8.12.3/8.12.3/Submit) with ESMTP id g5SFbmi5019987 for ; Fri, 28 Jun 2002 08:37:48 -0700 (PDT) Date: Fri, 28 Jun 2002 08:37:48 -0700 (PDT) From: Sashikiran Rachakonda To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] tunnel back to home agent Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Kernel Version : Linux 2.4 Prob Descrp : When a mobile node goes into a foreign network, it acts as a dhcp client and gets a new address. I bind this new address to eth0 and the mobile node's home address to a tunnel device,the remote end of the tunnel being the address of the home agent. The idea is to tunnel back to home from mobile node. That way the packets that leave the mobile node first reach the home agent and get routed from there, as if the mobile node is at home. Hence if i say ping w.x.y.z from the mobile node, the out going ip packet should appear as follows ------------------------> ------ --------------------------------------------------------- | mobile node's | | mobile node's | home agent's| ..... | home address |w.x.y.z| address obtained| address | | | | thru dhcp | | ----- --------------------------------------------------------- src des src des After setting the tunnel up, i try to add a default route to it as follows # route add default gw (home agent's address) dev (tunnel-name) It says Network Unreacheable. So, i try to do this # route add -host (home agent's address) gw (default router address obtained thru dhcp) dev (tunnel-name) It says Network Unreacheable. And some more along these lines. Nothing seems to work. Can anybody help with this? Thanx in advance Sashi Sashikiran Rachakonda 1880 SW 5th Portland, OR- 97207 PH: 503-223-4560 From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 28 13:08:14 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07389 for ; Fri, 28 Jun 2002 13:08:13 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11453; Fri, 28 Jun 2002 11:07:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21335; Fri, 28 Jun 2002 10:06:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SH58k7012096 for ; Fri, 28 Jun 2002 10:05:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SH583O012095 for mobile-ip-dist; Fri, 28 Jun 2002 10:05:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SH56k7012088 for ; Fri, 28 Jun 2002 10:05:06 -0700 (PDT) Received: from new-atlantic.east.sun.com (ss-snt-router.East.Sun.COM [129.148.253.13]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01915 for ; Fri, 28 Jun 2002 13:05:12 -0400 (EDT) Received: (from glass@localhost) by new-atlantic.east.sun.com (8.9.3+Sun/8.9.3) id NAA09576 for mobile-ip@sunroof.eng.sun.com; Fri, 28 Jun 2002 13:05:12 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5QMqBk7003638 for ; Wed, 26 Jun 2002 15:52:12 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24728 for ; Wed, 26 Jun 2002 15:52:17 -0700 (PDT) Received: from deimos.hpl.hp.com (deimos.hpl.hp.com [192.6.19.190]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28453 for ; Wed, 26 Jun 2002 15:52:17 -0700 (PDT) Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by deimos.hpl.hp.com (8.9.3 (PHNE_24419)/HPL-PA Relay) with ESMTP id PAA18211; Wed, 26 Jun 2002 15:52:16 -0700 (PDT) Received: from hplex1.hpl.hp.com (hplex1.hpl.hp.com [15.0.152.182]) by hplms2.hpl.hp.com (8.10.2/8.10.2 HPL-PA Hub) with SMTP id g5QMqFd25703; Wed, 26 Jun 2002 15:52:16 -0700 (PDT) Received: from 15.0.152.182 by hplex1.hpl.hp.com (InterScan E-Mail VirusWall NT); Wed, 26 Jun 2002 15:52:14 -0700 Received: by hplex1.hpl.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 15:52:14 -0700 Message-ID: <40700B4C02ABD5119F000090278766445336DD@hplex1.hpl.hp.com> From: "Lee, Sung Ju" To: "'sjlee@hpl.hp.com'" Subject: [mobile-ip] MobiCom CFPosters Date: Wed, 26 Jun 2002 15:52:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: ACM MobiCom 2002: Call for Student Posters! http://www.acm.org/sigmobile/mobicom/2002/cfp/posters.html ACM MobiCom 2002 is the eighth annual conference sponsored by ACM SIGMOBILE dedicated to addressing new challenges in mobile computing and networking. The MobiCom 2002 conference solicits student posters describing new and noteworthy research contributions to the field of mobile computing and networking. Student Posters: The conference solicits student posters that highlight recent and on-going research by students on mobile computing topics. Areas of interest include those that are listed on the technical paper call for papers, which can be found at http://www.acm.org/sigmobile/mobicom/2002/cfp/. Proposals should be a maximum of TWO pages in length and, while they don't need to describe completed work, the work should be advanced beyond the initial stages. The first author of all poster submissions must be a student. Poster abstracts will not be published in the proceedings but will instead be published on the web before the conference. Poster submissions will be reviewed. Authors of accepted papers must not submit a poster of the work they present in the conference. Submissions should be sent by email to Elizabeth Belding-Royer (ebelding@cs.ucsb.edu) by July 15, 2002. Why should you submit a poster? This is a great chance for students to obtain interesting and valuable feedback on on-going work from a knowledgeable crowd at the conference. What is a poster? A poster is a 1 meter x 1.25 meter rectangular board on which you can affix visually appealing material that describes your research. How you use this is up to you: you may choose to print out several 8.5"x11" or A4 sheets of paper (e.g., paper copies of overheads) and "tile" the poster board with these pages. Or, you may choose to print a single large sheet of paper describing the work and attach that to the poster board. You may bring your own poster boards if you like. Several document companies like Kinko's produce professional-looking posters from material produced on software like Powerpoint; you may want to use such a facility. You should prepare the best material (visually appealing and succinct) that effectively communicates your research problem, techniques, and results. What, when, and where to submit? If you are a student and are interested in this, then submit the following by July 15, 2002 by email to Elizabeth Belding-Royer (ebelding@cs.ucsb.edu): 1. A maximum TWO page description (in either postscript, txt, or pdf format only!) describing the research to be presented in the poster. Include the title, authors, and institutional affiliations. 2. A draft of the poster material (either multiple "tiles" or a single sheet of paper), in pdf or postscript format. Include the title, authors, and institutional affiliations. Send your submission in one email message with the two parts. We will select approximately 20 of the most interesting and thought-provoking posters by August 7, 2002 and notify all contact authors. More details will be sent at that time. Student Posters Co-Chairs: Elizabeth Belding-Royer, UC Santa Barbara ebelding@cs.ucsb.edu Sung-Ju Lee, Hewlett Packard Laboratories sjlee@hpl.hp.com From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 28 13:30:55 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08818 for ; Fri, 28 Jun 2002 13:30:50 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15876; Fri, 28 Jun 2002 11:30:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24169; Fri, 28 Jun 2002 10:29:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SHS4k7012396 for ; Fri, 28 Jun 2002 10:28:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SHS36n012395 for mobile-ip-dist; Fri, 28 Jun 2002 10:28:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SHS0k7012388 for ; Fri, 28 Jun 2002 10:28:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23775 for ; Fri, 28 Jun 2002 10:28:05 -0700 (PDT) Received: from melete.ch.intel.com (chfdns02.ch.intel.com [143.182.246.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14675 for ; Fri, 28 Jun 2002 11:28:05 -0600 (MDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by melete.ch.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g5SHS4b12716 for ; Fri, 28 Jun 2002 17:28:04 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002062810283019079 for ; Fri, 28 Jun 2002 10:28:30 -0700 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 Jun 2002 10:28:04 -0700 Message-ID: From: "Liu, Changwen" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] I-D ACTION:draft-ohnishi-mobileip-v6vpngateway-00 .txt Date: Fri, 28 Jun 2002 10:28:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I read through the draft and here is my quick observation/comment on this draft: Unlike MIPv4, MIPv6 (as of draft 17) has better authorization specification for binding update. For example, in order to avoid unauthorized binding update for a MNv6, "the security policy database entries MUST unequivocally identify a single SA for any given home address and home agent" in MIPv6 while MIPv4 SA doesn't has this restriction. In other words, if the GHA can send binding update to MIPv6 HA for a MNv6, the MNv6 loses its capability for sending binding update to its own MIPv6 HA. Hence no matter where MNv6 roams to, all MNv6 data traffic has to go through GHA and a lot of traffic has to go through the path HA-GHA. The routing for MNv6 can never be fully optimized as specified in MIPv6 and triangular routing is unavoidable. If one wants support full routing optimization for VPN traversal, it seems that the aforementioned line in MIPv6 specification may need to be changed slightly to allow more than one SAs for updating any given home address and home agent pair. My two cents. changwen > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, June 28, 2002 3:37 AM > Cc: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] I-D > ACTION:draft-ohnishi-mobileip-v6vpngateway-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Mobile IPv6 VPN using Gateway Home Agent > Author(s) : H. Ohnishi, K. Suzuki, Y. Takagi > Filename : draft-ohnishi-mobileip-v6vpngateway-00.txt > Pages : 18 > Date : 27-Jun-02 > > Mobile IPv6 [Mobile IPv6] provides mobility functions for IPv6. It > can also be used for public mobility services. One of the most > important services is the VPN service enabling users to access their > Intranets from outside. Mobile IP does notwork well with VPN, > however, and this issue is being discussed in the Mobile IP WG [VPN > problem]. This document proposes a simple mechanism that combines > VPN and Mobile IP functions. This mechanism uses a hierarchical HA > architecture and includes an HA with GW functions, called a Gateway > Home Agent (GHA). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ohnishi-mobileip-v6v pngateway-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ohnishi-mobileip-v6vpngateway-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-ohnishi-mobileip-v6vpngateway-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. From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 28 15:16:23 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15722 for ; Fri, 28 Jun 2002 15:16:23 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14721; Fri, 28 Jun 2002 12:15:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12898; Fri, 28 Jun 2002 12:14:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SJD3k7012792 for ; Fri, 28 Jun 2002 12:13:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SJD3jS012790 for mobile-ip-dist; Fri, 28 Jun 2002 12:13:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SJD0k7012781 for ; Fri, 28 Jun 2002 12:13:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03420 for ; Fri, 28 Jun 2002 12:13:06 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA09891 for ; Fri, 28 Jun 2002 13:13:04 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 991CF6A907; Fri, 28 Jun 2002 22:12:48 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BD3386A906 for ; Fri, 28 Jun 2002 22:12:28 +0300 (EEST) Message-ID: <3D1CB576.400@kolumbus.fi> Date: Fri, 28 Jun 2002 22:13:58 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Issue 51: cookie lengths Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here's a new issue that was originally brought up by Charlie, and then Tuomas Aura and myself studied it. Background: Current specification has 32 bit mobile cookies, 128 bit home and care-of cookies, and 96 bit authenticators. Question: Charlie Perkins asks: Can the cookie lengths for mobile, home, and care-of cookies be smaller? Is it necessary to have 32 and 128 bits? Proposal: From Tuomas Aura and Jari Arkko: After some analysis, we think it would be safe to have the home and care-of cookies as 64 bits. On the other hand, it seems that mobile cookies are too short if we set them at 16 bits, so they have to be at least 32 bits. Taking in account alignment / padding requirements, if we have more than 16 bits we might as well make them 64 bits without wasting any more bandwidth. As a result, this proposal does not change the size of the HOTI/COTI messages, but reduces the size of the HOT/COT messages by 8 bytes. Size of all mobile cookies will be 64 bits, and home and care-of cookies will also be 64 bits. Some fragments of analysis follows. HOME COOKIE: Guessing a home cookie would allow the attacker to defeat the return routability procedure, even outside the HA-CN path. At the worst case, it would allow the attacker to get access to traffic destined somewhere else. Here's an attack scenario: 1. Victim V is a stationary node (for instance). 2. Attacker A is anywhere on the Internet. 3. The goal is to steal traffic some CN, C, sends to V. 4. Send a HOT to C to figure out its current nonce index. The home address used does not matter, it can be the attacker's address A. 5. Send a COT from A to C, to get a valid cookie and care-of nonce index. 6. Send 231 packets from A to C, with the valid care-of cookie, guessed home cookie, and a nonce index retrieved earlier (or something slightly higher) 7. C will install a BCE for V, point to coa=A for the first packet that happens to have a matching cookie. Is this feasible? Assuming each packet in step 6 is about 100 bytes, we need about 231 * 100 * 8 bits of bandwidth to do this attack, i.e. about 4.7 hours at 100 mbit/s -- and the BCE would last for 5 minute. So while not quite practical at the moment, it seems feasible that at some future time network bandwidths are big enough to make this attack possible in some cases. But repeating 2^64 packets is not feasible, so this length is recommended. CARE-OF COOKIE: The primary purpose of the care-of cookie in CoT is to verify that the mobile is at the CoA. Otherwise, the attacker could be redirect data to that address. I think 32 bits should be enough for this cookie. It means that the attacker needs to send in the order of 232 false BUs to the correspondent in order to trick it into accepting one. However, perhaps it doesn't make sense to keep very different lengths for similar cookies in the protocol, so 64 bits is recommended for this as well. MOBILE COOKIES: The primary purpose of Mobile Cookies 1 and 2 is to prevent the attacker blindly sending a flood of CoT and HoT messages, so that the mobile always picks a false CoT or HoT instead of an authentic one. The result is that the correspondent rejects all BUs and route optimization fails (but see below for a more serious attack). This is not so serious. So it would seem that 16 bits is enough (but see below). It means that the blind attacker has to send in the order of 216 false CoT or HoT messages / authentic CoTI-HoTI pair. But all the cookies serve a secondary purpose: BA authentication. If the attacker is able to send false BAs, it can make believe that the BU has been accepted even if it has not. The result is that he mobile will send data directly to the correspondent, which will reject it. Thus, the nodes will be unable to communicate. The BA authentication work like this: The correspondent must be able to receive both mobile cookies, one sent from CoA directly and the other via HoA. The correct values of the mobile cookies in CoT and HoT convince the mobile that these messages likely came from the authentic correspondent. Thus, the mobile can also believe that the care-of cookie and the home cookie were sent by the authentic correspondent. This means that if the attacker spoofs CoT and HoT, it not only prevents route optimization but can also spoof BA and, thus, prevent the mobile and correspondent from communicating! This attack is just as serious as having a false BU accepted. A typical implementation of the mobile would probably reject any CoT or HoT with the wrong mobile cookie value, and wait until it has received at least one CoT and at least one HoT with the correct cookie. This means that if the mobile cookies are 16 bits each, the attacker has to send around 216+216 = 217 messages / authentic CoT-HoT pair in order to spoof both of these messages. After that, the correspondent will reject the mobile's BU message as unauthentic and the attacker can send a false BA (because it knows K_bu). What makes things slightly worse is that if the attacker can eavesdrop mobile cookie 2 in CoTI, it suffices to guess the other mobile cookie on HoTI. Thus, the attacker on the MN-CN path only needs to send 216 false CoT messages / authentic CoT-HoT pair. (Skip this paragraph if you agree with the above. -- A different implementation could reject the CoT or HoT (which have correct mobile cookie values) if it receives any false CoT or HoT messages (which have wrong mobile cookie values) between the correct ones. This would increase the cost of the above attack to 216*216 = 232 for the nodes that cannot eavesdrop CoTI. But it would also make it very easy for the attacker to prevent route optimization by sending a few false CoT messages.) The sequence number in BA helps against attackers who are not on the MN-CN route. I'm not sure how many bits it is going to be and how much entropy there is. Obviously, a real cookie in BU/BA would be better. Nevertheless, 16 bits + the sequence number is probably enough to prevent attackers who are not on the MN-CM route from creating false BUs. Both the sequence number and the BU/BA cookie suffer from the fact that an attacker on the BA/CN route can hear them. This leads me to think that mobile cookie 1 on HoT needs to be longer than mobile cookie 2 in CoT. My conclusion is that mobile cookie 1 in HoTI/HoT should be as long as the home cookie in HoT/BU. 32 bits should be enough. Mobile cookie 2 can be shorter, perhaps 16 bits is enough. That way, the cost of a DoS attack that prevents communication between the mobile and the correspondent is approximately equal regardless of whether the attacker uses false BUs or false BAs for the attack. So, setting mobile cookie 1 to 64 bits makes it as longs as the home cookie. But perhaps it doesn't make sense to have the other mobile cookies as different lengths, so we recommend them to be 64 bits as well. From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 28 15:56:44 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18172 for ; Fri, 28 Jun 2002 15:56:43 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04301; Fri, 28 Jun 2002 13:56:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29738; Fri, 28 Jun 2002 12:55:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SJrYk7012988 for ; Fri, 28 Jun 2002 12:53:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SJrXPx012987 for mobile-ip-dist; Fri, 28 Jun 2002 12:53:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SJrTk7012980 for ; Fri, 28 Jun 2002 12:53:30 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29151 for ; Fri, 28 Jun 2002 12:53:36 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06917 for ; Fri, 28 Jun 2002 13:53:35 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id E0D686A907; Fri, 28 Jun 2002 22:53:28 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7313E6A906; Fri, 28 Jun 2002 22:53:27 +0300 (EEST) Message-ID: <3D1CBF11.9020209@piuha.net> Date: Fri, 28 Jun 2002 22:54:57 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "T.J. Kniveton" Cc: Erik Nordmark , "Hesham Soliman (ERA)" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] confusion about prefix sol/adv References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit T.J. Kniveton wrote: > Yes, I can buy the tradeoff that nodes that want mobility must be "more" > configured (i.e. have the IID known by the HA, and have more config about > the home network). That doesn't necessarily satisfy the finicky beast called > IPsec. Right. >>So the MN needs to know this plus the home subnet prefix; hence it needs >>to know a possible Home Address for itself. >> > > Well it's not just knowing the home address -- basically the node must have > an SA for that home address too, right? so we are assuming we can skip steps > 1,2,3... and just start with an HoA (or quickly derive one), but already > have the SA..meaning deriving the HoA might be the *easy* part. True. But on the other hand, as has been discussed a possible home address indeed is available for the mobile node. This does not mean that the discovery process is useless - it might be that another home address is discovered through it, e.g. during renumbering. I agree that having the SA is the hard part. I really needs to be configured, and this is a change from the regular IPv6 ND situation, where the connectivity proves your right to ask and get information. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 28 16:12:18 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19203 for ; Fri, 28 Jun 2002 16:12:18 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15434; Fri, 28 Jun 2002 14:11:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24168; Fri, 28 Jun 2002 13:10:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SK8pk7013128 for ; Fri, 28 Jun 2002 13:08:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SK8pb6013127 for mobile-ip-dist; Fri, 28 Jun 2002 13:08:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SK8mk7013120 for ; Fri, 28 Jun 2002 13:08:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05863 for ; Fri, 28 Jun 2002 13:08:51 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05028 for ; Fri, 28 Jun 2002 13:08:51 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 602716A907; Fri, 28 Jun 2002 23:08:50 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E853E6A906 for ; Fri, 28 Jun 2002 23:08:48 +0300 (EEST) Message-ID: <3D1CC2AB.4080702@kolumbus.fi> Date: Fri, 28 Jun 2002 23:10:19 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] closing the sol/adv security issue Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, We need to close this issue and move on. Over the course of the discussion a number of observations and comments have been made. There seems to be some amount of disagreement about the level of security needed. We have also debated the order of events, the specific protocol that should carry the discovery messages, what information the MNs need to have at startup anyway, and so on. How to agree then? Given disagreement about the security level, perhaps it would be easiest to accept the tougher requirements. The question is, does this cause problems for us? Fortunately, this does appear to be so. As has been discussed, an SA and a potential home address is available in any case for the MN, so perhaps these could be used. Also, we have discussed whether protecting ICMPv6 would cause additional problems. I don't think it will -- if a packet matches the SPD entry it will be protected to the home agent. If not it, it will be sent in the clear. Either way, the HA will get even ICMP errors and other messages. A separate SA should be used for MH and ICMPv6. We have also discussed whether to use MH or ICMPv6 for the messages. My proposal is that we stick to the current approach, i.e. ICMPv6 to avoid too much document (and implementation) change. So here's a proposal on how to move forward: 1. Keep the current messages and functionality. 2. Require that all sol/adv messages be protected. 3. Document the fact that the mobile nodes can have some home address to begin with, and must in any case have SA(s). Ok? Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 28 18:01:04 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24846 for ; Fri, 28 Jun 2002 18:01:04 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27406; Fri, 28 Jun 2002 15:00:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09602; Fri, 28 Jun 2002 14:58:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SLvok7013403 for ; Fri, 28 Jun 2002 14:57:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SLvoZe013402 for mobile-ip-dist; Fri, 28 Jun 2002 14:57:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SLvlk7013395 for ; Fri, 28 Jun 2002 14:57:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09224 for ; Fri, 28 Jun 2002 14:57:52 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22928 for ; Fri, 28 Jun 2002 14:57:51 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id D5A536A907; Sat, 29 Jun 2002 00:57:44 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 33F636A906; Sat, 29 Jun 2002 00:57:43 +0300 (EEST) Message-ID: <3D1CDC30.5080103@piuha.net> Date: Sat, 29 Jun 2002 00:59:12 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Cc: James Kempf , Srinivasan.Damodaran@lntinfotech.com, Samita Chakrabarti Subject: [mobile-ip] closing issue 48, identifying link changes and prev-coa References: <3D11F3CB.8050700@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yet another issue to close. If you remember the discussion, this was about the default router that turned to a non-default router. This causes the mobile node to go for another default router on the same link, per rules of the movement detection section. Since the old router is no longer in the default router list, the MN thinks it has changed link, and may send a BU to the "previous HA". This will however fail since the old HA will try to do DAD, which the MN itself will respond to. Even if prefixes between the routers differ, the link local address will be the same, so the MN will answer a DAD query if the 'L' bit was on. We also discussed whether it makes sense to keep the previous coa functionality in the draft at all, and the application of SEND techniques in this space. We also noted that we don't enough experience to say exactly how security policies can be configured for the prev coa forwarding to work, and we are not sure it is practical to configure per MN SAs on the routers on the places you might be moving in. I have a primary proposal on how to go forward. This is based on the observation that the original situation isn't very typical, so we shouldn't try to optimize it. It is sufficient to ensure that nothing horrible happens. So, we don't care even if the forwarding from previous coa would fail in this situation, or if some unnessary tunneling would take place. As long as the current coa works well and nothing breaks in the old coa, we are happy. Forwarding from previous coa should of course work in the usual case when you actually move to another link. The proposal is that we allow MNs to request forwarding from previous CoA. We do not require them to be aware that they might possibly be on the same link due to one of the routers no longer being a default router. What happens then is that forwarding-from-previous-coa is requested. We require the 'D' and 'L' bits to be set in such BUs. This leads the HA to run DAD, which should fail as the link local address is still in use on the same physical link. Then, no forwarding will be done. (But this is fine, as the packets will normally come to the link anyway.) Does this work for everyone? (A possible backup proposal: drop this functionality and deal with it in another spec.) Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 28 18:24:52 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25893 for ; Fri, 28 Jun 2002 18:24:51 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10448; Fri, 28 Jun 2002 16:23:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10896; Fri, 28 Jun 2002 15:22:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SMLSk7013542 for ; Fri, 28 Jun 2002 15:21:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5SMLSsb013541 for mobile-ip-dist; Fri, 28 Jun 2002 15:21:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5SMLOk7013534 for ; Fri, 28 Jun 2002 15:21:25 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17530 for ; Fri, 28 Jun 2002 15:21:30 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09508 for ; Fri, 28 Jun 2002 16:21:29 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 9BEA36A907; Sat, 29 Jun 2002 01:21:23 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E80926A906 for ; Sat, 29 Jun 2002 01:21:21 +0300 (EEST) Message-ID: <3D1CE1BB.9000600@kolumbus.fi> Date: Sat, 29 Jun 2002 01:22:51 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Issue 49 (rfc 3041 or new prefixes and manual SAs) References: <3D1B8450.5050704@kolumbus.fi> <3D1B8706.5D8510F6@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit And more issues to close... I've had a discussion about this issue with a couple of people. The general feeling seems to be that making mobility work with privacy in a seamless and secure way may not be achievable right now. Or rather, it shouldn't be a requirement for the first version of the MIPv6 RFC. Let me highlight some of the issues involved in this: * On manually keyed IPsec SAs we have the problem of binding the SAs to the IP addresses, leading to a need for manual intervention when addresses change. * Security schemes that are not directly bound to addresses could also be used. But even these schemes have to deal with a few non-trivial questions, such as who has the authority to send a BU for a specific address to the HA? The very first authenticated MN to come up with that address? But then we'd have to store all addresses that have ever been used. Or perhaps we could allow the address to be used if no one else has a binding for it at the moment, or DAD succeeds? But what if I hijack everyone else's addresses after the HA reboots? * On certificate-based IPsec, one can use addresses in the Subject AltName field to force the HA to allow only the given address for the owner of that certificate. This would minimize configuration at the HA, but would bind every MN to their given addresses. * For renumbering, it is conceivable that the HA/CA could make new certificates for the same MN/public key but with the new address. But isn't clear how these are pushed to the MNs in the easiest manner. * For RFC 3041, the problem is harder because the MN has the initiative. Perhaps the MN could request a new SA/cert using its old address/SA/cert. Solving all of the above may not be possible in the immediate future and definately not before Monday 9 AM. So, I have the following proposal: - We keep on allowing RFC 3041 home addresses and new prefixes. - We point out that in order to use these, one must have e.g. manually configured SAs suitable for the new addresses. - We point out that future specifications will deal with this problem in a more complete manner. Does this work for everyone? Jari From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 29 00:42:16 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07402 for ; Sat, 29 Jun 2002 00:42:16 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA24871; Fri, 28 Jun 2002 21:42:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA11578; Fri, 28 Jun 2002 21:42:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5T4f7k7014157 for ; Fri, 28 Jun 2002 21:41:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5T4f730014156 for mobile-ip-dist; Fri, 28 Jun 2002 21:41:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5T4f4k7014149 for ; Fri, 28 Jun 2002 21:41:04 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA11452 for ; Fri, 28 Jun 2002 21:41:09 -0700 (PDT) From: vriz@lit.a-star.edu.sg Received: from lit.a-star.edu.sg (rodin.krdl.org.sg [192.122.139.27]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA10076 for ; Fri, 28 Jun 2002 22:41:07 -0600 (MDT) Received: from mailhost1 (localhost [127.0.0.1]) by lit.a-star.edu.sg (8.11.1/8.11.1) with ESMTP id g5T4eK127669 for ; Sat, 29 Jun 2002 12:40:20 +0800 (SGT) Received: from lit.org.sg (localhost [127.0.0.1]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 HotFix 0.5 (built Jun 7 2002)) with ESMTP id <0GYG00KGHADA88@mailhost.lit.org.sg> for mobile-ip@sunroof.eng.sun.com; Sat, 29 Jun 2002 12:41:41 +0800 (SGT) Received: from [192.122.139.152] by mailhost.lit.org.sg (mshttpd); Sat, 29 Jun 2002 12:41:34 +0800 Date: Sat, 29 Jun 2002 12:41:34 +0800 Subject: Re: [mobile-ip] New Draft: draft-vriz-mipv6-hbhlmap-00.txt To: Glenn Morrow Cc: Mobile IP Mailing List , Xu Yi , Henry Message-id: <3784e366a0.366a03784e@lit.org.sg> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 0.5 (built Jun 7 2002) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Dear Glenn, In this draft, what the mobile node intends to do is to discover the gateway local mobility agent (LMA) and intermediate LMAs (for redundancy purpose) for regional registration. The furthest operational LMA is then chosen. Therefore, an ICMPv6 Echo Request message is sent to the Home Agent as a probe trigger. In it, the new hop-by-hop (hbh) option is included for processing by the LMAs en-route. Unlike the specifications in RFC 2711: IPv6 Router Alert Option, whereby the first three bits of the option type are zero, and does not allow modifications to the option en-route, our new option has the first three bits set to '001'. This allows the option to change en-route so as to update the counter value for furthest operational LMA detection. I hope that the above has answered your questions. Thank you. Best Regards, Vrizlynn Thing (Ms) ----- Original Message ----- From: Glenn Morrow Date: Friday, June 28, 2002 11:04 pm Subject: RE: [mobile-ip] New Draft: draft-vriz-mipv6-hbhlmap-00.txt > Why did you believe you needed a new hop by hop header option? Was the > existing router alert using a new protocol value deemed > insufficient for > some reason? > > Thanks, > > Glenn > > > -----Original Message----- > > From: Vrizlynn Thing [mailto:vriz@lit.a-star.edu.sg] > > Sent: Wednesday, June 26, 2002 11:04 PM > > To: Mobile IP Mailing List > > Cc: Xu Yi; Henry > > Subject: [mobile-ip] New Draft: draft-vriz-mipv6-hbhlmap-00.txt > > > > > > Hi all, > > > > I've recently submitted "draft-vriz-mipv6-hbhlmap-00.txt" to > > the Mobile IP > > Working Group. > > It proposed a solution to provide support for Localized > > Mobility Management > > according to > > requirements set out in > > "draft-ietf-mobileip-lmm-requirements-01.txt" in > > Mobile IPv6. > > The detailed mechanisms and procedures are explained in the draft. > > > > Abstract: > > > > This document introduces an extension to Mobile IPv6 to provide > > support for Localized Mobility Management. This proposed Hop- > by-Hop > > Local Mobility Agents Probing scheme specifies the Local Mobility > > Agents Discovery, Selection and Failure Detection > architecture and > > procedures for deploying the localized mobility management, > whereby> the Local Mobility Agents are distributed. It reduces > the amount of > > signalling to the home agent and correspondent nodes when mobile > > node moves among the subnets of the visited domain. > > > > > > This document can be found at the following URL: > > http://www.ietf.org/internet-drafts/draft-vriz-mipv6-hbhlmap-00.txt > > > > Thank you. > > > > Best Regards, > > Vrizlynn Thing (Ms) > > > > > > > > Vrizlynn Thing (Ms) > > Senior Engineer > > Laboratories for Information Technology > > 21 Heng Mui Keng Terrace > > Singapore 119613 > > Tel: +65 68746728 > > Fax: +65 6776 8109 > > Email: vriz@lit.a-star.edu.sg > > > > > From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 29 01:06:39 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07799 for ; Sat, 29 Jun 2002 01:06:39 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA03161; Fri, 28 Jun 2002 22:06:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA15018; Fri, 28 Jun 2002 22:06:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5T54rk7014291 for ; Fri, 28 Jun 2002 22:04:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5T54r2p014290 for mobile-ip-dist; Fri, 28 Jun 2002 22:04:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5T54ok7014283 for ; Fri, 28 Jun 2002 22:04:50 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA14799 for ; Fri, 28 Jun 2002 22:04:55 -0700 (PDT) From: vriz@lit.a-star.edu.sg Received: from lit.a-star.edu.sg (rodin.krdl.org.sg [192.122.139.27]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA01587 for ; Fri, 28 Jun 2002 23:04:54 -0600 (MDT) Received: from mailhost1 (localhost [127.0.0.1]) by lit.a-star.edu.sg (8.11.1/8.11.1) with ESMTP id g5T547G28032 for ; Sat, 29 Jun 2002 13:04:07 +0800 (SGT) Received: from lit.org.sg (localhost [127.0.0.1]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 HotFix 0.5 (built Jun 7 2002)) with ESMTP id <0GYG00KMSBH288@mailhost.lit.org.sg> for mobile-ip@sunroof.eng.sun.com; Sat, 29 Jun 2002 13:05:32 +0800 (SGT) Received: from [192.122.139.152] by mailhost.lit.org.sg (mshttpd); Sat, 29 Jun 2002 13:05:26 +0800 Date: Sat, 29 Jun 2002 13:05:26 +0800 Subject: Re: [mobile-ip] New Draft: draft-vriz-mipv6-hbhlmap-00.txt To: Vrizlynn Thing Cc: Mobile IP Mailing List , Xu Yi , Henry Message-id: <34f5b3611f.3611f34f5b@lit.org.sg> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 0.5 (built Jun 7 2002) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi all, I've earlier announced the submission of the Internet Draft entitled "Hop by Hop Local Mobility Agents Probing for Mobile IPv6", with the file name "draft-vriz-mipv6-hbhlmap-00.txt". However, it was intended as a submission to the Mobile IP Working Group and therefore, the name of the file has been changed to "draft-vriz-mobileip- hbhlmap-00.txt" to conform to the file naming guideline for submission to the Mobile IP WG. The new URL of this Internet Draft is now: http://www.ietf.org/internet-drafts/draft-vriz-mobileip-hbhlmap-00.txt Thank you. Best Regards, Vrizlynn Thing (Ms) ----- Original Message ----- From: Vrizlynn Thing Date: Thursday, June 27, 2002 12:04 pm Subject: [mobile-ip] New Draft: draft-vriz-mipv6-hbhlmap-00.txt > Hi all, > > I've recently submitted "draft-vriz-mipv6-hbhlmap-00.txt" to the > Mobile IP > Working Group. > It proposed a solution to provide support for Localized Mobility > Managementaccording to > requirements set out in "draft-ietf-mobileip-lmm-requirements- > 01.txt" in > Mobile IPv6. > The detailed mechanisms and procedures are explained in the draft. > > Abstract: > > This document introduces an extension to Mobile IPv6 to provide > support for Localized Mobility Management. This proposed Hop-by-Hop > Local Mobility Agents Probing scheme specifies the Local Mobility > Agents Discovery, Selection and Failure Detection architecture and > procedures for deploying the localized mobility management, whereby > the Local Mobility Agents are distributed. It reduces the > amount of > signalling to the home agent and correspondent nodes when mobile > node moves among the subnets of the visited domain. > > > This document can be found at the following URL: > http://www.ietf.org/internet-drafts/draft-vriz-mipv6-hbhlmap-00.txt > > Thank you. > > Best Regards, > Vrizlynn Thing (Ms) > > > > Vrizlynn Thing (Ms) > Senior Engineer > Laboratories for Information Technology > 21 Heng Mui Keng Terrace > Singapore 119613 > Tel: +65 68746728 > Fax: +65 6776 8109 > Email: vriz@lit.a-star.edu.sg > > From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 29 03:08:31 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18756 for ; Sat, 29 Jun 2002 03:08:30 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26569; Sat, 29 Jun 2002 01:09:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24870; Sat, 29 Jun 2002 00:08:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5T77wk7014516 for ; Sat, 29 Jun 2002 00:07:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5T77vhM014515 for mobile-ip-dist; Sat, 29 Jun 2002 00:07:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5T77sk7014508 for ; Sat, 29 Jun 2002 00:07:54 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA12597 for ; Sat, 29 Jun 2002 00:08:00 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11500 for ; Sat, 29 Jun 2002 01:07:59 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5T78CL10233; Sat, 29 Jun 2002 02:08:12 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 29 Jun 2002 02:07:58 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF296@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: Mobile IP Mailing List Cc: "'Charles E. Perkins'" Subject: [mobile-ip] RFC3220: Why allowing FA to reject RRQ with error code 136 Date: Sat, 29 Jun 2002 02:07:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21F3B.B23B7DD0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C21F3B.B23B7DD0 Content-Type: text/plain; charset="iso-8859-1" Hello Charlie, I noticed that RFC3220 allows the FA to reject RRQ message with error code 136 as specified in paragraph 2 in section 3.7.2. This creates some conflicts as explained below: 1. In section 3.4. error code 136 is listed under "Registration denied by the home agent:" 2. In section 3.6.2.3., we read: "Code 136: (Denied by home agent, Unknown home agent address) ....... " 3. Already deployed MN consider, as (RFC2002) RFC3220 define, that error code 136 is generated by the HA and expects to see MN-HA Authentication extension where FA ABSOLUTELY has no capabilities of generating. see section 3.6.2.1 (b). 4. MN are supposed to retransmit RRQ when receiving a RRP with error code of 136. It also assumed to use the IP address inserted in the HA IP address field in the RRP. see section 3.6.2.3. Apparently it is not the case when FA rejects the request with RRP message and error code 136!!! 5. I believe that keeping those error codes seperated as generated by FA and HA is very useful and I assume that was the intention to start with as stated in section 3.6.2. RFC2002(RFC3220). I believe this creates more problems than solving. Your clarification is greatly appreciated. Regards, Ahmad Muhanna ------_=_NextPart_001_01C21F3B.B23B7DD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC3220: Why allowing FA to reject RRQ with error code = 136

Hello Charlie,

I noticed that RFC3220 allows the FA to reject RRQ = message with error code 136 as specified in paragraph 2 in section = 3.7.2.

This creates some conflicts as explained = below:
1. In section 3.4. error code 136 is listed under = "Registration denied by the home agent:"

2. In section 3.6.2.3., we read:
"Code 136:  (Denied by home agent, Unknown = home agent address)
....... "

3. Already deployed MN consider, as (RFC2002) RFC3220 = define, that error code 136 is generated by the HA and expects to see = MN-HA Authentication extension where FA ABSOLUTELY has no capabilities = of generating.

see section 3.6.2.1 (b).

4. MN are supposed to retransmit RRQ when receiving a = RRP with error code of 136. It also assumed to use the IP address = inserted in the HA IP address field in the RRP. see section 3.6.2.3. =

Apparently it is not the case when FA rejects the = request with RRP message and error code 136!!!

5. I believe that keeping those error codes seperated = as generated by FA and HA is very useful and I assume that was the = intention to start with as stated in section 3.6.2. = RFC2002(RFC3220).


I believe this creates more problems than = solving.

Your clarification is greatly appreciated.

Regards,
Ahmad Muhanna

------_=_NextPart_001_01C21F3B.B23B7DD0-- From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 29 11:44:08 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27547 for ; Sat, 29 Jun 2002 11:44:07 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03622; Sat, 29 Jun 2002 09:44:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25902; Sat, 29 Jun 2002 08:44:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5TFhQk7014989 for ; Sat, 29 Jun 2002 08:43:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5TFhQBZ014988 for mobile-ip-dist; Sat, 29 Jun 2002 08:43:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5TFhNk7014981 for ; Sat, 29 Jun 2002 08:43:23 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17793 for ; Sat, 29 Jun 2002 08:43:29 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10944 for ; Sat, 29 Jun 2002 09:43:28 -0600 (MDT) 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 IAA18501; Sat, 29 Jun 2002 08:43:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g5TFhRr27529; Sat, 29 Jun 2002 08:43:27 -0700 X-mProtect: <200206291543> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdwwiDuS; Sat, 29 Jun 2002 08:43:25 PDT Message-ID: <3D1DD559.152F65AE@iprg.nokia.com> Date: Sat, 29 Jun 2002 08:42:18 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ahmad Muhanna CC: Mobile IP Working Group Subject: [mobile-ip] Re: RFC3220: Why allowing FA to reject RRQ with error code 136 References: <6B49EDFE974BD51197D70002A56079D803ECF296@zrc2c013.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Ahmad, In the situation described in that paragraph, the mobile node has used the "wrong" home agent address. I thought the solution was reasonable. Perhaps the wording should be clarified somewhere else, but if the mobility agent denies in this circumstance, there is no chance for MN-HA anyway. In fact, I guess there's no chance whenever 136 is received. If you would like to suggest an improvement, that would be nice. Maybe the paragraph just doesn't belong there. Regards, Charlie P. Ahmad Muhanna wrote: > > > Hello Charlie, > > I noticed that RFC3220 allows the FA to reject RRQ message with error > code 136 as specified in paragraph 2 in section 3.7.2. > > This creates some conflicts as explained below: > 1. In section 3.4. error code 136 is listed under "Registration denied > by the home agent:" > > 2. In section 3.6.2.3., we read: > "Code 136: (Denied by home agent, Unknown home agent address) > ....... " > > 3. Already deployed MN consider, as (RFC2002) RFC3220 define, that > error code 136 is generated by the HA and expects to see MN-HA > Authentication extension where FA ABSOLUTELY has no capabilities of > generating. > > see section 3.6.2.1 (b). > > 4. MN are supposed to retransmit RRQ when receiving a RRP with error > code of 136. It also assumed to use the IP address inserted in the HA > IP address field in the RRP. see section 3.6.2.3. > > Apparently it is not the case when FA rejects the request with RRP > message and error code 136!!! > > 5. I believe that keeping those error codes seperated as generated by > FA and HA is very useful and I assume that was the intention to start > with as stated in section 3.6.2. RFC2002(RFC3220). > > I believe this creates more problems than solving. > > Your clarification is greatly appreciated. > > Regards, > Ahmad Muhanna From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 29 19:04:33 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07386 for ; Sat, 29 Jun 2002 19:04:33 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23179; Sat, 29 Jun 2002 16:04:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23242; Sat, 29 Jun 2002 16:04:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5TN3Uk7015521 for ; Sat, 29 Jun 2002 16:03:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5TN3UCs015520 for mobile-ip-dist; Sat, 29 Jun 2002 16:03:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5TN3Rk7015513 for ; Sat, 29 Jun 2002 16:03:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23140 for ; Sat, 29 Jun 2002 16:03:33 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA17531 for ; Sat, 29 Jun 2002 17:03:33 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5TMxnL23336; Sat, 29 Jun 2002 17:59:50 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 29 Jun 2002 17:59:35 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF297@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Charlie Perkins'" Cc: Mobile IP Working Group , "Ahmad Muhanna" Subject: [mobile-ip] RE: RFC3220: Why allowing FA to reject RRQ with error code 136 Date: Sat, 29 Jun 2002 17:59:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C21FC0.A35936B0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 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_01C21FC0.A35936B0 Content-Type: text/plain; charset="iso-8859-1" Hello Charlie, It is hard to suggest a solution for the issue at hand without understanding its background. I admit that I did not search the archive for this issue. However, let me give me guess here and please correct me if I am wrong: 1. This may be applicable in the situation when we have a co-located HA. FA & HA on the same box. 2. It also possible when the FA and the HA belongs to the same domain, like when we have dynamically allocated HA in the Foreign domain. Am I guessing correctly here? Also, please see two comments inline below Regards, Ahmad Muhanna Hello Ahmad, In the situation described in that paragraph, the mobile node has used the "wrong" home agent address. I thought the solution was reasonable. Perhaps the wording should be clarified somewhere else, but if the mobility agent denies in this circumstance, there is no chance for MN-HA anyway. In fact, I guess there's no chance whenever 136 is received. <> Well, I am not sure if this is correct. As per RFC2002 error code 136 is ONLY generated in the case of MN trying to discover its HA or to dynamically allocate a HA. However, RFC3220 added a new use for this code which generates the issue at hand, as in section 3.7.2. Now: When the MN tries to discover its HA, It is assumed that there are multiple HA's and all of them can access the security association between the Home domain and this MN. Otherwise, How these HA would accept the RRQ to start with. Therefore, in all circumistances when HA generates error code 136, it MUST include MN-HA authentication extension. Otherwise, it would be in violation of the same standard RFC2002(RFC3220), section 3.6.2.1 (b). <> If you would like to suggest an improvement, that would be nice. Maybe the paragraph just doesn't belong there. <> It is probably worth mentioning that the issue at hand is a very special one. We at a situation that the FA have some extra information about the IP address the MN included in the HA field in its RRQ message. Let us refer to it as "WRONG HA" for sake of simplicity later on. The FA ,here, for sure knows that this IP address is an "INVALID Home Agent Address" because it belongs to one of the interfaces of this FA. NOW: If my guess mentioned above was correct then we have two possible scenarios: Scenario 1: ----------- Wrong HA is one of the FA's interfaces IP addresses BUT this interface is not a HA. 1.1. Either allow the FA to forward this packet to this interface anyway. FA will never receive a RRP back and it will timeout and send error code 78 to the MN. "It is not a smart solution though also hints to MN that there is a network problem while there is none" However, it is real Registration timed out using the provided WRONG HA. or, 1.2. FA rejects the RRQ message and sends an appropriate error code generated by the FA. - Reuse of error code 88 "HA Unreachable", BUT some people may disagree because this will indicate to the MN that there is a network problem while in reality there is none. However, it is real the provided WRONG HA is UNREACHABLE. - Reuse of error code 70 "Poorly formed Request" !!! - Probably we missed this initially. We have error code 77 "invalid care-of address". This scenaro is very similar the FA knows that this is an invalid HA address. Why not creating a new FA error code, "INVALID Home Agent Address". Already deployed MN will NOT understand this, "backward compatibility again". BUT this is the best in my opinion. Scenario 2: ----------- Wrong HA is one of the FA's interfaces IP address AND this interface IS a HA BUT NOT serving this MN. 2.1. Either allow the FA to forward this packet to this interface anyway. HA will never recognize the MN and will discard the message. FA will never receive a RRP back and it will timeout and send error code 78 to the MN. "It is real, Registration timed out", 2.2. same as in 1.2. above. Conclusion: I think the best is to create a new error code GENERATED by the FA "Invalid Home Agent Address" The second best in my opinion is to reuse error code 88. IT is very real, the WRONG HA address the MN provided is UNREACHABLE. <> Thanks, Ahmad Regards, Charlie P. Ahmad Muhanna wrote: > > > Hello Charlie, > > I noticed that RFC3220 allows the FA to reject RRQ message with error > code 136 as specified in paragraph 2 in section 3.7.2. > > This creates some conflicts as explained below: > 1. In section 3.4. error code 136 is listed under "Registration denied > by the home agent:" > > 2. In section 3.6.2.3., we read: > "Code 136: (Denied by home agent, Unknown home agent address) > ....... " > > 3. Already deployed MN consider, as (RFC2002) RFC3220 define, that > error code 136 is generated by the HA and expects to see MN-HA > Authentication extension where FA ABSOLUTELY has no capabilities of > generating. > > see section 3.6.2.1 (b). > > 4. MN are supposed to retransmit RRQ when receiving a RRP with error > code of 136. It also assumed to use the IP address inserted in the HA > IP address field in the RRP. see section 3.6.2.3. > > Apparently it is not the case when FA rejects the request with RRP > message and error code 136!!! > > 5. I believe that keeping those error codes seperated as generated by > FA and HA is very useful and I assume that was the intention to start > with as stated in section 3.6.2. RFC2002(RFC3220). > > I believe this creates more problems than solving. > > Your clarification is greatly appreciated. > > Regards, > Ahmad Muhanna ------_=_NextPart_001_01C21FC0.A35936B0 Content-Type: text/html; charset="iso-8859-1" RE: RFC3220: Why allowing FA to reject RRQ with error code 136

Hello Charlie,
It is hard to suggest a solution for the issue at hand without understanding its background.
I admit that I did not search the archive for this issue. However, let me give me guess here
and please correct me if I am wrong:

1. This may be applicable in the situation when we have a co-located HA.
FA & HA on the same box.
2. It also possible when the FA and the HA belongs to the same domain,
like when we have dynamically allocated HA in the Foreign domain.

Am I guessing correctly here?

Also, please see two comments inline below

Regards,
Ahmad Muhanna


Hello Ahmad,

In the situation described in that paragraph, the mobile node
has used the "wrong" home agent address.  I thought the solution
was reasonable.  Perhaps the wording should be clarified
somewhere else, but if the mobility agent denies in this
circumstance, there is no chance for MN-HA anyway.  In
fact, I guess there's no chance whenever 136 is received.

<<START-1: Ahmad>>
Well, I am not sure if this is correct.
As per RFC2002 error code 136 is ONLY generated in the
case of MN trying to discover its HA or to dynamically allocate a HA.
However, RFC3220 added a new use for this code which generates the issue
at hand, as in section 3.7.2.

Now: When the MN tries to discover its HA, It is assumed that there
are multiple HA's and all of them can access the security association
between the Home domain and this MN. Otherwise, How these HA would
accept the RRQ to start with.
Therefore, in all circumistances when HA generates error code 136, it
MUST include MN-HA authentication extension. Otherwise, it would be in
violation of the same standard RFC2002(RFC3220), section 3.6.2.1 (b).
<<END-1: Ahmad>>

If you would like to suggest an improvement, that would
be nice.  Maybe the paragraph just doesn't belong there.

<<START-2 Ahmad>>
It is probably worth mentioning that the issue at hand is a very special one.
We at a situation that the FA have some extra information about the IP address
the MN included in the HA field in its RRQ message.
Let us refer to it as "WRONG HA" for sake of simplicity later on.
The FA ,here, for sure knows that this IP address is an "INVALID Home Agent Address"
because it belongs to one of the interfaces of this FA.

NOW: If my guess mentioned above was correct then we have two possible scenarios:
Scenario 1:
-----------
Wrong HA is one of the FA's interfaces IP addresses BUT this interface is not a HA.

        1.1.    Either allow the FA to forward this packet to this interface anyway.
                FA will never receive a RRP back and it will timeout and send error
                code 78 to the MN. "It is not a smart solution though also hints to
                MN that there is a network problem while there is none" However, it
                is real Registration timed out using the provided WRONG HA. or,

        1.2. FA rejects the RRQ message and sends an appropriate error code generated by the FA.

                - Reuse of error code 88 "HA Unreachable", BUT some people may disagree
                  because this will indicate to the MN that there is a network problem
                  while in reality there is none. However, it is real the provided WRONG HA
                  is UNREACHABLE.

                - Reuse of error code 70 "Poorly formed Request" !!!

                - Probably we missed this initially. We have error code 77 "invalid care-of
                  address". This scenaro is very similar the FA knows that this is an invalid
                  HA address. Why not creating a new FA error code, "INVALID Home Agent Address".
                  Already deployed MN will NOT understand this, "backward compatibility again".
                  BUT this is the best in my opinion.

Scenario 2:
-----------
Wrong HA is one of the FA's interfaces IP address AND this interface IS a HA BUT NOT serving this MN.

        2.1.    Either allow the FA to forward this packet to this interface anyway.
                HA will never recognize the MN and will discard the message.
                FA will never receive a RRP back and it will timeout and send error
                code 78 to the MN. "It is real, Registration timed out",

        2.2. same as in 1.2. above.


Conclusion:
I think the best is to create a new error code GENERATED by the FA "Invalid Home Agent Address"

The second best in my opinion is to reuse error code 88. IT is very real, the WRONG HA
address the MN provided is UNREACHABLE.
<<END-2 Ahmad>>

Thanks,
Ahmad      

Regards,
Charlie P.


Ahmad Muhanna wrote:

>
>
> Hello Charlie,
>
> I noticed that RFC3220 allows the FA to reject RRQ message with error
> code 136 as specified in paragraph 2 in section 3.7.2.
>
> This creates some conflicts as explained below:
> 1. In section 3.4. error code 136 is listed under "Registration denied
> by the home agent:"
>
> 2. In section 3.6.2.3., we read:
> "Code 136:  (Denied by home agent, Unknown home agent address)
> ....... "
>
> 3. Already deployed MN consider, as (RFC2002) RFC3220 define, that
> error code 136 is generated by the HA and expects to see MN-HA
> Authentication extension where FA ABSOLUTELY has no capabilities of
> generating.
>
> see section 3.6.2.1 (b).
>
> 4. MN are supposed to retransmit RRQ when receiving a RRP with error
> code of 136. It also assumed to use the IP address inserted in the HA
> IP address field in the RRP. see section 3.6.2.3.
>
> Apparently it is not the case when FA rejects the request with RRP
> message and error code 136!!!
>
> 5. I believe that keeping those error codes seperated as generated by
> FA and HA is very useful and I assume that was the intention to start
> with as stated in section 3.6.2. RFC2002(RFC3220).
>
> I believe this creates more problems than solving.
>
> Your clarification is greatly appreciated.
>
> Regards,
> Ahmad Muhanna

------_=_NextPart_001_01C21FC0.A35936B0-- From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 30 13:38:43 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07429 for ; Sun, 30 Jun 2002 13:38:43 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22316; Sun, 30 Jun 2002 11:39:25 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06691; Sun, 30 Jun 2002 10:38:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UHc4k7016624 for ; Sun, 30 Jun 2002 10:38:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g5UHc423016623 for mobile-ip-dist; Sun, 30 Jun 2002 10:38:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g5UHc1k7016616 for ; Sun, 30 Jun 2002 10:38:01 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08621 for ; Sun, 30 Jun 2002 10:38:06 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07540 for ; Sun, 30 Jun 2002 11:38:06 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 924DA6A905; Sun, 30 Jun 2002 20:37:56 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7B9546A901; Sun, 30 Jun 2002 20:37:54 +0300 (EEST) Message-ID: <3D1F424E.10806@kolumbus.fi> Date: Sun, 30 Jun 2002 20:39:26 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas Cc: "'mobile-ip@sunroof.eng.sun.com'" , "'Vijay Devarapalli'" , Charlie Perkins Subject: Re: [mobile-ip] closing issue 10 (esp vs ah) References: <3D1B8159.8090100@kolumbus.fi> <15643.37224.131596.350617@thomasm-u1.cisco.com> <3D1C4B8A.40605@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Some more thoughts on this subject... Mike has a point in the sense that if we allow multiple valid home addresses, if we use ESP, then the attacker could replace one such valid address with another valid one, and no policy check on the HA side could detect this. On the other hand, I don't think we have any mechanism that would allow multiple addresses to be protected by the same SA or cert but still keeping track of which addresses are allowed. Except perhaps just allocating the whole prefix or some number of bits from it to the mobile node. However, this does not appear to be a very practical approach for a number of reasons. One, if the whole prefix is allocated to the mobile node, the home agent can only serve one mobile node under this prefix. Two, as far as I know, X.509 does not support putting in a prefix/subnet in the subjectAltName field. In conclusion I think it would be a useful feature, but at the moment we don't have protocol support for such things even outside Mobile IP, so I don't think we should include the field in MIPv6 either. Jari