From mip6-bounces@ietf.org Fri Jun 02 12:01:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmC60-0000Sf-O5; Fri, 02 Jun 2006 12:01:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmC5y-0000LF-Vj for mip6@ietf.org; Fri, 02 Jun 2006 12:01:54 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmC5x-0005aX-Hu for mip6@ietf.org; Fri, 02 Jun 2006 12:01:54 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k52G1pJQ020500 for ; Fri, 2 Jun 2006 19:01:52 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 19:00:58 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 11:00:38 -0500 Received: from 172.19.244.91 ([172.19.244.91]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Jun 2006 16:00:38 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 02 Jun 2006 11:00:48 -0500 From: Basavaraj Patil To: Message-ID: Thread-Topic: WG LC: draft-ietf-mip6-location-privacy-ps (01) Thread-Index: AcaGXbaV9VG6wPJQEdqTqQARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Jun 2006 16:00:39.0107 (UTC) FILETIME=[B1490130:01C6865D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, This is the working group last call for I-D: draft-ietf-mip6-location-privacy-ps-01.txt (IP Address Location Privacy and Mobile IPv6: Problem Statement) WG LC will end on June 16th, 06. Please review and send your comments before the deadline. The document is intended to be published as an Informational RFC. -Chairs The link for the I-D: http://ietf.org/internet-drafts/draft-ietf-mip6-location-privacy-ps-01.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 06 19:32:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnl2H-0004iH-Eg; Tue, 06 Jun 2006 19:32:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnl2G-0004i4-0m; Tue, 06 Jun 2006 19:32:32 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnl2C-0001yF-Hd; Tue, 06 Jun 2006 19:32:31 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k56NWP3L029253; Wed, 7 Jun 2006 02:32:27 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 02:32:26 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jun 2006 02:32:25 +0300 Message-ID: <44861086.3090300@iprg.nokia.com> Date: Tue, 06 Jun 2006 16:32:22 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org, mobopts@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2006 23:32:25.0994 (UTC) FILETIME=[77E6B6A0:01C689C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Mip6] MIP and Upper Layer Protocol interaction X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello folks, we have problem dealing with change of HoA with a CN. If a MN wishes to change its HoA with a CN (e.g., use a different pseudo-hoa for privacy purposes), it has no _reliable_ way of knowing whether it has existing sessions with that CN. Any thoughts on how to handle this MIP - ULP interaction? -Rajeev _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 06 19:43:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnlDB-0002xl-0k; Tue, 06 Jun 2006 19:43:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnlD9-0002xX-En for mip6@ietf.org; Tue, 06 Jun 2006 19:43:47 -0400 Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnlD8-0003Vd-5h for mip6@ietf.org; Tue, 06 Jun 2006 19:43:47 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id EA9ED8000B4; Wed, 7 Jun 2006 02:43:44 +0300 (EEST) Date: Wed, 7 Jun 2006 02:43:44 +0300 (EEST) From: Wassim Haddad To: Rajeev Koodli In-Reply-To: <44861086.3090300@iprg.nokia.com> Message-ID: References: <44861086.3090300@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: mip6@ietf.org, mobopts@irtf.org Subject: [Mip6] Re: [Mobopts] MIP and Upper Layer Protocol interaction X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, On Tue, 6 Jun 2006, Rajeev Koodli wrote: > we have problem dealing with change of HoA with a CN. > > If a MN wishes to change its HoA with a CN (e.g., use a different > pseudo-hoa for privacy purposes), it has no _reliable_ way of > knowing whether it has existing sessions with that CN. => Can you please elaborate more on this? Is there any particular draft you're referring to? What type of pseudo-HoA you're considering? Regards, Wassim H. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 06 20:12:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnleq-0000US-Tc; Tue, 06 Jun 2006 20:12:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnlep-0000U1-Ub; Tue, 06 Jun 2006 20:12:23 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnleo-0006TO-G3; Tue, 06 Jun 2006 20:12:23 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k570CKgF028384; Wed, 7 Jun 2006 03:12:21 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 03:12:20 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jun 2006 03:12:20 +0300 Message-ID: <448619E2.9000905@iprg.nokia.com> Date: Tue, 06 Jun 2006 17:12:18 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wassim Haddad Subject: Re: [Mip6] Re: [Mobopts] MIP and Upper Layer Protocol interaction References: <44861086.3090300@iprg.nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 00:12:20.0383 (UTC) FILETIME=[0B117AF0:01C689C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Wassim, Wassim Haddad wrote: >>we have problem dealing with change of HoA with a CN. >> >>If a MN wishes to change its HoA with a CN (e.g., use a different >>pseudo-hoa for privacy purposes), it has no _reliable_ way of >>knowing whether it has existing sessions with that CN. >> >> > >=> Can you please elaborate more on this? Is there any particular >draft you're referring to? What type of pseudo-HoA you're considering? > > > No particular draft as such. The problem is if the MN wishes to change its HoA for whatever reasons (3041 style privacy included), it has no reliable means of determining whether there is an existing connection/session or not. -Rajeev >Regards, > >Wassim H. > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 06 20:35:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnm1J-0004Bh-D2; Tue, 06 Jun 2006 20:35:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnm1H-0004Al-NZ; Tue, 06 Jun 2006 20:35:35 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnm1F-0003U0-9W; Tue, 06 Jun 2006 20:35:35 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k56Nw8A21399; Tue, 6 Jun 2006 16:58:08 -0700 X-mProtect: <200606062358> Nokia Silicon Valley Messaging Protection Received: from danira-pool052146.americas.nokia.com (10.241.52.146, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdDCMyKl; Tue, 06 Jun 2006 16:58:06 PDT Message-ID: <44861F45.3010307@iprg.nokia.com> Date: Tue, 06 Jun 2006 17:35:17 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rajeev Koodli References: <44861086.3090300@iprg.nokia.com> In-Reply-To: <44861086.3090300@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: mip6@ietf.org, mobopts@irtf.org Subject: [Mip6] Re: [Mobopts] MIP and Upper Layer Protocol interaction X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello Rajeev, It could be that there isn't really a problem. Suppose that the mobile node keeps track of whether or not the correspondent node has a binding. Then, it can notify the correspondent if it changes home address, in addition to sending notifications about each new care-of address. If the correspondent node has no binding, then we can imagine that there hasn't been any traffic recently and that there are no TCP sessions. In that case, if the correspondent node wants to send data to the mobile node, it would have to re-resolve the mobile's host name. This could possibly require that the old home address first would fail. Presumably, this isn't exactly a mobility problem. I guess the motivation is to allow a device to operate with a new home agent in a new network but still maintain its existing "identity" from the point of view of some correspondent nodes. If I missed out on previous discussion about this point, please excuse my lack of context! Otherwise, can you say what use scenarios you had in mind? Regards, Charlie P. Rajeev Koodli wrote: > > Hello folks, > > we have problem dealing with change of HoA with a CN. > > If a MN wishes to change its HoA with a CN (e.g., use a different > pseudo-hoa for > privacy purposes), it has no _reliable_ way of knowing whether it has > existing sessions with that CN. > > Any thoughts on how to handle this MIP - ULP interaction? > > -Rajeev > > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 06 21:18:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnmgy-00083n-Bp; Tue, 06 Jun 2006 21:18:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnmgx-00083a-02; Tue, 06 Jun 2006 21:18:39 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnmgv-00070i-GS; Tue, 06 Jun 2006 21:18:38 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k571IZMV005269; Wed, 7 Jun 2006 04:18:36 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 04:18:35 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jun 2006 04:18:35 +0300 Message-ID: <44862969.6050809@iprg.nokia.com> Date: Tue, 06 Jun 2006 18:18:33 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles E. Perkins" References: <44861086.3090300@iprg.nokia.com> <44861F45.3010307@iprg.nokia.com> In-Reply-To: <44861F45.3010307@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 01:18:35.0937 (UTC) FILETIME=[4CAEE110:01C689D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: mip6@ietf.org, mobopts@irtf.org Subject: [Mip6] Re: [Mobopts] MIP and Upper Layer Protocol interaction X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Charlie, Charles E. Perkins wrote: > > Hello Rajeev, > > It could be that there isn't really a problem. > That would be good. :-) > Suppose that the mobile node keeps track of whether or not > the correspondent node has a binding. Then, it can notify > the correspondent if it changes home address, in addition > to sending notifications about each new care-of address. > > If the correspondent node has no binding, then we can > imagine that there hasn't been any traffic recently and that > there are no TCP sessions. > The CN (and the MN) can have a binding and not have a TCP connection. So, the emphasis here is on "reliably" in "being able to detect an existing connection". The BCE lifetime is not correlated to the lifetime of a TCP connection. (You _could_ have a CN teardown a binding and have it later send a BRR for a new connection. But this won't work easily with multiple connections). > In that case, if the correspondent node wants to send > data to the mobile node, it would have to re-resolve the > mobile's host name. This could possibly require that > the old home address first would fail. Presumably, this > isn't exactly a mobility problem. I guess the motivation > is to allow a device to operate with a new home agent > in a new network but still maintain its existing "identity" > from the point of view of some correspondent nodes. > I tend to agree that this may not be strictly a mobility problem. Typically, you need to resolve a user identifier to device identifier before starting a connection, and you can construct the mapping in such a way as to support dynamic HoAs. > If I missed out on previous discussion about this point, > please excuse my lack of context! Otherwise, can you > say what use scenarios you had in mind? > Well, a MN may use RFC 3041 style HoA or some other form to thwart compromises in location privacy and profiling. Regards, -Rajeev > Regards, > Charlie P. > > > > > Rajeev Koodli wrote: > >> >> Hello folks, >> >> we have problem dealing with change of HoA with a CN. >> >> If a MN wishes to change its HoA with a CN (e.g., use a different >> pseudo-hoa for >> privacy purposes), it has no _reliable_ way of knowing whether it has >> existing sessions with that CN. >> >> Any thoughts on how to handle this MIP - ULP interaction? >> >> -Rajeev >> >> >> >> >> >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> https://www1.ietf.org/mailman/listinfo/mobopts > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 06 21:23:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnmle-00021X-CN; Tue, 06 Jun 2006 21:23:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnmld-00021P-47 for mip6@ietf.org; Tue, 06 Jun 2006 21:23:29 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnmlb-00079g-Qt for mip6@ietf.org; Tue, 06 Jun 2006 21:23:29 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 18:23:24 -0700 Message-ID: <44862A89.5030201@azairenet.com> Date: Tue, 06 Jun 2006 18:23:21 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mip6] MIP and Upper Layer Protocol interaction References: <44861086.3090300@iprg.nokia.com> In-Reply-To: <44861086.3090300@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 01:23:24.0888 (UTC) FILETIME=[F8E94D80:01C689D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Rajeev Koodli wrote: > If a MN wishes to change its HoA with a CN (e.g., use a different > pseudo-hoa for > privacy purposes), it has no _reliable_ way of knowing whether it has > existing sessions with that CN. I read this paragraph three times, but couldn't get the context. if in the privacy context, I assume there is still a *real* HoA. the pseudo HoA appears in the route optimized traffic to the CN *instead* of the real HoA. the CN knows the real HoA and the pseudo HoA. the mapping from the real HoA to the pseudo HoA is done using the binding update list at the MN and the binding cache entry at the CN. if not for privacy, perhaps the mobile node shouldn't change its HoA abruptly, but let existing sessions continue with the existing HoA and use the new HoA for new sessions. the mobile node would also have to update the DNS entry if it wants its FQDN to resolve to the new HoA. hope this helps. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 06 22:52:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fno9Z-000396-8Q; Tue, 06 Jun 2006 22:52:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fno9Y-00038y-GG for mip6@ietf.org; Tue, 06 Jun 2006 22:52:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnnKf-0003R1-R3 for mip6@ietf.org; Tue, 06 Jun 2006 21:59:41 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fnn6k-00073v-1J for mip6@ietf.org; Tue, 06 Jun 2006 21:45:18 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 18:45:15 -0700 Message-ID: <44862FAB.9040902@azairenet.com> Date: Tue, 06 Jun 2006 18:45:15 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mip6] Re: [Mobopts] MIP and Upper Layer Protocol interaction References: <44861086.3090300@iprg.nokia.com> <44861F45.3010307@iprg.nokia.com> <44862969.6050809@iprg.nokia.com> In-Reply-To: <44862969.6050809@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 01:45:15.0996 (UTC) FILETIME=[066481C0:01C689D4] X-Spam-Score: -1.6 (-) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: mip6@ietf.org, "Charles E. Perkins" , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Rajeev Koodli wrote: > Typically, you need to resolve a user identifier to device identifier > before > starting a connection, and you can construct the mapping in such > a way as to support dynamic HoAs. the bootstrapping specifications can handle updating FQDN to HoA mapping. for identifiers other than FQDN we would need additional work. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 07 04:26:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FntN0-0001US-J2; Wed, 07 Jun 2006 04:26:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FntMz-0001UN-Vo for mip6@ietf.org; Wed, 07 Jun 2006 04:26:29 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FntMy-0006KE-Cq for mip6@ietf.org; Wed, 07 Jun 2006 04:26:29 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0H00M3WECH7T@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 07 Jun 2006 16:31:29 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0H00JVAECGC6@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 07 Jun 2006 16:31:29 +0800 (CST) Received: from x49105 ([10.110.114.67]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0H00B5REESBQ@szxml04-in.huawei.com> for mip6@ietf.org; Wed, 07 Jun 2006 16:32:55 +0800 (CST) Date: Wed, 07 Jun 2006 16:22:26 +0800 From: Sam Xia In-reply-to: To: mip6@ietf.org Message-id: <000001c68a0b$82c06cc0$43726e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaHJtinIm8MDIKQRNeYkdtOnkVCRwC4UX8g X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Rajeev.Koodli@nokia.com Subject: [Mip6] RE: Mip6 Digest, Vol 26, Issue 1 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, Rajeev , I am very interested in your draft. But there are some points I don't understand clearly. 1: at the first paragraph of page 2, there is a sentence as below: "Often, a binding between these two identifiers is also available, e.g., through DNS". Can you add some texts to clarify it more clearly? 2: at the third paragraph of page 2, there is a sentence as below: " In this document, the concerns arising from the use of a globally visible identifier, such as a Home Address, when roaming are described ". I think there should be a literal error to be revised. 3: I think that it will be very useful to add some texts to describe the impacts from revealing roaming of MN to home network. Maybe the home nodes have more means to determine that MN is away from home network. Best Regards, Sam Xia > -----Original Message----- > From: mip6-request@ietf.org [mailto:mip6-request@ietf.org] > Sent: Sunday, June 04, 2006 12:00 AM > To: mip6@ietf.org > Subject: Mip6 Digest, Vol 26, Issue 1 > > Send Mip6 mailing list submissions to > mip6@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/mip6 > or, via email, send a message with subject or body 'help' to > mip6-request@ietf.org > > You can reach the person managing the list at > mip6-owner@ietf.org > > When replying, please edit your Subject line so it is more > specific than "Re: Contents of Mip6 digest..." > > > Today's Topics: > > 1. WG LC: draft-ietf-mip6-location-privacy-ps (01) > (Basavaraj Patil) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 02 Jun 2006 11:00:48 -0500 > From: Basavaraj Patil > Subject: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01) > To: > Message-ID: > Content-Type: text/plain; charset="US-ASCII" > > > > Hello, > > This is the working group last call for I-D: > draft-ietf-mip6-location-privacy-ps-01.txt (IP Address > Location Privacy and Mobile IPv6: Problem Statement) > > WG LC will end on June 16th, 06. Please review and send your > comments before the deadline. > > The document is intended to be published as an Informational RFC. > > -Chairs > > The link for the I-D: > http://ietf.org/internet-drafts/draft-ietf-mip6-location-priva > cy-ps-01.txt > > > > > ------------------------------ > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > > End of Mip6 Digest, Vol 26, Issue 1 > *********************************** > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 07 11:19:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnzob-0000KQ-IS; Wed, 07 Jun 2006 11:19:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnzoa-0000KG-H4 for mip6@ietf.org; Wed, 07 Jun 2006 11:19:24 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnzoZ-0006zI-3K for mip6@ietf.org; Wed, 07 Jun 2006 11:19:24 -0400 Message-ID: <00ec01c68a45$cfdde480$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Charles E. Perkins" , "Rajeev Koodli" References: <44861086.3090300@iprg.nokia.com> <44861F45.3010307@iprg.nokia.com> Date: Wed, 7 Jun 2006 08:19:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mip6@ietf.org, mobopts@irtf.org Subject: [Mip6] Re: [Mobopts] MIP and Upper Layer Protocol interaction X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Charlie, Let's see if I understand. Are you saying that if the mobile node wants to change home address, it should change existing sessions by treating the change as route optimization? That is, it would send a route optimization binding update (with appropriate security) with the new home address as a care of address? Presumably new sessions would be started with the new home address. jak ----- Original Message ----- From: "Charles E. Perkins" To: "Rajeev Koodli" Cc: ; Sent: Tuesday, June 06, 2006 5:35 PM Subject: Re: [Mobopts] MIP and Upper Layer Protocol interaction > > Hello Rajeev, > > It could be that there isn't really a problem. > > Suppose that the mobile node keeps track of whether or not > the correspondent node has a binding. Then, it can notify > the correspondent if it changes home address, in addition > to sending notifications about each new care-of address. > > If the correspondent node has no binding, then we can > imagine that there hasn't been any traffic recently and that > there are no TCP sessions. > > In that case, if the correspondent node wants to send > data to the mobile node, it would have to re-resolve the > mobile's host name. This could possibly require that > the old home address first would fail. Presumably, this > isn't exactly a mobility problem. I guess the motivation > is to allow a device to operate with a new home agent > in a new network but still maintain its existing "identity" > from the point of view of some correspondent nodes. > > If I missed out on previous discussion about this point, > please excuse my lack of context! Otherwise, can you > say what use scenarios you had in mind? > > Regards, > Charlie P. > > > > > Rajeev Koodli wrote: > >> >> Hello folks, >> >> we have problem dealing with change of HoA with a CN. >> >> If a MN wishes to change its HoA with a CN (e.g., use a different >> pseudo-hoa for >> privacy purposes), it has no _reliable_ way of knowing whether it has >> existing sessions with that CN. >> >> Any thoughts on how to handle this MIP - ULP interaction? >> >> -Rajeev >> >> >> >> >> >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> https://www1.ietf.org/mailman/listinfo/mobopts > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 07 13:13:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1bQ-0001Hy-Ue; Wed, 07 Jun 2006 13:13:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1bP-0001Hl-FD; Wed, 07 Jun 2006 13:13:55 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo1bN-0004NV-W7; Wed, 07 Jun 2006 13:13:55 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k57HDldj027053; Wed, 7 Jun 2006 20:13:50 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 20:13:44 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 7 Jun 2006 20:13:45 +0300 Message-ID: <44870922.3040408@iprg.nokia.com> Date: Wed, 07 Jun 2006 10:13:06 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] MIP and Upper Layer Protocol interaction References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> In-Reply-To: <44862A89.5030201@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 17:13:45.0354 (UTC) FILETIME=[BBC1EEA0:01C68A55] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Rajeev Koodli wrote: > >> If a MN wishes to change its HoA with a CN (e.g., use a different >> pseudo-hoa for >> privacy purposes), it has no _reliable_ way of knowing whether it has >> existing sessions with that CN. > > > I read this paragraph three times, but couldn't get > the context. > > if in the privacy context, I assume there is still > a *real* HoA. the pseudo HoA appears in the route > optimized traffic to the CN *instead* of the real > HoA. the CN knows the real HoA and the pseudo HoA. > the mapping from the real HoA to the pseudo HoA is > done using the binding update list at the MN and > the binding cache entry at the CN. > This is a way to do it. Nevertheless, keeping the privacy issue aside.. > if not for privacy, perhaps the mobile node shouldn't > change its HoA abruptly, but let existing sessions > continue with the existing HoA and use the new HoA > for new sessions. the mobile node would also have > to update the DNS entry if it wants its FQDN to > resolve to the new HoA. > The problem here is how does the MN know to "let the existing sessions continue with the existing HoA"? If there is no CN's address in BUL, surely the MN can choose a suitable HoA. For a CN with which it has a binding, it has no reliable way of knowing whether there are any ULP sessions. -Rajeev > hope this helps. > > Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 07 14:51:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo385-0000T6-0z; Wed, 07 Jun 2006 14:51:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo383-0000Sx-Fs for mip6@ietf.org; Wed, 07 Jun 2006 14:51:43 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo382-0007k6-5O for mip6@ietf.org; Wed, 07 Jun 2006 14:51:43 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 11:51:40 -0700 Message-ID: <44872034.9010906@azairenet.com> Date: Wed, 07 Jun 2006 11:51:32 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mip6] MIP and Upper Layer Protocol interaction References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> In-Reply-To: <44870922.3040408@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 18:51:40.0388 (UTC) FILETIME=[698CFA40:01C68A63] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Rajeev Koodli wrote: >> if not for privacy, perhaps the mobile node shouldn't >> change its HoA abruptly, but let existing sessions >> continue with the existing HoA and use the new HoA >> for new sessions. the mobile node would also have >> to update the DNS entry if it wants its FQDN to >> resolve to the new HoA. >> > The problem here is how does the MN know to "let the > existing sessions continue with the existing HoA"? If there is no CN's > address in BUL, surely the MN can choose a suitable HoA. For > a CN with which it has a binding, it has no reliable way of knowing > whether there are any ULP sessions. we could easily say its implementation specific since its internal to the mobile node. :) there are many ways this can be achieved inside a mobile node. 1. the mobile node keeps track of number of packets sent using a particular binding update list entry. it can record this information in the binding update list entry itself. 2. the mobile node records the timestamp of the last packet sent using a particular binding update list entry in the binding update list entry itself. 3. the mobile node keeps track of all the sockets that were opened with a particular home address. 4. etc.... you would see this issue in a non-Mobile IPv6 host too when you have multiple IPv6 addresses and the host wants to stop using a particular IPv6 address and start using another IPv6 address. let me know if I am completely off track. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 07 20:45:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo8eL-0004H3-Br; Wed, 07 Jun 2006 20:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo8eJ-0004Gq-7B; Wed, 07 Jun 2006 20:45:23 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo8eH-0006NW-Pz; Wed, 07 Jun 2006 20:45:23 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k580j9TS019677; Thu, 8 Jun 2006 03:45:09 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 03:44:42 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Jun 2006 03:44:42 +0300 Message-ID: <448772F6.9060009@iprg.nokia.com> Date: Wed, 07 Jun 2006 17:44:38 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] MIP and Upper Layer Protocol interaction References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <44872034.9010906@azairenet.com> In-Reply-To: <44872034.9010906@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2006 00:44:42.0515 (UTC) FILETIME=[BB150E30:01C68A94] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, Vijay Devarapalli wrote: > we could easily say its implementation specific since its > internal to the mobile node. :) > that's okay. I am trying to see what we can use.. > there are many ways this can be achieved inside a mobile > node. > > 1. the mobile node keeps track of number of packets sent > using a particular binding update list entry. it can > record this information in the binding update list entry > itself. > > 2. the mobile node records the timestamp of the last packet > sent using a particular binding update list entry in the > binding update list entry itself. > > 3. the mobile node keeps track of all the sockets that > were opened with a particular home address. > This might work. (1 and 2 above don't really relate to whether a session/connection is alive or not). I am referring to such interaction. How do we formalize it (if not standardize it)? > 4. etc.... > > you would see this issue in a non-Mobile IPv6 host too > when you have multiple IPv6 addresses and the host wants > to stop using a particular IPv6 address and start using > another IPv6 address. > Yes, but you don't expect session persistence in that case. -Rajeev > let me know if I am completely off track. > > Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 08 14:12:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoOzB-00023Q-UX; Thu, 08 Jun 2006 14:12:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoOzA-00022y-OV for mip6@ietf.org; Thu, 08 Jun 2006 14:12:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoOzA-0007U5-N6 for mip6@ietf.org; Thu, 08 Jun 2006 14:12:00 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoOwc-0004ce-N2 for mip6@ietf.org; Thu, 08 Jun 2006 14:09:26 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 11:09:10 -0700 Message-ID: <44886786.1010106@azairenet.com> Date: Thu, 08 Jun 2006 11:08:06 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mip6] MIP and Upper Layer Protocol interaction References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <44872034.9010906@azairenet.com> <448772F6.9060009@iprg.nokia.com> In-Reply-To: <448772F6.9060009@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2006 18:09:10.0406 (UTC) FILETIME=[A40E5A60:01C68B26] X-Spam-Score: -1.8 (-) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Rajeev Koodli wrote: > Vijay Devarapalli wrote: > >> we could easily say its implementation specific since its >> internal to the mobile node. :) >> > that's okay. I am trying to see what we can use.. > >> there are many ways this can be achieved inside a mobile >> node. >> >> 1. the mobile node keeps track of number of packets sent >> using a particular binding update list entry. it can >> record this information in the binding update list entry >> itself. >> >> 2. the mobile node records the timestamp of the last packet >> sent using a particular binding update list entry in the >> binding update list entry itself. >> >> 3. the mobile node keeps track of all the sockets that >> were opened with a particular home address. >> > This might work. (1 and 2 above don't really relate to > whether a session/connection is alive or not). > > I am referring to such interaction. How do we formalize it > (if not standardize it)? not sure. draft-ietf-mip6-mipext-advapi-07.txt is one option, but it is already in the RFC Editor queue. another option is to write an Informational document that describes how a Mobile IPv6 host could deal with home address changes. >> you would see this issue in a non-Mobile IPv6 host too >> when you have multiple IPv6 addresses and the host wants >> to stop using a particular IPv6 address and start using >> another IPv6 address. >> > Yes, but you don't expect session persistence in that case. hmmm.... you still need the sessions using the old IPv6 address to continue right? Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 08 23:59:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoY9a-0008LW-OZ; Thu, 08 Jun 2006 23:59:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoY9Z-0008LL-BK for mip6@ietf.org; Thu, 08 Jun 2006 23:59:21 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoY9W-0006YD-1C for mip6@ietf.org; Thu, 08 Jun 2006 23:59:21 -0400 Received: by nf-out-0910.google.com with SMTP id o60so499460nfa for ; Thu, 08 Jun 2006 20:59:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jiTMKuvr2przdJMOc3DTEw/v5fvp7YPacFEsjXxZciat6mxlMbwO+iAPmeKCRDUTGuHpGOVRazLPW3Ogcd+ar1dJLhmgChJJ/W3nc/GHMX3lP0fpfWrB5WX8i27cv5wCr7owpGCE3YT/Ppgx4eCUKvJlZT+giizwr5plEDwRerY= Received: by 10.49.39.7 with SMTP id r7mr2003490nfj; Thu, 08 Jun 2006 20:59:17 -0700 (PDT) Received: by 10.49.30.19 with HTTP; Thu, 8 Jun 2006 20:59:17 -0700 (PDT) Message-ID: <10e14db20606082059g5258794aq6e56cfa583073003@mail.gmail.com> Date: Fri, 9 Jun 2006 09:29:17 +0530 From: "Syam Madanapalli" To: "Vijay Devarapalli" Subject: Re: [Mip6] MIP and Upper Layer Protocol interaction In-Reply-To: <44886786.1010106@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <44872034.9010906@azairenet.com> <448772F6.9060009@iprg.nokia.com> <44886786.1010106@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, [cut] > >> you would see this issue in a non-Mobile IPv6 host too > >> when you have multiple IPv6 addresses and the host wants > >> to stop using a particular IPv6 address and start using > >> another IPv6 address. > >> > > Yes, but you don't expect session persistence in that case. > > hmmm.... you still need the sessions using the old IPv6 > address to continue right? As we are changing the HoA, isn't it natural for Layer 3 session to break? For session continuity in such cases, we may need to take applications help. For example, SIP may re-invite using new address. Thanks, Syam > > Vijay > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 09 02:32:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoaXV-0002vN-1y; Fri, 09 Jun 2006 02:32:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoaXU-0002vI-N7 for mip6@ietf.org; Fri, 09 Jun 2006 02:32:12 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoaXS-0005eS-5C for mip6@ietf.org; Fri, 09 Jun 2006 02:32:12 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k596W9QC006047 for ; Fri, 9 Jun 2006 09:32:09 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 09:32:09 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 01:32:06 -0500 Received: from 172.21.155.138 ([172.21.155.138]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 9 Jun 2006 06:32:07 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 09 Jun 2006 09:32:11 +0300 From: Basavaraj Patil To: Message-ID: Thread-Topic: secdir review request for mip6-bootstrapping-split Thread-Index: AcZ365nrG1R1XtHYSLeLYlju5sDEEgINVTGAAttgXio= In-Reply-To: <002e01c6844c$cf006b90$6b01a8c0@familyroom> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 06:32:06.0520 (UTC) FILETIME=[6D7D8F80:01C68B8E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [Mip6] FW: secdir review request for mip6-bootstrapping-split X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, Below is a review by the Secdir on the Split scenario bootstrapping I-D. -Chairs ------ Forwarded Message > From: ext pat cain > Date: Tue, 30 May 2006 20:54:38 -0400 > To: , 'Russ Housley' , 'Sam > Hartman' > Cc: 'Jari Arkko' , 'Basavaraj Patil' > , 'ext Vijay Devarapalli' > , 'Gopal Dommety' , > 'James Kempf' , 'Giaretta Gerardo' > > Subject: RE: secdir review request for mip6-bootstrapping-split > > Hi, > > I did a special/out-of-cycle security review of: > >> The MIP6 WG I-D: draft-ietf-mip6-bootstrapping-split-02. >> URL: >> http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-02. > txt >> > > Although the general idea presented in the document will work, I did not > like the document. The document seems to be missing many specific details, > pointing to other docs when magic is needed (e.g., "the detailed discussion > is provided in [6]." There is no other discussion on the topic covered in > [6], which is about IKE and MIPv6). Although I have read the document three > times, I may still be missing something, but it seems like all the details > are either in some other (draft or in-process) document or declared "out of > scope" for this one. > > For example, in section 3 there is a note that checking a certificate > revocation list (called a 'CTL' here) is necessary, but nowhere in the > document does it explain where all the parameters for this evaluation come > from (Maybe a pointer to PKIX?). Likewise, in section 5.2, IPSec Security > Association Setup, there is no discussion of where the IPSec credentials > come from (EAP?) -- just a document reference. The document referenced > assumes that credential info is already present in the MN, so the > bootstrapping process seems a little magical. Yet there is significant > detail explaining how to update the MN's DNS entry. > > Maybe section 5.2 or a later section should show the flow of the AAA and/or > IKE protocols to make sure that the necessary information as described in > [6] is actually being found. Or fix the pictures of section 7 to actually > show the steps before the IKE authentication magic. As the document > currently envisions it, a mobile node (MN) uses EAP to authenticate to the > service provider (MSP), then discovers its Home Agent (HA) IPaddress, then > (magically) makes an IPSec security association with the HA via IKEv2. > IKEv2 requires a bunch of numbers to do this work (like KEi). This being a > bootstrapping document I expect that this section would have listed those > and where the MN got them or made them up from. Do the security credentials > come via the MSP->MN authentication process? How? [It's also possible that > the MN would just use EAP with the HA to craft the IPSec SA key, but that > scenario isn't discussed.] > > > In section 9.3, security considerations, the ONE SENTENCE points to another > document for the security of authentication issues. This being a > bootstrapping document, I expect another sentence or maybe two sentences, > discussing the major security issues with bootstrapping such as the > impossibility of total authentication (since the MN will not have enough > security information to perform all the authentication checks it has to > declare a trust point to start from); how to trust that the HA and maybe the > MSP are the correct entities to setup EAP/AAA/SA associations with (i.e., > how do I know that this device is my HA? Guessing wrong would be bad); and > how a MN validates its self-generated keying material. > > I think the idea expressed in the document is plausible, but as a > bootstrapping document it needs the bootstrap info. And if you're going to > mention certificates and CRLs, a pointer to the PKIX validation rules would > be useful. > > Pat Cain > > ------ End of Forwarded Message _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 09 05:53:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FodgV-0002P9-Nv; Fri, 09 Jun 2006 05:53:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FodgU-0002Oq-O7; Fri, 09 Jun 2006 05:53:42 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FodgS-0004kj-AH; Fri, 09 Jun 2006 05:53:42 -0400 Received: from pc236.centersystems.at (guest-rocq-135223.inria.fr [128.93.135.223]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k599rUvI015370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jun 2006 11:53:30 +0200 Date: Fri, 9 Jun 2006 11:53:31 +0200 From: Thierry Ernst To: mip6@ietf.org, ml-ietf-mobopts Subject: Re: [Mip6] MIP and Upper Layer Protocol interaction Message-Id: <20060609115331.1d81e007.thierry.ernst@inria.fr> In-Reply-To: <44872034.9010906@azairenet.com> References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <44872034.9010906@azairenet.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-j-chkmail-Score: MSGID : 4489451A.000 on nez-perce : j-chkmail score : XX : 5/20 0 X-Miltered: at nez-perce with ID 4489451A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Several comments: - doesn't this thread initiated Rajeev belong to Shim6 ? - if it doesn't, it would be more appropriate to discuss it on the Monami6 ML, although we excluded to produce an output on the matter where the MN (i.e. either a host or a router) has multiple HoAs. But, still, Monami6 see is the right ML to discuss it when node multihoming comes to mobility. Thierry. On Wed, 07 Jun 2006 11:51:32 -0700 Vijay Devarapalli wrote: > Rajeev Koodli wrote: > > >> if not for privacy, perhaps the mobile node shouldn't > >> change its HoA abruptly, but let existing sessions > >> continue with the existing HoA and use the new HoA > >> for new sessions. the mobile node would also have > >> to update the DNS entry if it wants its FQDN to > >> resolve to the new HoA. > >> > > The problem here is how does the MN know to "let the > > existing sessions continue with the existing HoA"? If there is no CN's > > address in BUL, surely the MN can choose a suitable HoA. For > > a CN with which it has a binding, it has no reliable way of knowing > > whether there are any ULP sessions. > > we could easily say its implementation specific since its > internal to the mobile node. :) > > there are many ways this can be achieved inside a mobile > node. > > 1. the mobile node keeps track of number of packets sent > using a particular binding update list entry. it can > record this information in the binding update list entry > itself. > > 2. the mobile node records the timestamp of the last packet > sent using a particular binding update list entry in the > binding update list entry itself. > > 3. the mobile node keeps track of all the sockets that > were opened with a particular home address. > > 4. etc.... > > you would see this issue in a non-Mobile IPv6 host too > when you have multiple IPv6 addresses and the host wants > to stop using a particular IPv6 address and start using > another IPv6 address. > > let me know if I am completely off track. > > Vijay > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > -- Thierry ERNST, PhD INRIA Rocquencourt Project-Team IMARA +33 1 39 63 59 30 (office) _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 09 12:47:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fok8x-0004Io-Vj; Fri, 09 Jun 2006 12:47:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fok8w-0004Cw-8U for mip6@ietf.org; Fri, 09 Jun 2006 12:47:30 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fok8u-00066A-RD for mip6@ietf.org; Fri, 09 Jun 2006 12:47:30 -0400 Received: from [10.1.210.4] ([10.1.210.4]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 09:47:24 -0700 Message-ID: <4489A617.3070809@azairenet.com> Date: Fri, 09 Jun 2006 09:47:19 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <44872034.9010906@azairenet.com> <20060609115331.1d81e007.thierry.ernst@inria.fr> In-Reply-To: <20060609115331.1d81e007.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 16:47:24.0621 (UTC) FILETIME=[6264B7D0:01C68BE4] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: mip6@ietf.org, ml-ietf-mobopts X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Thierry, I think this belongs in mobopts (or MIP6 if the problem is sufficiently well understood). its more about stopping the use of one HoA and starting the use of another HoA rather than using multiple home addresses. Vijay Thierry Ernst wrote: > Several comments: > - doesn't this thread initiated Rajeev belong to Shim6 ? > > - if it doesn't, it would be more appropriate to discuss it on the > Monami6 ML, although we excluded to produce an output on the matter > where the MN (i.e. either a host or a router) has multiple HoAs. But, > still, Monami6 see is the right ML to discuss it when node multihoming > comes to mobility. > > Thierry. > > > > > > On Wed, 07 Jun 2006 11:51:32 -0700 > Vijay Devarapalli wrote: > >> Rajeev Koodli wrote: >> >>>> if not for privacy, perhaps the mobile node shouldn't >>>> change its HoA abruptly, but let existing sessions >>>> continue with the existing HoA and use the new HoA >>>> for new sessions. the mobile node would also have >>>> to update the DNS entry if it wants its FQDN to >>>> resolve to the new HoA. >>>> >>> The problem here is how does the MN know to "let the >>> existing sessions continue with the existing HoA"? If there is no CN's >>> address in BUL, surely the MN can choose a suitable HoA. For >>> a CN with which it has a binding, it has no reliable way of knowing >>> whether there are any ULP sessions. >> we could easily say its implementation specific since its >> internal to the mobile node. :) >> >> there are many ways this can be achieved inside a mobile >> node. >> >> 1. the mobile node keeps track of number of packets sent >> using a particular binding update list entry. it can >> record this information in the binding update list entry >> itself. >> >> 2. the mobile node records the timestamp of the last packet >> sent using a particular binding update list entry in the >> binding update list entry itself. >> >> 3. the mobile node keeps track of all the sockets that >> were opened with a particular home address. >> >> 4. etc.... >> >> you would see this issue in a non-Mobile IPv6 host too >> when you have multiple IPv6 addresses and the host wants >> to stop using a particular IPv6 address and start using >> another IPv6 address. >> >> let me know if I am completely off track. >> >> Vijay >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 09 12:55:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FokH3-0004D7-2H; Fri, 09 Jun 2006 12:55:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FokH1-0004Ct-IC; Fri, 09 Jun 2006 12:55:51 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FokH0-000743-4y; Fri, 09 Jun 2006 12:55:51 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k59GtkEZ013738; Fri, 9 Jun 2006 19:55:46 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 19:55:46 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Jun 2006 19:55:45 +0300 Message-ID: <4489A80F.3060608@iprg.nokia.com> Date: Fri, 09 Jun 2006 09:55:43 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] MIP and Upper Layer Protocol interaction References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <44872034.9010906@azairenet.com> <448772F6.9060009@iprg.nokia.com> <44886786.1010106@azairenet.com> In-Reply-To: <44886786.1010106@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 16:55:45.0610 (UTC) FILETIME=[8D0192A0:01C68BE5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: >>> Yes, but you don't expect session persistence in that case. >> > > hmmm.... you still need the sessions using the old IPv6 > address to continue right? > I meant for non-MIP case.. If you are not using MIP, you don't expect the session to survive if you change the address. -Rajeev > Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 09 14:01:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FolIA-0007i3-AC; Fri, 09 Jun 2006 14:01:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FolI8-0007hx-Nm for mip6@ietf.org; Fri, 09 Jun 2006 14:01:04 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FolI7-0006z4-7X for mip6@ietf.org; Fri, 09 Jun 2006 14:01:04 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k59I0wEo031190; Fri, 9 Jun 2006 21:00:58 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 21:00:58 +0300 Received: from [127.0.0.1] ([172.18.141.68]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 9 Jun 2006 21:00:57 +0300 Message-ID: <4489B757.7020101@iprg.nokia.com> Date: Fri, 09 Jun 2006 11:00:55 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Xia Subject: Re: [Mip6] RE: Mip6 Digest, Vol 26, Issue 1 References: <000001c68a0b$82c06cc0$43726e0a@china.huawei.com> In-Reply-To: <000001c68a0b$82c06cc0$43726e0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 18:00:57.0951 (UTC) FILETIME=[A8F16EF0:01C68BEE] X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: mip6@ietf.org, Rajeev.Koodli@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Sam Xia, Sam Xia wrote: >1: at the first paragraph of page 2, there is a sentence as below: > "Often, a binding between these two identifiers is also available, e.g., >through DNS". > Can you add some texts to clarify it more clearly? > > > I think the statement is pretty clear. It says people could use something like DNS to find the mapping between user identifier and device identifier. What additional text would you like to see? >2: at the third paragraph of page 2, there is a sentence as below: > " In this document, the concerns arising from the use of a globally > visible identifier, such as a Home Address, when roaming are > described ". > I think there should be a literal error to be revised. > > > Please be more specific. >3: I think that it will be very useful to add some texts to describe the >impacts from revealing roaming of MN to home network. > Maybe the home nodes have more means to determine that MN is away from >home network. > > > Actually, the home network nodes do not have lot more information than correspondents. Only thing they know is that a MN may have moved when they see Proxy Neighbor Advertisements. A MN may simply use reverse tunneling via Home Agent when communicating with the home network nodes (since reverse tunneling is as good as route optimization for communicating with the home network). So, I can add the following text:. "When roaming, a MN may treat its home network nodes as any other correspondents. Reverse tunneling is perhaps sufficient for home network communication, since route-optimized communication will traverse the identical path. Hence, a MN can avoid revealing its Care of Address to its home network correspondents simply by using reverse tunneling. The home network nodes may be able to "guess" that a MN is away when they hear Proxy Neighbor Advertisements from the Home Agent, but they won't be able to know its current point of attachment unless the MN uses route optimization with them." Thanks for your input, -Rajeev > Best Regards, Sam Xia > > > >>-----Original Message----- >>From: mip6-request@ietf.org [mailto:mip6-request@ietf.org] >>Sent: Sunday, June 04, 2006 12:00 AM >>To: mip6@ietf.org >>Subject: Mip6 Digest, Vol 26, Issue 1 >> >>Send Mip6 mailing list submissions to >> mip6@ietf.org >> >>To subscribe or unsubscribe via the World Wide Web, visit >> https://www1.ietf.org/mailman/listinfo/mip6 >>or, via email, send a message with subject or body 'help' to >> mip6-request@ietf.org >> >>You can reach the person managing the list at >> mip6-owner@ietf.org >> >>When replying, please edit your Subject line so it is more >>specific than "Re: Contents of Mip6 digest..." >> >> >>Today's Topics: >> >> 1. WG LC: draft-ietf-mip6-location-privacy-ps (01) >>(Basavaraj Patil) >> >> >>---------------------------------------------------------------------- >> >>Message: 1 >>Date: Fri, 02 Jun 2006 11:00:48 -0500 >>From: Basavaraj Patil >>Subject: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01) >>To: >>Message-ID: >>Content-Type: text/plain; charset="US-ASCII" >> >> >> >>Hello, >> >>This is the working group last call for I-D: >>draft-ietf-mip6-location-privacy-ps-01.txt (IP Address >>Location Privacy and Mobile IPv6: Problem Statement) >> >>WG LC will end on June 16th, 06. Please review and send your >>comments before the deadline. >> >>The document is intended to be published as an Informational RFC. >> >>-Chairs >> >>The link for the I-D: >>http://ietf.org/internet-drafts/draft-ietf-mip6-location-priva >>cy-ps-01.txt >> >> >> >> >>------------------------------ >> >>_______________________________________________ >>Mip6 mailing list >>Mip6@ietf.org >>https://www1.ietf.org/mailman/listinfo/mip6 >> >> >>End of Mip6 Digest, Vol 26, Issue 1 >>*********************************** >> >> >> > > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 12 10:50:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpnjx-0007o7-OF; Mon, 12 Jun 2006 10:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpnjv-0007nh-2W; Mon, 12 Jun 2006 10:50:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpnjt-0006Xc-Qo; Mon, 12 Jun 2006 10:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5CEo1WR015660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jun 2006 14:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fpnjt-0003tH-Hb; Mon, 12 Jun 2006 10:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 12 Jun 2006 10:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : MIP6-bootstrapping via DHCPv6 for the Integrated Scenario Author(s) : K. Chowdhury, A. Yegin Filename : draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt Pages : 23 Date : 2006-6-12 The Mobile IPv6 bootstrapping problem statement describes two main scenarios. In the first scenario (i.e. the split scenario), the mobile node's mobility service is authorized by a different service authorizer than the basic network access authorizer. In the second scenario (i.e. the integrated scenario), the mobile node's mobility service is authorized by the same service authorizer as the basic network access service authorizer. This document defines a method for home agent information discovery based on DHCPv6 for the integrated scenario. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip6-bootstrapping-integrated-dhc-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-12095709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-12095709.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Mon Jun 12 13:18:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpq35-0003BC-6Q; Mon, 12 Jun 2006 13:17:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpq33-0003Aw-Fn; Mon, 12 Jun 2006 13:17:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpq33-0005cn-8o; Mon, 12 Jun 2006 13:17:57 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5CHHuHp002673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Jun 2006 17:17:56 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fpq31-0007pl-Vz; Mon, 12 Jun 2006 13:17:55 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 12 Jun 2006 13:17:55 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: mip6 chair , mip6 mailing list , Internet Architecture Board , mip6 chair , RFC Editor Subject: [Mip6] Document Action: 'Problem Statement for bootstrapping Mobile IPv6' to Informational RFC X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The IESG has approved the following document: - 'Problem Statement for bootstrapping Mobile IPv6 ' as an Informational RFC This document is the product of the Mobility for IPv6 Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-05.txt Technical Summary A mobile node needs at least the following information: a home address, home agent address and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document discuss the issues involved with how the mobile node can be bootstrapped for Mobile IPv6 and various potential deployment scenarios for mobile node bootstrapping. Working Group Summary This document is a work item of the MIP6 WG. The WG has consensus to publish this document as an Informational RFC. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 14 11:16:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqX6Q-0002rm-QU; Wed, 14 Jun 2006 11:16:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqX6P-0002rh-TW for mip6@ietf.org; Wed, 14 Jun 2006 11:16:17 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqX6P-00032Z-Ap for mip6@ietf.org; Wed, 14 Jun 2006 11:16:17 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id AD18B1FAAA9; Wed, 14 Jun 2006 17:16:16 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27715-01-41; Wed, 14 Jun 2006 17:16:16 +0200 (CEST) Received: from [155.54.205.190] (inf-205-190.um.es [155.54.205.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id ADFAE1FAAA2; Wed, 14 Jun 2006 17:16:13 +0200 (CEST) Message-ID: <4490283F.5030703@dif.um.es> Date: Wed, 14 Jun 2006 17:16:15 +0200 From: "Pedro M. Ruiz" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Subject: [Mip6] CFP LOCAN 2006: 2nd Int'l Workshop on Localized Communications and Topology Control for Ad Hoc Networks X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Our apologies for duplicate postings. --------------------------------------------------------------------------- CALL FOR PAPERS - LOCAN 2006 2nd International Workshop on Localized Communication and Topology Protocols for Ad hoc Networks in conjunction with MASS-2006 (www.ieee-mass.org) Vancouver, Canada, October 9 - 12, 2006 --------------------------------------------------------------------------- SUBJECT AND SCOPE ----------------- This workshop covers comprehensively the algorithmic issues in the hot area of ad hoc and sensor networking. The design of data communication techniques in multi-hop ad hoc networks has challenges at all layers of communication. This workshop concentrates on the network layer problems like data communication (routing, QoS-routing, geocasting, multicasting, broadcasting, etc.) and topology control (neighbor discovery, power adjustment, neighbor elimination, etc.). Additionally, sensor networks are currently recognized as one of the priority research areas by NSF. The area of sensor networking is gaining momentum within the research community. This workshop will address ongoing research on this field, including problems such as: physical properties, sensor training, security through intelligent node cooperation, medium access, sensor area coverage with random and deterministic placement, object location, sensor position determination, energy efficient broadcasting and activity scheduling, routing, connectivity, data dissemination and gathering, sensor centric quality of routing, temporal message ordering, path exposure, tree reconfiguration, topology construction, and transport layer. The main paradigm shift is to apply localized (or greedy) schemes as opposed to existing protocols requiring global information. Localized algorithms are distributed algorithms where simple local node behaviour achieves a desired global objective. Localized protocols provide scalable solutions, that is, solutions for wireless networks with an arbitrary number of nodes, which is the main goal of this plan. Sensor and rooftop/mesh networks, for instance, have hundreds or thousands of nodes. The main objective of the workshop is to present state of the art research results on data communication and topology control in rapidly growing area of ad hoc and sensor networks, with emphasizes on localized techniques. Topics of interest include, but are not limited to: * Medium access control * Analytical, mobility and validation models for ad hoc networks * Hybrid networks and wireless Internet * Security in ad hoc networks * Data management issues, query processing, and data delivery * Routing, broadcasting and multicasting in ad hoc networks * Energy-efficient protocols for ad hoc networks * Quality of service in medium access control and routing * Topology construction and maintenance in ad hoc networks * Neighborhood discovery and mobility management IMPORTANT DATES --------------- Manuscript Submission: June 19, 2006 Acceptance Notification: July 19, 2006 Final Manuscript Due: August 10, 2006 PAPER SUBMISSION ---------------- Papers must not exceed 10 single-spaced and two-column pages using at least 10 point size type on 8.5 x 11 inches pages. See style files, author guidelines and instructions at the conference website. Accepted papers will be published by IEEE Computer Society Press, as proceedings of the MASS2006 workshops. Please submit papers via email to both program co-chairs (pedrom@dif.um.es, fei.dai@ndsu.edu). GENERAL CO-CHAIRS ----------------- David Simplot-Ryl, University of Lille, France Ivan Stojmenovic, University of Ottawa, Canada PROGRAM CO-CHAIRS ----------------- Pedro M. Ruiz, University of Murcia, Spain Fei Dai, North Dakota State University, USA Program Committee ----------------- Michel Barbeau, Carleton University, Ottawa, Canada Raffaele Bruno, IIT-CNR, Italy Ian Chakeres, Boing Inc., USA Misha Dohler, France Telecom R&D, France Stefan Dulman, University of Twente, Netherlands Jie Gao, State University of New York, USA J. J. Garcia-Luna-Aceves, Univ. of California, Santa Cruz, USA Silvia Giordano, University of Applied Science, SUPSI, Switzerland Antonio F. Gomez-Skarmeta, University of Murcia, Spain Isabelle Guerin Lassous, INRIA Rhone Alpes, France Mattias Handy, Univ. Rostock, Germany Thomas Kunz, Carleton University, Canada Miguel A. Labrador, Univ. South Florida, USA Pietro Manzoni, Univ. Politecnica de Valencia, Spain Luis Orozco, Univ. Castilla La Mancha, Spain Josep Paradells, Technical University of Catalonia (UPC), Spain S. S. Ravi, State University of New York at Albany, USA Isabelle Simplot-Ryl, University of Lille, France ADDITIONAL INFORMATION ---------------------- Additional information about the workshop will be continuously updated at the LOCAN 2006 website. http://ants.dif.um.es/locan2006/ -- --------------------------------------------------------------------- Pedro M. Ruiz, Ph.D. E-mail: pedrom@dif.um.es Fac. Informatica, Univ. of Murcia Phone: +34968364335 Campus de Espinardo s/n Fax: +34968364151 E-30100, Espinardo, Murcia www: ants.dif.um.es/~pedrom/ SPAIN --------------------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 14 14:05:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqZjg-0000ev-2e; Wed, 14 Jun 2006 14:05:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqZje-0000ei-Cp for mip6@ietf.org; Wed, 14 Jun 2006 14:04:58 -0400 Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqZjd-0006mn-Tk for mip6@ietf.org; Wed, 14 Jun 2006 14:04:58 -0400 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly17d.srv.mailcontrol.com (MailControl) with SMTP id k5EI4un1028635 for ; Wed, 14 Jun 2006 19:04:57 +0100 Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 6bfb_9783676c_fbca_11da_8706_0030482aac25; Wed, 14 Jun 2006 19:24:09 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2006061420045507-372425 ; Wed, 14 Jun 2006 20:04:55 +0200 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: -0.200,BAYES_00: -1.665, SARE_RECV_ADDR: 0.027,SARE_SUB_RAND_LETTRS2: 1.666 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de for mip6@ietf.org; Wed, 14 Jun 2006 20:08:24 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01) In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01) Thread-Index: AcaGXbaV9VG6wPJQEdqTqQARJNUNiAIYJm8g To: Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4FB8E418@lan-ex-01.panasonic.de> Date: Wed, 14 Jun 2006 20:04:48 +0200 From: "Kilian Weniger" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-07-00-10 (www.mailcontrol.com) on 10.68.0.127 X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, please find my comments below. General -------- - the term "roaming" is used in this draft many times, but is the term (defined in RFC3753) really appropriate here? Shouldn't it be replaced by "handover"? IMHO, the location privacy problem does also exist in non-roaming cases (MN moves to different subnet within an operator's network, i.e., intra-domain handover). Comments on Section 2.1 ------------ - The first sentence says "When a Mobile IP MN roams from its home network to a visited network, use of Care of Address in communication with a correspondent reveals that the MN has roamed."=20 I think this is a bit vague. First, the problem does not only exist when the MN roams from home to visited network, it also exists if it roams from one visited to another visited network. Second, not only the fact is revealed that the MN has roamed/moved, but also where the MN is located after the movement. Suggested text: "When a Mobile IP MN does a handover from its home network to a visited network *or from one visited network to another*, use of Care of Address in communication with a correspondent reveals that the MN has just done a handover *and where the MN is currently topologically located*."=20 - location privacy is only compromised if the correspondent node is able to link the HoA to a specific user/user identity. Although this may often be the case, this should be explicitly stated (similar statement exists in section 2.2). - "to the correspondent node" should be added to the title of the section (in section 2.2, the care-of address is disclosed as well, but to on-lookers) Comments on Section 2.2 ------------ - Analog to the comment on section 2.1, the text should consider that the problem does also exist when the MN moves from one visited network to another.=20 - analog to the comment on section 2.1, "to on-lookers" should be added to the title - It should be mentioned that location privacy is only compromised if the on-looker is located on the path between MN and HA in bi-directional tunneling mode or on the path between MN and CN in route optimization mode.=20 Comments on Section 3 and conclusion ------------------------ - The granularity of location information revealed from a care-of address depends also on whether a local mobility management scheme such as HMIPv6 or netlmm is used or not. Maybe this should be mentioned somewhere. - The draft concludes that two problems exist: disclosure of CoA to CN and disclosure of HoA to on-lookers. I would like to see some conclusion and discussions of requirements, so that solutions later can better be evaluated against requirements. For instance * which level of granularity regarding location privacy is required (some argue that the level that netlmm provides is sufficient)?=20 * it should be possible to combine solutions for hiding CoA from CN and hiding HoA from on-lookers (i.e., provide both simultaneously)=20 * Route optimization should certainly be supported in both cases so that delay-sensitive services and efficient routing are possible. - The following paragraph is not really clear to me: "With its correspondents, the MN can either communicate directly or reverse tunnel its packets through the Home Agent. Using reverse tunneling does not reveal the new IP address of the MN, although performance may vary depending on the particular scenario. In some instances, the performance difference could be noticeable enough to serve as a hint to the correspondent."=20 What exactly is this hint about and how reliable is such hint? Does it mean that the correspondent can find out that the MN is not located at home only based on packet delay? While it might be true in some cases that the delay of reverse tunneled packets is high if the MN is away from home, this is not generally true, since there are many potential factors contributing to the packet delay. E.g., the delay heavily depends on the access technology used. When a users changes from a GPRS home network to a WLAN visited network, the packet delay may be much higher if the MN is at home compared to when it is located in the visited network. Since the correspondent node usually doesn't know which access technology is used by the MN, I do not see how the CN can derive the MN's location from packet delay. - Kilian=20 -----Original Message----- From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com]=20 Sent: Freitag, 2. Juni 2006 18:01 To: mip6@ietf.org Subject: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01) Hello, This is the working group last call for I-D: draft-ietf-mip6-location-privacy-ps-01.txt (IP Address Location Privacy and Mobile IPv6: Problem Statement) WG LC will end on June 16th, 06. Please review and send your comments before the deadline. The document is intended to be published as an Informational RFC. -Chairs The link for the I-D: http://ietf.org/internet-drafts/draft-ietf-mip6-location-privacy-ps-01.t xt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 14 15:50:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqbNO-000568-HL; Wed, 14 Jun 2006 15:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqbNK-00054h-9e; Wed, 14 Jun 2006 15:50:02 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqbNJ-00014s-RC; Wed, 14 Jun 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5EJo1WR030747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FqbNJ-0006ru-I3; Wed, 14 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-ha-switch-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobility Header Home Agent Switch Message Author(s) : B. Haley, et al. Filename : draft-ietf-mip6-ha-switch-00.txt Pages : 11 Date : 2006-6-14 This document specifies a new Mobility Header message type that can be used between a home agent and mobile node to signal a mobile node that it should acquire a new home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-ha-switch-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip6-ha-switch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-ha-switch-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: <2006-6-14111214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-ha-switch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-ha-switch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-14111214.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Wed Jun 14 17:48:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqdDa-0005c0-AM; Wed, 14 Jun 2006 17:48:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqdAn-0002ci-QS for mip6@ietf.org; Wed, 14 Jun 2006 17:45:13 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqcxb-0003G1-TR for mip6@ietf.org; Wed, 14 Jun 2006 17:31:36 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5ELVVSX022513 for ; Thu, 15 Jun 2006 00:31:35 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 00:31:33 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 16:31:33 -0500 Received: from 172.19.244.108 ([172.19.244.108]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Jun 2006 21:31:32 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 14 Jun 2006 16:31:35 -0500 From: Basavaraj Patil To: Message-ID: Thread-Topic: Request to progress MIP6 WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcaP+ch+Bv3nbPvtEdqcIgARJNUNiAAACDLp In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Jun 2006 21:31:33.0076 (UTC) FILETIME=[E8214140:01C68FF9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Subject: [Mip6] FW: Request to progress MIP6 WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org FYI, ------ Forwarded Message > From: Basavaraj Patil > Date: Wed, 14 Jun 2006 16:30:40 -0500 > To: ext Jari Arkko , > Cc: "W. Mark Townsley" , Gopal Dommety > , ext Vijay Devarapalli , > > Conversation: Request to progress MIP6 WG I-D: > draft-ietf-mip6-ikev2-ipsec-06.txt > Subject: Request to progress MIP6 WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt > > > > Hi Jari, > > The MIP6 WG I-D "Mobile IPv6 Operation with IKEv2 and the revised > IPsec architecture" draft has completed a second WG last call and is > now ready to be progressed towards standards track. Rev 06 of the I-D > has incorporated all the comments that have been received during the > last call and prior to it. > > We would like to request you to process this I-D and progress it towards > publication as a standards track RFC. > > Below is the template that was completed when we submitted the WG LC > the 1st time and sent it to the IESG (Margaret). Pretty much all the > statements are valid even now. > > -Raj > > ================================================== > >> The MIP6 WG I-D "Mobile IPv6 Operation with IKEv2 and the revised >> IPsec", I-D: draft-ietf-mip6-ikev2-ipsec-04.txt has completed WG last >> call and has been revised following the comments received. >> It is ready for AD review and forwarded through the IETF process for >> publication. >> >> Intended status for this I-D: Standards track >> >> >> 1) Have the chairs personally reviewed this version of the ID and do >> they believe this ID is sufficiently baked to forward to the IESG >> for publication? >> >> Yes. >> >> >> 2) Has the document had adequate review from both key WG members and >> key non-WG members? Do you have any concerns about the depth or >> breadth of the reviews that have been performed? >> >> The I-D has been reviewed sufficiently by WG members as well as >> experts in the area of IPsec and security. >> >> 3) Do you have concerns that the document needs more review from a >> particular (broader) perspective (e.g., security, operational >> complexity, someone familiar with AAA, etc.)? >> >> No. The document does not need further reviews. >> >> 4) Do you have any specific concerns/issues with this document that >> you believe the ADs and/or IESG should be aware of? For example, >> perhaps you are uncomfortable with certain parts of the document, >> or whether there really is a need for it, etc., but at the same >> time these issues have been discussed in the WG and the WG has >> indicated it wishes to advance the document anyway. >> >> There are no specific concerns with this document. >> >> 5) How solid is the WG consensus behind this document? Does it >> represent the strong concurrence of a few individuals, with others >> being silent, or does the WG as a whole understand and agree with >> it? >> >> Strong WG consensus. Base MIP6 specs (RFCs 3775/3776) specified the >> use of IKE (v1) as the means to establish the IPsec SA. This I-D is >> specifying the use of IKEv2 for establishing the MN-HA IPsec SA. >> >> >> 6) Has anyone threatened an appeal or otherwise indicated extreme >> discontent? If so, please summarize what are they upset about. >> >> No. >> >> 7) Have the chairs verified that the document adheres to _all_ of the >> ID nits? (see http://www.ietf.org/ID-nits.html). >> >> Yes. No Nits found. It has been run through the nits checker available >> at the tools.ietf web site. >> >> 8) Does the document a) split references into normative/informative, >> and b) are there normative references to IDs, where the IDs are not >> also ready for advancement or are otherwise in an unclear state? >> (Note: the RFC editor will not publish an RFC with normative >> references to IDs, it will delay publication until all such IDs are >> also ready for publication as RFCs.) >> >> Yes. >> >> 9) For Standards Track and BCP documents, the IESG approval >> announcement includes a writeup section with the following >> sections: >> >> - Technical Summary >> >> This document describes Mobile IPv6 operation with the revised >> IPsec architecture and IKEv2. >> >> - Working Group Summary >> >> The document has been discussed in the WG at several IETF >> meetings. It has also been reviewed sufficiently by WG members as >> well as security experts. There is consensus in publishing this I-D >> as a proposed standard. This specification is required in view of >> IKEv2 becoming the revised mechanism for setting up IPsec SAs. >> >> - Protocol Quality >> >> >> >> - is the protocol already being implemented? >> >> Yes. >> >> >> - have a significant number of vendors indicated they plan to >> implement the spec? >> >> There are some vendors who have at least indicated that they >> will implement this spec. >> >> - are there any reviewers (during the end stages) that merit >> explicit mention as having done a thorough review that resulted >> in important changes or a conclusion that the document was fine >> (except for maybe some nits?) >> >> The acknowledgement section captures this adequately. >> >> -Basavaraj >> >> ------ End of Forwarded Message _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 14 18:44:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqe5f-00059x-7D; Wed, 14 Jun 2006 18:43:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqe5d-00059Z-0K for mip6@ietf.org; Wed, 14 Jun 2006 18:43:57 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqe5c-0005HJ-F7 for mip6@ietf.org; Wed, 14 Jun 2006 18:43:56 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5EMhsrT025355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Jun 2006 15:43:55 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5EMho5g005039; Wed, 14 Jun 2006 15:43:53 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 15:43:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Request to progress MIP6 WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Wed, 14 Jun 2006 15:43:48 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04F60C@NAEX14.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Request to progress MIP6 WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcaP+ch+Bv3nbPvtEdqcIgARJNUNiAAACDLpAAJ9LnA= From: "Soliman, Hesham" To: "Basavaraj Patil" , X-OriginalArrivalTime: 14 Jun 2006 22:43:53.0166 (UTC) FILETIME=[03066EE0:01C69004] X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: jari.arkko@piuha.net X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, authors,=20 How was the issue I raised about the tunnel mode resolved in the draft? A quick glance tells me nothing changed. Hesham > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com]=20 > Sent: Wednesday, June 14, 2006 5:32 PM > To: mip6@ietf.org > Subject: [Mip6] FW: Request to progress MIP6 WG I-D:=20 > draft-ietf-mip6-ikev2-ipsec-06.txt >=20 >=20 > FYI, >=20 > ------ Forwarded Message > > From: Basavaraj Patil > > Date: Wed, 14 Jun 2006 16:30:40 -0500 > > To: ext Jari Arkko ,=20 > > > Cc: "W. Mark Townsley" , Gopal Dommety > > , ext Vijay Devarapalli=20 > , > > > > Conversation: Request to progress MIP6 WG I-D: > > draft-ietf-mip6-ikev2-ipsec-06.txt > > Subject: Request to progress MIP6 WG I-D:=20 > draft-ietf-mip6-ikev2-ipsec-06.txt > >=20 > >=20 > >=20 > > Hi Jari, > >=20 > > The MIP6 WG I-D "Mobile IPv6 Operation with IKEv2 and the revised > > IPsec architecture" draft has completed a second WG last=20 > call and is > > now ready to be progressed towards standards track. Rev 06=20 > of the I-D > > has incorporated all the comments that have been received=20 > during the > > last call and prior to it. > >=20 > > We would like to request you to process this I-D and=20 > progress it towards > > publication as a standards track RFC. > >=20 > > Below is the template that was completed when we submitted=20 > the WG LC > > the 1st time and sent it to the IESG (Margaret). Pretty=20 > much all the > > statements are valid even now. > >=20 > > -Raj > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > >=20 > >> The MIP6 WG I-D "Mobile IPv6 Operation with IKEv2 and the revised > >> IPsec", I-D: draft-ietf-mip6-ikev2-ipsec-04.txt has=20 > completed WG last > >> call and has been revised following the comments received. > >> It is ready for AD review and forwarded through the IETF=20 > process for > >> publication. > >>=20 > >> Intended status for this I-D: Standards track > >>=20 > >>=20 > >> 1) Have the chairs personally reviewed this version of=20 > the ID and do > >> they believe this ID is sufficiently baked to forward=20 > to the IESG > >> for publication? > >>=20 > >> Yes. > >>=20 > >>=20 > >> 2) Has the document had adequate review from both key WG=20 > members and > >> key non-WG members? Do you have any concerns about the depth or > >> breadth of the reviews that have been performed? > >>=20 > >> The I-D has been reviewed sufficiently by WG members as well as > >> experts in the area of IPsec and security. > >>=20 > >> 3) Do you have concerns that the document needs more review from a > >> particular (broader) perspective (e.g., security, operational > >> complexity, someone familiar with AAA, etc.)? > >>=20 > >> No. The document does not need further reviews. > >> =20 > >> 4) Do you have any specific concerns/issues with this=20 > document that > >> you believe the ADs and/or IESG should be aware of? For example, > >> perhaps you are uncomfortable with certain parts of the=20 > document, > >> or whether there really is a need for it, etc., but at the same > >> time these issues have been discussed in the WG and the WG has > >> indicated it wishes to advance the document anyway. > >>=20 > >> There are no specific concerns with this document. > >> =20 > >> 5) How solid is the WG consensus behind this document? Does it > >> represent the strong concurrence of a few individuals,=20 > with others > >> being silent, or does the WG as a whole understand and=20 > agree with > >> it? > >>=20 > >> Strong WG consensus. Base MIP6 specs (RFCs 3775/3776)=20 > specified the > >> use of IKE (v1) as the means to establish the IPsec SA.=20 > This I-D is > >> specifying the use of IKEv2 for establishing the MN-HA IPsec SA. > >>=20 > >>=20 > >> 6) Has anyone threatened an appeal or otherwise indicated extreme > >> discontent? If so, please summarize what are they upset about. > >>=20 > >> No. > >> =20 > >> 7) Have the chairs verified that the document adheres to=20 > _all_ of the > >> ID nits? (see http://www.ietf.org/ID-nits.html). > >>=20 > >> Yes. No Nits found. It has been run through the nits=20 > checker available > >> at the tools.ietf web site. > >> =20 > >> 8) Does the document a) split references into=20 > normative/informative, > >> and b) are there normative references to IDs, where the=20 > IDs are not > >> also ready for advancement or are otherwise in an unclear state? > >> (Note: the RFC editor will not publish an RFC with normative > >> references to IDs, it will delay publication until all=20 > such IDs are > >> also ready for publication as RFCs.) > >>=20 > >> Yes.=20 > >>=20 > >> 9) For Standards Track and BCP documents, the IESG approval > >> announcement includes a writeup section with the following > >> sections: > >>=20 > >> - Technical Summary > >>=20 > >> This document describes Mobile IPv6 operation with the revised > >> IPsec architecture and IKEv2. > >>=20 > >> - Working Group Summary > >>=20 > >> The document has been discussed in the WG at several IETF > >> meetings. It has also been reviewed sufficiently by WG=20 > members as > >> well as security experts. There is consensus in=20 > publishing this I-D > >> as a proposed standard. This specification is required=20 > in view of > >> IKEv2 becoming the revised mechanism for setting up IPsec SAs. > >>=20 > >> - Protocol Quality > >>=20 > >>=20 > >>=20 > >> - is the protocol already being implemented? > >>=20 > >> Yes. > >>=20 > >>=20 > >> - have a significant number of vendors indicated they plan to > >> implement the spec? > >>=20 > >> There are some vendors who have at least indicated that they > >> will implement this spec. > >> =20 > >> - are there any reviewers (during the end stages) that merit > >> explicit mention as having done a thorough review=20 > that resulted > >> in important changes or a conclusion that the=20 > document was fine > >> (except for maybe some nits?) > >>=20 > >> The acknowledgement section captures this adequately. > >>=20 > >> -Basavaraj > >>=20 > >>=20 >=20 > ------ End of Forwarded Message >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 14 23:57:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqiyq-00016i-KW; Wed, 14 Jun 2006 23:57:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqiyp-00016c-Tq for mip6@ietf.org; Wed, 14 Jun 2006 23:57:15 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqiyo-0006VW-1T for mip6@ietf.org; Wed, 14 Jun 2006 23:57:15 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0V00LMVVGI23@szxga02-in.huawei.com> for mip6@ietf.org; Thu, 15 Jun 2006 12:07:31 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0V00BNYVGIXU@szxga02-in.huawei.com> for mip6@ietf.org; Thu, 15 Jun 2006 12:07:30 +0800 (CST) Received: from w50392 ([10.164.45.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0V00C3SV7SI1@szxml04-in.huawei.com> for mip6@ietf.org; Thu, 15 Jun 2006 12:02:17 +0800 (CST) Date: Thu, 15 Jun 2006 11:51:40 +0800 From: Tom Wan To: mip6@ietf.org Message-id: <001a01c6902f$02f6f700$6e2ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [Mip6] Mip6] request comments on a new individual draft X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1578385583==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1578385583== Content-type: multipart/alternative; boundary="Boundary_(ID_wNUDK7hZA87UDsrJDsv7YA)" This is a multi-part message in MIME format. --Boundary_(ID_wNUDK7hZA87UDsrJDsv7YA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi,folks: I have submitted a new individual draft. Abstract The current Mobile IPv6 and NEMO specification supports only IPv6. As an extension, the DSMip6 protocol [v4traversal]defines how the dual-stack mobile node roams in the ipv4 network. The dsmip6 protocol assumes that both home agent and mobile node supports mipv4 and mipv6 protocol. It also assumes that both the home agent and mobile node have a configured ipv4 address. These assumptions do work during many scenarios. However, as the ipv4 address is a scarce resource in many counrties, some mobile nodes may not be able to get configured ipv4 home addresses from their home agents. In this scenario, a temporary ipv4 home address is more useful. This document will focuse on this scenario. Would you mind give me some comments?Your comments are much appreciated. BR Tom http://www.ietf.org/internet-drafts/draft-wan-mip6-nemo-routing-00.txt --Boundary_(ID_wNUDK7hZA87UDsrJDsv7YA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi,folks:
I have submitted a new individual draft.
 
Abstract

   The current Mobile IPv6 and NEMO specification supports only IPv6.
   As an extension, the DSMip6 protocol [v4traversal]defines how the
   dual-stack mobile node roams in the ipv4 network.  The dsmip6
   protocol assumes that both home agent and mobile node supports mipv4
   and mipv6 protocol.  It also assumes that both the home agent and
   mobile node have a configured ipv4 address.  These assumptions do
   work during many scenarios.  However, as the ipv4 address is a scarce
   resource in many counrties, some mobile nodes may not be able to get
   configured ipv4 home addresses from their home agents.  In this
   scenario, a temporary ipv4 home address is more useful.  This
   document will focuse on this scenario.
 
Would you mind give me some comments?Your comments are much appreciated.
 
 
BR
Tom
 
 
 
--Boundary_(ID_wNUDK7hZA87UDsrJDsv7YA)-- --===============1578385583== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1578385583==-- From mip6-bounces@ietf.org Thu Jun 15 10:49:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqtAP-0002UW-2E; Thu, 15 Jun 2006 10:49:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqtAN-0002UQ-HR for mip6@ietf.org; Thu, 15 Jun 2006 10:49:51 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqtAK-0005Tx-QV for mip6@ietf.org; Thu, 15 Jun 2006 10:49:51 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B67BF8989C; Thu, 15 Jun 2006 17:49:44 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5EDC58988E; Thu, 15 Jun 2006 17:49:44 +0300 (EEST) Message-ID: <44917382.4060102@kolumbus.fi> Date: Thu, 15 Jun 2006 17:49:38 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mobile IPv6 Mailing List References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: Peter McCann , Henrik Levkowetz Subject: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org FYI -- MIP4 wants to recharter to include work on dual stack Mobile IPv4 support (item 10 below). Given that MIP6 also works on related issues I wanted to point you to this update. Comments welcome. --Jari IESG Secretary wrote: >A new charter for the Mobility for IPv4 (mip4) working group in the Internet >Area of the IETF is being considered. The draft charter is provided below for >your review and comment. > >Review time is one week. > >The IETF Secretariat > >+++ > >Mobility for IPv4 (mip4) >========================== > >Last Modified: 2006-06-13 > >Current Status: Active Working Group > >Chair(s): >Peter McCann >Henrik Levkowetz > >Internet Area Director(s): >Jari Arkko >Mark Townsley > >Internet Area Advisor: >Jari Arkko > >Mailing Lists: >General Discussion: mip4@ietf.org >To Subscribe: mip4-request@ietf.org >In Body: subscribe >Archive: http://www.ietf.org/mail-archive/web/mip4/index.html > >Description of Working Group: > >IP mobility support for IPv4 nodes (hosts and routers) is specified in >RFC3344. RFC 3344 mobility allows a node to continue using >its "permanent" home address as it moves around the Internet. The >Mobile IP protocols support transparency above the IP layer, including >maintenance of active TCP connections and UDP port bindings.Besides >the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal >with concerns such as optimization, security, extensions, AAA support, >and deployment issues. > >MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 >networks). The scope of the deployment is on a fairly large scale and >accordingly, the MIP4 WG will focus on deployment issues and on >addressing known deficiencies and shortcomings in the protocol that >have come up as a result of deployment experience. Specifically, the >working group will complete the work items to facilitate interactions >with AAA environments, interactions with enterprise environments when >MIPv4 is used therein, and updating existing protocol specifications >in accordance with deployment needs and advancing those protocols that >are on the standards track. > >Work expected to be done by the MIP4 WG as proposed by this charter is >as follows: > >1. MIPv4 has been a proposed standard for several years. It has been >adopted by other standard development organizations and has been >deployed commercially. One of the next steps for the WG is to advance >the protocol to draft standard status. As part of advancing base >Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised >to reflect implementation experience > >2. Work items that are pending from the previous Mobile IP WG, which >will be completed by the MIP4 WG, are: > >- completion of the MIB for the revised base Mobile IP >specification (2006bis) > >- regional registration draft. > >3. The MIP4 WG will also complete the work on MIPv4 interactions >in VPN scenarios. This work will involve identifying the requirements >and a solution development for MIPv4 operation in the presence >of IPsec VPNs. > >4. Additionally, a proposal has been made for how MOBIKE could work >together with MIPv4. This proposal does not describe any new protocol, >but formulates a best current practice for deploying MOBIKE together >with MIPv4. The working group will adopt and complete this document. > >5. Some issues have been raised with respect to RFC3519. These will be >identified and addressed as appropriate, through errata, revision >of RFC 3519, and/or supplemental documents as needed. > >6. It has been proposed that the FMIP protocol, which has been >standardised for MIPv6 in the MIPSHOP working group, should also be >published as an experimental protocol for MIPv4. A draft for this >exists. The working group will take up and carry this work forward >to publication > >7. An extension to carry generic strings in the Registration Reply >message has been proposed. The purpose is to supply supplemental >human-readable information intended to the MN user. The working >group will complete the specification and applicability statement of >such an extension. > >8. RADIUS attributes for MIP4. A set of RADIUS attributes has >been proposed for MIPv4. > >The working group will first produce a requirements specification, >describing how the work differs from the requirements in RFC 2977 >and the functionality provided by RFC 4004 (the MIPv4 Diameter App). >The reason why this first step is required is that RFC 3127 pretty >clearly shows that full 2977 functionality can't be provided by even >a considerably extended RADIUS, so we need to match the requirements >to what can be done within RADIUS. > >Provided the requirements work finds approval with ADs and radext, >the workgroup will complete the specification of MIPv4 RADIUS >attributes, solicit feedback from the Radius Extensions WG, adjust, >and submit this for publication. > >9. MIPv4 Extension for Configuration Options. > >Several drafts have proposed extensions to help improve configuration >of MIPv4 clients. The latest proposal is for a general configuration >option extension which could carry information such as e.g., DNS >address and DHCP server address. The working group will take on >and complete one proposal for a configuration option extension. > >10. Dual-stack Support > >There have been several proposals for how to enable an IPv6 >connection over a network that supports Mobile IPv4. The >basic idea is to include an IPv6 address in the Mobile IPv4 >signaling messages. The working group will take on and complete >one proposal for IPv6 over Mobile IPv4. > >Goals and Milestones: > >Done AAA Keys for MIPv4 to IESG >Done MIPv4 VPN interaction problem statement to IESG >Done Low latency handover to experimental >Done Experimental MIPv4 message and extensions draft to IESG >Done Dynamic Home Agent assignment protocol solution to IESG >Done Revised MIPv4 Challenge/Response (3012bis) to IESG >Done Regional registration document to IESG >Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT WG for comment >Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG >May 2006 MIPv4 Mobike interaction (BCP) to the IESG >May 2006 MIPv4 VPN interaction (BCP) to the IESG >May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment >Jun 2006 Revised MIPv4 specification to IESG for Draft Std. >Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG >Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the IESG >Sep 2006 FMIPv4 (Experimental) to the IESG >Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG >Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG >Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG >Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 12:30:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqujL-0004Ls-Ix; Thu, 15 Jun 2006 12:30:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqujJ-0004Ln-Vl for mip6@ietf.org; Thu, 15 Jun 2006 12:30:01 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqujI-0007KB-MQ for mip6@ietf.org; Thu, 15 Jun 2006 12:30:01 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5FGU0oW030962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 15 Jun 2006 12:30:00 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k5FGTiOL249826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Jun 2006 10:29:44 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k5FGTxh2021115 for ; Thu, 15 Jun 2006 10:29:59 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.151.17]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5FGTxDn021109; Thu, 15 Jun 2006 10:29:59 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k5FGTtZs001857; Thu, 15 Jun 2006 12:29:56 -0400 Message-Id: <200606151629.k5FGTtZs001857@rotala.raleigh.ibm.com> To: Jari Arkko Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) In-Reply-To: Message from jari.arkko@kolumbus.fi of "Thu, 15 Jun 2006 17:49:38 +0300." <44917382.4060102@kolumbus.fi> Date: Thu, 15 Jun 2006 12:29:55 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Mobile IPv6 Mailing List , Peter McCann , Henrik Levkowetz X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > FYI -- MIP4 wants to recharter to include work on dual stack > Mobile IPv4 support (item 10 below). Given that MIP6 also > works on related issues I wanted to point you to this update. > Comments welcome. Is there a well-defined problem statement for item 10? Thomas _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 13:02:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvFC-0005fm-R7; Thu, 15 Jun 2006 13:02:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvFB-0005fh-Mr for mip6@ietf.org; Thu, 15 Jun 2006 13:02:57 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqvFA-0003xk-2Z for mip6@ietf.org; Thu, 15 Jun 2006 13:02:57 -0400 Message-ID: <003801c6909d$a7a918a0$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jari Arkko" , "Mobile IPv6 Mailing List" References: <44917382.4060102@kolumbus.fi> Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) Date: Thu, 15 Jun 2006 10:03:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: Peter McCann , Henrik Levkowetz X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org So I'm wondering if there is any work to be done here in addition to the draft that is currently being worked on in the MIP6 WG? If the only work involves having someone from the MIP4 WG review the draft, then is there really need for a new charter item? On the other hand, if there is need for another document describing the interaction between the MIP6 transition work and MIP4, then maybe there is need for a new charter item (but if that is true, I'd say it's a flaw in the MIP6 transition document, and it should be handled by updating that). Also, is there a MDIR concall tomorrow? jak ----- Original Message ----- From: "Jari Arkko" To: "Mobile IPv6 Mailing List" Cc: "Peter McCann" ; "Henrik Levkowetz" Sent: Thursday, June 15, 2006 7:49 AM Subject: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) > > FYI -- MIP4 wants to recharter to include work on dual stack > Mobile IPv4 support (item 10 below). Given that MIP6 also > works on related issues I wanted to point you to this update. > Comments welcome. > > --Jari > > IESG Secretary wrote: > >>A new charter for the Mobility for IPv4 (mip4) working group in the >>Internet >>Area of the IETF is being considered. The draft charter is provided below >>for >>your review and comment. >> >>Review time is one week. >> >>The IETF Secretariat >> >>+++ >> >>Mobility for IPv4 (mip4) >>========================== >> >>Last Modified: 2006-06-13 >> >>Current Status: Active Working Group >> >>Chair(s): >>Peter McCann >>Henrik Levkowetz >> >>Internet Area Director(s): >>Jari Arkko >>Mark Townsley >> >>Internet Area Advisor: >>Jari Arkko >> >>Mailing Lists: >>General Discussion: mip4@ietf.org >>To Subscribe: mip4-request@ietf.org >>In Body: subscribe >>Archive: http://www.ietf.org/mail-archive/web/mip4/index.html >> >>Description of Working Group: >> >>IP mobility support for IPv4 nodes (hosts and routers) is specified in >>RFC3344. RFC 3344 mobility allows a node to continue using >>its "permanent" home address as it moves around the Internet. The >>Mobile IP protocols support transparency above the IP layer, including >>maintenance of active TCP connections and UDP port bindings.Besides >>the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal >>with concerns such as optimization, security, extensions, AAA support, >>and deployment issues. >> >>MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 >>networks). The scope of the deployment is on a fairly large scale and >>accordingly, the MIP4 WG will focus on deployment issues and on >>addressing known deficiencies and shortcomings in the protocol that >>have come up as a result of deployment experience. Specifically, the >>working group will complete the work items to facilitate interactions >>with AAA environments, interactions with enterprise environments when >>MIPv4 is used therein, and updating existing protocol specifications >>in accordance with deployment needs and advancing those protocols that >>are on the standards track. >> >>Work expected to be done by the MIP4 WG as proposed by this charter is >>as follows: >> >>1. MIPv4 has been a proposed standard for several years. It has been >>adopted by other standard development organizations and has been >>deployed commercially. One of the next steps for the WG is to advance >>the protocol to draft standard status. As part of advancing base >>Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised >>to reflect implementation experience >> >>2. Work items that are pending from the previous Mobile IP WG, which >>will be completed by the MIP4 WG, are: >> >>- completion of the MIB for the revised base Mobile IP >>specification (2006bis) >> >>- regional registration draft. >> >>3. The MIP4 WG will also complete the work on MIPv4 interactions >>in VPN scenarios. This work will involve identifying the requirements >>and a solution development for MIPv4 operation in the presence >>of IPsec VPNs. >> >>4. Additionally, a proposal has been made for how MOBIKE could work >>together with MIPv4. This proposal does not describe any new protocol, >>but formulates a best current practice for deploying MOBIKE together >>with MIPv4. The working group will adopt and complete this document. >> >>5. Some issues have been raised with respect to RFC3519. These will be >>identified and addressed as appropriate, through errata, revision >>of RFC 3519, and/or supplemental documents as needed. >> >>6. It has been proposed that the FMIP protocol, which has been >>standardised for MIPv6 in the MIPSHOP working group, should also be >>published as an experimental protocol for MIPv4. A draft for this >>exists. The working group will take up and carry this work forward >>to publication >> >>7. An extension to carry generic strings in the Registration Reply >>message has been proposed. The purpose is to supply supplemental >>human-readable information intended to the MN user. The working >>group will complete the specification and applicability statement of >>such an extension. >> >>8. RADIUS attributes for MIP4. A set of RADIUS attributes has >>been proposed for MIPv4. >> >>The working group will first produce a requirements specification, >>describing how the work differs from the requirements in RFC 2977 >>and the functionality provided by RFC 4004 (the MIPv4 Diameter App). >>The reason why this first step is required is that RFC 3127 pretty >>clearly shows that full 2977 functionality can't be provided by even >>a considerably extended RADIUS, so we need to match the requirements >>to what can be done within RADIUS. >> >>Provided the requirements work finds approval with ADs and radext, >>the workgroup will complete the specification of MIPv4 RADIUS >>attributes, solicit feedback from the Radius Extensions WG, adjust, >>and submit this for publication. >> >>9. MIPv4 Extension for Configuration Options. >> >>Several drafts have proposed extensions to help improve configuration >>of MIPv4 clients. The latest proposal is for a general configuration >>option extension which could carry information such as e.g., DNS >>address and DHCP server address. The working group will take on >>and complete one proposal for a configuration option extension. >> >>10. Dual-stack Support >> >>There have been several proposals for how to enable an IPv6 >>connection over a network that supports Mobile IPv4. The >>basic idea is to include an IPv6 address in the Mobile IPv4 >>signaling messages. The working group will take on and complete >>one proposal for IPv6 over Mobile IPv4. >> >>Goals and Milestones: >> >>Done AAA Keys for MIPv4 to IESG >>Done MIPv4 VPN interaction problem statement to IESG >>Done Low latency handover to experimental >>Done Experimental MIPv4 message and extensions draft to IESG >>Done Dynamic Home Agent assignment protocol solution to IESG >>Done Revised MIPv4 Challenge/Response (3012bis) to IESG >>Done Regional registration document to IESG >>Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT WG for comment >>Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG >>May 2006 MIPv4 Mobike interaction (BCP) to the IESG >>May 2006 MIPv4 VPN interaction (BCP) to the IESG >>May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment >>Jun 2006 Revised MIPv4 specification to IESG for Draft Std. >>Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG >>Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the IESG >>Sep 2006 FMIPv4 (Experimental) to the IESG >>Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG >>Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG >>Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG >>Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG >> >> > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 13:14:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvQg-00035Z-DN; Thu, 15 Jun 2006 13:14:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvQf-00035U-SS for mip6@ietf.org; Thu, 15 Jun 2006 13:14:49 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqvQf-0005RL-O0 for mip6@ietf.org; Thu, 15 Jun 2006 13:14:49 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqvQd-0002hj-1t for mip6@ietf.org; Thu, 15 Jun 2006 13:14:49 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k5FHEem5027480; Thu, 15 Jun 2006 12:14:40 -0500 (CDT) Received: from [127.0.0.1] by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k5FHEdu08043; Thu, 15 Jun 2006 12:14:39 -0500 (CDT) Message-ID: <44919579.4070107@lucent.com> Date: Thu, 15 Jun 2006 12:14:33 -0500 From: Pete McCann User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) References: <44917382.4060102@kolumbus.fi> <003801c6909d$a7a918a0$026115ac@dcml.docomolabsusa.com> In-Reply-To: <003801c6909d$a7a918a0$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: Jari Arkko , Henrik Levkowetz , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The proposal is to do a MIP4 extension for handling IPv6 addresses. This is distinct from the MIP6 work item which is to extend MIP6 to handle v4 addresses. -Pete James Kempf wrote: > So I'm wondering if there is any work to be done here in addition to the > draft that is currently being worked on in the MIP6 WG? If the only work > involves having someone from the MIP4 WG review the draft, then is there > really need for a new charter item? On the other hand, if there is need > for another document describing the interaction between the MIP6 > transition work and MIP4, then maybe there is need for a new charter > item (but if that is true, I'd say it's a flaw in the MIP6 transition > document, and it should be handled by updating that). > > Also, is there a MDIR concall tomorrow? > > jak > > ----- Original Message ----- From: "Jari Arkko" > To: "Mobile IPv6 Mailing List" > Cc: "Peter McCann" ; "Henrik Levkowetz" > > Sent: Thursday, June 15, 2006 7:49 AM > Subject: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 > (mip4) > > >> >> FYI -- MIP4 wants to recharter to include work on dual stack >> Mobile IPv4 support (item 10 below). Given that MIP6 also >> works on related issues I wanted to point you to this update. >> Comments welcome. >> >> --Jari >> >> IESG Secretary wrote: >> >>> A new charter for the Mobility for IPv4 (mip4) working group in the >>> Internet >>> Area of the IETF is being considered. The draft charter is provided >>> below for >>> your review and comment. >>> >>> Review time is one week. >>> >>> The IETF Secretariat >>> >>> +++ >>> >>> Mobility for IPv4 (mip4) >>> ========================== >>> >>> Last Modified: 2006-06-13 >>> >>> Current Status: Active Working Group >>> >>> Chair(s): >>> Peter McCann >>> Henrik Levkowetz >>> >>> Internet Area Director(s): >>> Jari Arkko >>> Mark Townsley >>> >>> Internet Area Advisor: >>> Jari Arkko >>> >>> Mailing Lists: >>> General Discussion: mip4@ietf.org >>> To Subscribe: mip4-request@ietf.org >>> In Body: subscribe >>> Archive: http://www.ietf.org/mail-archive/web/mip4/index.html >>> >>> Description of Working Group: >>> >>> IP mobility support for IPv4 nodes (hosts and routers) is specified in >>> RFC3344. RFC 3344 mobility allows a node to continue using >>> its "permanent" home address as it moves around the Internet. The >>> Mobile IP protocols support transparency above the IP layer, including >>> maintenance of active TCP connections and UDP port bindings.Besides >>> the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal >>> with concerns such as optimization, security, extensions, AAA support, >>> and deployment issues. >>> >>> MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 >>> networks). The scope of the deployment is on a fairly large scale and >>> accordingly, the MIP4 WG will focus on deployment issues and on >>> addressing known deficiencies and shortcomings in the protocol that >>> have come up as a result of deployment experience. Specifically, the >>> working group will complete the work items to facilitate interactions >>> with AAA environments, interactions with enterprise environments when >>> MIPv4 is used therein, and updating existing protocol specifications >>> in accordance with deployment needs and advancing those protocols that >>> are on the standards track. >>> >>> Work expected to be done by the MIP4 WG as proposed by this charter is >>> as follows: >>> >>> 1. MIPv4 has been a proposed standard for several years. It has been >>> adopted by other standard development organizations and has been >>> deployed commercially. One of the next steps for the WG is to advance >>> the protocol to draft standard status. As part of advancing base >>> Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised >>> to reflect implementation experience >>> >>> 2. Work items that are pending from the previous Mobile IP WG, which >>> will be completed by the MIP4 WG, are: >>> >>> - completion of the MIB for the revised base Mobile IP >>> specification (2006bis) >>> >>> - regional registration draft. >>> >>> 3. The MIP4 WG will also complete the work on MIPv4 interactions >>> in VPN scenarios. This work will involve identifying the requirements >>> and a solution development for MIPv4 operation in the presence >>> of IPsec VPNs. >>> >>> 4. Additionally, a proposal has been made for how MOBIKE could work >>> together with MIPv4. This proposal does not describe any new protocol, >>> but formulates a best current practice for deploying MOBIKE together >>> with MIPv4. The working group will adopt and complete this document. >>> >>> 5. Some issues have been raised with respect to RFC3519. These will be >>> identified and addressed as appropriate, through errata, revision >>> of RFC 3519, and/or supplemental documents as needed. >>> >>> 6. It has been proposed that the FMIP protocol, which has been >>> standardised for MIPv6 in the MIPSHOP working group, should also be >>> published as an experimental protocol for MIPv4. A draft for this >>> exists. The working group will take up and carry this work forward >>> to publication >>> >>> 7. An extension to carry generic strings in the Registration Reply >>> message has been proposed. The purpose is to supply supplemental >>> human-readable information intended to the MN user. The working >>> group will complete the specification and applicability statement of >>> such an extension. >>> >>> 8. RADIUS attributes for MIP4. A set of RADIUS attributes has >>> been proposed for MIPv4. >>> >>> The working group will first produce a requirements specification, >>> describing how the work differs from the requirements in RFC 2977 >>> and the functionality provided by RFC 4004 (the MIPv4 Diameter App). >>> The reason why this first step is required is that RFC 3127 pretty >>> clearly shows that full 2977 functionality can't be provided by even >>> a considerably extended RADIUS, so we need to match the requirements >>> to what can be done within RADIUS. >>> >>> Provided the requirements work finds approval with ADs and radext, >>> the workgroup will complete the specification of MIPv4 RADIUS >>> attributes, solicit feedback from the Radius Extensions WG, adjust, >>> and submit this for publication. >>> >>> 9. MIPv4 Extension for Configuration Options. >>> >>> Several drafts have proposed extensions to help improve configuration >>> of MIPv4 clients. The latest proposal is for a general configuration >>> option extension which could carry information such as e.g., DNS >>> address and DHCP server address. The working group will take on >>> and complete one proposal for a configuration option extension. >>> >>> 10. Dual-stack Support >>> >>> There have been several proposals for how to enable an IPv6 >>> connection over a network that supports Mobile IPv4. The >>> basic idea is to include an IPv6 address in the Mobile IPv4 >>> signaling messages. The working group will take on and complete >>> one proposal for IPv6 over Mobile IPv4. >>> >>> Goals and Milestones: >>> >>> Done AAA Keys for MIPv4 to IESG >>> Done MIPv4 VPN interaction problem statement to IESG >>> Done Low latency handover to experimental >>> Done Experimental MIPv4 message and extensions draft to IESG >>> Done Dynamic Home Agent assignment protocol solution to IESG >>> Done Revised MIPv4 Challenge/Response (3012bis) to IESG >>> Done Regional registration document to IESG >>> Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT WG for comment >>> Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG >>> May 2006 MIPv4 Mobike interaction (BCP) to the IESG >>> May 2006 MIPv4 VPN interaction (BCP) to the IESG >>> May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment >>> Jun 2006 Revised MIPv4 specification to IESG for Draft Std. >>> Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG >>> Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the IESG >>> Sep 2006 FMIPv4 (Experimental) to the IESG >>> Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG >>> Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG >>> Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG >>> Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG >>> >>> >> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 13:20:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvVt-0006eX-OU; Thu, 15 Jun 2006 13:20:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvVs-0006eS-MA for mip6@ietf.org; Thu, 15 Jun 2006 13:20:12 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqvVr-0005wO-W1 for mip6@ietf.org; Thu, 15 Jun 2006 13:20:12 -0400 Message-ID: <008301c690a0$0cdc2940$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Pete McCann" References: <44917382.4060102@kolumbus.fi> <003801c6909d$a7a918a0$026115ac@dcml.docomolabsusa.com> <44919579.4070107@lucent.com> Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) Date: Thu, 15 Jun 2006 10:20:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: Jari Arkko , Henrik Levkowetz , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Is there some reason why that couldn't be included in the transition document? Wouldn't it be more practical from an implementation standpoint to have the transition mechanism documented in one place, so implementors didn't have to go paging through the RFC Web site to track down all the bits and pieces they need to make it work? jak ----- Original Message ----- From: "Pete McCann" To: "James Kempf" Cc: "Jari Arkko" ; "Mobile IPv6 Mailing List" ; "Henrik Levkowetz" Sent: Thursday, June 15, 2006 10:14 AM Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) > The proposal is to do a MIP4 extension for handling IPv6 addresses. > This is distinct from the MIP6 work item which is to extend MIP6 > to handle v4 addresses. > > -Pete > > James Kempf wrote: >> So I'm wondering if there is any work to be done here in addition to the >> draft that is currently being worked on in the MIP6 WG? If the only work >> involves having someone from the MIP4 WG review the draft, then is there >> really need for a new charter item? On the other hand, if there is need >> for another document describing the interaction between the MIP6 >> transition work and MIP4, then maybe there is need for a new charter item >> (but if that is true, I'd say it's a flaw in the MIP6 transition >> document, and it should be handled by updating that). >> >> Also, is there a MDIR concall tomorrow? >> >> jak >> >> ----- Original Message ----- From: "Jari Arkko" >> To: "Mobile IPv6 Mailing List" >> Cc: "Peter McCann" ; "Henrik Levkowetz" >> >> Sent: Thursday, June 15, 2006 7:49 AM >> Subject: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 >> (mip4) >> >> >>> >>> FYI -- MIP4 wants to recharter to include work on dual stack >>> Mobile IPv4 support (item 10 below). Given that MIP6 also >>> works on related issues I wanted to point you to this update. >>> Comments welcome. >>> >>> --Jari >>> >>> IESG Secretary wrote: >>> >>>> A new charter for the Mobility for IPv4 (mip4) working group in the >>>> Internet >>>> Area of the IETF is being considered. The draft charter is provided >>>> below for >>>> your review and comment. >>>> >>>> Review time is one week. >>>> >>>> The IETF Secretariat >>>> >>>> +++ >>>> >>>> Mobility for IPv4 (mip4) >>>> ========================== >>>> >>>> Last Modified: 2006-06-13 >>>> >>>> Current Status: Active Working Group >>>> >>>> Chair(s): >>>> Peter McCann >>>> Henrik Levkowetz >>>> >>>> Internet Area Director(s): >>>> Jari Arkko >>>> Mark Townsley >>>> >>>> Internet Area Advisor: >>>> Jari Arkko >>>> >>>> Mailing Lists: >>>> General Discussion: mip4@ietf.org >>>> To Subscribe: mip4-request@ietf.org >>>> In Body: subscribe >>>> Archive: http://www.ietf.org/mail-archive/web/mip4/index.html >>>> >>>> Description of Working Group: >>>> >>>> IP mobility support for IPv4 nodes (hosts and routers) is specified in >>>> RFC3344. RFC 3344 mobility allows a node to continue using >>>> its "permanent" home address as it moves around the Internet. The >>>> Mobile IP protocols support transparency above the IP layer, including >>>> maintenance of active TCP connections and UDP port bindings.Besides >>>> the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal >>>> with concerns such as optimization, security, extensions, AAA support, >>>> and deployment issues. >>>> >>>> MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 >>>> networks). The scope of the deployment is on a fairly large scale and >>>> accordingly, the MIP4 WG will focus on deployment issues and on >>>> addressing known deficiencies and shortcomings in the protocol that >>>> have come up as a result of deployment experience. Specifically, the >>>> working group will complete the work items to facilitate interactions >>>> with AAA environments, interactions with enterprise environments when >>>> MIPv4 is used therein, and updating existing protocol specifications >>>> in accordance with deployment needs and advancing those protocols that >>>> are on the standards track. >>>> >>>> Work expected to be done by the MIP4 WG as proposed by this charter is >>>> as follows: >>>> >>>> 1. MIPv4 has been a proposed standard for several years. It has been >>>> adopted by other standard development organizations and has been >>>> deployed commercially. One of the next steps for the WG is to advance >>>> the protocol to draft standard status. As part of advancing base >>>> Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised >>>> to reflect implementation experience >>>> >>>> 2. Work items that are pending from the previous Mobile IP WG, which >>>> will be completed by the MIP4 WG, are: >>>> >>>> - completion of the MIB for the revised base Mobile IP >>>> specification (2006bis) >>>> >>>> - regional registration draft. >>>> >>>> 3. The MIP4 WG will also complete the work on MIPv4 interactions >>>> in VPN scenarios. This work will involve identifying the requirements >>>> and a solution development for MIPv4 operation in the presence >>>> of IPsec VPNs. >>>> >>>> 4. Additionally, a proposal has been made for how MOBIKE could work >>>> together with MIPv4. This proposal does not describe any new protocol, >>>> but formulates a best current practice for deploying MOBIKE together >>>> with MIPv4. The working group will adopt and complete this document. >>>> >>>> 5. Some issues have been raised with respect to RFC3519. These will be >>>> identified and addressed as appropriate, through errata, revision >>>> of RFC 3519, and/or supplemental documents as needed. >>>> >>>> 6. It has been proposed that the FMIP protocol, which has been >>>> standardised for MIPv6 in the MIPSHOP working group, should also be >>>> published as an experimental protocol for MIPv4. A draft for this >>>> exists. The working group will take up and carry this work forward >>>> to publication >>>> >>>> 7. An extension to carry generic strings in the Registration Reply >>>> message has been proposed. The purpose is to supply supplemental >>>> human-readable information intended to the MN user. The working >>>> group will complete the specification and applicability statement of >>>> such an extension. >>>> >>>> 8. RADIUS attributes for MIP4. A set of RADIUS attributes has >>>> been proposed for MIPv4. >>>> >>>> The working group will first produce a requirements specification, >>>> describing how the work differs from the requirements in RFC 2977 >>>> and the functionality provided by RFC 4004 (the MIPv4 Diameter App). >>>> The reason why this first step is required is that RFC 3127 pretty >>>> clearly shows that full 2977 functionality can't be provided by even >>>> a considerably extended RADIUS, so we need to match the requirements >>>> to what can be done within RADIUS. >>>> >>>> Provided the requirements work finds approval with ADs and radext, >>>> the workgroup will complete the specification of MIPv4 RADIUS >>>> attributes, solicit feedback from the Radius Extensions WG, adjust, >>>> and submit this for publication. >>>> >>>> 9. MIPv4 Extension for Configuration Options. >>>> >>>> Several drafts have proposed extensions to help improve configuration >>>> of MIPv4 clients. The latest proposal is for a general configuration >>>> option extension which could carry information such as e.g., DNS >>>> address and DHCP server address. The working group will take on >>>> and complete one proposal for a configuration option extension. >>>> >>>> 10. Dual-stack Support >>>> >>>> There have been several proposals for how to enable an IPv6 >>>> connection over a network that supports Mobile IPv4. The >>>> basic idea is to include an IPv6 address in the Mobile IPv4 >>>> signaling messages. The working group will take on and complete >>>> one proposal for IPv6 over Mobile IPv4. >>>> >>>> Goals and Milestones: >>>> >>>> Done AAA Keys for MIPv4 to IESG >>>> Done MIPv4 VPN interaction problem statement to IESG >>>> Done Low latency handover to experimental >>>> Done Experimental MIPv4 message and extensions draft to IESG >>>> Done Dynamic Home Agent assignment protocol solution to IESG >>>> Done Revised MIPv4 Challenge/Response (3012bis) to IESG >>>> Done Regional registration document to IESG >>>> Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT WG for comment >>>> Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG >>>> May 2006 MIPv4 Mobike interaction (BCP) to the IESG >>>> May 2006 MIPv4 VPN interaction (BCP) to the IESG >>>> May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment >>>> Jun 2006 Revised MIPv4 specification to IESG for Draft Std. >>>> Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG >>>> Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the >>>> IESG >>>> Sep 2006 FMIPv4 (Experimental) to the IESG >>>> Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG >>>> Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG >>>> Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG >>>> Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >> >> > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 13:26:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvbZ-0008S5-69; Thu, 15 Jun 2006 13:26:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvbY-0008S0-7l for mip6@ietf.org; Thu, 15 Jun 2006 13:26:04 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqvbX-00069u-OC for mip6@ietf.org; Thu, 15 Jun 2006 13:26:04 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail4.lucent.com (8.13.6/IER-o) with ESMTP id k5FHPv7x004528; Thu, 15 Jun 2006 12:25:57 -0500 (CDT) Received: from [127.0.0.1] by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k5FHPuu26640; Thu, 15 Jun 2006 12:25:56 -0500 (CDT) Message-ID: <4491981D.4080206@lucent.com> Date: Thu, 15 Jun 2006 12:25:49 -0500 From: Pete McCann User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) References: <44917382.4060102@kolumbus.fi> <003801c6909d$a7a918a0$026115ac@dcml.docomolabsusa.com> <44919579.4070107@lucent.com> <008301c690a0$0cdc2940$026115ac@dcml.docomolabsusa.com> In-Reply-To: <008301c690a0$0cdc2940$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: Jari Arkko , Henrik Levkowetz , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org One is a MIP6 extension, the other is a MIP4 extension. It makes sense to me to split this up and do the work on extensions to the protocols in the working group for each protocol. -Pete James Kempf wrote: > Is there some reason why that couldn't be included in the transition > document? Wouldn't it be more practical from an implementation > standpoint to have the transition mechanism documented in one place, so > implementors didn't have to go paging through the RFC Web site to track > down all the bits and pieces they need to make it work? > > jak > > ----- Original Message ----- From: "Pete McCann" > To: "James Kempf" > Cc: "Jari Arkko" ; "Mobile IPv6 Mailing List" > ; "Henrik Levkowetz" > Sent: Thursday, June 15, 2006 10:14 AM > Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for > IPv4 (mip4) > > >> The proposal is to do a MIP4 extension for handling IPv6 addresses. >> This is distinct from the MIP6 work item which is to extend MIP6 >> to handle v4 addresses. >> >> -Pete >> >> James Kempf wrote: >>> So I'm wondering if there is any work to be done here in addition to >>> the draft that is currently being worked on in the MIP6 WG? If the >>> only work involves having someone from the MIP4 WG review the draft, >>> then is there really need for a new charter item? On the other hand, >>> if there is need for another document describing the interaction >>> between the MIP6 transition work and MIP4, then maybe there is need >>> for a new charter item (but if that is true, I'd say it's a flaw in >>> the MIP6 transition document, and it should be handled by updating >>> that). >>> >>> Also, is there a MDIR concall tomorrow? >>> >>> jak >>> >>> ----- Original Message ----- From: "Jari Arkko" >>> To: "Mobile IPv6 Mailing List" >>> Cc: "Peter McCann" ; "Henrik Levkowetz" >>> >>> Sent: Thursday, June 15, 2006 7:49 AM >>> Subject: [Mip6] FW: Internal WG Review: Recharter of Mobility for >>> IPv4 (mip4) >>> >>> >>>> >>>> FYI -- MIP4 wants to recharter to include work on dual stack >>>> Mobile IPv4 support (item 10 below). Given that MIP6 also >>>> works on related issues I wanted to point you to this update. >>>> Comments welcome. >>>> >>>> --Jari >>>> >>>> IESG Secretary wrote: >>>> >>>>> A new charter for the Mobility for IPv4 (mip4) working group in the >>>>> Internet >>>>> Area of the IETF is being considered. The draft charter is >>>>> provided below for >>>>> your review and comment. >>>>> >>>>> Review time is one week. >>>>> >>>>> The IETF Secretariat >>>>> >>>>> +++ >>>>> >>>>> Mobility for IPv4 (mip4) >>>>> ========================== >>>>> >>>>> Last Modified: 2006-06-13 >>>>> >>>>> Current Status: Active Working Group >>>>> >>>>> Chair(s): >>>>> Peter McCann >>>>> Henrik Levkowetz >>>>> >>>>> Internet Area Director(s): >>>>> Jari Arkko >>>>> Mark Townsley >>>>> >>>>> Internet Area Advisor: >>>>> Jari Arkko >>>>> >>>>> Mailing Lists: >>>>> General Discussion: mip4@ietf.org >>>>> To Subscribe: mip4-request@ietf.org >>>>> In Body: subscribe >>>>> Archive: http://www.ietf.org/mail-archive/web/mip4/index.html >>>>> >>>>> Description of Working Group: >>>>> >>>>> IP mobility support for IPv4 nodes (hosts and routers) is specified in >>>>> RFC3344. RFC 3344 mobility allows a node to continue using >>>>> its "permanent" home address as it moves around the Internet. The >>>>> Mobile IP protocols support transparency above the IP layer, including >>>>> maintenance of active TCP connections and UDP port bindings.Besides >>>>> the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal >>>>> with concerns such as optimization, security, extensions, AAA support, >>>>> and deployment issues. >>>>> >>>>> MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 >>>>> networks). The scope of the deployment is on a fairly large scale and >>>>> accordingly, the MIP4 WG will focus on deployment issues and on >>>>> addressing known deficiencies and shortcomings in the protocol that >>>>> have come up as a result of deployment experience. Specifically, the >>>>> working group will complete the work items to facilitate interactions >>>>> with AAA environments, interactions with enterprise environments when >>>>> MIPv4 is used therein, and updating existing protocol specifications >>>>> in accordance with deployment needs and advancing those protocols that >>>>> are on the standards track. >>>>> >>>>> Work expected to be done by the MIP4 WG as proposed by this charter is >>>>> as follows: >>>>> >>>>> 1. MIPv4 has been a proposed standard for several years. It has been >>>>> adopted by other standard development organizations and has been >>>>> deployed commercially. One of the next steps for the WG is to advance >>>>> the protocol to draft standard status. As part of advancing base >>>>> Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised >>>>> to reflect implementation experience >>>>> >>>>> 2. Work items that are pending from the previous Mobile IP WG, which >>>>> will be completed by the MIP4 WG, are: >>>>> >>>>> - completion of the MIB for the revised base Mobile IP >>>>> specification (2006bis) >>>>> >>>>> - regional registration draft. >>>>> >>>>> 3. The MIP4 WG will also complete the work on MIPv4 interactions >>>>> in VPN scenarios. This work will involve identifying the requirements >>>>> and a solution development for MIPv4 operation in the presence >>>>> of IPsec VPNs. >>>>> >>>>> 4. Additionally, a proposal has been made for how MOBIKE could work >>>>> together with MIPv4. This proposal does not describe any new protocol, >>>>> but formulates a best current practice for deploying MOBIKE together >>>>> with MIPv4. The working group will adopt and complete this document. >>>>> >>>>> 5. Some issues have been raised with respect to RFC3519. These will be >>>>> identified and addressed as appropriate, through errata, revision >>>>> of RFC 3519, and/or supplemental documents as needed. >>>>> >>>>> 6. It has been proposed that the FMIP protocol, which has been >>>>> standardised for MIPv6 in the MIPSHOP working group, should also be >>>>> published as an experimental protocol for MIPv4. A draft for this >>>>> exists. The working group will take up and carry this work forward >>>>> to publication >>>>> >>>>> 7. An extension to carry generic strings in the Registration Reply >>>>> message has been proposed. The purpose is to supply supplemental >>>>> human-readable information intended to the MN user. The working >>>>> group will complete the specification and applicability statement of >>>>> such an extension. >>>>> >>>>> 8. RADIUS attributes for MIP4. A set of RADIUS attributes has >>>>> been proposed for MIPv4. >>>>> >>>>> The working group will first produce a requirements specification, >>>>> describing how the work differs from the requirements in RFC 2977 >>>>> and the functionality provided by RFC 4004 (the MIPv4 Diameter App). >>>>> The reason why this first step is required is that RFC 3127 pretty >>>>> clearly shows that full 2977 functionality can't be provided by even >>>>> a considerably extended RADIUS, so we need to match the requirements >>>>> to what can be done within RADIUS. >>>>> >>>>> Provided the requirements work finds approval with ADs and radext, >>>>> the workgroup will complete the specification of MIPv4 RADIUS >>>>> attributes, solicit feedback from the Radius Extensions WG, adjust, >>>>> and submit this for publication. >>>>> >>>>> 9. MIPv4 Extension for Configuration Options. >>>>> >>>>> Several drafts have proposed extensions to help improve configuration >>>>> of MIPv4 clients. The latest proposal is for a general configuration >>>>> option extension which could carry information such as e.g., DNS >>>>> address and DHCP server address. The working group will take on >>>>> and complete one proposal for a configuration option extension. >>>>> >>>>> 10. Dual-stack Support >>>>> >>>>> There have been several proposals for how to enable an IPv6 >>>>> connection over a network that supports Mobile IPv4. The >>>>> basic idea is to include an IPv6 address in the Mobile IPv4 >>>>> signaling messages. The working group will take on and complete >>>>> one proposal for IPv6 over Mobile IPv4. >>>>> >>>>> Goals and Milestones: >>>>> >>>>> Done AAA Keys for MIPv4 to IESG >>>>> Done MIPv4 VPN interaction problem statement to IESG >>>>> Done Low latency handover to experimental >>>>> Done Experimental MIPv4 message and extensions draft to IESG >>>>> Done Dynamic Home Agent assignment protocol solution to IESG >>>>> Done Revised MIPv4 Challenge/Response (3012bis) to IESG >>>>> Done Regional registration document to IESG >>>>> Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT WG for comment >>>>> Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG >>>>> May 2006 MIPv4 Mobike interaction (BCP) to the IESG >>>>> May 2006 MIPv4 VPN interaction (BCP) to the IESG >>>>> May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment >>>>> Jun 2006 Revised MIPv4 specification to IESG for Draft Std. >>>>> Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG >>>>> Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the >>>>> IESG >>>>> Sep 2006 FMIPv4 (Experimental) to the IESG >>>>> Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG >>>>> Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG >>>>> Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG >>>>> Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>> >>> >>> >> > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 13:46:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvvJ-0003BZ-Kv; Thu, 15 Jun 2006 13:46:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvvH-0003BM-Ma for mip6@ietf.org; Thu, 15 Jun 2006 13:46:28 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqvvG-0008Ns-WC for mip6@ietf.org; Thu, 15 Jun 2006 13:46:27 -0400 Message-ID: <00b401c690a3$b975ec60$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Pete McCann" References: <44917382.4060102@kolumbus.fi> <003801c6909d$a7a918a0$026115ac@dcml.docomolabsusa.com> <44919579.4070107@lucent.com> <008301c690a0$0cdc2940$026115ac@dcml.docomolabsusa.com> <4491981D.4080206@lucent.com> Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) Date: Thu, 15 Jun 2006 10:47:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: Jari Arkko , Henrik Levkowetz , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org It certainly makes sense to have the MIP4 WG do a MIP4 extension, my question is still: does it need to be in a separate document? jak PS: I hate to sound overly ideological, but IETF really does need to consider the usability impact of its antiquated documentation technology when making decisions about what material goes into what documents. ----- Original Message ----- From: "Pete McCann" To: "James Kempf" Cc: "Jari Arkko" ; "Mobile IPv6 Mailing List" ; "Henrik Levkowetz" Sent: Thursday, June 15, 2006 10:25 AM Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) > One is a MIP6 extension, the other is a MIP4 extension. It makes > sense to me to split this up and do the work on extensions to the > protocols in the working group for each protocol. > > -Pete > > James Kempf wrote: >> Is there some reason why that couldn't be included in the transition >> document? Wouldn't it be more practical from an implementation standpoint >> to have the transition mechanism documented in one place, so implementors >> didn't have to go paging through the RFC Web site to track down all the >> bits and pieces they need to make it work? >> >> jak >> >> ----- Original Message ----- From: "Pete McCann" >> To: "James Kempf" >> Cc: "Jari Arkko" ; "Mobile IPv6 Mailing List" >> ; "Henrik Levkowetz" >> Sent: Thursday, June 15, 2006 10:14 AM >> Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for >> IPv4 (mip4) >> >> >>> The proposal is to do a MIP4 extension for handling IPv6 addresses. >>> This is distinct from the MIP6 work item which is to extend MIP6 >>> to handle v4 addresses. >>> >>> -Pete >>> >>> James Kempf wrote: >>>> So I'm wondering if there is any work to be done here in addition to >>>> the draft that is currently being worked on in the MIP6 WG? If the only >>>> work involves having someone from the MIP4 WG review the draft, then is >>>> there really need for a new charter item? On the other hand, if there >>>> is need for another document describing the interaction between the >>>> MIP6 transition work and MIP4, then maybe there is need for a new >>>> charter item (but if that is true, I'd say it's a flaw in the MIP6 >>>> transition document, and it should be handled by updating that). >>>> >>>> Also, is there a MDIR concall tomorrow? >>>> >>>> jak >>>> >>>> ----- Original Message ----- From: "Jari Arkko" >>>> >>>> To: "Mobile IPv6 Mailing List" >>>> Cc: "Peter McCann" ; "Henrik Levkowetz" >>>> >>>> Sent: Thursday, June 15, 2006 7:49 AM >>>> Subject: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 >>>> (mip4) >>>> >>>> >>>>> >>>>> FYI -- MIP4 wants to recharter to include work on dual stack >>>>> Mobile IPv4 support (item 10 below). Given that MIP6 also >>>>> works on related issues I wanted to point you to this update. >>>>> Comments welcome. >>>>> >>>>> --Jari >>>>> >>>>> IESG Secretary wrote: >>>>> >>>>>> A new charter for the Mobility for IPv4 (mip4) working group in the >>>>>> Internet >>>>>> Area of the IETF is being considered. The draft charter is provided >>>>>> below for >>>>>> your review and comment. >>>>>> >>>>>> Review time is one week. >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>>> +++ >>>>>> >>>>>> Mobility for IPv4 (mip4) >>>>>> ========================== >>>>>> >>>>>> Last Modified: 2006-06-13 >>>>>> >>>>>> Current Status: Active Working Group >>>>>> >>>>>> Chair(s): >>>>>> Peter McCann >>>>>> Henrik Levkowetz >>>>>> >>>>>> Internet Area Director(s): >>>>>> Jari Arkko >>>>>> Mark Townsley >>>>>> >>>>>> Internet Area Advisor: >>>>>> Jari Arkko >>>>>> >>>>>> Mailing Lists: >>>>>> General Discussion: mip4@ietf.org >>>>>> To Subscribe: mip4-request@ietf.org >>>>>> In Body: subscribe >>>>>> Archive: http://www.ietf.org/mail-archive/web/mip4/index.html >>>>>> >>>>>> Description of Working Group: >>>>>> >>>>>> IP mobility support for IPv4 nodes (hosts and routers) is specified >>>>>> in >>>>>> RFC3344. RFC 3344 mobility allows a node to continue using >>>>>> its "permanent" home address as it moves around the Internet. The >>>>>> Mobile IP protocols support transparency above the IP layer, >>>>>> including >>>>>> maintenance of active TCP connections and UDP port bindings.Besides >>>>>> the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal >>>>>> with concerns such as optimization, security, extensions, AAA >>>>>> support, >>>>>> and deployment issues. >>>>>> >>>>>> MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 >>>>>> networks). The scope of the deployment is on a fairly large scale and >>>>>> accordingly, the MIP4 WG will focus on deployment issues and on >>>>>> addressing known deficiencies and shortcomings in the protocol that >>>>>> have come up as a result of deployment experience. Specifically, the >>>>>> working group will complete the work items to facilitate interactions >>>>>> with AAA environments, interactions with enterprise environments when >>>>>> MIPv4 is used therein, and updating existing protocol specifications >>>>>> in accordance with deployment needs and advancing those protocols >>>>>> that >>>>>> are on the standards track. >>>>>> >>>>>> Work expected to be done by the MIP4 WG as proposed by this charter >>>>>> is >>>>>> as follows: >>>>>> >>>>>> 1. MIPv4 has been a proposed standard for several years. It has been >>>>>> adopted by other standard development organizations and has been >>>>>> deployed commercially. One of the next steps for the WG is to advance >>>>>> the protocol to draft standard status. As part of advancing base >>>>>> Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised >>>>>> to reflect implementation experience >>>>>> >>>>>> 2. Work items that are pending from the previous Mobile IP WG, which >>>>>> will be completed by the MIP4 WG, are: >>>>>> >>>>>> - completion of the MIB for the revised base Mobile IP >>>>>> specification (2006bis) >>>>>> >>>>>> - regional registration draft. >>>>>> >>>>>> 3. The MIP4 WG will also complete the work on MIPv4 interactions >>>>>> in VPN scenarios. This work will involve identifying the requirements >>>>>> and a solution development for MIPv4 operation in the presence >>>>>> of IPsec VPNs. >>>>>> >>>>>> 4. Additionally, a proposal has been made for how MOBIKE could work >>>>>> together with MIPv4. This proposal does not describe any new >>>>>> protocol, >>>>>> but formulates a best current practice for deploying MOBIKE together >>>>>> with MIPv4. The working group will adopt and complete this document. >>>>>> >>>>>> 5. Some issues have been raised with respect to RFC3519. These will >>>>>> be >>>>>> identified and addressed as appropriate, through errata, revision >>>>>> of RFC 3519, and/or supplemental documents as needed. >>>>>> >>>>>> 6. It has been proposed that the FMIP protocol, which has been >>>>>> standardised for MIPv6 in the MIPSHOP working group, should also be >>>>>> published as an experimental protocol for MIPv4. A draft for this >>>>>> exists. The working group will take up and carry this work forward >>>>>> to publication >>>>>> >>>>>> 7. An extension to carry generic strings in the Registration Reply >>>>>> message has been proposed. The purpose is to supply supplemental >>>>>> human-readable information intended to the MN user. The working >>>>>> group will complete the specification and applicability statement of >>>>>> such an extension. >>>>>> >>>>>> 8. RADIUS attributes for MIP4. A set of RADIUS attributes has >>>>>> been proposed for MIPv4. >>>>>> >>>>>> The working group will first produce a requirements specification, >>>>>> describing how the work differs from the requirements in RFC 2977 >>>>>> and the functionality provided by RFC 4004 (the MIPv4 Diameter App). >>>>>> The reason why this first step is required is that RFC 3127 pretty >>>>>> clearly shows that full 2977 functionality can't be provided by even >>>>>> a considerably extended RADIUS, so we need to match the requirements >>>>>> to what can be done within RADIUS. >>>>>> >>>>>> Provided the requirements work finds approval with ADs and radext, >>>>>> the workgroup will complete the specification of MIPv4 RADIUS >>>>>> attributes, solicit feedback from the Radius Extensions WG, adjust, >>>>>> and submit this for publication. >>>>>> >>>>>> 9. MIPv4 Extension for Configuration Options. >>>>>> >>>>>> Several drafts have proposed extensions to help improve configuration >>>>>> of MIPv4 clients. The latest proposal is for a general configuration >>>>>> option extension which could carry information such as e.g., DNS >>>>>> address and DHCP server address. The working group will take on >>>>>> and complete one proposal for a configuration option extension. >>>>>> >>>>>> 10. Dual-stack Support >>>>>> >>>>>> There have been several proposals for how to enable an IPv6 >>>>>> connection over a network that supports Mobile IPv4. The >>>>>> basic idea is to include an IPv6 address in the Mobile IPv4 >>>>>> signaling messages. The working group will take on and complete >>>>>> one proposal for IPv6 over Mobile IPv4. >>>>>> >>>>>> Goals and Milestones: >>>>>> >>>>>> Done AAA Keys for MIPv4 to IESG >>>>>> Done MIPv4 VPN interaction problem statement to IESG >>>>>> Done Low latency handover to experimental >>>>>> Done Experimental MIPv4 message and extensions draft to IESG >>>>>> Done Dynamic Home Agent assignment protocol solution to IESG >>>>>> Done Revised MIPv4 Challenge/Response (3012bis) to IESG >>>>>> Done Regional registration document to IESG >>>>>> Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT WG for >>>>>> comment >>>>>> Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG >>>>>> May 2006 MIPv4 Mobike interaction (BCP) to the IESG >>>>>> May 2006 MIPv4 VPN interaction (BCP) to the IESG >>>>>> May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment >>>>>> Jun 2006 Revised MIPv4 specification to IESG for Draft Std. >>>>>> Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG >>>>>> Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the >>>>>> IESG >>>>>> Sep 2006 FMIPv4 (Experimental) to the IESG >>>>>> Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG >>>>>> Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG >>>>>> Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG >>>>>> Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mip6 mailing list >>>>> Mip6@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>>> >>>> >>>> >>> >> >> > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 14:18:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqwPy-0002LW-TF; Thu, 15 Jun 2006 14:18:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqwPw-0002JF-SO for mip6@ietf.org; Thu, 15 Jun 2006 14:18:08 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqwPw-0002st-7S for mip6@ietf.org; Thu, 15 Jun 2006 14:18:08 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 11:18:04 -0700 Message-ID: <4491A458.6010104@azairenet.com> Date: Thu, 15 Jun 2006 11:18:00 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) References: <44917382.4060102@kolumbus.fi> In-Reply-To: <44917382.4060102@kolumbus.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2006 18:18:05.0020 (UTC) FILETIME=[0B9A39C0:01C690A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: Mobile IPv6 Mailing List , Peter McCann , Henrik Levkowetz X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Jari Arkko wrote: > FYI -- MIP4 wants to recharter to include work on dual stack > Mobile IPv4 support (item 10 below). Given that MIP6 also > works on related issues I wanted to point you to this update. > Comments welcome. I am opposed to this. I had expressed concerns on the MIP4 mailing list and there was a long discussion after that. here is the link to that thread. http://www1.ietf.org/mail-archive/web/mip4/current/msg01763.html IMHO, it will be good to get more opinions (non-MIPv4 folks especially) on this. Vijay > > --Jari > > IESG Secretary wrote: > >> A new charter for the Mobility for IPv4 (mip4) working group in the Internet >> Area of the IETF is being considered. The draft charter is provided below for >> your review and comment. >> >> Review time is one week. >> >> The IETF Secretariat >> >> +++ >> >> Mobility for IPv4 (mip4) >> ========================== >> >> Last Modified: 2006-06-13 >> >> Current Status: Active Working Group >> >> Chair(s): >> Peter McCann >> Henrik Levkowetz >> >> Internet Area Director(s): >> Jari Arkko >> Mark Townsley >> >> Internet Area Advisor: >> Jari Arkko >> >> Mailing Lists: >> General Discussion: mip4@ietf.org >> To Subscribe: mip4-request@ietf.org >> In Body: subscribe >> Archive: http://www.ietf.org/mail-archive/web/mip4/index.html >> >> Description of Working Group: >> >> IP mobility support for IPv4 nodes (hosts and routers) is specified in >> RFC3344. RFC 3344 mobility allows a node to continue using >> its "permanent" home address as it moves around the Internet. The >> Mobile IP protocols support transparency above the IP layer, including >> maintenance of active TCP connections and UDP port bindings.Besides >> the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal >> with concerns such as optimization, security, extensions, AAA support, >> and deployment issues. >> >> MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 >> networks). The scope of the deployment is on a fairly large scale and >> accordingly, the MIP4 WG will focus on deployment issues and on >> addressing known deficiencies and shortcomings in the protocol that >> have come up as a result of deployment experience. Specifically, the >> working group will complete the work items to facilitate interactions >> with AAA environments, interactions with enterprise environments when >> MIPv4 is used therein, and updating existing protocol specifications >> in accordance with deployment needs and advancing those protocols that >> are on the standards track. >> >> Work expected to be done by the MIP4 WG as proposed by this charter is >> as follows: >> >> 1. MIPv4 has been a proposed standard for several years. It has been >> adopted by other standard development organizations and has been >> deployed commercially. One of the next steps for the WG is to advance >> the protocol to draft standard status. As part of advancing base >> Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised >> to reflect implementation experience >> >> 2. Work items that are pending from the previous Mobile IP WG, which >> will be completed by the MIP4 WG, are: >> >> - completion of the MIB for the revised base Mobile IP >> specification (2006bis) >> >> - regional registration draft. >> >> 3. The MIP4 WG will also complete the work on MIPv4 interactions >> in VPN scenarios. This work will involve identifying the requirements >> and a solution development for MIPv4 operation in the presence >> of IPsec VPNs. >> >> 4. Additionally, a proposal has been made for how MOBIKE could work >> together with MIPv4. This proposal does not describe any new protocol, >> but formulates a best current practice for deploying MOBIKE together >> with MIPv4. The working group will adopt and complete this document. >> >> 5. Some issues have been raised with respect to RFC3519. These will be >> identified and addressed as appropriate, through errata, revision >> of RFC 3519, and/or supplemental documents as needed. >> >> 6. It has been proposed that the FMIP protocol, which has been >> standardised for MIPv6 in the MIPSHOP working group, should also be >> published as an experimental protocol for MIPv4. A draft for this >> exists. The working group will take up and carry this work forward >> to publication >> >> 7. An extension to carry generic strings in the Registration Reply >> message has been proposed. The purpose is to supply supplemental >> human-readable information intended to the MN user. The working >> group will complete the specification and applicability statement of >> such an extension. >> >> 8. RADIUS attributes for MIP4. A set of RADIUS attributes has >> been proposed for MIPv4. >> >> The working group will first produce a requirements specification, >> describing how the work differs from the requirements in RFC 2977 >> and the functionality provided by RFC 4004 (the MIPv4 Diameter App). >> The reason why this first step is required is that RFC 3127 pretty >> clearly shows that full 2977 functionality can't be provided by even >> a considerably extended RADIUS, so we need to match the requirements >> to what can be done within RADIUS. >> >> Provided the requirements work finds approval with ADs and radext, >> the workgroup will complete the specification of MIPv4 RADIUS >> attributes, solicit feedback from the Radius Extensions WG, adjust, >> and submit this for publication. >> >> 9. MIPv4 Extension for Configuration Options. >> >> Several drafts have proposed extensions to help improve configuration >> of MIPv4 clients. The latest proposal is for a general configuration >> option extension which could carry information such as e.g., DNS >> address and DHCP server address. The working group will take on >> and complete one proposal for a configuration option extension. >> >> 10. Dual-stack Support >> >> There have been several proposals for how to enable an IPv6 >> connection over a network that supports Mobile IPv4. The >> basic idea is to include an IPv6 address in the Mobile IPv4 >> signaling messages. The working group will take on and complete >> one proposal for IPv6 over Mobile IPv4. >> >> Goals and Milestones: >> >> Done AAA Keys for MIPv4 to IESG >> Done MIPv4 VPN interaction problem statement to IESG >> Done Low latency handover to experimental >> Done Experimental MIPv4 message and extensions draft to IESG >> Done Dynamic Home Agent assignment protocol solution to IESG >> Done Revised MIPv4 Challenge/Response (3012bis) to IESG >> Done Regional registration document to IESG >> Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT WG for comment >> Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG >> May 2006 MIPv4 Mobike interaction (BCP) to the IESG >> May 2006 MIPv4 VPN interaction (BCP) to the IESG >> May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment >> Jun 2006 Revised MIPv4 specification to IESG for Draft Std. >> Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG >> Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the IESG >> Sep 2006 FMIPv4 (Experimental) to the IESG >> Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG >> Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG >> Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG >> Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG >> >> > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 14:31:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqwco-0000q1-Uc; Thu, 15 Jun 2006 14:31:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqwcn-0000pw-6J for mip6@ietf.org; Thu, 15 Jun 2006 14:31:25 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqwcm-00044y-MB for mip6@ietf.org; Thu, 15 Jun 2006 14:31:25 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5FIVM3j012704; Thu, 15 Jun 2006 11:31:22 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k5FIVLQL008474; Thu, 15 Jun 2006 13:31:21 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id B9FAF865980; Thu, 15 Jun 2006 20:31:20 +0200 (CEST) Message-ID: <4491A778.6010202@motorola.com> Date: Thu, 15 Jun 2006 20:31:20 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) References: <44917382.4060102@kolumbus.fi> <003801c6909d$a7a918a0$026115ac@dcml.docomolabsusa.com> <44919579.4070107@lucent.com> <008301c690a0$0cdc2940$026115ac@dcml.docomolabsusa.com> <4491981D.4080206@lucent.com> <00b401c690a3$b975ec60$026115ac@dcml.docomolabsusa.com> In-Reply-To: <00b401c690a3$b975ec60$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: Jari Arkko , Pete McCann , Henrik Levkowetz , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James Kempf wrote: > It certainly makes sense to have the MIP4 WG do a MIP4 extension, my > question is still: does it need to be in a separate document? In what would a common document be different than just using MIP6 3775 and MIP4 3344? If v4 access then use MIP6 over the MIP4 MN-HA tunnel. If v6 access then use MIP4 over the MIP6 MN-HA tunnel. IMHO the current DS-MIPv6 proposal already does much more than needed (tries to offer IPv4 continuous sessions, when it should try to only offer IPv6 continuous sessions) and unnecessarily puts a stringent requirement on HA (run both IPv4 and IPv6). So I'd rather favour splitting the DS-MIPv6 document, _and_ have a separate DS-MIPv4 document. Sounds as much work, I agree, but simpler problems may be easier to address. Alex > > jak > > PS: I hate to sound overly ideological, but IETF really does need to > consider the usability impact of its antiquated documentation > technology when making decisions about what material goes into what > documents. > > ----- Original Message ----- From: "Pete McCann" > To: "James Kempf" Cc: "Jari Arkko" > ; "Mobile IPv6 Mailing List" ; > "Henrik Levkowetz" Sent: Thursday, June 15, > 2006 10:25 AM Subject: Re: [Mip6] FW: Internal WG Review: Recharter > of Mobility for IPv4 (mip4) > > >> One is a MIP6 extension, the other is a MIP4 extension. It makes >> sense to me to split this up and do the work on extensions to the >> protocols in the working group for each protocol. >> >> -Pete >> >> James Kempf wrote: >>> Is there some reason why that couldn't be included in the >>> transition document? Wouldn't it be more practical from an >>> implementation standpoint to have the transition mechanism >>> documented in one place, so implementors didn't have to go paging >>> through the RFC Web site to track down all the bits and pieces >>> they need to make it work? >>> >>> jak >>> >>> ----- Original Message ----- From: "Pete McCann" >>> To: "James Kempf" >>> Cc: "Jari Arkko" ; "Mobile IPv6 Mailing >>> List" ; "Henrik Levkowetz" >>> Sent: Thursday, June 15, 2006 10:14 AM Subject: Re: [Mip6] FW: >>> Internal WG Review: Recharter of Mobility for IPv4 (mip4) >>> >>> >>>> The proposal is to do a MIP4 extension for handling IPv6 >>>> addresses. This is distinct from the MIP6 work item which is to >>>> extend MIP6 to handle v4 addresses. >>>> >>>> -Pete >>>> >>>> James Kempf wrote: >>>>> So I'm wondering if there is any work to be done here in >>>>> addition to the draft that is currently being worked on in >>>>> the MIP6 WG? If the only work involves having someone from >>>>> the MIP4 WG review the draft, then is there really need for a >>>>> new charter item? On the other hand, if there is need for >>>>> another document describing the interaction between the MIP6 >>>>> transition work and MIP4, then maybe there is need for a new >>>>> charter item (but if that is true, I'd say it's a flaw in >>>>> the MIP6 transition document, and it should be handled by >>>>> updating that). >>>>> >>>>> Also, is there a MDIR concall tomorrow? >>>>> >>>>> jak >>>>> >>>>> ----- Original Message ----- From: "Jari Arkko" >>>>> To: "Mobile IPv6 Mailing List" >>>>> Cc: "Peter McCann" ; >>>>> "Henrik Levkowetz" Sent: Thursday, >>>>> June 15, 2006 7:49 AM Subject: [Mip6] FW: Internal WG Review: >>>>> Recharter of Mobility for IPv4 (mip4) >>>>> >>>>> >>>>>> >>>>>> FYI -- MIP4 wants to recharter to include work on dual >>>>>> stack Mobile IPv4 support (item 10 below). Given that MIP6 >>>>>> also works on related issues I wanted to point you to this >>>>>> update. Comments welcome. >>>>>> >>>>>> --Jari >>>>>> >>>>>> IESG Secretary wrote: >>>>>> >>>>>>> A new charter for the Mobility for IPv4 (mip4) working >>>>>>> group in the Internet Area of the IETF is being >>>>>>> considered. The draft charter is provided below for your >>>>>>> review and comment. >>>>>>> >>>>>>> Review time is one week. >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> >>>>>>> +++ >>>>>>> >>>>>>> Mobility for IPv4 (mip4) ========================== >>>>>>> >>>>>>> Last Modified: 2006-06-13 >>>>>>> >>>>>>> Current Status: Active Working Group >>>>>>> >>>>>>> Chair(s): Peter McCann Henrik >>>>>>> Levkowetz >>>>>>> >>>>>>> Internet Area Director(s): Jari Arkko >>>>>>> Mark Townsley >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Internet Area Advisor: Jari Arkko >>>>>>> >>>>>>> Mailing Lists: General Discussion: mip4@ietf.org To >>>>>>> Subscribe: mip4-request@ietf.org In Body: subscribe >>>>>>> Archive: >>>>>>> http://www.ietf.org/mail-archive/web/mip4/index.html >>>>>>> >>>>>>> Description of Working Group: >>>>>>> >>>>>>> IP mobility support for IPv4 nodes (hosts and routers) is >>>>>>> specified in RFC3344. RFC 3344 mobility allows a node to >>>>>>> continue using its "permanent" home address as it moves >>>>>>> around the Internet. The Mobile IP protocols support >>>>>>> transparency above the IP layer, including maintenance of >>>>>>> active TCP connections and UDP port bindings.Besides the >>>>>>> basic Mobile IPv4 (MIPv4) protocols, several other >>>>>>> drafts deal with concerns such as optimization, security, >>>>>>> extensions, AAA support, and deployment issues. >>>>>>> >>>>>>> MIPv4 is currently being deployed on a wide basis (e.g., >>>>>>> in cdma2000 networks). The scope of the deployment is on >>>>>>> a fairly large scale and accordingly, the MIP4 WG will >>>>>>> focus on deployment issues and on addressing known >>>>>>> deficiencies and shortcomings in the protocol that have >>>>>>> come up as a result of deployment experience. >>>>>>> Specifically, the working group will complete the work >>>>>>> items to facilitate interactions with AAA environments, >>>>>>> interactions with enterprise environments when MIPv4 is >>>>>>> used therein, and updating existing protocol >>>>>>> specifications in accordance with deployment needs and >>>>>>> advancing those protocols that are on the standards >>>>>>> track. >>>>>>> >>>>>>> Work expected to be done by the MIP4 WG as proposed by >>>>>>> this charter is as follows: >>>>>>> >>>>>>> 1. MIPv4 has been a proposed standard for several years. >>>>>>> It has been adopted by other standard development >>>>>>> organizations and has been deployed commercially. One of >>>>>>> the next steps for the WG is to advance the protocol to >>>>>>> draft standard status. As part of advancing base Mobile >>>>>>> IP specs to DS, the MIPv4 NAI RFC (2794) will be revised >>>>>>> to reflect implementation experience >>>>>>> >>>>>>> 2. Work items that are pending from the previous Mobile >>>>>>> IP WG, which will be completed by the MIP4 WG, are: >>>>>>> >>>>>>> - completion of the MIB for the revised base Mobile IP >>>>>>> specification (2006bis) >>>>>>> >>>>>>> - regional registration draft. >>>>>>> >>>>>>> 3. The MIP4 WG will also complete the work on MIPv4 >>>>>>> interactions in VPN scenarios. This work will involve >>>>>>> identifying the requirements and a solution development >>>>>>> for MIPv4 operation in the presence of IPsec VPNs. >>>>>>> >>>>>>> 4. Additionally, a proposal has been made for how MOBIKE >>>>>>> could work together with MIPv4. This proposal does not >>>>>>> describe any new protocol, but formulates a best current >>>>>>> practice for deploying MOBIKE together with MIPv4. The >>>>>>> working group will adopt and complete this document. >>>>>>> >>>>>>> 5. Some issues have been raised with respect to RFC3519. >>>>>>> These will be identified and addressed as appropriate, >>>>>>> through errata, revision of RFC 3519, and/or supplemental >>>>>>> documents as needed. >>>>>>> >>>>>>> 6. It has been proposed that the FMIP protocol, which has >>>>>>> been standardised for MIPv6 in the MIPSHOP working >>>>>>> group, should also be published as an experimental >>>>>>> protocol for MIPv4. A draft for this exists. The working >>>>>>> group will take up and carry this work forward to >>>>>>> publication >>>>>>> >>>>>>> 7. An extension to carry generic strings in the >>>>>>> Registration Reply message has been proposed. The purpose >>>>>>> is to supply supplemental human-readable information >>>>>>> intended to the MN user. The working group will complete >>>>>>> the specification and applicability statement of such an >>>>>>> extension. >>>>>>> >>>>>>> 8. RADIUS attributes for MIP4. A set of RADIUS attributes >>>>>>> has been proposed for MIPv4. >>>>>>> >>>>>>> The working group will first produce a requirements >>>>>>> specification, describing how the work differs from the >>>>>>> requirements in RFC 2977 and the functionality provided >>>>>>> by RFC 4004 (the MIPv4 Diameter App). The reason why this >>>>>>> first step is required is that RFC 3127 pretty clearly >>>>>>> shows that full 2977 functionality can't be provided by >>>>>>> even a considerably extended RADIUS, so we need to match >>>>>>> the requirements to what can be done within RADIUS. >>>>>>> >>>>>>> Provided the requirements work finds approval with ADs >>>>>>> and radext, the workgroup will complete the specification >>>>>>> of MIPv4 RADIUS attributes, solicit feedback from the >>>>>>> Radius Extensions WG, adjust, and submit this for >>>>>>> publication. >>>>>>> >>>>>>> 9. MIPv4 Extension for Configuration Options. >>>>>>> >>>>>>> Several drafts have proposed extensions to help improve >>>>>>> configuration of MIPv4 clients. The latest proposal is >>>>>>> for a general configuration option extension which could >>>>>>> carry information such as e.g., DNS address and DHCP >>>>>>> server address. The working group will take on and >>>>>>> complete one proposal for a configuration option >>>>>>> extension. >>>>>>> >>>>>>> 10. Dual-stack Support >>>>>>> >>>>>>> There have been several proposals for how to enable an >>>>>>> IPv6 connection over a network that supports Mobile IPv4. >>>>>>> The basic idea is to include an IPv6 address in the >>>>>>> Mobile IPv4 signaling messages. The working group will >>>>>>> take on and complete one proposal for IPv6 over Mobile >>>>>>> IPv4. >>>>>>> >>>>>>> Goals and Milestones: >>>>>>> >>>>>>> Done AAA Keys for MIPv4 to IESG Done MIPv4 VPN >>>>>>> interaction problem statement to IESG Done Low latency >>>>>>> handover to experimental Done Experimental MIPv4 message >>>>>>> and extensions draft to IESG Done Dynamic Home Agent >>>>>>> assignment protocol solution to IESG Done Revised MIPv4 >>>>>>> Challenge/Response (3012bis) to IESG Done Regional >>>>>>> registration document to IESG Mar 2006 MIPv4 RADIUS >>>>>>> Extensions Requirements to RADEXT WG for comment Apr 2006 >>>>>>> Revised rfc2794bis (NAI extension) (Draft Std.) to the >>>>>>> IESG May 2006 MIPv4 Mobike interaction (BCP) to the IESG >>>>>>> May 2006 MIPv4 VPN interaction (BCP) to the IESG May 2006 >>>>>>> RADIUS Extensions for MIPv4 to the RADEXT WG for comment >>>>>>> Jun 2006 Revised MIPv4 specification to IESG for Draft >>>>>>> Std. Jun 2006 Generic Strings for MIPv4 (Proposed Std.) >>>>>>> to the IESG Aug 2006 MIPv4 Extension for Config. Options >>>>>>> (Proposed Std.) to the IESG Sep 2006 FMIPv4 >>>>>>> (Experimental) to the IESG Sep 2006 MIPv4 RADIUS >>>>>>> Extensions Requirements to the IESG Sep 2006 RADIUS >>>>>>> Extensions for MIPv4 (Proposed Std.) to the IESG Dec 2006 >>>>>>> Revised MIB for MIPv4 (Proposed Std.) to IESG Dec 2006 >>>>>>> Dual-stack MIPv4 (Proposed Std.) to IESG >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ Mip6 >>>>>> mailing list Mip6@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > > > _______________________________________________ Mip6 mailing list > Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 14:46:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqwrE-0008IW-Ij; Thu, 15 Jun 2006 14:46:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqwrD-0008Er-CD for mip6@ietf.org; Thu, 15 Jun 2006 14:46:19 -0400 Received: from av7-2-sn3.vrr.skanova.net ([81.228.9.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqwrC-0005nC-LU for mip6@ietf.org; Thu, 15 Jun 2006 14:46:19 -0400 Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id C23B437FF5; Thu, 15 Jun 2006 20:20:07 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id A1B2337F98; Thu, 15 Jun 2006 20:20:07 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id DF8D137E45; Thu, 15 Jun 2006 20:46:16 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1Fqwr9-0003xj-MG; Thu, 15 Jun 2006 20:46:15 +0200 Message-ID: <4491AAF7.5000803@levkowetz.com> Date: Thu, 15 Jun 2006 20:46:15 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) References: <44917382.4060102@kolumbus.fi> <003801c6909d$a7a918a0$026115ac@dcml.docomolabsusa.com> In-Reply-To: <003801c6909d$a7a918a0$026115ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: Jari Arkko , Peter McCann , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1699356298==" Errors-To: mip6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1699356298== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig118BD9814AE23EF3D8BE02AE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig118BD9814AE23EF3D8BE02AE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi James, on 2006-06-15 19:03 James Kempf said the following: > So I'm wondering if there is any work to be done here in addition to th= e=20 > draft that is currently being worked on in the MIP6 WG? If the only wor= k=20 > involves having someone from the MIP4 WG review the draft, then is ther= e=20 > really need for a new charter item? On the other hand, if there is need= for=20 > another document describing the interaction between the MIP6 transition= work=20 > and MIP4, then maybe there is need for a new charter item (but if that = is=20 > true, I'd say it's a flaw in the MIP6 transition document, and it shoul= d be=20 > handled by updating that). This work item covers the ability of MIPv4 to carry IPv6 packets, and doe= s not overlap with the MIP6 work of giving MIPv6 the ability to carry IPv4 packets and run over IPv4 access networks. Regards, Henrik > jak >=20 > ----- Original Message -----=20 > From: "Jari Arkko" > To: "Mobile IPv6 Mailing List" > Cc: "Peter McCann" ; "Henrik Levkowetz"=20 > > Sent: Thursday, June 15, 2006 7:49 AM > Subject: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 = > (mip4) >=20 >=20 >> >> FYI -- MIP4 wants to recharter to include work on dual stack >> Mobile IPv4 support (item 10 below). Given that MIP6 also >> works on related issues I wanted to point you to this update. >> Comments welcome. >> >> --Jari >> >> IESG Secretary wrote: >> >>>A new charter for the Mobility for IPv4 (mip4) working group in the=20 >>>Internet >>>Area of the IETF is being considered. The draft charter is provided b= elow=20 >>>for >>>your review and comment. >>> >>>Review time is one week. >>> >>>The IETF Secretariat >>> >>>+++ >>> >>>Mobility for IPv4 (mip4) >>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >>> >>>Last Modified: 2006-06-13 >>> >>>Current Status: Active Working Group >>> >>>Chair(s): >>>Peter McCann >>>Henrik Levkowetz >>> >>>Internet Area Director(s): >>>Jari Arkko >>>Mark Townsley >>> >>>Internet Area Advisor: >>>Jari Arkko >>> >>>Mailing Lists: >>>General Discussion: mip4@ietf.org >>>To Subscribe: mip4-request@ietf.org >>>In Body: subscribe >>>Archive: http://www.ietf.org/mail-archive/web/mip4/index.html >>> >>>Description of Working Group: >>> >>>IP mobility support for IPv4 nodes (hosts and routers) is specified in= >>>RFC3344. RFC 3344 mobility allows a node to continue using >>>its "permanent" home address as it moves around the Internet. The >>>Mobile IP protocols support transparency above the IP layer, including= >>>maintenance of active TCP connections and UDP port bindings.Besides >>>the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal >>>with concerns such as optimization, security, extensions, AAA support,= >>>and deployment issues. >>> >>>MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 >>>networks). The scope of the deployment is on a fairly large scale and >>>accordingly, the MIP4 WG will focus on deployment issues and on >>>addressing known deficiencies and shortcomings in the protocol that >>>have come up as a result of deployment experience. Specifically, the >>>working group will complete the work items to facilitate interactions >>>with AAA environments, interactions with enterprise environments when >>>MIPv4 is used therein, and updating existing protocol specifications >>>in accordance with deployment needs and advancing those protocols that= >>>are on the standards track. >>> >>>Work expected to be done by the MIP4 WG as proposed by this charter is= >>>as follows: >>> >>>1. MIPv4 has been a proposed standard for several years. It has been >>>adopted by other standard development organizations and has been >>>deployed commercially. One of the next steps for the WG is to advance >>>the protocol to draft standard status. As part of advancing base >>>Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised >>>to reflect implementation experience >>> >>>2. Work items that are pending from the previous Mobile IP WG, which >>>will be completed by the MIP4 WG, are: >>> >>>- completion of the MIB for the revised base Mobile IP >>>specification (2006bis) >>> >>>- regional registration draft. >>> >>>3. The MIP4 WG will also complete the work on MIPv4 interactions >>>in VPN scenarios. This work will involve identifying the requirements >>>and a solution development for MIPv4 operation in the presence >>>of IPsec VPNs. >>> >>>4. Additionally, a proposal has been made for how MOBIKE could work >>>together with MIPv4. This proposal does not describe any new protocol,= >>>but formulates a best current practice for deploying MOBIKE together >>>with MIPv4. The working group will adopt and complete this document. >>> >>>5. Some issues have been raised with respect to RFC3519. These will be= >>>identified and addressed as appropriate, through errata, revision >>>of RFC 3519, and/or supplemental documents as needed. >>> >>>6. It has been proposed that the FMIP protocol, which has been >>>standardised for MIPv6 in the MIPSHOP working group, should also be >>>published as an experimental protocol for MIPv4. A draft for this >>>exists. The working group will take up and carry this work forward >>>to publication >>> >>>7. An extension to carry generic strings in the Registration Reply >>>message has been proposed. The purpose is to supply supplemental >>>human-readable information intended to the MN user. The working >>>group will complete the specification and applicability statement of >>>such an extension. >>> >>>8. RADIUS attributes for MIP4. A set of RADIUS attributes has >>>been proposed for MIPv4. >>> >>>The working group will first produce a requirements specification, >>>describing how the work differs from the requirements in RFC 2977 >>>and the functionality provided by RFC 4004 (the MIPv4 Diameter App). >>>The reason why this first step is required is that RFC 3127 pretty >>>clearly shows that full 2977 functionality can't be provided by even >>>a considerably extended RADIUS, so we need to match the requirements >>>to what can be done within RADIUS. >>> >>>Provided the requirements work finds approval with ADs and radext, >>>the workgroup will complete the specification of MIPv4 RADIUS >>>attributes, solicit feedback from the Radius Extensions WG, adjust, >>>and submit this for publication. >>> >>>9. MIPv4 Extension for Configuration Options. >>> >>>Several drafts have proposed extensions to help improve configuration >>>of MIPv4 clients. The latest proposal is for a general configuration >>>option extension which could carry information such as e.g., DNS >>>address and DHCP server address. The working group will take on >>>and complete one proposal for a configuration option extension. >>> >>>10. Dual-stack Support >>> >>>There have been several proposals for how to enable an IPv6 >>>connection over a network that supports Mobile IPv4. The >>>basic idea is to include an IPv6 address in the Mobile IPv4 >>>signaling messages. The working group will take on and complete >>>one proposal for IPv6 over Mobile IPv4. >>> >>>Goals and Milestones: >>> >>>Done AAA Keys for MIPv4 to IESG >>>Done MIPv4 VPN interaction problem statement to IESG >>>Done Low latency handover to experimental >>>Done Experimental MIPv4 message and extensions draft to IESG >>>Done Dynamic Home Agent assignment protocol solution to IESG >>>Done Revised MIPv4 Challenge/Response (3012bis) to IESG >>>Done Regional registration document to IESG >>>Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT WG for comment= >>>Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG >>>May 2006 MIPv4 Mobike interaction (BCP) to the IESG >>>May 2006 MIPv4 VPN interaction (BCP) to the IESG >>>May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment >>>Jun 2006 Revised MIPv4 specification to IESG for Draft Std. >>>Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG >>>Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the IE= SG >>>Sep 2006 FMIPv4 (Experimental) to the IESG >>>Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG >>>Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG >>>Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG >>>Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG >>> >>> >> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >>=20 >=20 >=20 >=20 --------------enig118BD9814AE23EF3D8BE02AE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEkar3eVhrtTJkXCMRArUCAKCbVEV/UWS6Arn55kbDV4XdIkDcxACgvN/L iZ/v3x2ZjzpkzB7JlmgpaM4= =BVkI -----END PGP SIGNATURE----- --------------enig118BD9814AE23EF3D8BE02AE-- --===============1699356298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1699356298==-- From mip6-bounces@ietf.org Thu Jun 15 14:49:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqwub-0001m4-1t; Thu, 15 Jun 2006 14:49:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqwuZ-0001lm-J1 for mip6@ietf.org; Thu, 15 Jun 2006 14:49:47 -0400 Received: from av10-1-sn2.hy.skanova.net ([81.228.8.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqwuY-0005sP-Lr for mip6@ietf.org; Thu, 15 Jun 2006 14:49:47 -0400 Received: by av10-1-sn2.hy.skanova.net (Postfix, from userid 502) id CD79437E80; Thu, 15 Jun 2006 20:49:45 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-1-sn2.hy.skanova.net (Postfix) with ESMTP id A9CE437E54; Thu, 15 Jun 2006 20:49:45 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 1CCA237E53; Thu, 15 Jun 2006 20:49:44 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FqwuT-00042V-1P; Thu, 15 Jun 2006 20:49:44 +0200 Message-ID: <4491ABC4.1050705@levkowetz.com> Date: Thu, 15 Jun 2006 20:49:40 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) References: <44917382.4060102@kolumbus.fi> <003801c6909d$a7a918a0$026115ac@dcml.docomolabsusa.com> <44919579.4070107@lucent.com> <008301c690a0$0cdc2940$026115ac@dcml.docomolabsusa.com> In-Reply-To: <008301c690a0$0cdc2940$026115ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: Jari Arkko , Pete McCann , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1501602027==" Errors-To: mip6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1501602027== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig57509DC8A31058F84A22770E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig57509DC8A31058F84A22770E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi James, on 2006-06-15 19:20 James Kempf said the following: > Is there some reason why that couldn't be included in the transition=20 > document? Wouldn't it be more practical from an implementation standpoi= nt to=20 > have the transition mechanism documented in one place, so implementors = > didn't have to go paging through the RFC Web site to track down all the= bits=20 > and pieces they need to make it work? Since this work is only relevant for MNs and mobility agents that are running MIPv4, I think it makes a fair amount of sense to place it in a document which simply describes it as an MIPv4 option - which is what it is... Henrik > jak >=20 > ----- Original Message -----=20 > From: "Pete McCann" > To: "James Kempf" > Cc: "Jari Arkko" ; "Mobile IPv6 Mailing List"=20 > ; "Henrik Levkowetz" > Sent: Thursday, June 15, 2006 10:14 AM > Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for I= Pv4=20 > (mip4) >=20 >=20 >> The proposal is to do a MIP4 extension for handling IPv6 addresses. >> This is distinct from the MIP6 work item which is to extend MIP6 >> to handle v4 addresses. >> >> -Pete >> >> James Kempf wrote: >>> So I'm wondering if there is any work to be done here in addition to = the=20 >>> draft that is currently being worked on in the MIP6 WG? If the only w= ork=20 >>> involves having someone from the MIP4 WG review the draft, then is th= ere=20 >>> really need for a new charter item? On the other hand, if there is ne= ed=20 >>> for another document describing the interaction between the MIP6=20 >>> transition work and MIP4, then maybe there is need for a new charter = item=20 >>> (but if that is true, I'd say it's a flaw in the MIP6 transition=20 >>> document, and it should be handled by updating that). >>> >>> Also, is there a MDIR concall tomorrow? >>> >>> jak >>> >>> ----- Original Message ----- From: "Jari Arkko" >>> To: "Mobile IPv6 Mailing List" >>> Cc: "Peter McCann" ; "Henrik Levkowetz"=20 >>> >>> Sent: Thursday, June 15, 2006 7:49 AM >>> Subject: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv= 4=20 >>> (mip4) >>> >>> >>>> >>>> FYI -- MIP4 wants to recharter to include work on dual stack >>>> Mobile IPv4 support (item 10 below). Given that MIP6 also >>>> works on related issues I wanted to point you to this update. >>>> Comments welcome. >>>> >>>> --Jari >>>> >>>> IESG Secretary wrote: >>>> >>>>> A new charter for the Mobility for IPv4 (mip4) working group in the= =20 >>>>> Internet >>>>> Area of the IETF is being considered. The draft charter is provide= d=20 >>>>> below for >>>>> your review and comment. >>>>> >>>>> Review time is one week. >>>>> >>>>> The IETF Secretariat >>>>> >>>>> +++ >>>>> >>>>> Mobility for IPv4 (mip4) >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>> >>>>> Last Modified: 2006-06-13 >>>>> >>>>> Current Status: Active Working Group >>>>> >>>>> Chair(s): >>>>> Peter McCann >>>>> Henrik Levkowetz >>>>> >>>>> Internet Area Director(s): >>>>> Jari Arkko >>>>> Mark Townsley >>>>> >>>>> Internet Area Advisor: >>>>> Jari Arkko >>>>> >>>>> Mailing Lists: >>>>> General Discussion: mip4@ietf.org >>>>> To Subscribe: mip4-request@ietf.org >>>>> In Body: subscribe >>>>> Archive: http://www.ietf.org/mail-archive/web/mip4/index.html >>>>> >>>>> Description of Working Group: >>>>> >>>>> IP mobility support for IPv4 nodes (hosts and routers) is specified= in >>>>> RFC3344. RFC 3344 mobility allows a node to continue using >>>>> its "permanent" home address as it moves around the Internet. The >>>>> Mobile IP protocols support transparency above the IP layer, includ= ing >>>>> maintenance of active TCP connections and UDP port bindings.Besides= >>>>> the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal >>>>> with concerns such as optimization, security, extensions, AAA suppo= rt, >>>>> and deployment issues. >>>>> >>>>> MIPv4 is currently being deployed on a wide basis (e.g., in cdma200= 0 >>>>> networks). The scope of the deployment is on a fairly large scale a= nd >>>>> accordingly, the MIP4 WG will focus on deployment issues and on >>>>> addressing known deficiencies and shortcomings in the protocol that= >>>>> have come up as a result of deployment experience. Specifically, th= e >>>>> working group will complete the work items to facilitate interactio= ns >>>>> with AAA environments, interactions with enterprise environments wh= en >>>>> MIPv4 is used therein, and updating existing protocol specification= s >>>>> in accordance with deployment needs and advancing those protocols t= hat >>>>> are on the standards track. >>>>> >>>>> Work expected to be done by the MIP4 WG as proposed by this charter= is >>>>> as follows: >>>>> >>>>> 1. MIPv4 has been a proposed standard for several years. It has bee= n >>>>> adopted by other standard development organizations and has been >>>>> deployed commercially. One of the next steps for the WG is to advan= ce >>>>> the protocol to draft standard status. As part of advancing base >>>>> Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised >>>>> to reflect implementation experience >>>>> >>>>> 2. Work items that are pending from the previous Mobile IP WG, whic= h >>>>> will be completed by the MIP4 WG, are: >>>>> >>>>> - completion of the MIB for the revised base Mobile IP >>>>> specification (2006bis) >>>>> >>>>> - regional registration draft. >>>>> >>>>> 3. The MIP4 WG will also complete the work on MIPv4 interactions >>>>> in VPN scenarios. This work will involve identifying the requiremen= ts >>>>> and a solution development for MIPv4 operation in the presence >>>>> of IPsec VPNs. >>>>> >>>>> 4. Additionally, a proposal has been made for how MOBIKE could work= >>>>> together with MIPv4. This proposal does not describe any new protoc= ol, >>>>> but formulates a best current practice for deploying MOBIKE togethe= r >>>>> with MIPv4. The working group will adopt and complete this document= =2E >>>>> >>>>> 5. Some issues have been raised with respect to RFC3519. These will= be >>>>> identified and addressed as appropriate, through errata, revision >>>>> of RFC 3519, and/or supplemental documents as needed. >>>>> >>>>> 6. It has been proposed that the FMIP protocol, which has been >>>>> standardised for MIPv6 in the MIPSHOP working group, should also be= >>>>> published as an experimental protocol for MIPv4. A draft for this >>>>> exists. The working group will take up and carry this work forward >>>>> to publication >>>>> >>>>> 7. An extension to carry generic strings in the Registration Reply >>>>> message has been proposed. The purpose is to supply supplemental >>>>> human-readable information intended to the MN user. The working >>>>> group will complete the specification and applicability statement o= f >>>>> such an extension. >>>>> >>>>> 8. RADIUS attributes for MIP4. A set of RADIUS attributes has >>>>> been proposed for MIPv4. >>>>> >>>>> The working group will first produce a requirements specification, >>>>> describing how the work differs from the requirements in RFC 2977 >>>>> and the functionality provided by RFC 4004 (the MIPv4 Diameter App)= =2E >>>>> The reason why this first step is required is that RFC 3127 pretty >>>>> clearly shows that full 2977 functionality can't be provided by eve= n >>>>> a considerably extended RADIUS, so we need to match the requirement= s >>>>> to what can be done within RADIUS. >>>>> >>>>> Provided the requirements work finds approval with ADs and radext, >>>>> the workgroup will complete the specification of MIPv4 RADIUS >>>>> attributes, solicit feedback from the Radius Extensions WG, adjust,= >>>>> and submit this for publication. >>>>> >>>>> 9. MIPv4 Extension for Configuration Options. >>>>> >>>>> Several drafts have proposed extensions to help improve configurati= on >>>>> of MIPv4 clients. The latest proposal is for a general configuratio= n >>>>> option extension which could carry information such as e.g., DNS >>>>> address and DHCP server address. The working group will take on >>>>> and complete one proposal for a configuration option extension. >>>>> >>>>> 10. Dual-stack Support >>>>> >>>>> There have been several proposals for how to enable an IPv6 >>>>> connection over a network that supports Mobile IPv4. The >>>>> basic idea is to include an IPv6 address in the Mobile IPv4 >>>>> signaling messages. The working group will take on and complete >>>>> one proposal for IPv6 over Mobile IPv4. >>>>> >>>>> Goals and Milestones: >>>>> >>>>> Done AAA Keys for MIPv4 to IESG >>>>> Done MIPv4 VPN interaction problem statement to IESG >>>>> Done Low latency handover to experimental >>>>> Done Experimental MIPv4 message and extensions draft to IESG >>>>> Done Dynamic Home Agent assignment protocol solution to IESG >>>>> Done Revised MIPv4 Challenge/Response (3012bis) to IESG >>>>> Done Regional registration document to IESG >>>>> Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT WG for comm= ent >>>>> Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IES= G >>>>> May 2006 MIPv4 Mobike interaction (BCP) to the IESG >>>>> May 2006 MIPv4 VPN interaction (BCP) to the IESG >>>>> May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment >>>>> Jun 2006 Revised MIPv4 specification to IESG for Draft Std. >>>>> Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG >>>>> Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the= =20 >>>>> IESG >>>>> Sep 2006 FMIPv4 (Experimental) to the IESG >>>>> Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG >>>>> Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG >>>>> Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG >>>>> Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>> >>> >>> >>=20 >=20 >=20 >=20 --------------enig57509DC8A31058F84A22770E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEkavFeVhrtTJkXCMRAn3CAKDkYs5r9VobEVa+n79HoDpZEzFrdQCg+aVa vqR1jlkvft75ouWo7kBJuwY= =Xo9l -----END PGP SIGNATURE----- --------------enig57509DC8A31058F84A22770E-- --===============1501602027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1501602027==-- From mip6-bounces@ietf.org Thu Jun 15 15:03:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqx7v-0007IR-2B; Thu, 15 Jun 2006 15:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqx7t-0007IG-Nj for mip6@ietf.org; Thu, 15 Jun 2006 15:03:33 -0400 Received: from av12-1-sn2.hy.skanova.net ([81.228.8.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqx7s-00073e-QP for mip6@ietf.org; Thu, 15 Jun 2006 15:03:33 -0400 Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id 1C3ED37F4D; Thu, 15 Jun 2006 21:03:32 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id 0BC8937E80; Thu, 15 Jun 2006 21:03:32 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 8D8F837E4A; Thu, 15 Jun 2006 21:03:31 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1Fqx7q-0004uO-SX; Thu, 15 Jun 2006 21:03:30 +0200 Message-ID: <4491AF02.4070000@levkowetz.com> Date: Thu, 15 Jun 2006 21:03:30 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) References: <44917382.4060102@kolumbus.fi> <003801c6909d$a7a918a0$026115ac@dcml.docomolabsusa.com> <44919579.4070107@lucent.com> <008301c690a0$0cdc2940$026115ac@dcml.docomolabsusa.com> <4491981D.4080206@lucent.com> <00b401c690a3$b975ec60$026115ac@dcml.docomolabsusa.com> In-Reply-To: <00b401c690a3$b975ec60$026115ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Cc: Jari Arkko , Pete McCann , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0922629436==" Errors-To: mip6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0922629436== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig55D1114A658E898D1D215A68" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig55D1114A658E898D1D215A68 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi James, > PS: I hate to sound overly ideological, but IETF really does need to=20 > consider the usability impact of its antiquated documentation technolog= y=20 > when making decisions about what material goes into what documents. More and more people these days are browsing documents under http://tools.ietf.org/html/ and thereby gets HTML links between documents - take for instance the MIPv6 or MIPv4 specifications, and follow links to your heart's desire: http://tools.ietf.org/html/rfc3775 http://tools.ietf.org/html/rfc3344 or go to the htmlized version of the RFC index and click on: http://tools.ietf.org/rfc/index (I've had a factor of 10 increase of traffic to the tools.ietf.org servers over the last ~ 9 months...) This works best if people use references like this: "RFC 3344 [1]", which lets you go directly to the RFC, but also with just numbered or symbolic references without the RFC spelled out it lets you click to the referenced document via the reference section. Since I'm convinced that this can be further improved, and will be increasingly well used, I think it would be very wrong to group things that aren't particularly closely related into one mega-document when they would be better described, and more easily worked at, as separate documents. Regards, Henrik > ----- Original Message -----=20 > From: "Pete McCann" > To: "James Kempf" > Cc: "Jari Arkko" ; "Mobile IPv6 Mailing List"=20 > ; "Henrik Levkowetz" > Sent: Thursday, June 15, 2006 10:25 AM > Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for I= Pv4=20 > (mip4) >=20 >=20 >> One is a MIP6 extension, the other is a MIP4 extension. It makes >> sense to me to split this up and do the work on extensions to the >> protocols in the working group for each protocol. >> >> -Pete >> >> James Kempf wrote: >>> Is there some reason why that couldn't be included in the transition = >>> document? Wouldn't it be more practical from an implementation standp= oint=20 >>> to have the transition mechanism documented in one place, so implemen= tors=20 >>> didn't have to go paging through the RFC Web site to track down all t= he=20 >>> bits and pieces they need to make it work? >>> >>> jak >>> >>> ----- Original Message ----- From: "Pete McCann" >>> To: "James Kempf" >>> Cc: "Jari Arkko" ; "Mobile IPv6 Mailing List"= =20 >>> ; "Henrik Levkowetz" >>> Sent: Thursday, June 15, 2006 10:14 AM >>> Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for= =20 >>> IPv4 (mip4) >>> >>> >>>> The proposal is to do a MIP4 extension for handling IPv6 addresses. >>>> This is distinct from the MIP6 work item which is to extend MIP6 >>>> to handle v4 addresses. >>>> >>>> -Pete >>>> >>>> James Kempf wrote: >>>>> So I'm wondering if there is any work to be done here in addition t= o=20 >>>>> the draft that is currently being worked on in the MIP6 WG? If the = only=20 >>>>> work involves having someone from the MIP4 WG review the draft, the= n is=20 >>>>> there really need for a new charter item? On the other hand, if the= re=20 >>>>> is need for another document describing the interaction between the= =20 >>>>> MIP6 transition work and MIP4, then maybe there is need for a new=20 >>>>> charter item (but if that is true, I'd say it's a flaw in the MIP6 = >>>>> transition document, and it should be handled by updating that). >>>>> >>>>> Also, is there a MDIR concall tomorrow? >>>>> >>>>> jak >>>>> >>>>> ----- Original Message ----- From: "Jari Arkko"=20 >>>>> >>>>> To: "Mobile IPv6 Mailing List" >>>>> Cc: "Peter McCann" ; "Henrik Levkowetz"=20 >>>>> >>>>> Sent: Thursday, June 15, 2006 7:49 AM >>>>> Subject: [Mip6] FW: Internal WG Review: Recharter of Mobility for I= Pv4=20 >>>>> (mip4) >>>>> >>>>> >>>>>> >>>>>> FYI -- MIP4 wants to recharter to include work on dual stack >>>>>> Mobile IPv4 support (item 10 below). Given that MIP6 also >>>>>> works on related issues I wanted to point you to this update. >>>>>> Comments welcome. >>>>>> >>>>>> --Jari >>>>>> >>>>>> IESG Secretary wrote: >>>>>> >>>>>>> A new charter for the Mobility for IPv4 (mip4) working group in t= he=20 >>>>>>> Internet >>>>>>> Area of the IETF is being considered. The draft charter is provi= ded=20 >>>>>>> below for >>>>>>> your review and comment. >>>>>>> >>>>>>> Review time is one week. >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> >>>>>>> +++ >>>>>>> >>>>>>> Mobility for IPv4 (mip4) >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>>>>> >>>>>>> Last Modified: 2006-06-13 >>>>>>> >>>>>>> Current Status: Active Working Group >>>>>>> >>>>>>> Chair(s): >>>>>>> Peter McCann >>>>>>> Henrik Levkowetz >>>>>>> >>>>>>> Internet Area Director(s): >>>>>>> Jari Arkko >>>>>>> Mark Townsley >>>>>>> >>>>>>> Internet Area Advisor: >>>>>>> Jari Arkko >>>>>>> >>>>>>> Mailing Lists: >>>>>>> General Discussion: mip4@ietf.org >>>>>>> To Subscribe: mip4-request@ietf.org >>>>>>> In Body: subscribe >>>>>>> Archive: http://www.ietf.org/mail-archive/web/mip4/index.html >>>>>>> >>>>>>> Description of Working Group: >>>>>>> >>>>>>> IP mobility support for IPv4 nodes (hosts and routers) is specifi= ed=20 >>>>>>> in >>>>>>> RFC3344. RFC 3344 mobility allows a node to continue using >>>>>>> its "permanent" home address as it moves around the Internet. The= >>>>>>> Mobile IP protocols support transparency above the IP layer,=20 >>>>>>> including >>>>>>> maintenance of active TCP connections and UDP port bindings.Besid= es >>>>>>> the basic Mobile IPv4 (MIPv4) protocols, several other drafts dea= l >>>>>>> with concerns such as optimization, security, extensions, AAA=20 >>>>>>> support, >>>>>>> and deployment issues. >>>>>>> >>>>>>> MIPv4 is currently being deployed on a wide basis (e.g., in cdma2= 000 >>>>>>> networks). The scope of the deployment is on a fairly large scale= and >>>>>>> accordingly, the MIP4 WG will focus on deployment issues and on >>>>>>> addressing known deficiencies and shortcomings in the protocol th= at >>>>>>> have come up as a result of deployment experience. Specifically, = the >>>>>>> working group will complete the work items to facilitate interact= ions >>>>>>> with AAA environments, interactions with enterprise environments = when >>>>>>> MIPv4 is used therein, and updating existing protocol specificati= ons >>>>>>> in accordance with deployment needs and advancing those protocols= =20 >>>>>>> that >>>>>>> are on the standards track. >>>>>>> >>>>>>> Work expected to be done by the MIP4 WG as proposed by this chart= er=20 >>>>>>> is >>>>>>> as follows: >>>>>>> >>>>>>> 1. MIPv4 has been a proposed standard for several years. It has b= een >>>>>>> adopted by other standard development organizations and has been >>>>>>> deployed commercially. One of the next steps for the WG is to adv= ance >>>>>>> the protocol to draft standard status. As part of advancing base >>>>>>> Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised >>>>>>> to reflect implementation experience >>>>>>> >>>>>>> 2. Work items that are pending from the previous Mobile IP WG, wh= ich >>>>>>> will be completed by the MIP4 WG, are: >>>>>>> >>>>>>> - completion of the MIB for the revised base Mobile IP >>>>>>> specification (2006bis) >>>>>>> >>>>>>> - regional registration draft. >>>>>>> >>>>>>> 3. The MIP4 WG will also complete the work on MIPv4 interactions >>>>>>> in VPN scenarios. This work will involve identifying the requirem= ents >>>>>>> and a solution development for MIPv4 operation in the presence >>>>>>> of IPsec VPNs. >>>>>>> >>>>>>> 4. Additionally, a proposal has been made for how MOBIKE could wo= rk >>>>>>> together with MIPv4. This proposal does not describe any new=20 >>>>>>> protocol, >>>>>>> but formulates a best current practice for deploying MOBIKE toget= her >>>>>>> with MIPv4. The working group will adopt and complete this docume= nt. >>>>>>> >>>>>>> 5. Some issues have been raised with respect to RFC3519. These wi= ll=20 >>>>>>> be >>>>>>> identified and addressed as appropriate, through errata, revision= >>>>>>> of RFC 3519, and/or supplemental documents as needed. >>>>>>> >>>>>>> 6. It has been proposed that the FMIP protocol, which has been >>>>>>> standardised for MIPv6 in the MIPSHOP working group, should also = be >>>>>>> published as an experimental protocol for MIPv4. A draft for this= >>>>>>> exists. The working group will take up and carry this work forwar= d >>>>>>> to publication >>>>>>> >>>>>>> 7. An extension to carry generic strings in the Registration Repl= y >>>>>>> message has been proposed. The purpose is to supply supplemental >>>>>>> human-readable information intended to the MN user. The working >>>>>>> group will complete the specification and applicability statement= of >>>>>>> such an extension. >>>>>>> >>>>>>> 8. RADIUS attributes for MIP4. A set of RADIUS attributes has >>>>>>> been proposed for MIPv4. >>>>>>> >>>>>>> The working group will first produce a requirements specification= , >>>>>>> describing how the work differs from the requirements in RFC 2977= >>>>>>> and the functionality provided by RFC 4004 (the MIPv4 Diameter Ap= p). >>>>>>> The reason why this first step is required is that RFC 3127 prett= y >>>>>>> clearly shows that full 2977 functionality can't be provided by e= ven >>>>>>> a considerably extended RADIUS, so we need to match the requireme= nts >>>>>>> to what can be done within RADIUS. >>>>>>> >>>>>>> Provided the requirements work finds approval with ADs and radext= , >>>>>>> the workgroup will complete the specification of MIPv4 RADIUS >>>>>>> attributes, solicit feedback from the Radius Extensions WG, adjus= t, >>>>>>> and submit this for publication. >>>>>>> >>>>>>> 9. MIPv4 Extension for Configuration Options. >>>>>>> >>>>>>> Several drafts have proposed extensions to help improve configura= tion >>>>>>> of MIPv4 clients. The latest proposal is for a general configurat= ion >>>>>>> option extension which could carry information such as e.g., DNS >>>>>>> address and DHCP server address. The working group will take on >>>>>>> and complete one proposal for a configuration option extension. >>>>>>> >>>>>>> 10. Dual-stack Support >>>>>>> >>>>>>> There have been several proposals for how to enable an IPv6 >>>>>>> connection over a network that supports Mobile IPv4. The >>>>>>> basic idea is to include an IPv6 address in the Mobile IPv4 >>>>>>> signaling messages. The working group will take on and complete >>>>>>> one proposal for IPv6 over Mobile IPv4. >>>>>>> >>>>>>> Goals and Milestones: >>>>>>> >>>>>>> Done AAA Keys for MIPv4 to IESG >>>>>>> Done MIPv4 VPN interaction problem statement to IESG >>>>>>> Done Low latency handover to experimental >>>>>>> Done Experimental MIPv4 message and extensions draft to IESG >>>>>>> Done Dynamic Home Agent assignment protocol solution to IESG >>>>>>> Done Revised MIPv4 Challenge/Response (3012bis) to IESG >>>>>>> Done Regional registration document to IESG >>>>>>> Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT WG for=20 >>>>>>> comment >>>>>>> Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the I= ESG >>>>>>> May 2006 MIPv4 Mobike interaction (BCP) to the IESG >>>>>>> May 2006 MIPv4 VPN interaction (BCP) to the IESG >>>>>>> May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment= >>>>>>> Jun 2006 Revised MIPv4 specification to IESG for Draft Std. >>>>>>> Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG >>>>>>> Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to t= he=20 >>>>>>> IESG >>>>>>> Sep 2006 FMIPv4 (Experimental) to the IESG >>>>>>> Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG >>>>>>> Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG >>>>>>> Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG >>>>>>> Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mip6 mailing list >>>>>> Mip6@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>>>> >>>>> >>>>> >>>> >>> >>> >>=20 >=20 >=20 >=20 --------------enig55D1114A658E898D1D215A68 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEka8CeVhrtTJkXCMRAscpAKDSFeyE3qGZ44+fe5TEPE1HDjoC+ACfWSAj zpaw6w6z+6ftZL7CSIQdUUI= =J5xV -----END PGP SIGNATURE----- --------------enig55D1114A658E898D1D215A68-- --===============0922629436== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0922629436==-- From mip6-bounces@ietf.org Thu Jun 15 15:35:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqxca-0007Zv-0i; Thu, 15 Jun 2006 15:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxcY-0007Yz-KE; Thu, 15 Jun 2006 15:35:14 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqxcY-0001uU-0u; Thu, 15 Jun 2006 15:35:14 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5FJZArZ019203; Thu, 15 Jun 2006 22:35:10 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 22:34:33 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 14:34:16 -0500 Received: from 172.19.244.70 ([172.19.244.70]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Jun 2006 19:34:16 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 15 Jun 2006 14:34:19 -0500 From: Basavaraj Patil To: , ext Jari Arkko Message-ID: Thread-Topic: Request to process WG I-D: draft-ietf-mip6-cn-ipsec-02.txt on standards track Thread-Index: AcaQsrHo8LaVEvylEdqHQQARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Jun 2006 19:34:16.0953 (UTC) FILETIME=[B0AFD690:01C690B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: Gopal Dommety , mip6@ietf.org, jeanmichel.combes@francetelecom.com, Francis.Dupont@point6.net Subject: [Mip6] Request to process WG I-D: draft-ietf-mip6-cn-ipsec-02.txt on standards track X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello Jari, The MIP6 WG I-D: draft-ietf-mip6-cn-ipsec-02.txt, "Using IPsec between Mobile and Correspondent IPv6 Nodes" has completed WG last call in March, 06. The I-D is now ready for IESG review and to be progressed as a standards track document. -Raj ============================================ 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication? Yes. 2) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Sufficient. 3) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No concerns about the need for broader or additional reviews. 4) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway. None. 5) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Consensus about an alternative mechanism to Return routability for securing the route optimization messages exists. 6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. No. 7) Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). Yes. 8) Does the document a) split references into normative/informative, and b) are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (Note: the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) Yes. 9) For Standards Track and BCP documents, the IESG approval announcement includes a writeup section with the following sections: - Technical Summary The I-D defines how IPsec can be used for securing the MIP6 (RFC3775) route optimization messages between an MN and CN. Return routability testing (RRT) is the default method for MIP6 to enable route optimization. This I-D proposes a mechanism that can be used when an IPsec SA between the MN and CN exists instead of RRT. - Working Group Summary The I-D has been presented to the WG and discussed in WG meetings in 2005. While there is not an overwhelming need for such a solution, it does provide an alternative especially when there exists an IPsec SA between the MN and CN. - Protocol Quality The I-D only defines how IPsec can be used for securing the RO messages and no new protocol is defined. - is the protocol already being implemented? No. - have a significant number of vendors indicated they plan to implement the spec? No. - are there any reviewers (during the end stages) that merit explicit mention as having done a thorough review that resulted in important changes or a conclusion that the document was fine (except for maybe some nits?) No. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 15:36:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqxdy-0000Jk-L7; Thu, 15 Jun 2006 15:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqxdx-0000Jb-Eh for mip6@ietf.org; Thu, 15 Jun 2006 15:36:41 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqxdw-0001wl-6n for mip6@ietf.org; Thu, 15 Jun 2006 15:36:41 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5FJaTZl024178; Thu, 15 Jun 2006 12:36:29 -0700 (MST) Received: from [10.169.4.53] (mvp-10-169-4-53.corp.mot.com [10.169.4.53]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k5FJaRoG008346; Thu, 15 Jun 2006 14:36:28 -0500 (CDT) Message-ID: <4491B6BA.5080104@motorola.com> Date: Thu, 15 Jun 2006 21:36:26 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) References: <44917382.4060102@kolumbus.fi> <003801c6909d$a7a918a0$026115ac@dcml.docomolabsusa.com> <4491AAF7.5000803@levkowetz.com> In-Reply-To: <4491AAF7.5000803@levkowetz.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Jari Arkko , Peter McCann , James Kempf , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Henrik Levkowetz wrote: > Hi James, > > on 2006-06-15 19:03 James Kempf said the following: >> So I'm wondering if there is any work to be done here in addition >> to the draft that is currently being worked on in the MIP6 WG? If >> the only work involves having someone from the MIP4 WG review the >> draft, then is there really need for a new charter item? On the >> other hand, if there is need for another document describing the >> interaction between the MIP6 transition work and MIP4, then maybe >> there is need for a new charter item (but if that is true, I'd say >> it's a flaw in the MIP6 transition document, and it should be >> handled by updating that). > > This work item covers the ability of MIPv4 to carry IPv6 packets, and > does not overlap with the MIP6 work of giving MIPv6 the ability to > carry IPv4 packets and run over IPv4 access networks. Right it doesn't overlap with the MIP6 _particular_ work of giving MIPv6 the ability to carry IPv4 packets and run over IPv4 access networks, which is not all DS-MIPv6. But DS-MIPv4 seems to overlap with the DS-MIPv6 characteristic whereby DS-MIPv6 does proxy ARP for a permanent IPv4 home address and whereby DS-MIPv6 offers reachability at a permanent IPv4 home address. If DS-MIPv6 only cared about IPv6 permanent home addresses (not IPv4) then there would be more place for DS-MIPv4. For v4-v6 transition one would have two possibilities: either use DS-MIPv6 (if the original stack is MIP6) or use DS-MIPv4 (if the original stack is MIP4). As two separate specs (DS-MIP4, DS-MIP6) I don't see anything wrong with that. A common spec (containing both DS-MIPv4 and DS-MIPv6 concepts) would have to remove some text from the current DS-MIPv6 text. And it risks becoming a bigger spec than MIP4+MIP6 combined, I'm afraid. On the topic of tools.ietf.org, I'm a fan of many of the new tools and thanks for them. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 15:44:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqxla-000407-LL; Thu, 15 Jun 2006 15:44:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxlZ-000402-90 for mip6@ietf.org; Thu, 15 Jun 2006 15:44:33 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqxlX-0002fQ-T5 for mip6@ietf.org; Thu, 15 Jun 2006 15:44:33 -0400 Message-ID: <00d901c690b4$391f1850$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Henrik Levkowetz" References: <44917382.4060102@kolumbus.fi> <003801c6909d$a7a918a0$026115ac@dcml.docomolabsusa.com> <44919579.4070107@lucent.com> <008301c690a0$0cdc2940$026115ac@dcml.docomolabsusa.com> <4491981D.4080206@lucent.com> <00b401c690a3$b975ec60$026115ac@dcml.docomolabsusa.com> <4491AF02.4070000@levkowetz.com> Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) Date: Thu, 15 Jun 2006 12:45:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Jari Arkko , Pete McCann , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org >Since I'm convinced that this can be further improved, and will >be increasingly well used, I think it would be very wrong to >group things that aren't particularly closely related into one >mega-document when they would be better described, and more easily >worked at, as separate documents. If two things aren't part of the same set of mechanisms an implementor would need in order to implement a protocol or system, then of course they shouldn't be in the same document. But in the past, there has been a tendency to want to break protocol definitions apart, for better modularity. For example, breaking out route optimization from the MIP6 document which is currently in the charter (so this discussion is not completely irrelevant to the list, which is why I'm posting it here too). While I am in principle in favor of this, without some kind of hypertext linking, this imposes a higher cognitive burden on the implementor. They may not even know where all the pieces are. I'm certainly glad to see the tools.ietf.org hypertext linking being used, but I don't think it is really a solution until it becomes the default way that RFCs are available online, that is, it is linked from the official IETF RFC Web page. It also is lacking an important aspect of modern documentation technology - the ability to do high quality graphics. As protocols become more complex, graphical representations become more important for complete understanding. ASCII art just doesn't cut it anymore, despite emacs macros and all the other tools people have proposed. Neither does being able to post an alternative postscript version. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 15:47:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxoJ-0005HP-T5; Thu, 15 Jun 2006 15:47:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxoJ-0005HK-2u for mip6@ietf.org; Thu, 15 Jun 2006 15:47:23 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqxoI-0002wx-FA for mip6@ietf.org; Thu, 15 Jun 2006 15:47:23 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5FJlLch005070; Thu, 15 Jun 2006 22:47:21 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 22:47:19 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 14:47:17 -0500 Received: from 172.19.244.70 ([172.19.244.70]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Jun 2006 19:47:16 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 15 Jun 2006 14:47:19 -0500 Subject: Re: [Mip6] FW: Request to progress MIP6 WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt From: Basavaraj Patil To: "ext Soliman, Hesham" , Message-ID: Thread-Topic: [Mip6] FW: Request to progress MIP6 WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcaP+ch+Bv3nbPvtEdqcIgARJNUNiAAACDLpAAJ9LnAALCk1pg== In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04F60C@NAEX14.na.qualcomm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Jun 2006 19:47:17.0240 (UTC) FILETIME=[81C62F80:01C690B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: jari.arkko@piuha.net X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Based on the discussion about whether to include tunnel mode specification by a small handful of people, the final conclusion was to include text that specifies how to send BU messages in tunnel mode. -Raj On 6/14/06 5:43 PM, "ext Soliman, Hesham" wrote: > Hi Raj, authors, > > How was the issue I raised about the tunnel mode resolved in the draft? > A quick glance tells me nothing changed. > > Hesham > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] >> Sent: Wednesday, June 14, 2006 5:32 PM >> To: mip6@ietf.org >> Subject: [Mip6] FW: Request to progress MIP6 WG I-D: >> draft-ietf-mip6-ikev2-ipsec-06.txt >> >> >> FYI, >> >> ------ Forwarded Message >>> From: Basavaraj Patil >>> Date: Wed, 14 Jun 2006 16:30:40 -0500 >>> To: ext Jari Arkko , >> >>> Cc: "W. Mark Townsley" , Gopal Dommety >>> , ext Vijay Devarapalli >> , >>> >>> Conversation: Request to progress MIP6 WG I-D: >>> draft-ietf-mip6-ikev2-ipsec-06.txt >>> Subject: Request to progress MIP6 WG I-D: >> draft-ietf-mip6-ikev2-ipsec-06.txt >>> >>> >>> >>> Hi Jari, >>> >>> The MIP6 WG I-D "Mobile IPv6 Operation with IKEv2 and the revised >>> IPsec architecture" draft has completed a second WG last >> call and is >>> now ready to be progressed towards standards track. Rev 06 >> of the I-D >>> has incorporated all the comments that have been received >> during the >>> last call and prior to it. >>> >>> We would like to request you to process this I-D and >> progress it towards >>> publication as a standards track RFC. >>> >>> Below is the template that was completed when we submitted >> the WG LC >>> the 1st time and sent it to the IESG (Margaret). Pretty >> much all the >>> statements are valid even now. >>> >>> -Raj >>> >>> ================================================== >>> >>>> The MIP6 WG I-D "Mobile IPv6 Operation with IKEv2 and the revised >>>> IPsec", I-D: draft-ietf-mip6-ikev2-ipsec-04.txt has >> completed WG last >>>> call and has been revised following the comments received. >>>> It is ready for AD review and forwarded through the IETF >> process for >>>> publication. >>>> >>>> Intended status for this I-D: Standards track >>>> >>>> >>>> 1) Have the chairs personally reviewed this version of >> the ID and do >>>> they believe this ID is sufficiently baked to forward >> to the IESG >>>> for publication? >>>> >>>> Yes. >>>> >>>> >>>> 2) Has the document had adequate review from both key WG >> members and >>>> key non-WG members? Do you have any concerns about the depth or >>>> breadth of the reviews that have been performed? >>>> >>>> The I-D has been reviewed sufficiently by WG members as well as >>>> experts in the area of IPsec and security. >>>> >>>> 3) Do you have concerns that the document needs more review from a >>>> particular (broader) perspective (e.g., security, operational >>>> complexity, someone familiar with AAA, etc.)? >>>> >>>> No. The document does not need further reviews. >>>> >>>> 4) Do you have any specific concerns/issues with this >> document that >>>> you believe the ADs and/or IESG should be aware of? For example, >>>> perhaps you are uncomfortable with certain parts of the >> document, >>>> or whether there really is a need for it, etc., but at the same >>>> time these issues have been discussed in the WG and the WG has >>>> indicated it wishes to advance the document anyway. >>>> >>>> There are no specific concerns with this document. >>>> >>>> 5) How solid is the WG consensus behind this document? Does it >>>> represent the strong concurrence of a few individuals, >> with others >>>> being silent, or does the WG as a whole understand and >> agree with >>>> it? >>>> >>>> Strong WG consensus. Base MIP6 specs (RFCs 3775/3776) >> specified the >>>> use of IKE (v1) as the means to establish the IPsec SA. >> This I-D is >>>> specifying the use of IKEv2 for establishing the MN-HA IPsec SA. >>>> >>>> >>>> 6) Has anyone threatened an appeal or otherwise indicated extreme >>>> discontent? If so, please summarize what are they upset about. >>>> >>>> No. >>>> >>>> 7) Have the chairs verified that the document adheres to >> _all_ of the >>>> ID nits? (see http://www.ietf.org/ID-nits.html). >>>> >>>> Yes. No Nits found. It has been run through the nits >> checker available >>>> at the tools.ietf web site. >>>> >>>> 8) Does the document a) split references into >> normative/informative, >>>> and b) are there normative references to IDs, where the >> IDs are not >>>> also ready for advancement or are otherwise in an unclear state? >>>> (Note: the RFC editor will not publish an RFC with normative >>>> references to IDs, it will delay publication until all >> such IDs are >>>> also ready for publication as RFCs.) >>>> >>>> Yes. >>>> >>>> 9) For Standards Track and BCP documents, the IESG approval >>>> announcement includes a writeup section with the following >>>> sections: >>>> >>>> - Technical Summary >>>> >>>> This document describes Mobile IPv6 operation with the revised >>>> IPsec architecture and IKEv2. >>>> >>>> - Working Group Summary >>>> >>>> The document has been discussed in the WG at several IETF >>>> meetings. It has also been reviewed sufficiently by WG >> members as >>>> well as security experts. There is consensus in >> publishing this I-D >>>> as a proposed standard. This specification is required >> in view of >>>> IKEv2 becoming the revised mechanism for setting up IPsec SAs. >>>> >>>> - Protocol Quality >>>> >>>> >>>> >>>> - is the protocol already being implemented? >>>> >>>> Yes. >>>> >>>> >>>> - have a significant number of vendors indicated they plan to >>>> implement the spec? >>>> >>>> There are some vendors who have at least indicated that they >>>> will implement this spec. >>>> >>>> - are there any reviewers (during the end stages) that merit >>>> explicit mention as having done a thorough review >> that resulted >>>> in important changes or a conclusion that the >> document was fine >>>> (except for maybe some nits?) >>>> >>>> The acknowledgement section captures this adequately. >>>> >>>> -Basavaraj >>>> >>>> >> >> ------ End of Forwarded Message >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 15:55:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxwH-00065x-PV; Thu, 15 Jun 2006 15:55:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqxwG-00065n-QZ for mip6@ietf.org; Thu, 15 Jun 2006 15:55:36 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqxwF-0003rT-C1 for mip6@ietf.org; Thu, 15 Jun 2006 15:55:36 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5FJtUqQ007209; Thu, 15 Jun 2006 22:55:30 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 22:55:30 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 14:55:26 -0500 Received: from 172.19.244.70 ([172.19.244.70]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Jun 2006 19:55:26 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 15 Jun 2006 14:55:29 -0500 From: Basavaraj Patil To: Message-ID: Thread-Topic: Please review I-D: draft-chowdhury-mip6-radius-01.txt Thread-Index: AcaQtabi5VtgFPyoEdqHQQARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Jun 2006 19:55:26.0849 (UTC) FILETIME=[A59A9710:01C690B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Gopal Dommety , Hannes , ext Avi Lior Subject: [Mip6] Please review I-D: draft-chowdhury-mip6-radius-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, The following I-D: draft-chowdhury-mip6-radius-01.txt, "RADIUS Mobile IPv6 Support" is an essential aspect of the bootstrapping solution work done by the design team. We would like to request the Radext WG to consider it as a WG document and progress it on standards track. However prior to asking the Radext WG, we would like the MIP6 WG members to review the I-D and provide feedback. Hence please reeivew and comment on the I-D. URL: http://ietf.org/internet-drafts/draft-chowdhury-mip6-radius-01.txt -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 16:14:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyEa-0000OL-3e; Thu, 15 Jun 2006 16:14:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyEY-0000OF-SE for mip6@ietf.org; Thu, 15 Jun 2006 16:14:30 -0400 Received: from av11-2-sn2.hy.skanova.net ([81.228.8.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqyEX-0005fz-E2 for mip6@ietf.org; Thu, 15 Jun 2006 16:14:30 -0400 Received: by av11-2-sn2.hy.skanova.net (Postfix, from userid 502) id E42A437FAC; Thu, 15 Jun 2006 22:14:28 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-2-sn2.hy.skanova.net (Postfix) with ESMTP id D516937ED0; Thu, 15 Jun 2006 22:14:28 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 82E6D37E42; Thu, 15 Jun 2006 22:14:28 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FqyEQ-0004Tg-Th; Thu, 15 Jun 2006 22:14:25 +0200 Message-ID: <4491BF9E.7020004@levkowetz.com> Date: Thu, 15 Jun 2006 22:14:22 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) References: <44917382.4060102@kolumbus.fi> <003801c6909d$a7a918a0$026115ac@dcml.docomolabsusa.com> <44919579.4070107@lucent.com> <008301c690a0$0cdc2940$026115ac@dcml.docomolabsusa.com> <4491981D.4080206@lucent.com> <00b401c690a3$b975ec60$026115ac@dcml.docomolabsusa.com> <4491AF02.4070000@levkowetz.com> <00d901c690b4$391f1850$026115ac@dcml.docomolabsusa.com> In-Reply-To: <00d901c690b4$391f1850$026115ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Jari Arkko , Pete McCann , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1323785405==" Errors-To: mip6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1323785405== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1CDC214F34F0B3124BBE7DF0" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1CDC214F34F0B3124BBE7DF0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi James, on 2006-06-15 21:45 James Kempf said the following: >>Since I'm convinced that this can be further improved, and will >>be increasingly well used, I think it would be very wrong to >>group things that aren't particularly closely related into one >>mega-document when they would be better described, and more easily >>worked at, as separate documents. >=20 > If two things aren't part of the same set of mechanisms an implementor = would=20 > need in order to implement a protocol or system, then of course they=20 > shouldn't be in the same document. Ok. > But in the past, there has been a tendency to want to break protocol=20 > definitions apart, for better modularity. For example, breaking out rou= te=20 > optimization from the MIP6 document which is currently in the charter (= so=20 > this discussion is not completely irrelevant to the list, which is why = I'm=20 > posting it here too). While I am in principle in favor of this, without= some=20 > kind of hypertext linking, this imposes a higher cognitive burden on th= e=20 > implementor. They may not even know where all the pieces are. Agreed. > I'm certainly glad to see the tools.ietf.org hypertext linking being us= ed,=20 > but I don't think it is really a solution until it becomes the default = way=20 > that RFCs are available online, that is, it is linked from the official= IETF=20 > RFC Web page. Also agreed. > It also is lacking an important aspect of modern documentation=20 > technology - the ability to do high quality graphics. As protocols beco= me=20 > more complex, graphical representations become more important for compl= ete=20 > understanding. ASCII art just doesn't cut it anymore, despite emacs mac= ros=20 > and all the other tools people have proposed. Neither does being able t= o=20 > post an alternative postscript version. I mostly agree, but maybe don't feel as strongly about this as you do. Regards, Henrik --------------enig1CDC214F34F0B3124BBE7DF0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEkb+eeVhrtTJkXCMRAlJfAKDkZT2eySosnkqqgaNn2zQC8nLJsgCffl87 DuAN4zQxGTMjpC9xl8ubW2c= =lFSY -----END PGP SIGNATURE----- --------------enig1CDC214F34F0B3124BBE7DF0-- --===============1323785405== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1323785405==-- From mip6-bounces@ietf.org Thu Jun 15 17:21:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqzGn-0002iv-S9; Thu, 15 Jun 2006 17:20:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqzGn-0002iq-4W for mip6@ietf.org; Thu, 15 Jun 2006 17:20:53 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqzGm-0006dI-JF for mip6@ietf.org; Thu, 15 Jun 2006 17:20:53 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5FLKo9U005657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Jun 2006 14:20:51 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5FLKjZc025181; Thu, 15 Jun 2006 14:20:49 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 14:20:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Request to progress MIP6 WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Thu, 15 Jun 2006 14:20:42 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04F6DD@NAEX14.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Request to progress MIP6 WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcaP+ch+Bv3nbPvtEdqcIgARJNUNiAAACDLpAAJ9LnAALCk1pgADO+EQ From: "Soliman, Hesham" To: "Basavaraj Patil" , X-OriginalArrivalTime: 15 Jun 2006 21:20:45.0611 (UTC) FILETIME=[909FAFB0:01C690C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: jari.arkko@piuha.net X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org But this conclusion was never sent to the list or agreed on. Shouldn't=20 we at least formally close the issue?=20 Hesham > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com]=20 > Sent: Thursday, June 15, 2006 3:47 PM > To: Soliman, Hesham; mip6@ietf.org > Cc: jari.arkko@piuha.net > Subject: Re: [Mip6] FW: Request to progress MIP6 WG I-D:=20 > draft-ietf-mip6-ikev2-ipsec-06.txt >=20 >=20 > Based on the discussion about whether to include tunnel mode=20 > specification > by a small handful of people, the final conclusion was to=20 > include text that > specifies how to send BU messages in tunnel mode. >=20 > -Raj >=20 >=20 > On 6/14/06 5:43 PM, "ext Soliman, Hesham"=20 > wrote: >=20 > > Hi Raj, authors, > >=20 > > How was the issue I raised about the tunnel mode resolved=20 > in the draft? > > A quick glance tells me nothing changed. > >=20 > > Hesham > >=20 > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > >> Sent: Wednesday, June 14, 2006 5:32 PM > >> To: mip6@ietf.org > >> Subject: [Mip6] FW: Request to progress MIP6 WG I-D: > >> draft-ietf-mip6-ikev2-ipsec-06.txt > >>=20 > >>=20 > >> FYI, > >>=20 > >> ------ Forwarded Message > >>> From: Basavaraj Patil > >>> Date: Wed, 14 Jun 2006 16:30:40 -0500 > >>> To: ext Jari Arkko , > >> > >>> Cc: "W. Mark Townsley" , Gopal Dommety > >>> , ext Vijay Devarapalli > >> , > >>> > >>> Conversation: Request to progress MIP6 WG I-D: > >>> draft-ietf-mip6-ikev2-ipsec-06.txt > >>> Subject: Request to progress MIP6 WG I-D: > >> draft-ietf-mip6-ikev2-ipsec-06.txt > >>>=20 > >>>=20 > >>>=20 > >>> Hi Jari, > >>>=20 > >>> The MIP6 WG I-D "Mobile IPv6 Operation with IKEv2 and the revised > >>> IPsec architecture" draft has completed a second WG last > >> call and is > >>> now ready to be progressed towards standards track. Rev 06 > >> of the I-D > >>> has incorporated all the comments that have been received > >> during the > >>> last call and prior to it. > >>>=20 > >>> We would like to request you to process this I-D and > >> progress it towards > >>> publication as a standards track RFC. > >>>=20 > >>> Below is the template that was completed when we submitted > >> the WG LC > >>> the 1st time and sent it to the IESG (Margaret). Pretty > >> much all the > >>> statements are valid even now. > >>>=20 > >>> -Raj > >>>=20 > >>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > >>>=20 > >>>> The MIP6 WG I-D "Mobile IPv6 Operation with IKEv2 and=20 > the revised > >>>> IPsec", I-D: draft-ietf-mip6-ikev2-ipsec-04.txt has > >> completed WG last > >>>> call and has been revised following the comments received. > >>>> It is ready for AD review and forwarded through the IETF > >> process for > >>>> publication. > >>>>=20 > >>>> Intended status for this I-D: Standards track > >>>>=20 > >>>>=20 > >>>> 1) Have the chairs personally reviewed this version of > >> the ID and do > >>>> they believe this ID is sufficiently baked to forward > >> to the IESG > >>>> for publication? > >>>>=20 > >>>> Yes. > >>>>=20 > >>>>=20 > >>>> 2) Has the document had adequate review from both key WG > >> members and > >>>> key non-WG members? Do you have any concerns about=20 > the depth or > >>>> breadth of the reviews that have been performed? > >>>>=20 > >>>> The I-D has been reviewed sufficiently by WG members as well as > >>>> experts in the area of IPsec and security. > >>>>=20 > >>>> 3) Do you have concerns that the document needs more=20 > review from a > >>>> particular (broader) perspective (e.g., security, operational > >>>> complexity, someone familiar with AAA, etc.)? > >>>>=20 > >>>> No. The document does not need further reviews. > >>>> =20 > >>>> 4) Do you have any specific concerns/issues with this > >> document that > >>>> you believe the ADs and/or IESG should be aware of?=20 > For example, > >>>> perhaps you are uncomfortable with certain parts of the > >> document, > >>>> or whether there really is a need for it, etc., but=20 > at the same > >>>> time these issues have been discussed in the WG and the WG has > >>>> indicated it wishes to advance the document anyway. > >>>>=20 > >>>> There are no specific concerns with this document. > >>>> =20 > >>>> 5) How solid is the WG consensus behind this document? Does it > >>>> represent the strong concurrence of a few individuals, > >> with others > >>>> being silent, or does the WG as a whole understand and > >> agree with > >>>> it? > >>>>=20 > >>>> Strong WG consensus. Base MIP6 specs (RFCs 3775/3776) > >> specified the > >>>> use of IKE (v1) as the means to establish the IPsec SA. > >> This I-D is > >>>> specifying the use of IKEv2 for establishing the MN-HA IPsec SA. > >>>>=20 > >>>>=20 > >>>> 6) Has anyone threatened an appeal or otherwise=20 > indicated extreme > >>>> discontent? If so, please summarize what are they=20 > upset about. > >>>>=20 > >>>> No. > >>>> =20 > >>>> 7) Have the chairs verified that the document adheres to > >> _all_ of the > >>>> ID nits? (see http://www.ietf.org/ID-nits.html). > >>>>=20 > >>>> Yes. No Nits found. It has been run through the nits > >> checker available > >>>> at the tools.ietf web site. > >>>> =20 > >>>> 8) Does the document a) split references into > >> normative/informative, > >>>> and b) are there normative references to IDs, where the > >> IDs are not > >>>> also ready for advancement or are otherwise in an=20 > unclear state? > >>>> (Note: the RFC editor will not publish an RFC with normative > >>>> references to IDs, it will delay publication until all > >> such IDs are > >>>> also ready for publication as RFCs.) > >>>>=20 > >>>> Yes.=20 > >>>>=20 > >>>> 9) For Standards Track and BCP documents, the IESG approval > >>>> announcement includes a writeup section with the following > >>>> sections: > >>>>=20 > >>>> - Technical Summary > >>>>=20 > >>>> This document describes Mobile IPv6 operation with the revised > >>>> IPsec architecture and IKEv2. > >>>>=20 > >>>> - Working Group Summary > >>>>=20 > >>>> The document has been discussed in the WG at several IETF > >>>> meetings. It has also been reviewed sufficiently by WG > >> members as > >>>> well as security experts. There is consensus in > >> publishing this I-D > >>>> as a proposed standard. This specification is required > >> in view of > >>>> IKEv2 becoming the revised mechanism for setting up IPsec SAs. > >>>>=20 > >>>> - Protocol Quality > >>>>=20 > >>>>=20 > >>>>=20 > >>>> - is the protocol already being implemented? > >>>>=20 > >>>> Yes. > >>>>=20 > >>>>=20 > >>>> - have a significant number of vendors indicated=20 > they plan to > >>>> implement the spec? > >>>>=20 > >>>> There are some vendors who have at least=20 > indicated that they > >>>> will implement this spec. > >>>> =20 > >>>> - are there any reviewers (during the end stages) that merit > >>>> explicit mention as having done a thorough review > >> that resulted > >>>> in important changes or a conclusion that the > >> document was fine > >>>> (except for maybe some nits?) > >>>>=20 > >>>> The acknowledgement section captures this adequately. > >>>>=20 > >>>> -Basavaraj > >>>>=20 > >>>>=20 > >>=20 > >> ------ End of Forwarded Message > >>=20 > >>=20 > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 17:23:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqzJW-0004lD-N6; Thu, 15 Jun 2006 17:23:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqzJV-0004l8-I3 for mip6@ietf.org; Thu, 15 Jun 2006 17:23:41 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqzJU-0006gZ-6v for mip6@ietf.org; Thu, 15 Jun 2006 17:23:41 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5FLNbJe005838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Jun 2006 14:23:38 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5FLNPnf026066; Thu, 15 Jun 2006 14:23:37 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 14:23:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) Date: Thu, 15 Jun 2006 14:23:16 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04F6DF@NAEX14.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) Thread-Index: AcaQm3E+vYAwpv5tR16tQPl94+mi9gAJkr8A From: "Soliman, Hesham" To: "Thomas Narten" , "Jari Arkko" X-OriginalArrivalTime: 15 Jun 2006 21:23:19.0373 (UTC) FILETIME=[EC45E7D0:01C690C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Mobile IPv6 Mailing List , Peter McCann , Henrik Levkowetz X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > FYI -- MIP4 wants to recharter to include work on dual stack > > Mobile IPv4 support (item 10 below). Given that MIP6 also > > works on related issues I wanted to point you to this update. > > Comments welcome. >=20 > Is there a well-defined problem statement for item 10? =3D> There is a problem statement in MIP6 that covers both groups.=20 Unfortunately it has just expired, We'll submit another one for this=20 meeting. This problem statement drove the work in MIP6 and MIP4. Hesham >=20 > Thomas >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 17:56:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqzpS-0007kd-VC; Thu, 15 Jun 2006 17:56:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqzpR-0007kV-3k for mip6@ietf.org; Thu, 15 Jun 2006 17:56:41 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqzpP-00018v-Pz for mip6@ietf.org; Thu, 15 Jun 2006 17:56:41 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 14:56:31 -0700 Message-ID: <4491D78B.1010205@azairenet.com> Date: Thu, 15 Jun 2006 14:56:27 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] Please review I-D: draft-chowdhury-mip6-radius-01.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2006 21:56:31.0806 (UTC) FILETIME=[8FDB0DE0:01C690C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Gopal Dommety , mip6@ietf.org, ext Avi Lior , Hannes X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I know Kuntal presented this draft atleast a couple of times at the IETF meetings, but we are jumping ahead. I would like to see draft-ietf-mip6-aaa-ha-goals-01.txt become a bit stable first (I don't think it has received enough reviews). the DIME WG jumped the gun before the MIP6 WG could decide what exactly is needed for the HA-AAAH interface. Vijay Basavaraj Patil wrote: > Hello, > > The following I-D: draft-chowdhury-mip6-radius-01.txt, "RADIUS Mobile > IPv6 Support" is an essential aspect of the bootstrapping solution > work done by the design team. > We would like to request the Radext WG to consider it as a WG document > and progress it on standards track. However prior to asking the Radext > WG, we would like the MIP6 WG members to review the I-D and provide > feedback. > > Hence please reeivew and comment on the I-D. > URL: > http://ietf.org/internet-drafts/draft-chowdhury-mip6-radius-01.txt > > -Raj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 19:01:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0py-0002y9-El; Thu, 15 Jun 2006 19:01:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0px-0002y4-2t for mip6@ietf.org; Thu, 15 Jun 2006 19:01:17 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr0pw-000807-Bp for mip6@ietf.org; Thu, 15 Jun 2006 19:01:17 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5FN1BIw026675; Fri, 16 Jun 2006 02:01:15 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 02:00:41 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 18:00:32 -0500 Received: from 172.19.244.70 ([172.19.244.70]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Jun 2006 23:00:32 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 15 Jun 2006 18:00:35 -0500 Subject: Re: [Mip6] FW: Request to progress MIP6 WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt From: Basavaraj Patil To: "ext Soliman, Hesham" , Message-ID: Thread-Topic: [Mip6] FW: Request to progress MIP6 WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcaP+ch+Bv3nbPvtEdqcIgARJNUNiAAACDLpAAJ9LnAALCk1pgADO+EQAAOED14= In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04F6DD@NAEX14.na.qualcomm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Jun 2006 23:00:32.0779 (UTC) FILETIME=[814105B0:01C690CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: jari.arkko@piuha.net X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Sure. I agree. It would make more sense to send a note with the conclusion. Will send one. -Raj On 6/15/06 4:20 PM, "ext Soliman, Hesham" wrote: > But this conclusion was never sent to the list or agreed on. Shouldn't > we at least formally close the issue? > > Hesham > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] >> Sent: Thursday, June 15, 2006 3:47 PM >> To: Soliman, Hesham; mip6@ietf.org >> Cc: jari.arkko@piuha.net >> Subject: Re: [Mip6] FW: Request to progress MIP6 WG I-D: >> draft-ietf-mip6-ikev2-ipsec-06.txt >> >> >> Based on the discussion about whether to include tunnel mode >> specification >> by a small handful of people, the final conclusion was to >> include text that >> specifies how to send BU messages in tunnel mode. >> >> -Raj >> >> >> On 6/14/06 5:43 PM, "ext Soliman, Hesham" >> wrote: >> >>> Hi Raj, authors, >>> >>> How was the issue I raised about the tunnel mode resolved >> in the draft? >>> A quick glance tells me nothing changed. >>> >>> Hesham >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] >>>> Sent: Wednesday, June 14, 2006 5:32 PM >>>> To: mip6@ietf.org >>>> Subject: [Mip6] FW: Request to progress MIP6 WG I-D: >>>> draft-ietf-mip6-ikev2-ipsec-06.txt >>>> >>>> >>>> FYI, >>>> >>>> ------ Forwarded Message >>>>> From: Basavaraj Patil >>>>> Date: Wed, 14 Jun 2006 16:30:40 -0500 >>>>> To: ext Jari Arkko , >>>> >>>>> Cc: "W. Mark Townsley" , Gopal Dommety >>>>> , ext Vijay Devarapalli >>>> , >>>>> >>>>> Conversation: Request to progress MIP6 WG I-D: >>>>> draft-ietf-mip6-ikev2-ipsec-06.txt >>>>> Subject: Request to progress MIP6 WG I-D: >>>> draft-ietf-mip6-ikev2-ipsec-06.txt >>>>> >>>>> >>>>> >>>>> Hi Jari, >>>>> >>>>> The MIP6 WG I-D "Mobile IPv6 Operation with IKEv2 and the revised >>>>> IPsec architecture" draft has completed a second WG last >>>> call and is >>>>> now ready to be progressed towards standards track. Rev 06 >>>> of the I-D >>>>> has incorporated all the comments that have been received >>>> during the >>>>> last call and prior to it. >>>>> >>>>> We would like to request you to process this I-D and >>>> progress it towards >>>>> publication as a standards track RFC. >>>>> >>>>> Below is the template that was completed when we submitted >>>> the WG LC >>>>> the 1st time and sent it to the IESG (Margaret). Pretty >>>> much all the >>>>> statements are valid even now. >>>>> >>>>> -Raj >>>>> >>>>> ================================================== >>>>> >>>>>> The MIP6 WG I-D "Mobile IPv6 Operation with IKEv2 and >> the revised >>>>>> IPsec", I-D: draft-ietf-mip6-ikev2-ipsec-04.txt has >>>> completed WG last >>>>>> call and has been revised following the comments received. >>>>>> It is ready for AD review and forwarded through the IETF >>>> process for >>>>>> publication. >>>>>> >>>>>> Intended status for this I-D: Standards track >>>>>> >>>>>> >>>>>> 1) Have the chairs personally reviewed this version of >>>> the ID and do >>>>>> they believe this ID is sufficiently baked to forward >>>> to the IESG >>>>>> for publication? >>>>>> >>>>>> Yes. >>>>>> >>>>>> >>>>>> 2) Has the document had adequate review from both key WG >>>> members and >>>>>> key non-WG members? Do you have any concerns about >> the depth or >>>>>> breadth of the reviews that have been performed? >>>>>> >>>>>> The I-D has been reviewed sufficiently by WG members as well as >>>>>> experts in the area of IPsec and security. >>>>>> >>>>>> 3) Do you have concerns that the document needs more >> review from a >>>>>> particular (broader) perspective (e.g., security, operational >>>>>> complexity, someone familiar with AAA, etc.)? >>>>>> >>>>>> No. The document does not need further reviews. >>>>>> >>>>>> 4) Do you have any specific concerns/issues with this >>>> document that >>>>>> you believe the ADs and/or IESG should be aware of? >> For example, >>>>>> perhaps you are uncomfortable with certain parts of the >>>> document, >>>>>> or whether there really is a need for it, etc., but >> at the same >>>>>> time these issues have been discussed in the WG and the WG has >>>>>> indicated it wishes to advance the document anyway. >>>>>> >>>>>> There are no specific concerns with this document. >>>>>> >>>>>> 5) How solid is the WG consensus behind this document? Does it >>>>>> represent the strong concurrence of a few individuals, >>>> with others >>>>>> being silent, or does the WG as a whole understand and >>>> agree with >>>>>> it? >>>>>> >>>>>> Strong WG consensus. Base MIP6 specs (RFCs 3775/3776) >>>> specified the >>>>>> use of IKE (v1) as the means to establish the IPsec SA. >>>> This I-D is >>>>>> specifying the use of IKEv2 for establishing the MN-HA IPsec SA. >>>>>> >>>>>> >>>>>> 6) Has anyone threatened an appeal or otherwise >> indicated extreme >>>>>> discontent? If so, please summarize what are they >> upset about. >>>>>> >>>>>> No. >>>>>> >>>>>> 7) Have the chairs verified that the document adheres to >>>> _all_ of the >>>>>> ID nits? (see http://www.ietf.org/ID-nits.html). >>>>>> >>>>>> Yes. No Nits found. It has been run through the nits >>>> checker available >>>>>> at the tools.ietf web site. >>>>>> >>>>>> 8) Does the document a) split references into >>>> normative/informative, >>>>>> and b) are there normative references to IDs, where the >>>> IDs are not >>>>>> also ready for advancement or are otherwise in an >> unclear state? >>>>>> (Note: the RFC editor will not publish an RFC with normative >>>>>> references to IDs, it will delay publication until all >>>> such IDs are >>>>>> also ready for publication as RFCs.) >>>>>> >>>>>> Yes. >>>>>> >>>>>> 9) For Standards Track and BCP documents, the IESG approval >>>>>> announcement includes a writeup section with the following >>>>>> sections: >>>>>> >>>>>> - Technical Summary >>>>>> >>>>>> This document describes Mobile IPv6 operation with the revised >>>>>> IPsec architecture and IKEv2. >>>>>> >>>>>> - Working Group Summary >>>>>> >>>>>> The document has been discussed in the WG at several IETF >>>>>> meetings. It has also been reviewed sufficiently by WG >>>> members as >>>>>> well as security experts. There is consensus in >>>> publishing this I-D >>>>>> as a proposed standard. This specification is required >>>> in view of >>>>>> IKEv2 becoming the revised mechanism for setting up IPsec SAs. >>>>>> >>>>>> - Protocol Quality >>>>>> >>>>>> >>>>>> >>>>>> - is the protocol already being implemented? >>>>>> >>>>>> Yes. >>>>>> >>>>>> >>>>>> - have a significant number of vendors indicated >> they plan to >>>>>> implement the spec? >>>>>> >>>>>> There are some vendors who have at least >> indicated that they >>>>>> will implement this spec. >>>>>> >>>>>> - are there any reviewers (during the end stages) that merit >>>>>> explicit mention as having done a thorough review >>>> that resulted >>>>>> in important changes or a conclusion that the >>>> document was fine >>>>>> (except for maybe some nits?) >>>>>> >>>>>> The acknowledgement section captures this adequately. >>>>>> >>>>>> -Basavaraj >>>>>> >>>>>> >>>> >>>> ------ End of Forwarded Message >>>> >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>> >> >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 19:05:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0tW-0006jK-GQ; Thu, 15 Jun 2006 19:04:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0tV-0006jF-2Q for mip6@ietf.org; Thu, 15 Jun 2006 19:04:57 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr0tT-0008GL-JP for mip6@ietf.org; Thu, 15 Jun 2006 19:04:57 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5FN4amY030265; Fri, 16 Jun 2006 02:04:37 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 02:03:43 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 18:03:40 -0500 Received: from 172.19.244.70 ([172.19.244.70]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Jun 2006 23:03:40 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 15 Jun 2006 18:03:43 -0500 Subject: Re: [Mip6] Please review I-D: draft-chowdhury-mip6-radius-01.txt From: Basavaraj Patil To: ext Vijay Devarapalli Message-ID: Thread-Topic: [Mip6] Please review I-D: draft-chowdhury-mip6-radius-01.txt Thread-Index: AcaQz/KiMUZv1fzDEdqHQQARJNUNiA== In-Reply-To: <4491D78B.1010205@azairenet.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Jun 2006 23:03:40.0722 (UTC) FILETIME=[F146D920:01C690CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Gopal Dommety , mip6@ietf.org, ext Avi Lior , Hannes X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The AAA-HA goals I-D is expected to act as the requirements from a AAA perspective whose scope is beyond just bootstrapping. So I agree that we should ensure that the requirements I-D has consensus in the WG prior to the solutions being taken up in DIME or RADEXT. I hope Gerardo is able to get a new revision of the I-D out and we can go to last call after that. -Raj On 6/15/06 4:56 PM, "ext Vijay Devarapalli" wrote: > I know Kuntal presented this draft atleast a couple of > times at the IETF meetings, but we are jumping ahead. > I would like to see draft-ietf-mip6-aaa-ha-goals-01.txt > become a bit stable first (I don't think it has received > enough reviews). > > the DIME WG jumped the gun before the MIP6 WG could > decide what exactly is needed for the HA-AAAH interface. > > Vijay > > Basavaraj Patil wrote: >> Hello, >> >> The following I-D: draft-chowdhury-mip6-radius-01.txt, "RADIUS Mobile >> IPv6 Support" is an essential aspect of the bootstrapping solution >> work done by the design team. >> We would like to request the Radext WG to consider it as a WG document >> and progress it on standards track. However prior to asking the Radext >> WG, we would like the MIP6 WG members to review the I-D and provide >> feedback. >> >> Hence please reeivew and comment on the I-D. >> URL: >> http://ietf.org/internet-drafts/draft-chowdhury-mip6-radius-01.txt >> >> -Raj >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 19:16:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr14Z-0003mv-R5; Thu, 15 Jun 2006 19:16:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr14Y-0003mg-NA for mip6@ietf.org; Thu, 15 Jun 2006 19:16:22 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr14X-0001KV-T9 for mip6@ietf.org; Thu, 15 Jun 2006 19:16:22 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5FNGFqZ021616; Fri, 16 Jun 2006 02:16:16 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 02:15:29 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 18:15:26 -0500 Received: from 172.19.244.70 ([172.19.244.70]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Jun 2006 23:15:26 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 15 Jun 2006 18:15:28 -0500 Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) From: Basavaraj Patil To: Levkowetz , James Kempf Message-ID: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) Thread-Index: AcaQ0ZbY1YH1fvzEEdqHQQARJNUNiA== In-Reply-To: <4491AAF7.5000803@levkowetz.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Jun 2006 23:15:26.0285 (UTC) FILETIME=[95D337D0:01C690D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: Jari Arkko , Peter McCann , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Henrik, In the DS-MIP6 case the reasoning for the work has been that IPv6 native access is not expected to be ubiquitous and hence given that the host is DS and access is IPv4, there is a need to enable MIP6 continuity while being attached to a v4 network. The ability to carry IPv4 within the MIP6 session is to enable applications and services that are v4 based on the hosts and is applicable in the scenario when the host is connected to a native v6 access only (which I guess we believe will be the situation at some point in the future). So I believe there is a good reason to do this for MIP6. In the case of IPv4 hosts which are DS and MIP4 enabled, I do not think that you have to contend with the fact that you have to deal with a v6 access only. Secondly if the v6 stack on the host needs to connect to a v6 router, it could just as well use a standard transition mechanism. So having IPv6 packets carried over a MIP4 session IMO is not really a critical need. If there is a belief that a MIP4 based transition mechanism for IPv6 is needed, then fine. I think that would be the only requirement for such a solution. -Raj On 6/15/06 1:46 PM, "ext Henrik Levkowetz" wrote: > Hi James, > > on 2006-06-15 19:03 James Kempf said the following: >> So I'm wondering if there is any work to be done here in addition to the >> draft that is currently being worked on in the MIP6 WG? If the only work >> involves having someone from the MIP4 WG review the draft, then is there >> really need for a new charter item? On the other hand, if there is need for >> another document describing the interaction between the MIP6 transition work >> and MIP4, then maybe there is need for a new charter item (but if that is >> true, I'd say it's a flaw in the MIP6 transition document, and it should be >> handled by updating that). > > This work item covers the ability of MIPv4 to carry IPv6 packets, and does > not overlap with the MIP6 work of giving MIPv6 the ability to carry IPv4 > packets and run over IPv4 access networks. > > Regards, > > Henrik > > >> jak >> >> ----- Original Message ----- >> From: "Jari Arkko" >> To: "Mobile IPv6 Mailing List" >> Cc: "Peter McCann" ; "Henrik Levkowetz" >> >> Sent: Thursday, June 15, 2006 7:49 AM >> Subject: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 >> (mip4) >> >> >>> >>> FYI -- MIP4 wants to recharter to include work on dual stack >>> Mobile IPv4 support (item 10 below). Given that MIP6 also >>> works on related issues I wanted to point you to this update. >>> Comments welcome. >>> >>> --Jari >>> >>> IESG Secretary wrote: >>> >>>> A new charter for the Mobility for IPv4 (mip4) working group in the >>>> Internet >>>> Area of the IETF is being considered. The draft charter is provided below >>>> for >>>> your review and comment. >>>> >>>> Review time is one week. >>>> >>>> The IETF Secretariat >>>> >>>> +++ >>>> >>>> Mobility for IPv4 (mip4) >>>> ========================== >>>> >>>> Last Modified: 2006-06-13 >>>> >>>> Current Status: Active Working Group >>>> >>>> Chair(s): >>>> Peter McCann >>>> Henrik Levkowetz >>>> >>>> Internet Area Director(s): >>>> Jari Arkko >>>> Mark Townsley >>>> >>>> Internet Area Advisor: >>>> Jari Arkko >>>> >>>> Mailing Lists: >>>> General Discussion: mip4@ietf.org >>>> To Subscribe: mip4-request@ietf.org >>>> In Body: subscribe >>>> Archive: http://www.ietf.org/mail-archive/web/mip4/index.html >>>> >>>> Description of Working Group: >>>> >>>> IP mobility support for IPv4 nodes (hosts and routers) is specified in >>>> RFC3344. RFC 3344 mobility allows a node to continue using >>>> its "permanent" home address as it moves around the Internet. The >>>> Mobile IP protocols support transparency above the IP layer, including >>>> maintenance of active TCP connections and UDP port bindings.Besides >>>> the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal >>>> with concerns such as optimization, security, extensions, AAA support, >>>> and deployment issues. >>>> >>>> MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 >>>> networks). The scope of the deployment is on a fairly large scale and >>>> accordingly, the MIP4 WG will focus on deployment issues and on >>>> addressing known deficiencies and shortcomings in the protocol that >>>> have come up as a result of deployment experience. Specifically, the >>>> working group will complete the work items to facilitate interactions >>>> with AAA environments, interactions with enterprise environments when >>>> MIPv4 is used therein, and updating existing protocol specifications >>>> in accordance with deployment needs and advancing those protocols that >>>> are on the standards track. >>>> >>>> Work expected to be done by the MIP4 WG as proposed by this charter is >>>> as follows: >>>> >>>> 1. MIPv4 has been a proposed standard for several years. It has been >>>> adopted by other standard development organizations and has been >>>> deployed commercially. One of the next steps for the WG is to advance >>>> the protocol to draft standard status. As part of advancing base >>>> Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised >>>> to reflect implementation experience >>>> >>>> 2. Work items that are pending from the previous Mobile IP WG, which >>>> will be completed by the MIP4 WG, are: >>>> >>>> - completion of the MIB for the revised base Mobile IP >>>> specification (2006bis) >>>> >>>> - regional registration draft. >>>> >>>> 3. The MIP4 WG will also complete the work on MIPv4 interactions >>>> in VPN scenarios. This work will involve identifying the requirements >>>> and a solution development for MIPv4 operation in the presence >>>> of IPsec VPNs. >>>> >>>> 4. Additionally, a proposal has been made for how MOBIKE could work >>>> together with MIPv4. This proposal does not describe any new protocol, >>>> but formulates a best current practice for deploying MOBIKE together >>>> with MIPv4. The working group will adopt and complete this document. >>>> >>>> 5. Some issues have been raised with respect to RFC3519. These will be >>>> identified and addressed as appropriate, through errata, revision >>>> of RFC 3519, and/or supplemental documents as needed. >>>> >>>> 6. It has been proposed that the FMIP protocol, which has been >>>> standardised for MIPv6 in the MIPSHOP working group, should also be >>>> published as an experimental protocol for MIPv4. A draft for this >>>> exists. The working group will take up and carry this work forward >>>> to publication >>>> >>>> 7. An extension to carry generic strings in the Registration Reply >>>> message has been proposed. The purpose is to supply supplemental >>>> human-readable information intended to the MN user. The working >>>> group will complete the specification and applicability statement of >>>> such an extension. >>>> >>>> 8. RADIUS attributes for MIP4. A set of RADIUS attributes has >>>> been proposed for MIPv4. >>>> >>>> The working group will first produce a requirements specification, >>>> describing how the work differs from the requirements in RFC 2977 >>>> and the functionality provided by RFC 4004 (the MIPv4 Diameter App). >>>> The reason why this first step is required is that RFC 3127 pretty >>>> clearly shows that full 2977 functionality can't be provided by even >>>> a considerably extended RADIUS, so we need to match the requirements >>>> to what can be done within RADIUS. >>>> >>>> Provided the requirements work finds approval with ADs and radext, >>>> the workgroup will complete the specification of MIPv4 RADIUS >>>> attributes, solicit feedback from the Radius Extensions WG, adjust, >>>> and submit this for publication. >>>> >>>> 9. MIPv4 Extension for Configuration Options. >>>> >>>> Several drafts have proposed extensions to help improve configuration >>>> of MIPv4 clients. The latest proposal is for a general configuration >>>> option extension which could carry information such as e.g., DNS >>>> address and DHCP server address. The working group will take on >>>> and complete one proposal for a configuration option extension. >>>> >>>> 10. Dual-stack Support >>>> >>>> There have been several proposals for how to enable an IPv6 >>>> connection over a network that supports Mobile IPv4. The >>>> basic idea is to include an IPv6 address in the Mobile IPv4 >>>> signaling messages. The working group will take on and complete >>>> one proposal for IPv6 over Mobile IPv4. >>>> >>>> Goals and Milestones: >>>> >>>> Done AAA Keys for MIPv4 to IESG >>>> Done MIPv4 VPN interaction problem statement to IESG >>>> Done Low latency handover to experimental >>>> Done Experimental MIPv4 message and extensions draft to IESG >>>> Done Dynamic Home Agent assignment protocol solution to IESG >>>> Done Revised MIPv4 Challenge/Response (3012bis) to IESG >>>> Done Regional registration document to IESG >>>> Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT WG for comment >>>> Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG >>>> May 2006 MIPv4 Mobike interaction (BCP) to the IESG >>>> May 2006 MIPv4 VPN interaction (BCP) to the IESG >>>> May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment >>>> Jun 2006 Revised MIPv4 specification to IESG for Draft Std. >>>> Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG >>>> Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the IESG >>>> Sep 2006 FMIPv4 (Experimental) to the IESG >>>> Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG >>>> Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG >>>> Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG >>>> Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >> >> >> > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 19:36:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr1Nw-0003aE-Tz; Thu, 15 Jun 2006 19:36:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr1Nv-0003Zw-8U for mip6@ietf.org; Thu, 15 Jun 2006 19:36:23 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr1Nt-00042c-V6 for mip6@ietf.org; Thu, 15 Jun 2006 19:36:23 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 16:36:20 -0700 Message-ID: <4491EEF4.5060706@azairenet.com> Date: Thu, 15 Jun 2006 16:36:20 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Mobile IPv6 Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2006 23:36:20.0307 (UTC) FILETIME=[8147CA30:01C690D4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Mip6] Experimental and Vendor specific messages X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org hello, the following two drafts specify experimental and vendor specific mobility header messages and options. http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-experimental-messages-00.txt http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-vsm-00.txt the motivation behind these drafts is that they would encourage experiments and protocol extensions to Mobile IPv6. comments would be much appreciated. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 20:12:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr1xA-0000HS-45; Thu, 15 Jun 2006 20:12:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr1x8-0000H7-Ka for mip6@ietf.org; Thu, 15 Jun 2006 20:12:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr1Ag-0001nA-LA for mip6@ietf.org; Thu, 15 Jun 2006 19:22:42 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fr0xm-0007v2-OD for mip6@ietf.org; Thu, 15 Jun 2006 19:09:25 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5FN9HQJ029650; Fri, 16 Jun 2006 02:09:17 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 02:09:07 +0300 Received: from [127.0.0.1] ([172.18.141.83]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 16 Jun 2006 02:09:06 +0300 Message-ID: <4491E890.6060900@iprg.nokia.com> Date: Thu, 15 Jun 2006 16:09:04 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kilian Weniger Subject: Re: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01) References: <4D2F935F08D41A4C8866693F4F0D7C4FB8E418@lan-ex-01.panasonic.de> In-Reply-To: <4D2F935F08D41A4C8866693F4F0D7C4FB8E418@lan-ex-01.panasonic.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2006 23:09:06.0819 (UTC) FILETIME=[B3A54D30:01C690D0] X-Spam-Score: -2.6 (--) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Kilian, thanks for the input. Kilian Weniger wrote: >General >-------- > >- the term "roaming" is used in this draft many times, but is the term >(defined in RFC3753) really appropriate here? Shouldn't it be replaced >by "handover"? IMHO, the location privacy problem does also exist in >non-roaming cases (MN moves to different subnet within an operator's >network, i.e., intra-domain handover). > > > we are not following the strict definition of "roaming" as in RFC3753. Roaming may or may not have operator intervention. The draft is neutral about it. Handover is a special case of mobility in which you are concerned about existing sessions. So, when a MN roams, it could have existing sessions or not. If you would like me to define the term, I can. For instance, Roaming: The process of moving from one network to another (with or without existing sessions). >Comments on Section 2.1 >------------ > >- The first sentence says > > "When a Mobile IP MN roams from its home network to a visited network, > use of Care of Address in communication with a correspondent reveals > that the MN has roamed." > >I think this is a bit vague. First, the problem does not only exist when >the MN roams from home to visited network, it also exists if it roams >from one visited to another visited network. Second, not only the fact >is revealed that the MN has roamed/moved, but also where the MN is >located after the movement. Suggested text: > > "When a Mobile IP MN does a handover from its home network to a visited >network *or from one visited network to another*, use of Care of Address >in communication with a correspondent reveals that the MN has just done >a handover *and where the MN is currently topologically located*." > > > I agree with the first part. The second part is commonly understood, and is described in the Introduction. Perhaps I could add to: "Furthermore, a user may not wish to reveal roaming to correspondent(s). In Mobile IP, this translates to the use of Care of Address." "As with Home Address, the Care of Address can also reveal the topological location of the Mobile Node". >- location privacy is only compromised if the correspondent node is able >to link the HoA to a specific user/user identity. Although this may >often be the case, this should be explicitly stated (similar statement >exists in section 2.2). > > > This is again common for the entire document. From Section 1: :..The location privacy problem is particularly applicable to Mobile IP where the Home Address on a visited network can reveal device roaming and, together with a user identifier (such as a SIP URI), can reveal user roaming.." >- "to the correspondent node" should be added to the title of the >section (in section 2.2, the care-of address is disclosed as well, but >to on-lookers) > > > > Okay. >Comments on Section 2.2 >------------ > >- Analog to the comment on section 2.1, the text should consider that >the problem does also exist when the MN moves from one visited network >to another. > > > Ok. >- analog to the comment on section 2.1, "to on-lookers" should be added >to the title > > > Ok. >- It should be mentioned that location privacy is only compromised if >the on-looker is located on the path between MN and HA in bi-directional >tunneling mode or on the path between MN and CN in route optimization >mode. > > > > Check. >Comments on Section 3 and conclusion >------------------------ > >- The granularity of location information revealed from a care-of >address depends also on whether a local mobility management scheme such >as HMIPv6 or netlmm is used or not. Maybe this should be mentioned >somewhere. > > > Well, regardless of the on-link prefix, the granularity points to the physical address of the ISP. With more sophisticated tools, one could get a better blueprint, which is recognized at the end of 2nd paragraph of Section 3. >- The draft concludes that two problems exist: disclosure of CoA to CN >and disclosure of HoA to on-lookers. I would like to see some conclusion >and discussions of requirements, so that solutions later can better be >evaluated against requirements. For instance >* which level of granularity regarding location privacy is required >(some argue that the level that netlmm provides is sufficient)? > > We should be able to hide HoA all together and have something to say about how to use CoA judiciously if the MN is concerned about revealing the CoA. >* it should be possible to combine solutions for hiding CoA from CN and >hiding HoA from on-lookers (i.e., provide both simultaneously) >* Route optimization should certainly be supported in both cases so that >delay-sensitive services and efficient routing are possible. > > > None of these are excluded in the solutions. The only requirement I see is that the solutions should not require additions to Mobile IP functional elements. So, you have a MN, HA and CN. And you have MIP signaling protocol. What protocol enhancements we need to provide location privacy? (I somehow think that this assumption of MIP model is clear in all the protocol work surrounding MIP. I could make it clear that no new elements are required) >- The following paragraph is not really clear to me: "With its >correspondents, the MN can either communicate directly or > reverse tunnel its packets through the Home Agent. Using reverse >tunneling does not reveal the new IP address of the MN, although >performance may vary depending on the particular scenario. In some >instances, the performance difference could be noticeable enough to >serve as a hint to the correspondent." > >What exactly is this hint about and how reliable is such hint? Does it >mean that the correspondent can find out that the MN is not located at >home only based on packet delay? While it might be true in some cases >that the delay of reverse tunneled packets is high if the MN is away >from home, this is not generally true, since there are many potential >factors contributing to the packet delay. E.g., the delay heavily >depends on the access technology used. When a users changes from a GPRS >home network to a WLAN visited network, the packet delay may be much >higher if the MN is at home compared to when it is located in the >visited network. Since the correspondent node usually doesn't know which >access technology is used by the MN, I do not see how the CN can derive >the MN's location from packet delay. > > > It does not state that the CN can derive MN's location from packet delay. The hints are just that; they are not conclusive. If you roam across continents, your CN may notice the difference. That's all it is trying to say ("_In some instances_..). I could add "However, such a difference is not always conclusive". -Rajeev >- Kilian > > >-----Original Message----- >From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] >Sent: Freitag, 2. Juni 2006 18:01 >To: mip6@ietf.org >Subject: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01) > > > >Hello, > >This is the working group last call for I-D: >draft-ietf-mip6-location-privacy-ps-01.txt (IP Address Location Privacy >and Mobile IPv6: Problem Statement) > >WG LC will end on June 16th, 06. Please review and send your comments >before the deadline. > >The document is intended to be published as an Informational RFC. > >-Chairs > >The link for the I-D: >http://ietf.org/internet-drafts/draft-ietf-mip6-location-privacy-ps-01.t >xt > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 20:41:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr2Ou-000725-01; Thu, 15 Jun 2006 20:41:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr2Oq-000716-Mm; Thu, 15 Jun 2006 20:41:24 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr2Op-0002Fm-As; Thu, 15 Jun 2006 20:41:24 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k5G0fMr3012638; Thu, 15 Jun 2006 17:41:22 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k5G0fMgj012637; Thu, 15 Jun 2006 17:41:22 -0700 Date: Thu, 15 Jun 2006 17:41:22 -0700 Message-Id: <200606160041.k5G0fMgj012637@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: mip6@ietf.org, rfc-editor@rfc-editor.org Subject: [Mip6] RFC 4449 on Securing Mobile IPv6 Route Optimization Using a Static Shared Key X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4449 Title: Securing Mobile IPv6 Route Optimization Using a Static Shared Key Author: C. Perkins Status: Standards Track Date: June 2006 Mailbox: charles.perkins@nokia.com Pages: 7 Characters: 15080 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mip6-precfgkbm-04.txt URL: http://www.rfc-editor.org/rfc/rfc4449.txt A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates. [STANDARDS TRACK] This document is a product of the Mobility for IPv6 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 15 21:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3KH-0004Fc-6p; Thu, 15 Jun 2006 21:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3KE-0004FX-7x for mip6@ietf.org; Thu, 15 Jun 2006 21:40:42 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr3KC-0000x3-Fy for mip6@ietf.org; Thu, 15 Jun 2006 21:40:42 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0X0022UJCX5T@szxga01-in.huawei.com> for mip6@ietf.org; Fri, 16 Jun 2006 09:41:21 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0X00H3XJCX2G@szxga01-in.huawei.com> for mip6@ietf.org; Fri, 16 Jun 2006 09:41:21 +0800 (CST) Received: from w50392 ([10.164.45.173]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0X001YVJCPZ8@szxml03-in.huawei.com> for mip6@ietf.org; Fri, 16 Jun 2006 09:41:13 +0800 (CST) Date: Fri, 16 Jun 2006 09:39:47 +0800 From: Tom Wan Subject: [mip6]new draft of ds ps: draft-wan-mip6-nemo-dsanalysis-00.txt request for comment To: mip6@ietf.org Message-id: <012701c690e5$c0a6b860$6e2ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0916944507==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0916944507== Content-type: multipart/alternative; boundary="Boundary_(ID_Z7BhpI4NfnNgG5Op1HXIIg)" This is a multi-part message in MIME format. --Boundary_(ID_Z7BhpI4NfnNgG5Op1HXIIg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hello, folks: I have written a draft on the ds problem statement.please review it and give me comments.Your comments are appreciated. Abstract The purpose of this document is to investigate the motivations for mobile entities using dual stacks and the scenarios of mobile entities with dual-stacks roaming in the ipv4 or ipv6 network. This document also discusses the problems to be solved during these scenarios. BR Tom --Boundary_(ID_Z7BhpI4NfnNgG5Op1HXIIg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hello, folks:
I have written a draft on the ds problem statement.please review it and give me comments.Your comments are appreciated.
 
Abstract

   The purpose of this document is to investigate the motivations for
   mobile entities using dual stacks and the scenarios of mobile
   entities with dual-stacks roaming in the ipv4 or ipv6 network.  This
   document also discusses the problems to be solved during these
   scenarios.

 
 
 
BR
Tom
--Boundary_(ID_Z7BhpI4NfnNgG5Op1HXIIg)-- --===============0916944507== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0916944507==-- From mip6-bounces@ietf.org Thu Jun 15 22:14:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3qv-0000ba-UE; Thu, 15 Jun 2006 22:14:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3qu-0000bU-2A for mip6@ietf.org; Thu, 15 Jun 2006 22:14:28 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr3qq-0004Ts-8e for mip6@ietf.org; Thu, 15 Jun 2006 22:14:28 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0X006AKL9QDI@szxga03-in.huawei.com> for mip6@ietf.org; Fri, 16 Jun 2006 10:22:38 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0X00M2BL9PVN@szxga03-in.huawei.com> for mip6@ietf.org; Fri, 16 Jun 2006 10:22:38 +0800 (CST) Received: from w50392 ([10.164.45.173]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0X0015HKWVZ8@szxml03-in.huawei.com> for mip6@ietf.org; Fri, 16 Jun 2006 10:14:56 +0800 (CST) Date: Fri, 16 Jun 2006 10:13:29 +0800 From: Tom Wan Subject: [mip6]new draft of ds ps: draft-wan-mip6-nemo-dsanalysis-00.txtrequest for comment To: mip6@ietf.org Message-id: <019801c690ea$75d099f0$6e2ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0325968983==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0325968983== Content-type: multipart/alternative; boundary="Boundary_(ID_1cMCZddHw/CFk68DTJnP4Q)" This is a multi-part message in MIME format. --Boundary_(ID_1cMCZddHw/CFk68DTJnP4Q) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, folks: I have written a draft on the ds problem statement.please review it and give me comments.Your comments are appreciated. Abstract The purpose of this document is to investigate the motivations for mobile entities using dual stacks and the scenarios of mobile entities with dual-stacks roaming in the ipv4 or ipv6 network. This document also discusses the problems to be solved during these scenarios. I am sorry for sending this message again, because I forgot to attach the link address in the former mail. http://www.ietf.org/internet-drafts/draft-wan-mip6-nemo-dsanalysis-00.txt BR Tom --Boundary_(ID_1cMCZddHw/CFk68DTJnP4Q) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi, folks:
I have written a draft on the ds problem statement.please review it and give me comments.Your comments are appreciated.
 
Abstract

   The purpose of this document is to investigate the motivations for
   mobile entities using dual stacks and the scenarios of mobile
   entities with dual-stacks roaming in the ipv4 or ipv6 network.  This
   document also discusses the problems to be solved during these
   scenarios.
 
I am sorry for sending this message again, because I forgot to attach the link address in the former mail.

 
 
BR
Tom
 
 
 
--Boundary_(ID_1cMCZddHw/CFk68DTJnP4Q)-- --===============0325968983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0325968983==-- From mip6-bounces@ietf.org Thu Jun 15 22:25:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr41O-0007vT-27; Thu, 15 Jun 2006 22:25:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr41L-0007vI-VG for mip6@ietf.org; Thu, 15 Jun 2006 22:25:15 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr41L-0005Rx-Cu for mip6@ietf.org; Thu, 15 Jun 2006 22:25:15 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5G2PDh2013578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Jun 2006 19:25:14 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5G2PBVC012511; Thu, 15 Jun 2006 19:25:12 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 19:25:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Request to progress MIP6 WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt Date: Thu, 15 Jun 2006 19:24:48 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04F71D@NAEX14.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Request to progress MIP6 WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt Thread-Index: AcaP+ch+Bv3nbPvtEdqcIgARJNUNiAAACDLpAAJ9LnAALCk1pgADO+EQAAOED14ABxFbsA== From: "Soliman, Hesham" To: "Basavaraj Patil" , X-OriginalArrivalTime: 16 Jun 2006 02:25:08.0750 (UTC) FILETIME=[164D8AE0:01C690EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: jari.arkko@piuha.net X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Ok thanks. It would also make sense to update the questionnaire sent to Jari=20 to reflect that there was an objection to the current draft progressing. Since the discussion was limited to 3 people I would say a third is a significant=20 objection against this.=20 Hesham=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com]=20 > Sent: Thursday, June 15, 2006 7:01 PM > To: Soliman, Hesham; mip6@ietf.org > Cc: jari.arkko@piuha.net > Subject: Re: [Mip6] FW: Request to progress MIP6 WG I-D:=20 > draft-ietf-mip6-ikev2-ipsec-06.txt >=20 >=20 > Sure. I agree. It would make more sense to send a note with=20 > the conclusion. > Will send one. >=20 > -Raj >=20 >=20 > On 6/15/06 4:20 PM, "ext Soliman, Hesham"=20 > wrote: >=20 > > But this conclusion was never sent to the list or agreed=20 > on. Shouldn't > > we at least formally close the issue? > >=20 > > Hesham > >=20 > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > >> Sent: Thursday, June 15, 2006 3:47 PM > >> To: Soliman, Hesham; mip6@ietf.org > >> Cc: jari.arkko@piuha.net > >> Subject: Re: [Mip6] FW: Request to progress MIP6 WG I-D: > >> draft-ietf-mip6-ikev2-ipsec-06.txt > >>=20 > >>=20 > >> Based on the discussion about whether to include tunnel mode > >> specification > >> by a small handful of people, the final conclusion was to > >> include text that > >> specifies how to send BU messages in tunnel mode. > >>=20 > >> -Raj > >>=20 > >>=20 > >> On 6/14/06 5:43 PM, "ext Soliman, Hesham" > >> wrote: > >>=20 > >>> Hi Raj, authors, > >>>=20 > >>> How was the issue I raised about the tunnel mode resolved > >> in the draft? > >>> A quick glance tells me nothing changed. > >>>=20 > >>> Hesham > >>>=20 > >>>> -----Original Message----- > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > >>>> Sent: Wednesday, June 14, 2006 5:32 PM > >>>> To: mip6@ietf.org > >>>> Subject: [Mip6] FW: Request to progress MIP6 WG I-D: > >>>> draft-ietf-mip6-ikev2-ipsec-06.txt > >>>>=20 > >>>>=20 > >>>> FYI, > >>>>=20 > >>>> ------ Forwarded Message > >>>>> From: Basavaraj Patil > >>>>> Date: Wed, 14 Jun 2006 16:30:40 -0500 > >>>>> To: ext Jari Arkko , > >>>> > >>>>> Cc: "W. Mark Townsley" , Gopal Dommety > >>>>> , ext Vijay Devarapalli > >>>> , > >>>>> > >>>>> Conversation: Request to progress MIP6 WG I-D: > >>>>> draft-ietf-mip6-ikev2-ipsec-06.txt > >>>>> Subject: Request to progress MIP6 WG I-D: > >>>> draft-ietf-mip6-ikev2-ipsec-06.txt > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>> Hi Jari, > >>>>>=20 > >>>>> The MIP6 WG I-D "Mobile IPv6 Operation with IKEv2 and=20 > the revised > >>>>> IPsec architecture" draft has completed a second WG last > >>>> call and is > >>>>> now ready to be progressed towards standards track. Rev 06 > >>>> of the I-D > >>>>> has incorporated all the comments that have been received > >>>> during the > >>>>> last call and prior to it. > >>>>>=20 > >>>>> We would like to request you to process this I-D and > >>>> progress it towards > >>>>> publication as a standards track RFC. > >>>>>=20 > >>>>> Below is the template that was completed when we submitted > >>>> the WG LC > >>>>> the 1st time and sent it to the IESG (Margaret). Pretty > >>>> much all the > >>>>> statements are valid even now. > >>>>>=20 > >>>>> -Raj > >>>>>=20 > >>>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > >>>>>=20 > >>>>>> The MIP6 WG I-D "Mobile IPv6 Operation with IKEv2 and > >> the revised > >>>>>> IPsec", I-D: draft-ietf-mip6-ikev2-ipsec-04.txt has > >>>> completed WG last > >>>>>> call and has been revised following the comments received. > >>>>>> It is ready for AD review and forwarded through the IETF > >>>> process for > >>>>>> publication. > >>>>>>=20 > >>>>>> Intended status for this I-D: Standards track > >>>>>>=20 > >>>>>>=20 > >>>>>> 1) Have the chairs personally reviewed this version of > >>>> the ID and do > >>>>>> they believe this ID is sufficiently baked to forward > >>>> to the IESG > >>>>>> for publication? > >>>>>>=20 > >>>>>> Yes. > >>>>>>=20 > >>>>>>=20 > >>>>>> 2) Has the document had adequate review from both key WG > >>>> members and > >>>>>> key non-WG members? Do you have any concerns about > >> the depth or > >>>>>> breadth of the reviews that have been performed? > >>>>>>=20 > >>>>>> The I-D has been reviewed sufficiently by WG members=20 > as well as > >>>>>> experts in the area of IPsec and security. > >>>>>>=20 > >>>>>> 3) Do you have concerns that the document needs more > >> review from a > >>>>>> particular (broader) perspective (e.g., security,=20 > operational > >>>>>> complexity, someone familiar with AAA, etc.)? > >>>>>>=20 > >>>>>> No. The document does not need further reviews. > >>>>>> =20 > >>>>>> 4) Do you have any specific concerns/issues with this > >>>> document that > >>>>>> you believe the ADs and/or IESG should be aware of? > >> For example, > >>>>>> perhaps you are uncomfortable with certain parts of the > >>>> document, > >>>>>> or whether there really is a need for it, etc., but > >> at the same > >>>>>> time these issues have been discussed in the WG and=20 > the WG has > >>>>>> indicated it wishes to advance the document anyway. > >>>>>>=20 > >>>>>> There are no specific concerns with this document. > >>>>>> =20 > >>>>>> 5) How solid is the WG consensus behind this=20 > document? Does it > >>>>>> represent the strong concurrence of a few individuals, > >>>> with others > >>>>>> being silent, or does the WG as a whole understand and > >>>> agree with > >>>>>> it? > >>>>>>=20 > >>>>>> Strong WG consensus. Base MIP6 specs (RFCs 3775/3776) > >>>> specified the > >>>>>> use of IKE (v1) as the means to establish the IPsec SA. > >>>> This I-D is > >>>>>> specifying the use of IKEv2 for establishing the=20 > MN-HA IPsec SA. > >>>>>>=20 > >>>>>>=20 > >>>>>> 6) Has anyone threatened an appeal or otherwise > >> indicated extreme > >>>>>> discontent? If so, please summarize what are they > >> upset about. > >>>>>>=20 > >>>>>> No. > >>>>>> =20 > >>>>>> 7) Have the chairs verified that the document adheres to > >>>> _all_ of the > >>>>>> ID nits? (see http://www.ietf.org/ID-nits.html). > >>>>>>=20 > >>>>>> Yes. No Nits found. It has been run through the nits > >>>> checker available > >>>>>> at the tools.ietf web site. > >>>>>> =20 > >>>>>> 8) Does the document a) split references into > >>>> normative/informative, > >>>>>> and b) are there normative references to IDs, where the > >>>> IDs are not > >>>>>> also ready for advancement or are otherwise in an > >> unclear state? > >>>>>> (Note: the RFC editor will not publish an RFC with normative > >>>>>> references to IDs, it will delay publication until all > >>>> such IDs are > >>>>>> also ready for publication as RFCs.) > >>>>>>=20 > >>>>>> Yes.=20 > >>>>>>=20 > >>>>>> 9) For Standards Track and BCP documents, the IESG approval > >>>>>> announcement includes a writeup section with the following > >>>>>> sections: > >>>>>>=20 > >>>>>> - Technical Summary > >>>>>>=20 > >>>>>> This document describes Mobile IPv6 operation with=20 > the revised > >>>>>> IPsec architecture and IKEv2. > >>>>>>=20 > >>>>>> - Working Group Summary > >>>>>>=20 > >>>>>> The document has been discussed in the WG at several IETF > >>>>>> meetings. It has also been reviewed sufficiently by WG > >>>> members as > >>>>>> well as security experts. There is consensus in > >>>> publishing this I-D > >>>>>> as a proposed standard. This specification is required > >>>> in view of > >>>>>> IKEv2 becoming the revised mechanism for setting up=20 > IPsec SAs. > >>>>>>=20 > >>>>>> - Protocol Quality > >>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>>> - is the protocol already being implemented? > >>>>>>=20 > >>>>>> Yes. > >>>>>>=20 > >>>>>>=20 > >>>>>> - have a significant number of vendors indicated > >> they plan to > >>>>>> implement the spec? > >>>>>>=20 > >>>>>> There are some vendors who have at least > >> indicated that they > >>>>>> will implement this spec. > >>>>>> =20 > >>>>>> - are there any reviewers (during the end stages)=20 > that merit > >>>>>> explicit mention as having done a thorough review > >>>> that resulted > >>>>>> in important changes or a conclusion that the > >>>> document was fine > >>>>>> (except for maybe some nits?) > >>>>>>=20 > >>>>>> The acknowledgement section captures this adequately. > >>>>>>=20 > >>>>>> -Basavaraj > >>>>>>=20 > >>>>>>=20 > >>>>=20 > >>>> ------ End of Forwarded Message > >>>>=20 > >>>>=20 > >>>> _______________________________________________ > >>>> Mip6 mailing list > >>>> Mip6@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/mip6 > >>>>=20 > >>=20 > >>=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 16 01:36:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr70R-0004Ds-U6; Fri, 16 Jun 2006 01:36:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr70Q-0004DH-Le for mip6@ietf.org; Fri, 16 Jun 2006 01:36:30 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr6wf-0004r3-JE for mip6@ietf.org; Fri, 16 Jun 2006 01:32:38 -0400 Received: from [10.1.210.11] ([10.1.210.11]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Jun 2006 22:32:34 -0700 Message-ID: <4492426C.6040202@azairenet.com> Date: Thu, 15 Jun 2006 22:32:28 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] FW: Request to progress MIP6 WG I-D: draft-ietf-mip6-ikev2-ipsec-06.txt References: <7EB20EA0938B4D42A2D82689365C9B7A04F71D@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04F71D@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2006 05:32:34.0893 (UTC) FILETIME=[4586C7D0:01C69106] X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Cc: mip6@ietf.org, jari.arkko@piuha.net, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org there were a few more comments on the mailing list. (I remember atleast Shinta commenting on the proposed change). on the offlist discussion there were more than three people involved. Vijay Soliman, Hesham wrote: > Ok thanks. It would also make sense to update the questionnaire sent to > Jari > to reflect that there was an objection to the current draft progressing. > Since the discussion was limited to 3 people I would say a third is a > significant > objection against this. > > Hesham > > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > > Sent: Thursday, June 15, 2006 7:01 PM > > To: Soliman, Hesham; mip6@ietf.org > > Cc: jari.arkko@piuha.net > > Subject: Re: [Mip6] FW: Request to progress MIP6 WG I-D: > > draft-ietf-mip6-ikev2-ipsec-06.txt > > > > > > Sure. I agree. It would make more sense to send a note with > > the conclusion. > > Will send one. > > > > -Raj > > > > > > On 6/15/06 4:20 PM, "ext Soliman, Hesham" > > wrote: > > > > > But this conclusion was never sent to the list or agreed > > on. Shouldn't > > > we at least formally close the issue? > > > > > > Hesham > > > > > >> -----Original Message----- > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > > >> Sent: Thursday, June 15, 2006 3:47 PM > > >> To: Soliman, Hesham; mip6@ietf.org > > >> Cc: jari.arkko@piuha.net > > >> Subject: Re: [Mip6] FW: Request to progress MIP6 WG I-D: > > >> draft-ietf-mip6-ikev2-ipsec-06.txt > > >> > > >> > > >> Based on the discussion about whether to include tunnel mode > > >> specification > > >> by a small handful of people, the final conclusion was to > > >> include text that > > >> specifies how to send BU messages in tunnel mode. > > >> > > >> -Raj > > >> > > >> > > >> On 6/14/06 5:43 PM, "ext Soliman, Hesham" > > >> wrote: > > >> > > >>> Hi Raj, authors, > > >>> > > >>> How was the issue I raised about the tunnel mode resolved > > >> in the draft? > > >>> A quick glance tells me nothing changed. > > >>> > > >>> Hesham > > >>> > > >>>> -----Original Message----- > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > > >>>> Sent: Wednesday, June 14, 2006 5:32 PM > > >>>> To: mip6@ietf.org > > >>>> Subject: [Mip6] FW: Request to progress MIP6 WG I-D: > > >>>> draft-ietf-mip6-ikev2-ipsec-06.txt > > >>>> > > >>>> > > >>>> FYI, > > >>>> > > >>>> ------ Forwarded Message > > >>>>> From: Basavaraj Patil > > >>>>> Date: Wed, 14 Jun 2006 16:30:40 -0500 > > >>>>> To: ext Jari Arkko , > > >>>> > > >>>>> Cc: "W. Mark Townsley" , Gopal Dommety > > >>>>> , ext Vijay Devarapalli > > >>>> , > > >>>>> > > >>>>> Conversation: Request to progress MIP6 WG I-D: > > >>>>> draft-ietf-mip6-ikev2-ipsec-06.txt > > >>>>> Subject: Request to progress MIP6 WG I-D: > > >>>> draft-ietf-mip6-ikev2-ipsec-06.txt > > >>>>> > > >>>>> > > >>>>> > > >>>>> Hi Jari, > > >>>>> > > >>>>> The MIP6 WG I-D "Mobile IPv6 Operation with IKEv2 and > > the revised > > >>>>> IPsec architecture" draft has completed a second WG last > > >>>> call and is > > >>>>> now ready to be progressed towards standards track. Rev 06 > > >>>> of the I-D > > >>>>> has incorporated all the comments that have been received > > >>>> during the > > >>>>> last call and prior to it. > > >>>>> > > >>>>> We would like to request you to process this I-D and > > >>>> progress it towards > > >>>>> publication as a standards track RFC. > > >>>>> > > >>>>> Below is the template that was completed when we submitted > > >>>> the WG LC > > >>>>> the 1st time and sent it to the IESG (Margaret). Pretty > > >>>> much all the > > >>>>> statements are valid even now. > > >>>>> > > >>>>> -Raj > > >>>>> > > >>>>> ================================================== > > >>>>> > > >>>>>> The MIP6 WG I-D "Mobile IPv6 Operation with IKEv2 and > > >> the revised > > >>>>>> IPsec", I-D: draft-ietf-mip6-ikev2-ipsec-04.txt has > > >>>> completed WG last > > >>>>>> call and has been revised following the comments received. > > >>>>>> It is ready for AD review and forwarded through the IETF > > >>>> process for > > >>>>>> publication. > > >>>>>> > > >>>>>> Intended status for this I-D: Standards track > > >>>>>> > > >>>>>> > > >>>>>> 1) Have the chairs personally reviewed this version of > > >>>> the ID and do > > >>>>>> they believe this ID is sufficiently baked to forward > > >>>> to the IESG > > >>>>>> for publication? > > >>>>>> > > >>>>>> Yes. > > >>>>>> > > >>>>>> > > >>>>>> 2) Has the document had adequate review from both key WG > > >>>> members and > > >>>>>> key non-WG members? Do you have any concerns about > > >> the depth or > > >>>>>> breadth of the reviews that have been performed? > > >>>>>> > > >>>>>> The I-D has been reviewed sufficiently by WG members > > as well as > > >>>>>> experts in the area of IPsec and security. > > >>>>>> > > >>>>>> 3) Do you have concerns that the document needs more > > >> review from a > > >>>>>> particular (broader) perspective (e.g., security, > > operational > > >>>>>> complexity, someone familiar with AAA, etc.)? > > >>>>>> > > >>>>>> No. The document does not need further reviews. > > >>>>>> > > >>>>>> 4) Do you have any specific concerns/issues with this > > >>>> document that > > >>>>>> you believe the ADs and/or IESG should be aware of? > > >> For example, > > >>>>>> perhaps you are uncomfortable with certain parts of the > > >>>> document, > > >>>>>> or whether there really is a need for it, etc., but > > >> at the same > > >>>>>> time these issues have been discussed in the WG and > > the WG has > > >>>>>> indicated it wishes to advance the document anyway. > > >>>>>> > > >>>>>> There are no specific concerns with this document. > > >>>>>> > > >>>>>> 5) How solid is the WG consensus behind this > > document? Does it > > >>>>>> represent the strong concurrence of a few individuals, > > >>>> with others > > >>>>>> being silent, or does the WG as a whole understand and > > >>>> agree with > > >>>>>> it? > > >>>>>> > > >>>>>> Strong WG consensus. Base MIP6 specs (RFCs 3775/3776) > > >>>> specified the > > >>>>>> use of IKE (v1) as the means to establish the IPsec SA. > > >>>> This I-D is > > >>>>>> specifying the use of IKEv2 for establishing the > > MN-HA IPsec SA. > > >>>>>> > > >>>>>> > > >>>>>> 6) Has anyone threatened an appeal or otherwise > > >> indicated extreme > > >>>>>> discontent? If so, please summarize what are they > > >> upset about. > > >>>>>> > > >>>>>> No. > > >>>>>> > > >>>>>> 7) Have the chairs verified that the document adheres to > > >>>> _all_ of the > > >>>>>> ID nits? (see http://www.ietf.org/ID-nits.html). > > >>>>>> > > >>>>>> Yes. No Nits found. It has been run through the nits > > >>>> checker available > > >>>>>> at the tools.ietf web site. > > >>>>>> > > >>>>>> 8) Does the document a) split references into > > >>>> normative/informative, > > >>>>>> and b) are there normative references to IDs, where the > > >>>> IDs are not > > >>>>>> also ready for advancement or are otherwise in an > > >> unclear state? > > >>>>>> (Note: the RFC editor will not publish an RFC with normative > > >>>>>> references to IDs, it will delay publication until all > > >>>> such IDs are > > >>>>>> also ready for publication as RFCs.) > > >>>>>> > > >>>>>> Yes. > > >>>>>> > > >>>>>> 9) For Standards Track and BCP documents, the IESG approval > > >>>>>> announcement includes a writeup section with the following > > >>>>>> sections: > > >>>>>> > > >>>>>> - Technical Summary > > >>>>>> > > >>>>>> This document describes Mobile IPv6 operation with > > the revised > > >>>>>> IPsec architecture and IKEv2. > > >>>>>> > > >>>>>> - Working Group Summary > > >>>>>> > > >>>>>> The document has been discussed in the WG at several IETF > > >>>>>> meetings. It has also been reviewed sufficiently by WG > > >>>> members as > > >>>>>> well as security experts. There is consensus in > > >>>> publishing this I-D > > >>>>>> as a proposed standard. This specification is required > > >>>> in view of > > >>>>>> IKEv2 becoming the revised mechanism for setting up > > IPsec SAs. > > >>>>>> > > >>>>>> - Protocol Quality > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> - is the protocol already being implemented? > > >>>>>> > > >>>>>> Yes. > > >>>>>> > > >>>>>> > > >>>>>> - have a significant number of vendors indicated > > >> they plan to > > >>>>>> implement the spec? > > >>>>>> > > >>>>>> There are some vendors who have at least > > >> indicated that they > > >>>>>> will implement this spec. > > >>>>>> > > >>>>>> - are there any reviewers (during the end stages) > > that merit > > >>>>>> explicit mention as having done a thorough review > > >>>> that resulted > > >>>>>> in important changes or a conclusion that the > > >>>> document was fine > > >>>>>> (except for maybe some nits?) > > >>>>>> > > >>>>>> The acknowledgement section captures this adequately. > > >>>>>> > > >>>>>> -Basavaraj > > >>>>>> > > >>>>>> > > >>>> > > >>>> ------ End of Forwarded Message > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Mip6 mailing list > > >>>> Mip6@ietf.org > > >>>> https://www1.ietf.org/mailman/listinfo/mip6 > > >>>> > > >> > > >> > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 16 02:46:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr860-0005ma-PG; Fri, 16 Jun 2006 02:46:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr85z-0005gq-Jk; Fri, 16 Jun 2006 02:46:19 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr85x-000638-Td; Fri, 16 Jun 2006 02:46:19 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1Fr85j-0005gz-1c; Fri, 16 Jun 2006 08:46:05 +0200 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 8C907864F; Fri, 16 Jun 2006 08:46:02 +0200 (CEST) Message-ID: <449253AA.7020907@tm.uka.de> Date: Fri, 16 Jun 2006 08:46:02 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.4) Gecko/20060527 SUSE/1.5.0.4-0.1 Thunderbird/1.5.0.4 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Rajeev Koodli , Vijay Devarapalli Subject: Re: [Mip6] MIP and Upper Layer Protocol interaction References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <44872034.9010906@azairenet.com> <448772F6.9060009@iprg.nokia.com> In-Reply-To: <448772F6.9060009@iprg.nokia.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.5 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.1 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Rajeev and Vijay, you could also look at existing Internet protocol control blocks. All connections, regardless of the transport protocol they use, are represented by an Internet PCB. That Internet PCB may link to a separate transport-protocol-specific PCB, but that's less important for your needs. You can iterate through a list of all Internet PCBs and look for the "foreign addresses" (i.e., CNs' addresses) recorded. If the MN has an entry in its binding update list for a given foreign address, it would have to notify that CN about the change of its home address. In a related project, we wanted to find out about the establishment of new and the tear-down of old upper-layer connections. Our goal was to create a Mobile IPv6 binding even when the mobile node is at home, in order to facilitate proactive Mobile IPv6 signaling on the home link, which some optimizations require. The project was a diploma thesis of one of my students, Daniel Jungbluth, which I supervised. The following is a link to the documentation of this work: http://doc.tm.uka.de/2006/jungbluth-2006-homebindings.pdf Daniel's diploma thesis is not exactly what /you/ are having in mind---you need to check for existing upper-layer connections, while we wanted to recognize the establishment of new or tear-down of old connections. Specifically, /we/ could not easily use Internet PCBs for our needs; keeping an eye on the sockets turned out the best way to do this in our case. But the document linked above might still be of interest to you. Check section 4.2 in particular. Kind regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Rajeev Koodli wrote: > > Hi Vijay, > > Vijay Devarapalli wrote: > >> we could easily say its implementation specific since its >> internal to the mobile node. :) >> > that's okay. I am trying to see what we can use.. > >> there are many ways this can be achieved inside a mobile >> node. >> >> 1. the mobile node keeps track of number of packets sent >> using a particular binding update list entry. it can >> record this information in the binding update list entry >> itself. >> >> 2. the mobile node records the timestamp of the last packet >> sent using a particular binding update list entry in the >> binding update list entry itself. >> >> 3. the mobile node keeps track of all the sockets that >> were opened with a particular home address. >> > This might work. (1 and 2 above don't really relate to > whether a session/connection is alive or not). > > I am referring to such interaction. How do we formalize it > (if not standardize it)? > >> 4. etc.... >> >> you would see this issue in a non-Mobile IPv6 host too >> when you have multiple IPv6 addresses and the host wants >> to stop using a particular IPv6 address and start using >> another IPv6 address. >> > Yes, but you don't expect session persistence in that case. > > -Rajeev > >> let me know if I am completely off track. >> >> Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 16 04:02:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr9Hv-0008Sy-3I; Fri, 16 Jun 2006 04:02:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr9Hu-0008Se-KZ for mip6@ietf.org; Fri, 16 Jun 2006 04:02:42 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr9Hq-0002u8-Mm for mip6@ietf.org; Fri, 16 Jun 2006 04:02:42 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0Y00CAZ1P2PF@szxga02-in.huawei.com> for mip6@ietf.org; Fri, 16 Jun 2006 16:17:26 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0Y00DH81P14Q@szxga02-in.huawei.com> for mip6@ietf.org; Fri, 16 Jun 2006 16:17:25 +0800 (CST) Received: from w50392 ([10.164.45.173]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0Y008Z310Y0W@szxml03-in.huawei.com> for mip6@ietf.org; Fri, 16 Jun 2006 16:02:59 +0800 (CST) Date: Fri, 16 Jun 2006 16:01:32 +0800 From: Tom Wan Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) To: James Kempf , Jari Arkko , Mobile IPv6 Mailing List Message-id: <014e01c6911b$14f605d0$6e2ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=UTF-8; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <44917382.4060102@kolumbus.fi> <003801c6909d$a7a918a0$026115ac@dcml.docomolabsusa.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Peter McCann , Henrik Levkowetz X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I think the current draft in the WG can solve some problems, but it can not solve all problems. The current assumptions require that all HA and MN must have an stable ipv4 address at home network.This is reasonable in some scenarios. But there are some other scenarios. In these scenarios home network does not support ipv4 protocol.It is reasonable too. In some countries, ipv4 address is a scarce resource, so it may be impossible for every HA to assign a stable ipv4 address to every MN. In these scenarios, current solution does not work. So I think there may be some additional work in the v4 traversal field in the mip6 WG. solutions on these scenarios can be a complementarity to the dsmip6 protocol which is now the work in the design team. How do you think my draft on the other DS scenarios? I think it is different work from the design team and maybe my solution can be a complementarity to the dsmip6 protocol. The two solutions will not contradict with each other because their assumptions are different. On the topic whether the mip4 WG should work on ds solution, I have no idea now. BR Tom _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 16 04:22:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr9bB-0005jV-Gc; Fri, 16 Jun 2006 04:22:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr9b8-0005hg-FH for mip6@ietf.org; Fri, 16 Jun 2006 04:22:34 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr9Or-0003Fz-MR for mip6@ietf.org; Fri, 16 Jun 2006 04:10:01 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0Y00G021QE13@szxga03-in.huawei.com> for mip6@ietf.org; Fri, 16 Jun 2006 16:18:15 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0Y00CVH1QEDU@szxga03-in.huawei.com> for mip6@ietf.org; Fri, 16 Jun 2006 16:18:14 +0800 (CST) Received: from y52774 ([10.164.44.184]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0Y008G21DA0W@szxml03-in.huawei.com> for mip6@ietf.org; Fri, 16 Jun 2006 16:10:31 +0800 (CST) Date: Fri, 16 Jun 2006 16:08:58 +0800 From: Michael Ye Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) To: 'Mobile IPv6 Mailing List' Message-id: <000b01c6911c$220802e0$b82ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I think the current draft in the WG can solve some problems, but it can not solve all problems. The current assumptions require that all HA and MN must have an stable ipv4 address at home network.This is reasonable in some scenarios. But there are some other scenarios. In these scenarios home network does not support ipv4 protocol.It is reasonable too. In some countries, ipv4 address is a scarce resource, so it may be impossible for HA to assign a stable ipv4 address to MN. In these scenarios, current solution does not work. So I think there may be some additional work in the v4 traversal field in the mip6 WG. solutions on these scenarios can be a complementarity to the dsmip6 protocol which is now work in the design team. How do you think my draft on the other DS scenarios? I think they are different works and maybe my solution can be a complementarity to the dsmip6 protocol. The two solutions will not contradict with each other because their assumptions are different. On the topic whether the mip4 WG should work on ds solution, I have no idea now. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 16 04:51:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrA2o-00007N-JT; Fri, 16 Jun 2006 04:51:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrA2n-00007I-Ho for mip6@ietf.org; Fri, 16 Jun 2006 04:51:09 -0400 Received: from av8-1-sn3.vrr.skanova.net ([81.228.9.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrA2m-00056r-MR for mip6@ietf.org; Fri, 16 Jun 2006 04:51:09 -0400 Received: by av8-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 1FE3D386E9; Fri, 16 Jun 2006 10:51:08 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 0EA47386AF; Fri, 16 Jun 2006 10:51:08 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 9E57637E45; Fri, 16 Jun 2006 10:51:06 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FrA2b-0001Lp-4m; Fri, 16 Jun 2006 10:50:58 +0200 Message-ID: <449270E9.2070202@levkowetz.com> Date: Fri, 16 Jun 2006 10:50:49 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Cc: Jari Arkko , Peter McCann , James Kempf , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0960655949==" Errors-To: mip6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0960655949== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig94F7B63F64FF0382F73D8E27" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig94F7B63F64FF0382F73D8E27 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Raj, on 2006-06-16 01:15 Basavaraj Patil said the following: > Henrik, >=20 > In the DS-MIP6 case the reasoning for the work has been that IPv6 nativ= e > access is not expected to be ubiquitous and hence given that the host i= s DS > and access is IPv4, there is a need to enable MIP6 continuity while bei= ng > attached to a v4 network. The ability to carry IPv4 within the MIP6 ses= sion > is to enable applications and services that are v4 based on the hosts a= nd is > applicable in the scenario when the host is connected to a native v6 ac= cess > only (which I guess we believe will be the situation at some point in t= he > future). So I believe there is a good reason to do this for MIP6. Agreed. > In the case of IPv4 hosts which are DS and MIP4 enabled, I do not think= that > you have to contend with the fact that you have to deal with a v6 acces= s > only. We're not proposing that. > Secondly if the v6 stack on the host needs to connect to a v6 router, > it could just as well use a standard transition mechanism. Using which IP mobility support? > So having IPv6 > packets carried over a MIP4 session IMO is not really a critical need. If you by saying this are proposing that a DS node with MIP4 should provide mobility support for IPv4 sessions, but not for IPv6 sessions, I disagree strongly. If MIP4 is the mobility protocol available on the DS node, it should provide transport for both IPv4 and IPv6, without prejudice. > If > there is a belief that a MIP4 based transition mechanism for IPv6 is ne= eded, > then fine. I think that would be the only requirement for such a soluti= on. Couching this in terms of 'transition mechanisms' occludes the simplicity= of the issue. MIPv4 should provide transport - i.e., mobility support - = for both IPv4 and IPv6 traffic. Regards, Henrik > -Raj >=20 >=20 > On 6/15/06 1:46 PM, "ext Henrik Levkowetz" wrote= : >=20 >> Hi James, >>=20 >> on 2006-06-15 19:03 James Kempf said the following: >>> So I'm wondering if there is any work to be done here in addition to = the >>> draft that is currently being worked on in the MIP6 WG? If the only w= ork >>> involves having someone from the MIP4 WG review the draft, then is th= ere >>> really need for a new charter item? On the other hand, if there is ne= ed for >>> another document describing the interaction between the MIP6 transiti= on work >>> and MIP4, then maybe there is need for a new charter item (but if tha= t is >>> true, I'd say it's a flaw in the MIP6 transition document, and it sho= uld be >>> handled by updating that). >>=20 >> This work item covers the ability of MIPv4 to carry IPv6 packets, and = does >> not overlap with the MIP6 work of giving MIPv6 the ability to carry IP= v4 >> packets and run over IPv4 access networks. >>=20 >> Regards, >>=20 >> Henrik >>=20 >>=20 >>> jak >>>=20 >>> ----- Original Message ----- >>> From: "Jari Arkko" >>> To: "Mobile IPv6 Mailing List" >>> Cc: "Peter McCann" ; "Henrik Levkowetz" >>> >>> Sent: Thursday, June 15, 2006 7:49 AM >>> Subject: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv= 4 >>> (mip4) >>>=20 >>>=20 >>>>=20 >>>> FYI -- MIP4 wants to recharter to include work on dual stack >>>> Mobile IPv4 support (item 10 below). Given that MIP6 also >>>> works on related issues I wanted to point you to this update. >>>> Comments welcome. >>>>=20 >>>> --Jari >>>>=20 >>>> IESG Secretary wrote: >>>>=20 >>>>> A new charter for the Mobility for IPv4 (mip4) working group in the= >>>>> Internet >>>>> Area of the IETF is being considered. The draft charter is provide= d below >>>>> for >>>>> your review and comment. >>>>>=20 >>>>> Review time is one week. >>>>>=20 >>>>> The IETF Secretariat >>>>>=20 >>>>> +++ >>>>>=20 >>>>> Mobility for IPv4 (mip4) >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>>=20 >>>>> Last Modified: 2006-06-13 >>>>>=20 >>>>> Current Status: Active Working Group >>>>>=20 >>>>> Chair(s): >>>>> Peter McCann >>>>> Henrik Levkowetz >>>>>=20 >>>>> Internet Area Director(s): >>>>> Jari Arkko >>>>> Mark Townsley >>>>>=20 >>>>> Internet Area Advisor: >>>>> Jari Arkko >>>>>=20 >>>>> Mailing Lists: >>>>> General Discussion: mip4@ietf.org >>>>> To Subscribe: mip4-request@ietf.org >>>>> In Body: subscribe >>>>> Archive: http://www.ietf.org/mail-archive/web/mip4/index.html >>>>>=20 >>>>> Description of Working Group: >>>>>=20 >>>>> IP mobility support for IPv4 nodes (hosts and routers) is specified= in >>>>> RFC3344. RFC 3344 mobility allows a node to continue using >>>>> its "permanent" home address as it moves around the Internet. The >>>>> Mobile IP protocols support transparency above the IP layer, includ= ing >>>>> maintenance of active TCP connections and UDP port bindings.Besides= >>>>> the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal >>>>> with concerns such as optimization, security, extensions, AAA suppo= rt, >>>>> and deployment issues. >>>>>=20 >>>>> MIPv4 is currently being deployed on a wide basis (e.g., in cdma200= 0 >>>>> networks). The scope of the deployment is on a fairly large scale a= nd >>>>> accordingly, the MIP4 WG will focus on deployment issues and on >>>>> addressing known deficiencies and shortcomings in the protocol that= >>>>> have come up as a result of deployment experience. Specifically, th= e >>>>> working group will complete the work items to facilitate interactio= ns >>>>> with AAA environments, interactions with enterprise environments wh= en >>>>> MIPv4 is used therein, and updating existing protocol specification= s >>>>> in accordance with deployment needs and advancing those protocols t= hat >>>>> are on the standards track. >>>>>=20 >>>>> Work expected to be done by the MIP4 WG as proposed by this charter= is >>>>> as follows: >>>>>=20 >>>>> 1. MIPv4 has been a proposed standard for several years. It has bee= n >>>>> adopted by other standard development organizations and has been >>>>> deployed commercially. One of the next steps for the WG is to advan= ce >>>>> the protocol to draft standard status. As part of advancing base >>>>> Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised >>>>> to reflect implementation experience >>>>>=20 >>>>> 2. Work items that are pending from the previous Mobile IP WG, whic= h >>>>> will be completed by the MIP4 WG, are: >>>>>=20 >>>>> - completion of the MIB for the revised base Mobile IP >>>>> specification (2006bis) >>>>>=20 >>>>> - regional registration draft. >>>>>=20 >>>>> 3. The MIP4 WG will also complete the work on MIPv4 interactions >>>>> in VPN scenarios. This work will involve identifying the requiremen= ts >>>>> and a solution development for MIPv4 operation in the presence >>>>> of IPsec VPNs. >>>>>=20 >>>>> 4. Additionally, a proposal has been made for how MOBIKE could work= >>>>> together with MIPv4. This proposal does not describe any new protoc= ol, >>>>> but formulates a best current practice for deploying MOBIKE togethe= r >>>>> with MIPv4. The working group will adopt and complete this document= =2E >>>>>=20 >>>>> 5. Some issues have been raised with respect to RFC3519. These will= be >>>>> identified and addressed as appropriate, through errata, revision >>>>> of RFC 3519, and/or supplemental documents as needed. >>>>>=20 >>>>> 6. It has been proposed that the FMIP protocol, which has been >>>>> standardised for MIPv6 in the MIPSHOP working group, should also be= >>>>> published as an experimental protocol for MIPv4. A draft for this >>>>> exists. The working group will take up and carry this work forward >>>>> to publication >>>>>=20 >>>>> 7. An extension to carry generic strings in the Registration Reply >>>>> message has been proposed. The purpose is to supply supplemental >>>>> human-readable information intended to the MN user. The working >>>>> group will complete the specification and applicability statement o= f >>>>> such an extension. >>>>>=20 >>>>> 8. RADIUS attributes for MIP4. A set of RADIUS attributes has >>>>> been proposed for MIPv4. >>>>>=20 >>>>> The working group will first produce a requirements specification, >>>>> describing how the work differs from the requirements in RFC 2977 >>>>> and the functionality provided by RFC 4004 (the MIPv4 Diameter App)= =2E >>>>> The reason why this first step is required is that RFC 3127 pretty >>>>> clearly shows that full 2977 functionality can't be provided by eve= n >>>>> a considerably extended RADIUS, so we need to match the requirement= s >>>>> to what can be done within RADIUS. >>>>>=20 >>>>> Provided the requirements work finds approval with ADs and radext, >>>>> the workgroup will complete the specification of MIPv4 RADIUS >>>>> attributes, solicit feedback from the Radius Extensions WG, adjust,= >>>>> and submit this for publication. >>>>>=20 >>>>> 9. MIPv4 Extension for Configuration Options. >>>>>=20 >>>>> Several drafts have proposed extensions to help improve configurati= on >>>>> of MIPv4 clients. The latest proposal is for a general configuratio= n >>>>> option extension which could carry information such as e.g., DNS >>>>> address and DHCP server address. The working group will take on >>>>> and complete one proposal for a configuration option extension. >>>>>=20 >>>>> 10. Dual-stack Support >>>>>=20 >>>>> There have been several proposals for how to enable an IPv6 >>>>> connection over a network that supports Mobile IPv4. The >>>>> basic idea is to include an IPv6 address in the Mobile IPv4 >>>>> signaling messages. The working group will take on and complete >>>>> one proposal for IPv6 over Mobile IPv4. >>>>>=20 >>>>> Goals and Milestones: >>>>>=20 >>>>> Done AAA Keys for MIPv4 to IESG >>>>> Done MIPv4 VPN interaction problem statement to IESG >>>>> Done Low latency handover to experimental >>>>> Done Experimental MIPv4 message and extensions draft to IESG >>>>> Done Dynamic Home Agent assignment protocol solution to IESG >>>>> Done Revised MIPv4 Challenge/Response (3012bis) to IESG >>>>> Done Regional registration document to IESG >>>>> Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT WG for comm= ent >>>>> Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IES= G >>>>> May 2006 MIPv4 Mobike interaction (BCP) to the IESG >>>>> May 2006 MIPv4 VPN interaction (BCP) to the IESG >>>>> May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment >>>>> Jun 2006 Revised MIPv4 specification to IESG for Draft Std. >>>>> Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG >>>>> Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the= IESG >>>>> Sep 2006 FMIPv4 (Experimental) to the IESG >>>>> Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG >>>>> Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG >>>>> Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG >>>>> Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 --------------enig94F7B63F64FF0382F73D8E27 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEknDxeVhrtTJkXCMRAkQoAKCSjVqJEk4fFG34yvXnp0uu/IMwtACg7fCU MJaiZk6czMwAmaSxGZ/kf88= =ldRz -----END PGP SIGNATURE----- --------------enig94F7B63F64FF0382F73D8E27-- --===============0960655949== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0960655949==-- From mip6-bounces@ietf.org Fri Jun 16 05:33:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAhp-0002bA-5M; Fri, 16 Jun 2006 05:33:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAho-0002b5-6d for mip6@ietf.org; Fri, 16 Jun 2006 05:33:32 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrAhm-0007DF-B8 for mip6@ietf.org; Fri, 16 Jun 2006 05:33:32 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0Y004N858OFV@szxga01-in.huawei.com> for mip6@ietf.org; Fri, 16 Jun 2006 17:34:01 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0Y00H3I58OF5@szxga01-in.huawei.com> for mip6@ietf.org; Fri, 16 Jun 2006 17:34:00 +0800 (CST) Received: from w50392 ([10.164.45.173]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0Y00ARX58GNL@szxml03-in.huawei.com> for mip6@ietf.org; Fri, 16 Jun 2006 17:33:53 +0800 (CST) Date: Fri, 16 Jun 2006 17:32:27 +0800 From: Tom Wan Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) To: Henrik Levkowetz , Basavaraj Patil Message-id: <004401c69127$c86df800$6e2ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <449270E9.2070202@levkowetz.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Jari Arkko , Peter McCann , James Kempf , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Henrik wrote: If MIP4 is the mobility protocol available on the DS node, it should provide transport for both IPv4 and IPv6, without prejudice. ==> In some scenarios,I agree. In other scenarios, I'd like to add one opinion that sometimes one protocol will have to be over the other. So I think it is up to the scenarios. BR Tom ----- Original Message ----- From: "Henrik Levkowetz" To: "Basavaraj Patil" Cc: "Jari Arkko" ; "Peter McCann" ; "James Kempf" ; "Mobile IPv6 Mailing List" Sent: Friday, June 16, 2006 4:50 PM Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 16 10:05:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEx2-00057U-Cy; Fri, 16 Jun 2006 10:05:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrEx0-00057O-Ve for mip6@ietf.org; Fri, 16 Jun 2006 10:05:30 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrEwy-0008F9-Ih for mip6@ietf.org; Fri, 16 Jun 2006 10:05:30 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k5GE5FJJ008261; Fri, 16 Jun 2006 07:05:15 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k5GE5Dla003139; Fri, 16 Jun 2006 09:05:14 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 64378865980; Fri, 16 Jun 2006 16:05:13 +0200 (CEST) Message-ID: <4492BA98.3050403@motorola.com> Date: Fri, 16 Jun 2006 16:05:12 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04F73D@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04F73D@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Jari Arkko , Peter McCann , James Kempf , Henrik Levkowetz , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Tsirtsis, George wrote: > DSMIPv4 overlaps with DSMIPv6 as much as MIPv4 overlaps with > MIPv6....i.e., not a lot. Absolutely, MIP4 cares about v4 addresses only, maybe no overlap at all between MIP4 and MIP6. Overlap between DS-MIP6 and DS-MIP4 is different though IMHO. > The protocols do something similar but they are very different and it > makes no sense to define them in the same spec. > > - DSMIPv4 extensions are extensions to MIPv4. The spec needs to > define what a MIPv4 HA, FA and MN are supposed to do with the > extensions as wells as how the different entities discover support > for such extensions in the specific protocol. > > - DSMIPv6 extensions are extensions to MIPv6. The spec needs to > define what a MIPv6 HA and MN are supposed to do with it and all the > rest of it specifically in the context of MIPv6 protocol. I understand one MN would run either DS-MIPv6 or DS-MIPv4. But how about the HA? Would a HA run both DS-MIPv4 _and_ DS-MIPv6? If one HA wants to serve both DS-MIPv6 nodes _and_ DS-MIPv4 nodes then it would have to run both DS-MIPv6 _and_ DS-MIPv4. DS-MIPv4 does proxy ARP for the IPv4 HoA (inherits its MIP4 behaviour). DS-MIPv6 also does that proxy. There seems to be some overlap DS-MIP4 DS-MIPv6 IMHO. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 16 11:51:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGbP-0006n2-Mq; Fri, 16 Jun 2006 11:51:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGbO-0006mx-Bk for mip6@ietf.org; Fri, 16 Jun 2006 11:51:18 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrGbM-00088d-Tz for mip6@ietf.org; Fri, 16 Jun 2006 11:51:18 -0400 Message-ID: <012201c6915c$cde20bc0$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" , "Tsirtsis, George" References: <7EB20EA0938B4D42A2D82689365C9B7A04F73D@NAEX14.na.qualcomm.com> <4492BA98.3050403@motorola.com> Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) Date: Fri, 16 Jun 2006 08:52:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Jari Arkko , Peter McCann , Henrik Levkowetz , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org So I think I understand this from a technical standpoint. If a DS MN has MIP4 on it but not MIP6 and must for some reason (Wants to access something on an IPv6 networks somewhere through its MIP4 home agent? Other?) send IPv6 packets back through its home agent, it would use this extension. Is this right? But I'm having a bit of trouble believing that this is ever going to be an important deployment scenerio. Why would a DS MN have MIP4 on it and not MIP6? Is this something that 3GPP2 or some other major customer of MIP4 is asking for, or is it something the MIP4 WG wants to do to establish a kind of technical symmetry with the DS-MIP6 work? Also, presumably once the IPv6 packet gets decapsulated at the MIP4 HA, it must be sent out on an IPv6 link. So the home network must be dual stack anyway. In that case, if the home mobility service provider is offering IPv6 service, why would it not offer MIP6 also? Or maybe instead of releasing the packet directly from the MIP6 home agent, it goes to some kind of 6to4 gateway? If that's the case, then why not use one of the standard 6to4 transition mechanisms? Perhaps I'm missing some important point that motivates the necessity for this work? jak ----- Original Message ----- From: "Alexandru Petrescu" To: "Tsirtsis, George" Cc: "Henrik Levkowetz" ; "Jari Arkko" ; "Peter McCann" ; "James Kempf" ; "Mobile IPv6 Mailing List" Sent: Friday, June 16, 2006 7:05 AM Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) > Tsirtsis, George wrote: >> DSMIPv4 overlaps with DSMIPv6 as much as MIPv4 overlaps with >> MIPv6....i.e., not a lot. > > Absolutely, MIP4 cares about v4 addresses only, maybe no overlap at all > between MIP4 and MIP6. Overlap between DS-MIP6 and DS-MIP4 is different > though IMHO. > >> The protocols do something similar but they are very different and it >> makes no sense to define them in the same spec. >> >> - DSMIPv4 extensions are extensions to MIPv4. The spec needs to define >> what a MIPv4 HA, FA and MN are supposed to do with the extensions as >> wells as how the different entities discover support for such extensions >> in the specific protocol. >> >> - DSMIPv6 extensions are extensions to MIPv6. The spec needs to define >> what a MIPv6 HA and MN are supposed to do with it and all the rest of it >> specifically in the context of MIPv6 protocol. > > I understand one MN would run either DS-MIPv6 or DS-MIPv4. But how > about the HA? Would a HA run both DS-MIPv4 _and_ DS-MIPv6? > > If one HA wants to serve both DS-MIPv6 nodes _and_ DS-MIPv4 nodes then > it would have to run both DS-MIPv6 _and_ DS-MIPv4. DS-MIPv4 does proxy > ARP for the IPv4 HoA (inherits its MIP4 behaviour). DS-MIPv6 also does > that proxy. There seems to be some overlap DS-MIP4 DS-MIPv6 IMHO. > > Alex > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 16 12:05:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGp4-00080U-Oz; Fri, 16 Jun 2006 12:05:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGp3-0007vX-EU for mip6@ietf.org; Fri, 16 Jun 2006 12:05:25 -0400 Received: from otm-mgo00.iij.ad.jp ([210.138.20.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrGp1-0000ux-Rb for mip6@ietf.org; Fri, 16 Jun 2006 12:05:25 -0400 Received: OTM-MO(otm-mgo00) id k5GG5Hmp037531; Sat, 17 Jun 2006 01:05:17 +0900 (JST) Received: OTM-MIX(otm-mix01) id k5GG5HVa022588; Sat, 17 Jun 2006 01:05:17 +0900 (JST) Received: from [192.168.86.2] (h002n086.iij.ad.jp [192.168.86.2]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp) id k5GG5AE1018042 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 17 Jun 2006 01:05:14 +0900 (JST) In-Reply-To: <449253AA.7020907@tm.uka.de> References: <44861086.3090300@iprg.nokia.com> <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <44872034.9010906@azairenet.com> <448772F6.9060009@iprg.nokia.com> <449253AA.7020907@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <258D4D2C-FF32-4F1A-9513-C6FAC010485C@iijlab.net> Content-Transfer-Encoding: 7bit From: Keiichi SHIMA Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction Date: Fri, 16 Jun 2006 18:05:08 +0200 To: Christian Vogt X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mip6@ietf.org, Rajeev Koodli , Keiichi SHIMA , Vijay Devarapalli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, On 2006/06/16, at 8:46, Christian Vogt wrote: > you could also look at existing Internet protocol control blocks. > > All connections, regardless of the transport protocol they use, are > represented by an Internet PCB. That Internet PCB may link to a > separate transport-protocol-specific PCB, but that's less important > for > your needs. You can iterate through a list of all Internet PCBs and > look for the "foreign addresses" (i.e., CNs' addresses) recorded. If > the MN has an entry in its binding update list for a given foreign > address, it would have to notify that CN about the change of its home > address. In the BSD style PCB archtecture, we can check all connections using TCP, but it is difficult to check UDP connection(?)s. Because one UDP socket (= one PCB) may be used for multiple destination. I think, if we need more accurate mechanism to bind upper layers and MIP layer, maybe we need a new mechanism. --- Keiichi SHIMA IIJ Research Laboratory WIDE Project _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 16 14:07:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIjF-0002Rh-5N; Fri, 16 Jun 2006 14:07:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrIjD-0002Rc-UZ for mip6@ietf.org; Fri, 16 Jun 2006 14:07:32 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrIjC-0006Lx-GJ for mip6@ietf.org; Fri, 16 Jun 2006 14:07:31 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5GI7QF0012756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jun 2006 11:07:27 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5GI7LKd021913; Fri, 16 Jun 2006 11:07:21 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 11:07:20 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) Date: Fri, 16 Jun 2006 11:07:22 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84A1D8A9@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) Thread-Index: AcaRXy1uP98L/lIERrylNgB+SaYtsAAD9Ibw From: "Narayanan, Vidya" To: "James Kempf" , "Alexandru Petrescu" , "Tsirtsis, George" X-OriginalArrivalTime: 16 Jun 2006 18:07:20.0488 (UTC) FILETIME=[B5D83280:01C6916F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Jari Arkko , Peter McCann , Henrik Levkowetz , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org It seems like we are revisiting a lot of discussion that happened on the mip4 mailing list a couple of months ago on the same topic.=20 So, there are a couple of use cases for the DSMIP4 work as I see it:=20 1. It allows incremental IPv6 deployment in scenarios where MIP4 has already been deployed. For e.g., the clients may be moved to dual stacks, while the infrastructure is still IPv4 (which means MIP4 HAs, IPv4 AAAs, etc.).=20 2. It allows scenarios such as a MIP4 client in a cellphone, for instance, to attach to an IPv6 laptop and provide mobility for both devices. The cellphone itself only supports IPv4, while it is performing mobility for an IPv6 address that belongs to a host attached to it.=20 In both cases above, DSMIP4 fills the transition need.=20 Vidya =20 > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 > Sent: Friday, June 16, 2006 8:52 AM > To: Alexandru Petrescu; Tsirtsis, George > Cc: Jari Arkko; Peter McCann; Henrik Levkowetz; Mobile IPv6=20 > Mailing List > Subject: Re: [Mip6] FW: Internal WG Review: Recharter of=20 > Mobility forIPv4(mip4) >=20 > So I think I understand this from a technical standpoint. If=20 > a DS MN has > MIP4 on it but not MIP6 and must for some reason (Wants to=20 > access something on an IPv6 networks somewhere through its=20 > MIP4 home agent? Other?) send IPv6 packets back through its=20 > home agent, it would use this extension. Is this right? >=20 > But I'm having a bit of trouble believing that this is ever=20 > going to be an important deployment scenerio. Why would a DS=20 > MN have MIP4 on it and not MIP6? Is this something that 3GPP2=20 > or some other major customer of MIP4 is asking for, or is it=20 > something the MIP4 WG wants to do to establish a kind of=20 > technical symmetry with the DS-MIP6 work? >=20 > Also, presumably once the IPv6 packet gets decapsulated at=20 > the MIP4 HA, it must be sent out on an IPv6 link. So the home=20 > network must be dual stack anyway. In that case, if the home=20 > mobility service provider is offering IPv6 service, why would=20 > it not offer MIP6 also? Or maybe instead of releasing the=20 > packet directly from the MIP6 home agent, it goes to some=20 > kind of 6to4 gateway? If that's the case, then why not use=20 > one of the standard 6to4 transition mechanisms? >=20 > Perhaps I'm missing some important point that motivates the=20 > necessity for this work? >=20 > jak >=20 >=20 > ----- Original Message ----- > From: "Alexandru Petrescu" > To: "Tsirtsis, George" > Cc: "Henrik Levkowetz" ; "Jari Arkko"=20 > ; "Peter McCann" ;=20 > "James Kempf"=20 > ; "Mobile IPv6 Mailing List" > Sent: Friday, June 16, 2006 7:05 AM > Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for > IPv4(mip4) >=20 >=20 > > Tsirtsis, George wrote: > >> DSMIPv4 overlaps with DSMIPv6 as much as MIPv4 overlaps with=20 > >> MIPv6....i.e., not a lot. > > > > Absolutely, MIP4 cares about v4 addresses only, maybe no overlap at=20 > > all between MIP4 and MIP6. Overlap between DS-MIP6 and DS-MIP4 is=20 > > different though IMHO. > > > >> The protocols do something similar but they are very=20 > different and it =20 > >> makes no sense to define them in the same spec. > >> > >> - DSMIPv4 extensions are extensions to MIPv4. The spec needs to=20 > >> define what a MIPv4 HA, FA and MN are supposed to do with the=20 > >> extensions as wells as how the different entities discover support=20 > >> for such extensions in the specific protocol. > >> > >> - DSMIPv6 extensions are extensions to MIPv6. The spec needs to=20 > >> define what a MIPv6 HA and MN are supposed to do with it=20 > and all the=20 > >> rest of it specifically in the context of MIPv6 protocol. > > > > I understand one MN would run either DS-MIPv6 or DS-MIPv4. But how=20 > > about the HA? Would a HA run both DS-MIPv4 _and_ DS-MIPv6? > > > > If one HA wants to serve both DS-MIPv6 nodes _and_ DS-MIPv4=20 > nodes then=20 > > it would have to run both DS-MIPv6 _and_ DS-MIPv4. DS-MIPv4 does=20 > > proxy ARP for the IPv4 HoA (inherits its MIP4 behaviour). DS-MIPv6=20 > > also does that proxy. There seems to be some overlap=20 > DS-MIP4 DS-MIPv6 IMHO. > > > > Alex > > > >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 16 14:44:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrJIr-0008SN-C3; Fri, 16 Jun 2006 14:44:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrJIq-0008SI-38 for mip6@ietf.org; Fri, 16 Jun 2006 14:44:20 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrJIo-0003q6-Mk for mip6@ietf.org; Fri, 16 Jun 2006 14:44:19 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 11:44:16 -0700 Message-ID: <4492FB9F.70306@azairenet.com> Date: Fri, 16 Jun 2006 11:42:39 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) References: <2EBB8025B6D1BA41B567DB32C1D8DB84A1D8A9@NAEX06.na.qualcomm.com> In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB84A1D8A9@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2006 18:44:16.0992 (UTC) FILETIME=[DEFBDE00:01C69174] X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: Jari Arkko , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org (trimmed the cc list a bit) Narayanan, Vidya wrote: > It seems like we are revisiting a lot of discussion that happened on the > mip4 mailing list a couple of months ago on the same topic. > > So, there are a couple of use cases for the DSMIP4 work as I see it: > > 1. It allows incremental IPv6 deployment in scenarios where MIP4 has > already been deployed. For e.g., the clients may be moved to dual > stacks, while the infrastructure is still IPv4 (which means MIP4 HAs, > IPv4 AAAs, etc.). I never bought this argument on the MIP4 mailing list. there is nothing incremental about deploying IPv6 services but not being able to upgrade your HA. clients are dual stack anyway. also please expand on the "etc." > 2. It allows scenarios such as a MIP4 client in a cellphone, for > instance, to attach to an IPv6 laptop and provide mobility for both > devices. The cellphone itself only supports IPv4, while it is performing > mobility for an IPv6 address that belongs to a host attached to it. laptop supporting IPv6 but the cellphone not? come on, I dont think this is realistic. Vijay > > In both cases above, DSMIP4 fills the transition need. > > Vidya > > > >>-----Original Message----- >>From: James Kempf [mailto:kempf@docomolabs-usa.com] >>Sent: Friday, June 16, 2006 8:52 AM >>To: Alexandru Petrescu; Tsirtsis, George >>Cc: Jari Arkko; Peter McCann; Henrik Levkowetz; Mobile IPv6 >>Mailing List >>Subject: Re: [Mip6] FW: Internal WG Review: Recharter of >>Mobility forIPv4(mip4) >> >>So I think I understand this from a technical standpoint. If >>a DS MN has >>MIP4 on it but not MIP6 and must for some reason (Wants to >>access something on an IPv6 networks somewhere through its >>MIP4 home agent? Other?) send IPv6 packets back through its >>home agent, it would use this extension. Is this right? >> >>But I'm having a bit of trouble believing that this is ever >>going to be an important deployment scenerio. Why would a DS >>MN have MIP4 on it and not MIP6? Is this something that 3GPP2 >>or some other major customer of MIP4 is asking for, or is it >>something the MIP4 WG wants to do to establish a kind of >>technical symmetry with the DS-MIP6 work? >> >>Also, presumably once the IPv6 packet gets decapsulated at >>the MIP4 HA, it must be sent out on an IPv6 link. So the home >>network must be dual stack anyway. In that case, if the home >>mobility service provider is offering IPv6 service, why would >>it not offer MIP6 also? Or maybe instead of releasing the >>packet directly from the MIP6 home agent, it goes to some >>kind of 6to4 gateway? If that's the case, then why not use >>one of the standard 6to4 transition mechanisms? >> >>Perhaps I'm missing some important point that motivates the >>necessity for this work? >> >> jak >> >> >>----- Original Message ----- >>From: "Alexandru Petrescu" >>To: "Tsirtsis, George" >>Cc: "Henrik Levkowetz" ; "Jari Arkko" >>; "Peter McCann" ; >>"James Kempf" >>; "Mobile IPv6 Mailing List" >>Sent: Friday, June 16, 2006 7:05 AM >>Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for >>IPv4(mip4) >> >> >> >>>Tsirtsis, George wrote: >>> >>>>DSMIPv4 overlaps with DSMIPv6 as much as MIPv4 overlaps with >>>>MIPv6....i.e., not a lot. >>> >>>Absolutely, MIP4 cares about v4 addresses only, maybe no overlap at >>>all between MIP4 and MIP6. Overlap between DS-MIP6 and DS-MIP4 is >>>different though IMHO. >>> >>> >>>>The protocols do something similar but they are very >> >>different and it >> >>>>makes no sense to define them in the same spec. >>>> >>>>- DSMIPv4 extensions are extensions to MIPv4. The spec needs to >>>>define what a MIPv4 HA, FA and MN are supposed to do with the >>>>extensions as wells as how the different entities discover support >>>>for such extensions in the specific protocol. >>>> >>>>- DSMIPv6 extensions are extensions to MIPv6. The spec needs to >>>>define what a MIPv6 HA and MN are supposed to do with it >> >>and all the >> >>>>rest of it specifically in the context of MIPv6 protocol. >>> >>>I understand one MN would run either DS-MIPv6 or DS-MIPv4. But how >>>about the HA? Would a HA run both DS-MIPv4 _and_ DS-MIPv6? >>> >>>If one HA wants to serve both DS-MIPv6 nodes _and_ DS-MIPv4 >> >>nodes then >> >>>it would have to run both DS-MIPv6 _and_ DS-MIPv4. DS-MIPv4 does >>>proxy ARP for the IPv4 HoA (inherits its MIP4 behaviour). DS-MIPv6 >>>also does that proxy. There seems to be some overlap >> >>DS-MIP4 DS-MIPv6 IMHO. >> >>>Alex >>> >>> >> >> >> >>_______________________________________________ >>Mip6 mailing list >>Mip6@ietf.org >>https://www1.ietf.org/mailman/listinfo/mip6 >> > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 16 15:17:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrJp0-0001la-43; Fri, 16 Jun 2006 15:17:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrJoz-0001lU-5e for mip6@ietf.org; Fri, 16 Jun 2006 15:17:33 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrJox-0007Ez-SE for mip6@ietf.org; Fri, 16 Jun 2006 15:17:33 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AA1728989C; Fri, 16 Jun 2006 22:17:30 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6598389887; Fri, 16 Jun 2006 22:17:30 +0300 (EEST) Message-ID: <449303C4.2060002@kolumbus.fi> Date: Fri, 16 Jun 2006 22:17:24 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Mip6] mip6 rechartering X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org All, The chairs and I reviewed the status of the working group last week, and during that review it came apparent that some of the drafts that the group has adopted do not have a matching charter item. For instance, the charter mentions work on a problem statement for dual stack operation but the group is already working on solutions. Other examples include cn-ipsec and location-privacy-ps. There may also be items in the charter that are no longer interesting, such as a multicast problem statement. As a result, I would like to recharter you to keep what you are working on and the charter in sync. I have asked the chairs to work on proposed changes, and once we are happy with them we can discuss the details on the mailing list. Note that this is not an open season for adding new work to the charter; this rechartering focuses only on work that that the group has already taken on. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 16 21:34:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrPhs-0006Ka-Vw; Fri, 16 Jun 2006 21:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrPhr-0006F1-Tt for mip6@ietf.org; Fri, 16 Jun 2006 21:34:35 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrPhq-0004Se-Dn for mip6@ietf.org; Fri, 16 Jun 2006 21:34:35 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5H1YTPS029142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Jun 2006 18:34:30 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5H1YO05001930; Fri, 16 Jun 2006 18:34:28 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Jun 2006 18:23:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) Date: Fri, 16 Jun 2006 18:23:29 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04F814@NAEX14.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) Thread-Index: AcaRfAfqJK4Hvp0NRzS5Yvz3wMBq+gAL95NA From: "Soliman, Hesham" To: "James Kempf" , "Alexandru Petrescu" , "Tsirtsis, George" X-OriginalArrivalTime: 17 Jun 2006 01:23:32.0796 (UTC) FILETIME=[A5C177C0:01C691AC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Jari Arkko , Peter McCann , Henrik Levkowetz , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > So I think I understand this from a technical standpoint. If=20 > a DS MN has=20 > MIP4 on it but not MIP6 and must for some reason (Wants to=20 > access something=20 > on an IPv6 networks somewhere through its MIP4 home agent?=20 > Other?) send IPv6=20 > packets back through its home agent, it would use this=20 > extension. Is this=20 > right? =3D> Correct. >=20 > But I'm having a bit of trouble believing that this is ever=20 > going to be an=20 > important deployment scenerio. Why would a DS MN have MIP4=20 > on it and not=20 > MIP6?=20 =3D> Because MIPv4 already exists and is already deployed. So if you are running MIPv4 on a device then one day you upgrade that device with ipv6.exe or your favourite name for you OS you end up with a dual stack node that already has MIPv4 on it.=20 So what do you do when the implementation follows RFC 2893 and gets both IPv6 and=20 IPv4 addresses for the CN from the DNS and it chooses IPv6? Do you go with IPv6 without=20 mobility or do you change the implementation and break the RFC? Is this something that 3GPP2 or some other major=20 > customer of MIP4 is=20 > asking for, or is it something the MIP4 WG wants to do to=20 > establish a kind=20 > of technical symmetry with the DS-MIP6 work? =3D> Regardless of the PP that wants it, the scenario is feasible isn't it? I don't know what PP/2 wants, but I've seen customers that like this. >=20 > Also, presumably once the IPv6 packet gets decapsulated at=20 > the MIP4 HA, it=20 > must be sent out on an IPv6 link. So the home network must=20 > be dual stack=20 > anyway. In that case, if the home mobility service provider=20 > is offering IPv6=20 > service, why would it not offer MIP6 also?=20 =3D> Because you can turn on IPv6 in most products now without trouble, but the same=20 can't be said for MIPv6. Also, even if you turn on MIPv6, how do you upgrade all MNs? Do we want to force an operator to upgrade all MNs instantly to support v6? Hesham >=20 > ----- Original Message -----=20 > From: "Alexandru Petrescu" > To: "Tsirtsis, George" > Cc: "Henrik Levkowetz" ; "Jari Arkko"=20 > ; "Peter McCann" ;=20 > "James Kempf"=20 > ; "Mobile IPv6 Mailing List"=20 > > Sent: Friday, June 16, 2006 7:05 AM > Subject: Re: [Mip6] FW: Internal WG Review: Recharter of=20 > Mobility for=20 > IPv4(mip4) >=20 >=20 > > Tsirtsis, George wrote: > >> DSMIPv4 overlaps with DSMIPv6 as much as MIPv4 overlaps with=20 > >> MIPv6....i.e., not a lot. > > > > Absolutely, MIP4 cares about v4 addresses only, maybe no=20 > overlap at all > > between MIP4 and MIP6. Overlap between DS-MIP6 and=20 > DS-MIP4 is different > > though IMHO. > > > >> The protocols do something similar but they are very=20 > different and it > >> makes no sense to define them in the same spec. > >> > >> - DSMIPv4 extensions are extensions to MIPv4. The spec=20 > needs to define=20 > >> what a MIPv4 HA, FA and MN are supposed to do with the=20 > extensions as=20 > >> wells as how the different entities discover support for=20 > such extensions=20 > >> in the specific protocol. > >> > >> - DSMIPv6 extensions are extensions to MIPv6. The spec=20 > needs to define=20 > >> what a MIPv6 HA and MN are supposed to do with it and all=20 > the rest of it=20 > >> specifically in the context of MIPv6 protocol. > > > > I understand one MN would run either DS-MIPv6 or DS-MIPv4. But how > > about the HA? Would a HA run both DS-MIPv4 _and_ DS-MIPv6? > > > > If one HA wants to serve both DS-MIPv6 nodes _and_=20 > DS-MIPv4 nodes then > > it would have to run both DS-MIPv6 _and_ DS-MIPv4. =20 > DS-MIPv4 does proxy=20 > > ARP for the IPv4 HoA (inherits its MIP4 behaviour). =20 > DS-MIPv6 also does=20 > > that proxy. There seems to be some overlap DS-MIP4 DS-MIPv6 IMHO. > > > > Alex > > > >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Jun 17 10:50:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frc7v-0003QR-MI; Sat, 17 Jun 2006 10:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frc7u-0003Lf-9a for mip6@ietf.org; Sat, 17 Jun 2006 10:50:18 -0400 Received: from [2001:660:7301:3192:211:43ff:fea3:7e4b] (helo=laposte.rennes.enst-bretagne.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Frc7s-0005Em-LZ for mip6@ietf.org; Sat, 17 Jun 2006 10:50:18 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k5HEoDAQ021889; Sat, 17 Jun 2006 16:50:13 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k5HEoBxK021880; Sat, 17 Jun 2006 16:50:11 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k5HEo9wN075640; Sat, 17 Jun 2006 16:50:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200606171450.k5HEo9wN075640@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko Subject: Re: [Mip6] mip6 rechartering In-reply-to: Your message of Fri, 16 Jun 2006 22:17:24 +0300. <449303C4.2060002@kolumbus.fi> Date: Sat, 17 Jun 2006 16:50:09 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: Other examples include cn-ipsec... => I know that everything is a matter of taste but IMHO the cn-ipsec draft is just a (second) example of this charter item: - Route optimization will require security mechanisms for trusting and updating the binding information.Return-routability is the basic mechanism for route-optimization. Mechanisms using a shared secret Key/Security Association will be considered. ^^^^^^^^^^^^^^^^^^^^ Methods for establishing a security association between the mobile node and the correspondent node are out of the scope of the WG. Regards Francis.Dupont@point6.net _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Jun 17 12:50:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frdzl-0005Ws-4O; Sat, 17 Jun 2006 12:50:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frdzj-0005Wj-C4 for mip6@ietf.org; Sat, 17 Jun 2006 12:49:59 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Frdzi-0002OK-33 for mip6@ietf.org; Sat, 17 Jun 2006 12:49:59 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5HGndRt017769; Sat, 17 Jun 2006 09:49:43 -0700 (MST) Received: from [10.129.40.9] ([10.129.40.9]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k5HGna5I029241; Sat, 17 Jun 2006 11:49:37 -0500 (CDT) Message-ID: <4494329F.6040608@motorola.com> Date: Sat, 17 Jun 2006 18:49:35 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Jari Arkko , Peter McCann , James Kempf , Levkowetz , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Please allow me to express related points of view. Basavaraj Patil wrote: > Henrik, > > In the DS-MIP6 case the reasoning for the work has been that IPv6 > native access is not expected to be ubiquitous and hence given that > the host is DS and access is IPv4, there is a need to enable MIP6 > continuity while being attached to a v4 network. I agree. > The ability to carry IPv4 within the MIP6 session Not sure whether you think DS-MIPv6 here... I guess so. DS-MIPv6 carries IPv4 addresses in MIP6 messaging, and MIP6 messages in IPv4 messages. > is to enable applications and services that are v4 based on the hosts > This is wrong IMHO. DS-MIPv6 should only care about IPv6 applications, not about IPv4 applications. > and is applicable in the scenario when the host is connected to a > native v6 access only (which I guess we believe will be the situation > at some point in the future). So I believe there is a good reason to > do this for MIP6. Again, I disagree MIP6 extensions should care about serving IPv4 applications. They should only care about IPv6 apps, and only when the access is IPv4. > In the case of IPv4 hosts which are DS and MIP4 enabled, I do not > think that you have to contend with the fact that you have to deal > with a v6 access only. It is very reasonable to believe that IPv6 networks will simultaneously support IPv4, especially in the access part, and at least in the very near future. I share this view. However, protocol development in IETF may happen such that some networks risk to be only IPv6, not IPv4. For example, recently in the NEMO WG there seemed to be a strong pushback on development of NEMOv4 (simple extensions to Mobile IPv4 to support network mobility). I.e. moving networks would be only IPv6 networks. In this case, a MIPv4 MN wishing to visit such a network would need IPv6 extensions to MIP4 to be able to connect to it. > Secondly if the v6 stack on the host needs to connect to a v6 router, > it could just as well use a standard transition mechanism. Completely agree. Moreover, this applies to DS-MIPv6. If the host runs MIP6, connects to an IPv4 access and needs to talk to its IPv6 HA it is sufficient to use a standard transition mechanism. That could be the MIP4 NAT Traversal part, or 6to4 or Teredo or IKE or even STUN. 6to4 can't easily be used behind NAT. MIP4 NAT Traversal, Teredo, IKE and STUN can. All three use UDP encapsulation. (All three have some issues with some NATs but that's another point.) > So having IPv6 packets carried over a MIP4 session IMO is not really > a critical need. If there is a belief that a MIP4 based transition > mechanism for IPv6 is needed, then fine. I believe there is a much more critical need for work on MIP4 extensions to support IPv6 than is for DS-MIPv6. There are much more deployed MIP4 nodes than MIP6 nodes. Many deployers are faced with a migration problem, from IPv4 to IPv6. Very few lucky have the luxury to start with a clean slate network and end nodes. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Jun 17 17:03:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrhxJ-0003So-Kc; Sat, 17 Jun 2006 17:03:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrhxH-0003Rr-Nl for mip6@ietf.org; Sat, 17 Jun 2006 17:03:43 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrhxG-00019x-Ey for mip6@ietf.org; Sat, 17 Jun 2006 17:03:43 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EB5B38989C; Sun, 18 Jun 2006 00:03:40 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A706F8988E; Sun, 18 Jun 2006 00:03:40 +0300 (EEST) Message-ID: <44946E25.6030202@kolumbus.fi> Date: Sun, 18 Jun 2006 00:03:33 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mip6] mip6 rechartering References: <200606171450.k5HEo9wN075640@givry.rennes.enst-bretagne.fr> In-Reply-To: <200606171450.k5HEo9wN075640@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Francis Dupont wrote: > In your previous mail you wrote: > > Other examples include cn-ipsec... > >=> I know that everything is a matter of taste but IMHO the cn-ipsec >draft is just a (second) example of this charter item: > > Perhaps, or perhaps not. But either way, it would be great if the charter actually specified clearly what it means. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jun 18 22:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs9lr-0000sq-TB; Sun, 18 Jun 2006 22:45:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs9lq-0000sl-Ta for mip6@ietf.org; Sun, 18 Jun 2006 22:45:46 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fs9lp-0007VO-Cr for mip6@ietf.org; Sun, 18 Jun 2006 22:45:46 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1300DY871FJ1@szxga02-in.huawei.com> for mip6@ietf.org; Mon, 19 Jun 2006 11:00:51 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J130028Q71EGP@szxga02-in.huawei.com> for mip6@ietf.org; Mon, 19 Jun 2006 11:00:51 +0800 (CST) Received: from w50392 ([10.164.45.222]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1300AJP6DBUE@szxml03-in.huawei.com> for mip6@ietf.org; Mon, 19 Jun 2006 10:46:24 +0800 (CST) Date: Mon, 19 Jun 2006 10:44:51 +0800 From: Tom Wan Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) To: Alexandru Petrescu , Basavaraj Patil Message-id: <002d01c6934a$573f7f80$6e2ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4494329F.6040608@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: Jari Arkko , Peter McCann , James Kempf , Levkowetz , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > It is very reasonable to believe that IPv6 networks will simultaneously > support IPv4, especially in the access part, and at least in the very > near future. I share this view. ===> I think it is only a wish. I hope IPv6 networks should simultaneously support IPv4 too. But In some conditions, it may be impossible, because many countries have no enough ipv4 addresses. They can not assign every MN an ipv4 home address. So the most important point is that MN may have no stable ipv4 home address. > Not sure whether you think DS-MIPv6 here... I guess so. DS-MIPv6 > carries IPv4 addresses in MIP6 messaging, and MIP6 messages in > IPv4 messages. > >> is to enable applications and services that are v4 based on the hosts >> > This is wrong IMHO. DS-MIPv6 should only care about IPv6 applications, > not about IPv4 applications. > ===> I'd like to emphasize this point. I think that the two protocols(ipv4/ipv6) have two usages: one is for routing and the other is for application. The routing usage is mainly implemanted on routers and the application usage is implemanted on the mobile node. As mobile ip is a network layer solution, we should focuse on the routing usage. I think the application usage is out of scope of mobile ip. In addition, after we solve the routing problem. application layer usage is not a problem. > Completely agree. Moreover, this applies to DS-MIPv6. If the host runs > MIP6, connects to an IPv4 access and needs to talk to its IPv6 HA it is > sufficient to use a standard transition mechanism. That could be the > MIP4 NAT Traversal part, or 6to4 or Teredo or IKE or even STUN. 6to4 > can't easily be used behind NAT. MIP4 NAT Traversal, Teredo, IKE and > STUN can. All three use UDP encapsulation. (All three have some issues > with some NATs but that's another point.) > >> So having IPv6 packets carried over a MIP4 session IMO is not really >> a critical need. If there is a belief that a MIP4 based transition >> mechanism for IPv6 is needed, then fine. ===> Standard transiton mechanism is only one direction. there are two directions of solutions. One is based on the v4/v6 interaction solutions. The other is based on the mip4/mip6 protocol. I think mip4/mip6 protocol is enough for v4/v6. If we use NAT/PT method, many folks will criticize it. Currently, few venders dear to use NAT/PT solution, it will cause many problems. So I think ipv6 over ipv4 is necessary. In the ipv6 WG, there are two kinds of solutions on the v4/v6 interaction topic. One is based on NAT/PT, the other is based on the tunneling mechanisms. They both work. IMO, I think we can consider a solution. The solution is based on tunneling mechanism and it will not do much impact to the mip4/mip6 protocols. This is one requirement. ----- Original Message ----- From: "Alexandru Petrescu" To: "Basavaraj Patil" Cc: "Jari Arkko" ; "Peter McCann" ; "James Kempf" ; "Levkowetz" ; "Mobile IPv6 Mailing List" Sent: Sunday, June 18, 2006 12:49 AM Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) > Please allow me to express related points of view. > > Basavaraj Patil wrote: >> Henrik, >> >> In the DS-MIP6 case the reasoning for the work has been that IPv6 native >> access is not expected to be ubiquitous and hence given that the host is >> DS and access is IPv4, there is a need to enable MIP6 continuity while >> being attached to a v4 network. > > I agree. > >> The ability to carry IPv4 within the MIP6 session > > Not sure whether you think DS-MIPv6 here... I guess so. DS-MIPv6 > carries IPv4 addresses in MIP6 messaging, and MIP6 messages in > IPv4 messages. > >> is to enable applications and services that are v4 based on the hosts >> > This is wrong IMHO. DS-MIPv6 should only care about IPv6 applications, > not about IPv4 applications. > >> and is applicable in the scenario when the host is connected to a native >> v6 access only (which I guess we believe will be the situation >> at some point in the future). So I believe there is a good reason to >> do this for MIP6. > > Again, I disagree MIP6 extensions should care about serving IPv4 > applications. They should only care about IPv6 apps, and only when the > access is IPv4. > >> In the case of IPv4 hosts which are DS and MIP4 enabled, I do not think >> that you have to contend with the fact that you have to deal with a v6 >> access only. > > It is very reasonable to believe that IPv6 networks will simultaneously > support IPv4, especially in the access part, and at least in the very > near future. I share this view. > > However, protocol development in IETF may happen such that some > networks risk to be only IPv6, not IPv4. For example, recently in the > NEMO WG there seemed to be a strong pushback on development of NEMOv4 > (simple extensions to Mobile IPv4 to support network mobility). I.e. > moving networks would be only IPv6 networks. In this case, a MIPv4 MN > wishing to visit such a network would need IPv6 extensions to MIP4 to be > able to connect to it. > >> Secondly if the v6 stack on the host needs to connect to a v6 router, >> it could just as well use a standard transition mechanism. > > Completely agree. Moreover, this applies to DS-MIPv6. If the host runs > MIP6, connects to an IPv4 access and needs to talk to its IPv6 HA it is > sufficient to use a standard transition mechanism. That could be the > MIP4 NAT Traversal part, or 6to4 or Teredo or IKE or even STUN. 6to4 > can't easily be used behind NAT. MIP4 NAT Traversal, Teredo, IKE and > STUN can. All three use UDP encapsulation. (All three have some issues > with some NATs but that's another point.) > >> So having IPv6 packets carried over a MIP4 session IMO is not really >> a critical need. If there is a belief that a MIP4 based transition >> mechanism for IPv6 is needed, then fine. > > I believe there is a much more critical need for work on MIP4 extensions > to support IPv6 than is for DS-MIPv6. There are much more deployed MIP4 > nodes than MIP6 nodes. Many deployers are faced with a migration > problem, from IPv4 to IPv6. Very few lucky have the luxury to start > with a clean slate network and end nodes. > > Alex > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jun 18 23:10:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsA9m-0004B0-PC; Sun, 18 Jun 2006 23:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsA9k-0004Ap-RW for mip6@ietf.org; Sun, 18 Jun 2006 23:10:28 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsA9X-0000jh-7i for mip6@ietf.org; Sun, 18 Jun 2006 23:10:28 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1300IBI7I94F@szxga01-in.huawei.com> for mip6@ietf.org; Mon, 19 Jun 2006 11:10:58 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1300BKF7I91D@szxga01-in.huawei.com> for mip6@ietf.org; Mon, 19 Jun 2006 11:10:57 +0800 (CST) Received: from w50392 ([10.164.45.222]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1300AO17I2UE@szxml03-in.huawei.com> for mip6@ietf.org; Mon, 19 Jun 2006 11:10:51 +0800 (CST) Date: Mon, 19 Jun 2006 11:09:19 +0800 From: Tom Wan Subject: Re: [Mip6] mip6 rechartering To: Jari Arkko , mip6@ietf.org Message-id: <00a601c6934d$c1d4a020$6e2ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <449303C4.2060002@kolumbus.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org All: I hope you can review my draft. It focuses on the problem statement and scenario analysis. http://www.ietf.org/internet-drafts/draft-wan-mip6-nemo-dsanalysis-00.txt BR Tom ----- Original Message ----- From: "Jari Arkko" To: Sent: Saturday, June 17, 2006 3:17 AM Subject: [Mip6] mip6 rechartering > > All, > > The chairs and I reviewed the status of the working group > last week, and during that review it came apparent that > some of the drafts that the group has adopted do not > have a matching charter item. For instance, the charter > mentions work on a problem statement for dual > stack operation but the group is already working on > solutions. Other examples include cn-ipsec and > location-privacy-ps. There may also be items in the > charter that are no longer interesting, such as a > multicast problem statement. > > As a result, I would like to recharter you to keep what > you are working on and the charter in sync. I have > asked the chairs to work on proposed changes, and > once we are happy with them we can discuss the > details on the mailing list. Note that this is not an > open season for adding new work to the charter; > this rechartering focuses only on work that that > the group has already taken on. > > Jari > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jun 18 23:13:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsACJ-0004fm-Li; Sun, 18 Jun 2006 23:13:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsACJ-0004fe-6L for mip6@ietf.org; Sun, 18 Jun 2006 23:13:07 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsACH-0001AC-Og for mip6@ietf.org; Sun, 18 Jun 2006 23:13:07 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1300IB07N44F@szxga01-in.huawei.com> for mip6@ietf.org; Mon, 19 Jun 2006 11:13:52 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1300BPB7N31D@szxga01-in.huawei.com> for mip6@ietf.org; Mon, 19 Jun 2006 11:13:52 +0800 (CST) Received: from w50392 ([10.164.45.222]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J130025V826BY@szxml04-in.huawei.com> for mip6@ietf.org; Mon, 19 Jun 2006 11:22:56 +0800 (CST) Date: Mon, 19 Jun 2006 11:12:12 +0800 From: Tom Wan Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) To: Alexandru Petrescu , Basavaraj Patil Message-id: <00ae01c6934e$29625480$6e2ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4494329F.6040608@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Jari Arkko , Peter McCann , James Kempf , Levkowetz , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, all: I think your discussion is related to my drafts: http://www.ietf.org/internet-drafts/draft-wan-mip6-nemo-dsanalysis-00.txt http://www.ietf.org/internet-drafts/draft-wan-mip6-nemo-routing-00.txt I hope you can review and discuss them. BR Tom ----- Original Message ----- From: "Alexandru Petrescu" To: "Basavaraj Patil" Cc: "Jari Arkko" ; "Peter McCann" ; "James Kempf" ; "Levkowetz" ; "Mobile IPv6 Mailing List" Sent: Sunday, June 18, 2006 12:49 AM Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) > Please allow me to express related points of view. > > Basavaraj Patil wrote: >> Henrik, >> >> In the DS-MIP6 case the reasoning for the work has been that IPv6 native >> access is not expected to be ubiquitous and hence given that the host is >> DS and access is IPv4, there is a need to enable MIP6 continuity while >> being attached to a v4 network. > > I agree. > >> The ability to carry IPv4 within the MIP6 session > > Not sure whether you think DS-MIPv6 here... I guess so. DS-MIPv6 > carries IPv4 addresses in MIP6 messaging, and MIP6 messages in > IPv4 messages. > >> is to enable applications and services that are v4 based on the hosts >> > This is wrong IMHO. DS-MIPv6 should only care about IPv6 applications, > not about IPv4 applications. > >> and is applicable in the scenario when the host is connected to a native >> v6 access only (which I guess we believe will be the situation >> at some point in the future). So I believe there is a good reason to >> do this for MIP6. > > Again, I disagree MIP6 extensions should care about serving IPv4 > applications. They should only care about IPv6 apps, and only when the > access is IPv4. > >> In the case of IPv4 hosts which are DS and MIP4 enabled, I do not think >> that you have to contend with the fact that you have to deal with a v6 >> access only. > > It is very reasonable to believe that IPv6 networks will simultaneously > support IPv4, especially in the access part, and at least in the very > near future. I share this view. > > However, protocol development in IETF may happen such that some > networks risk to be only IPv6, not IPv4. For example, recently in the > NEMO WG there seemed to be a strong pushback on development of NEMOv4 > (simple extensions to Mobile IPv4 to support network mobility). I.e. > moving networks would be only IPv6 networks. In this case, a MIPv4 MN > wishing to visit such a network would need IPv6 extensions to MIP4 to be > able to connect to it. > >> Secondly if the v6 stack on the host needs to connect to a v6 router, >> it could just as well use a standard transition mechanism. > > Completely agree. Moreover, this applies to DS-MIPv6. If the host runs > MIP6, connects to an IPv4 access and needs to talk to its IPv6 HA it is > sufficient to use a standard transition mechanism. That could be the > MIP4 NAT Traversal part, or 6to4 or Teredo or IKE or even STUN. 6to4 > can't easily be used behind NAT. MIP4 NAT Traversal, Teredo, IKE and > STUN can. All three use UDP encapsulation. (All three have some issues > with some NATs but that's another point.) > >> So having IPv6 packets carried over a MIP4 session IMO is not really >> a critical need. If there is a belief that a MIP4 based transition >> mechanism for IPv6 is needed, then fine. > > I believe there is a much more critical need for work on MIP4 extensions > to support IPv6 than is for DS-MIPv6. There are much more deployed MIP4 > nodes than MIP6 nodes. Many deployers are faced with a migration > problem, from IPv4 to IPv6. Very few lucky have the luxury to start > with a clean slate network and end nodes. > > Alex > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 03:14:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsDxK-0001kd-VQ; Mon, 19 Jun 2006 03:13:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsDxH-0001ah-LJ for mip6@ietf.org; Mon, 19 Jun 2006 03:13:51 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsDlF-00046T-Sx for mip6@ietf.org; Mon, 19 Jun 2006 03:01:26 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 465591FAC23; Mon, 19 Jun 2006 09:01:25 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22545-01-27; Mon, 19 Jun 2006 09:01:24 +0200 (CEST) Received: from [192.168.1.33] (216.Red-83-33-34.dynamicIP.rima-tde.net [83.33.34.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id ADD2D1FAC86; Mon, 19 Jun 2006 09:01:19 +0200 (CEST) Message-ID: <44964BBF.9040403@dif.um.es> Date: Mon, 19 Jun 2006 09:01:19 +0200 From: "Pedro M. Ruiz" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Subject: [Mip6] CFP LOCAN 2006: 2nd Int'l Workshop on Localized Communications and Topology Control for Ad Hoc Networks X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Due to several requests, we decided to extend the submission deadline to June 26th. Please, find the reviesed CFP below. We apologize for any possible cross-posting. --------------------------------------------------------------------------- CALL FOR PAPERS - LOCAN 2006 2nd International Workshop on Localized Communication and Topology Protocols for Ad hoc Networks in conjunction with MASS-2006 (www.ieee-mass.org) Vancouver, Canada, October 9 - 12, 2006 --------------------------------------------------------------------------- SUBJECT AND SCOPE ----------------- This workshop covers comprehensively the algorithmic issues in the hot area of ad hoc and sensor networking. The design of data communication techniques in multi-hop ad hoc networks has challenges at all layers of communication. This workshop concentrates on the network layer problems like data communication (routing, QoS-routing, geocasting, multicasting, broadcasting, etc.) and topology control (neighbor discovery, power adjustment, neighbor elimination, etc.). Additionally, sensor networks are currently recognized as one of the priority research areas by NSF. The area of sensor networking is gaining momentum within the research community. This workshop will address ongoing research on this field, including problems such as: physical properties, sensor training, security through intelligent node cooperation, medium access, sensor area coverage with random and deterministic placement, object location, sensor position determination, energy efficient broadcasting and activity scheduling, routing, connectivity, data dissemination and gathering, sensor centric quality of routing, temporal message ordering, path exposure, tree reconfiguration, topology construction, and transport layer. The main paradigm shift is to apply localized (or greedy) schemes as opposed to existing protocols requiring global information. Localized algorithms are distributed algorithms where simple local node behaviour achieves a desired global objective. Localized protocols provide scalable solutions, that is, solutions for wireless networks with an arbitrary number of nodes, which is the main goal of this plan. Sensor and rooftop/mesh networks, for instance, have hundreds or thousands of nodes. The main objective of the workshop is to present state of the art research results on data communication and topology control in rapidly growing area of ad hoc and sensor networks, with emphasizes on localized techniques. Topics of interest include, but are not limited to: * Medium access control * Analytical, mobility and validation models for ad hoc networks * Hybrid networks and wireless Internet * Security in ad hoc networks * Data management issues, query processing, and data delivery * Routing, broadcasting and multicasting in ad hoc networks * Energy-efficient protocols for ad hoc networks * Quality of service in medium access control and routing * Topology construction and maintenance in ad hoc networks * Neighborhood discovery and mobility management IMPORTANT DATES --------------- Manuscript Submission: June 26, 2006 Acceptance Notification: July 19, 2006 Final Manuscript Due: August 10, 2006 PAPER SUBMISSION ---------------- Papers must not exceed 10 single-spaced and two-column pages using at least 10 point size type on 8.5 x 11 inches pages. See style files, author guidelines and instructions at the conference website. Accepted papers will be published by IEEE Computer Society Press, as proceedings of the MASS2006 workshops. Please submit papers via email to both program co-chairs (pedrom@dif.um.es, fei.dai@ndsu.edu). GENERAL CO-CHAIRS ----------------- David Simplot-Ryl, University of Lille, France Ivan Stojmenovic, University of Ottawa, Canada PROGRAM CO-CHAIRS ----------------- Pedro M. Ruiz, University of Murcia, Spain Fei Dai, North Dakota State University, USA Program Committee ----------------- Michel Barbeau, Carleton University, Ottawa, Canada Raffaele Bruno, IIT-CNR, Italy Ian Chakeres, Boeing Inc., USA Misha Dohler, France Telecom R&D, France Stefan Dulman, University of Twente, Netherlands Jie Gao, State University of New York, USA J. J. Garcia-Luna-Aceves, Univ. of California, Santa Cruz, USA Silvia Giordano, University of Applied Science, SUPSI, Switzerland Antonio F. Gomez-Skarmeta, University of Murcia, Spain Isabelle Guerin Lassous, INRIA Rhone Alpes, France Mattias Handy, Univ. Rostock, Germany Thomas Kunz, Carleton University, Canada Miguel A. Labrador, Univ. South Florida, USA Pietro Manzoni, Univ. Politecnica de Valencia, Spain Luis Orozco, Univ. Castilla La Mancha, Spain Josep Paradells, Technical University of Catalonia (UPC), Spain S. S. Ravi, State University of New York at Albany, USA Isabelle Simplot-Ryl, University of Lille, France ADDITIONAL INFORMATION ---------------------- Additional information about the workshop will be continuously updated at the LOCAN 2006 website. http://ants.dif.um.es/locan2006/ -- --------------------------------------------------------------------- Pedro M. Ruiz, Ph.D. E-mail: pedrom@dif.um.es Fac. Informatica, Univ. of Murcia Phone: +34968364335 Campus de Espinardo s/n Fax: +34968364151 E-30100, Espinardo, Murcia www: ants.dif.um.es/~pedrom/ SPAIN --------------------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 03:39:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsEM1-0005en-4w; Mon, 19 Jun 2006 03:39:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsELz-0005ed-Ge for mip6@ietf.org; Mon, 19 Jun 2006 03:39:23 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsEL3-0006kj-Kf for mip6@ietf.org; Mon, 19 Jun 2006 03:39:23 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 0728A4C057; Mon, 19 Jun 2006 16:38:21 +0900 (JST) Date: Mon, 19 Jun 2006 10:38:19 +0300 From: Shinta Sugimoto To: Rajeev Koodli Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction In-Reply-To: <44870922.3040408@iprg.nokia.com> References: <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> Message-Id: <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: mip6@ietf.org, Vijay Devarapalli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Rajeev, I am catching up on this thread. Please find my comments inline. On Wed, 07 Jun 2006 10:13:06 -0700 Rajeev Koodli wrote: > Vijay Devarapalli wrote: > > > Rajeev Koodli wrote: > > > >> If a MN wishes to change its HoA with a CN (e.g., use a different > >> pseudo-hoa for > >> privacy purposes), it has no _reliable_ way of knowing whether it has > >> existing sessions with that CN. > > > > > > I read this paragraph three times, but couldn't get > > the context. > > > > if in the privacy context, I assume there is still > > a *real* HoA. the pseudo HoA appears in the route > > optimized traffic to the CN *instead* of the real > > HoA. the CN knows the real HoA and the pseudo HoA. > > the mapping from the real HoA to the pseudo HoA is > > done using the binding update list at the MN and > > the binding cache entry at the CN. > > > This is a way to do it. Nevertheless, keeping the privacy issue aside.. > > > if not for privacy, perhaps the mobile node shouldn't > > change its HoA abruptly, but let existing sessions > > continue with the existing HoA and use the new HoA > > for new sessions. the mobile node would also have > > to update the DNS entry if it wants its FQDN to > > resolve to the new HoA. > > > The problem here is how does the MN know to "let the > existing sessions continue with the existing HoA"? If there is no CN's > address in BUL, surely the MN can choose a suitable HoA. For > a CN with which it has a binding, it has no reliable way of knowing > whether there are any ULP sessions. If you need to maintain the sessions while changing the HoA from one to another, I think you need additional mechanism than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed to assure the reachability to a given HoA with the current location of the mobile node (CoA). If the app wants to change HoAs for some reason (I assume that privacy is the main interest), there is a need to maintain the mapping of the identity and the locator of the mobile node. One option would be to run Shim6 over MIPv6. Such usage has already been discussed in Shim6 WG. By mobile node establishing Shim6 context with its HA/CN, it could utilize multiple HoAs without annoying upper layer protocols. However, I am not sure if it fulfills your requirement especially in terms of privacy (hiding the identity, which is MN's HoA in this case). Would you see any problem with this approach ? I see that signaling overhead may also be a concern (to run both Shim6 and MIPv6). I have some additional questions: - If privacy is the main concern, would you think http://www.ietf.org/internet-drafts/draft-dupont-mip6-privacyext-03.txt would help to solve your initial requirement ? If not, could you please tell me why ? - Do you assume that different HoAs that mobile node may request are derived from different home prefixes ? Or are you considering that the node generates HoAs from a single prefix with privacy extension ? Regards, Shinta _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 04:50:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsFT9-0006hl-D3; Mon, 19 Jun 2006 04:50:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsFT7-0006hT-Kh; Mon, 19 Jun 2006 04:50:49 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsFT5-0006x9-3x; Mon, 19 Jun 2006 04:50:49 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 42E9F23CCA5; Mon, 19 Jun 2006 10:50:46 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31754-01; Mon, 19 Jun 2006 10:50:44 +0200 (CEST) Received: from [155.54.205.190] (inf-205-190.um.es [155.54.205.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id E452023CAF6; Mon, 19 Jun 2006 10:50:43 +0200 (CEST) Message-ID: <44966564.8000304@dif.um.es> Date: Mon, 19 Jun 2006 10:50:44 +0200 From: "Pedro M. Ruiz" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: 'IETF Manet' , tccc@cs.columbia.edu, ahsntc@bbcr.uwaterloo.ca, mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Subject: [Mip6] Call for Demos: IEEE MASS 2006 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org CALL FOR DEMOS IEEE Mobile Ad-hoc and Sensor Systems (MASS) 2006 October 9-12, 2006, Vancouver, Canada http://www.cse.fau.edu/mass2006/ Sponsored by: IEEE, Air Force, and NSF Technical demonstrations showing innovative and original research are solicited. In general this conference is interested in demonstrations of technology that validate important research issues or showcase realistic applications in mobile ad-hoc systems and sensor networks. Specific topics of interest include (but are not limited to) the following: * Network protocols for mobile ad-hoc/sensor networks * Operating system and middleware for mobile ad-hoc/sensor networks * Network testbed measurements and benchmarks * Distributed algorithms for energy/topology management, in mobile ad-hoc/sensor networks * Localization in time and space * Novel hardware and software platforms * Simulation and optimization tools * Security and robustness in mobile ad-hoc/sensor networks * Programming and validation methodology * Application of mobile ad-hoc/sensor networks in health care * Social and business impacts of mobile ad-hoc/sensor networks * Novel network architectures All the demos that are selected will be included in the conference proceedings in the form of 4-page short papers. Please consult the technical co-chair, Jennifer Hou, at jhou@cs.uiuc.edu, if you are uncertain whether your demo falls within the scope of the conference. DEMO SUBMISSION INSTRUCTIONS Please send a one-page description of your demo to jhou@cs.uiuc.edu in plain text or PDF format by the dates listed below. Be as specific as possible in describing what you will show. (Plain text is preferred unless there are graphics.) IMPORTANT DATES One-page demo descriptions: July 1, 2006 Notification of acceptance: July 20, 2006 Camera-ready manuscript: August 10, 2006 Conference dates: October 9-12, 2006 -- --------------------------------------------------------------------- Pedro M. Ruiz, Ph.D. E-mail: pedrom@dif.um.es Fac. Informatica, Univ. of Murcia Phone: +34968364335 Campus de Espinardo s/n Fax: +34968364151 E-30100, Espinardo, Murcia www: ants.dif.um.es/~pedrom/ SPAIN --------------------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 04:57:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsFZP-0001KZ-P7; Mon, 19 Jun 2006 04:57:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsFZO-0001KK-3K; Mon, 19 Jun 2006 04:57:18 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsFZM-0000ow-74; Mon, 19 Jun 2006 04:57:18 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 9EABB23CB9B; Mon, 19 Jun 2006 10:57:15 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32124-01-13; Mon, 19 Jun 2006 10:57:12 +0200 (CEST) Received: from [155.54.205.190] (inf-205-190.um.es [155.54.205.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id 76C2D23C9EC; Mon, 19 Jun 2006 10:57:12 +0200 (CEST) Message-ID: <449666E9.9090204@dif.um.es> Date: Mon, 19 Jun 2006 10:57:13 +0200 From: "Pedro M. Ruiz" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org, 'IETF Manet' Content-Type: multipart/mixed; boundary="------------000407030200070804030609" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: Subject: [Mip6] Call for participation AD HOC NOW 2006 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --------------000407030200070804030609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -- --------------------------------------------------------------------- Pedro M. Ruiz, Ph.D. E-mail: pedrom@dif.um.es Fac. Informatica, Univ. of Murcia Phone: +34968364335 Campus de Espinardo s/n Fax: +34968364151 E-30100, Espinardo, Murcia www: ants.dif.um.es/~pedrom/ SPAIN --------------------------------------------------------------------- --------------000407030200070804030609 Content-Type: text/plain; x-mac-type="54455854"; x-mac-creator="74657874"; name="CallForParticipation.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="CallForParticipation.txt" =============================================================================== We apologize if you receive this CFP more than once. ---------------------------------------------------------------------------- CALL FOR PARTICIPATION - AD HOC NOW 2006 5th International Conference on Ad hoc Networks and Wireless Ottawa, Canada, August 17-19, 2006 http://kunz-pc.sce.carleton.ca/AdHocNow2006/ ---------------------------------------------------------------------------- IMPORTANT DATES: =============== Early Registration Deadline: July 10, 2006 Conference Dates : Aug. 17-19, 2006 NOTE: The Summer School on Wireless Sensor Networks will be held from Aug. 14-16, just before the conference. The conference website also has a link to the summer school. FOR ADDITIONAL INFORMATION: ========================== For questions regarding obtaining visas, accommodation, etc, please contact Thomas Kunz (mailto:tkunz@sce.carleton.ca). KEYNOTE SPEAKERS: ================= (a) Professor Mani B. Srivastava (Univ. of California Los Angeles) (b) Professor Victor C. M. Leung (Univ. of British Columbia) PRELIMINARY PROGRAM: ===================== Thursday, Aug. 17, 2006 ----------------------- 08:45 - 09:00 Welcome 09:00 - 10:00 Keynote Speaker: Mani B. Srivastava Sensor Networks: From Smart Dust to Multi-scale, Multi-modal, Multi-user Observing Systems 10:00 - 10:20 Coffee Break 10:20 - 12:00 Routing in Sensor Networks ---------------------------------------- Yasser Gadallah (CANADA) A Comparative Study of Routing Strategies for Wireless Sensor Networks: Are MANET Protocols Good Fit? Steven Cheung, Bruno Dutertre, Ulf Lindqvist (USA) Detecting Disruptive Routers in Wireless Sensor Networks Kwang-il Hwang, Doo-seop Eom (KOREA) Energy-Efficient Data Dissemination in Sensor Networks by Distributed Dynamic Tree Management Ke Liu, Nael B. Abu-Ghazaleh (USA) Virtual Coordinates with Backtracking for Void Traversal in Geographic Routing 12:00 - 13:30 Lunch Break 13:30 - 15:10 Routing in MANET ------------------------------ Andrea E. F. Clementi, Miriam Di Ianni, Massimo Lauria, Angelo Monti, Gianluca Rossi, Riccardo Silvestri (ITALY) A Distributed Protocol for the Bounded-Hops Converge-cast in Ad-Hoc Networks Carlos A.S. Oliveira (USA) Discrete Optimization Models for Cooperative Communication in Ad Hoc Networks Kwan-Wu Chin, Darryn Lowe (AUSTRALIA) ROAR: A Multi-Rate Opportunistic AODV Routing Protocol for Ad-Hoc Networks Hector Tejeda, Edgar Chavez, Juan A. Sanchez, Pedro M. Ruiz (SPAIN/CANADA) Energy-efficient Face Routing on the Virtual Spanner 15:10 - 15:30 Coffee Break 15:30 - 17:00 Short Papers on Routing ------------------------------------- Shan-Shan Li, Pei-Dong Zhu, Xiang-Ke Liao, Wei-Fang Cheng Shao-Liang Peng (CHINA) Energy Efficient Multipath Routing using Network Coding in Wireless Sensor Networks Ansgar Fehnker, Peng Gao (AUSTRALIA) Formal Verification and Simulation for Performance Analysis for Probabilistic Broadcast Protocols Moon-Sang Jeong, Yeong-Hun Cho, Jong-Tae Park (KOREA) Policy-Based Route Optimization for Network Mobility of Next Generation Wireless Networks Jiang Hao, Jian-Jin Li, Kun Mean Hou, Chen Lijia (CHINA/FRANCE) Geographic pattern routing for MANETOR in IVC Geraud Allard, Pascale Minet, Dang-Quan Nguyen, Nirisha Shrestha (FRANCE) Evaluation of the Energy Consumption in MANET Jianxin Wang, Xianman Zhu, Jianer Chen (CHINA/USA) Link Availability at Any Time in MANET 19:00 Conference Dinner at the Empire Grill Friday, Aug. 18, 2006: ---------------------- 09:00 - 10:00 Keynote Speaker: Victor C. M. Leung Advances in Wireless Personal Area Networking 10:00 - 10:20 Coffee Break 10:20 - 12:00 Security I ------------------------ Sangheethaa Sukumaran, Elijah Blessing (INDIA) Reputation based Localized Access Control for Mobile Ad-hoc Networks Effie Makri, Yannis C. Stamatiou (GREECE) Distributively Increasing the percentage of similarities between strings with applications to key agreement Katrin Hoeper, Guang Gong (CANADA) Key Revocation for Identity-Based Schemes in Mobile Ad Hoc Networks J. A. Ploskonka, A. R. Hurson (USA) Self-Monitoring Security in Ad Hoc Routing 12:00 - 13:30 Lunch Break 13:30 - 15:10 Security II ------------------------- Dave Singelee, Bart Preneel (BELGIUM) Improved Pairing Protocol for Bluetooth Christine Laurendeau, Michel Barbeau (CANADA) Threats to Security in DSRC/WAVE Yongwei Wang and Mukesh Singhal (USA) LSTOP: A Light-weight Scalable Truthful Routing Protocol in MANETs with Selfish Nodes Peter Ebinger, Tobias Bucher (GERMANY) Modelling and Analysis of Attacks on the MANET Routing in AODV 15:10 - 15:40 Coffee Break 15:40 - 16:55 Wireless MAC -------------------------- Jacek Cichon, Miroslaw Kutylowski, Marcin Zawada (POLAND) Initialization for Ad Hoc Radio Networks with Carrier Sensing and Collision Detection Hans van den Berg, Michel Mandjes, Frank Roijers (THE NETHERLANDS) Performance Modeling of a Bottleneck Node in an IEEE 802.11 Ad-hoc Network Mohammad Z. Ahmad, Damla Turgut, R. Bhakthavathsalam (USA) Circularity-based Medium Access Control in Mobile Ad hoc Networks Saturday, Aug. 19, 2006: ------------------------ 09:00 - 10:00 Short Papers on Security, QoS and TCP --------------------------------------------------- Eun-Jun Yoon, Kee-Young Yoo (KOREA) Improving the ID-based Key Exchange Protocol in Wireless Mobile Ad Hoc Networks Dae-Young Lee, Hyun-Cheol Jeong (KOREA) An Efficient Certificate Management for Mobile Ad-Hoc Network Byungjoo Park, In Huh, Haniph Latchman (USA) Performance Improvement of TCP with an Efficient Contention Window Control Mechanism (ECWC) in IEEE 802.11 based Multi-hop Wireless Networks Joo-Sang Youn, Seung-Joon Seok, Chul-Hee Kang (KOREA) New Service Differentiation Model for end-to-end QoS provisioning in Wireless Ad Hoc Networks 10:00 - 10:30 Coffee Break 10:30 - 11:45 Upper Layer Issues I ---------------------------------- Ioannis Krontiris, Tassos Dimitriou (GREECE) Authenticated In-Network Programming for Wireless Sensor Networks Jung-Hoon Song, Kyung-Hwan Ahn, Dong-Hoon Cho, Ki-Jun Han (KOREA) A Congestion Window Adjustment Scheme for Improving TCP Performance over Mobile Ad-Hoc Networks Choong Ming Chin, Moh Lim Sim, Sverrir Olafsson (Malaysia/UK) Predictive Call Admission Control Algorithm for Power-Controlled Wireless Systems 11:45 - 13:15 Lunch Break 13:15 - 14:30 Upper Layer Issues II ----------------------------------- Vikram Munishwar, Sameer Tilak, Nael B. Abu-Ghazaleh (USA) File System Support for Adjustable Resolution Applications in Sensor Networks Emre Atsan, Oznur Ozkasap (TURKEY) A Classification and Performance Comparison of Mobility Models for Ad Hoc Networks Hye-Soo Kim, Dinh Trieu Duong, Jae-Yun Jeong, Byoung-Kyu Dan, Sung-Jea Ko (KOREA) Power-Aware Rate Control for Mobile Multimedia Communications PROCEEDINGS: ============ The proceedings of Adhoc Now 2006 will be published by Springer-Verlag, as Volume 4104 of the Lecture Notes in Computer Science (LNCS) series. TECHNICAL COMMITTEES ==================== Program Committee Co-Chairs: Thomas Kunz, Carleton University, Canada S. S. Ravi, SUNY Albany, USA Steering Committee: Evangelos Kranakis, Carleton University, Canada Michel Barbeau, Carleton University, Canada S. S. Ravi, SUNY Albany, USA Ioanis Nikolaidis, Univ. of Alberta, Canada Violet R. Syrotiuk, Arizona State Univ., USA Publicity Committee: Mieso Denko, University of Guelph, Canada Pedro M. Ruiz, Univ. of Murcia, Spain Technical Program Committee: Nael Abu-Ghazaleh, SUNY Binghamton, USA Eitan Altman, INRIA, France Michel Barbeau, Carleton University, Canada Rida Bazzi, Arizona State Univ., USA Prosenjit Bose, Carleton University, Canada Torsten Brown, Univ. Berne, Switzerland Gruia Calinescu, Illinois Inst. of Tech., USA Edgar Chavez, Univ. Michoacana, Mexico Hsiao-Hwa Chen, National Sun Yat-Sen Univ., Taiwan Jorge Cobb, UT Dallas, USA Marco Conti, IIT-CNR, Italy Pilu Crescenzi, Univ. Florence, Italy Mieso Denko, Univ. of Guelph, Canada Stefan Dobrev, Univ. of Ottawa, Canada Mischa Dohler, King's College, London, UK Andras Farago, UT Dallas, USA Laura Feeney, Swedish Institute of Computer Science, Sweden Stefan Fischer, Univ. Luebeck, Germany Antonio Gomez-Skarmeta, Univ. of Murcia, Spain Alex Hall, ETH, Zurich Admela Jukan, Univ. of Illinois at Urbana-Champaign, USA Valerie King, Univ. Victoria, Canada Evangelos Kranakis, Carleton University, Canada Danny Krizanc, Wesleyan University, USA Sven Krumke, Univ. Kaiseslautern, Germany Thomas Kunz, Carleton Univ., Canada Louise Lamont, Communications Research Center, Canada Errol Lloyd, Univ. Delaware, USA Angela Mielke, Los Alamos National Labs, USA Jelena Misic, Univ. Manitoba, Canada Pat Morin, Carleton University, Canada Lata Narayanan, Concordia Univ, Canada Ioanis Nikolaidis, U. Alberta, Canada J. Opatrny, Concordia Univ., Canada Marina Papatriantafilou, Chalmers Univ., Sweden Paolo Penna, Univ. Salerno, Italy Cristina Pinotti, Univ. Perugia, Italy Guy Pujolle, Univ. Pierre et Marie Curie, France Ravi Prakash, Univ. Texas at Dallas, USA Sergio Rajsbaum, UNAM, Mexico S. S. Ravi, SUNY Albany, USA Jean-Marc Robert, Alcatel, Canada Pedro M. Ruiz, Campus de Espinardo, Murcia, Spain Christian Schindelhauer, Univ. Paderborn, Germany Andrew Scott, Lancaster Univ., UK Martha Steenstrup, Stow Research LLC and Clemson Univ., USA Ivan Stojmenovic, Univ. Ottawa, Canada Ravi Sundaram, Northeastern University, USA Violet R. Syrotiuk, Arizona State Univ., USA Damla Turgut, Univ. of Florida, USA Anil Kumar Vullikanti, Virginia Tech., USA Paul Ward, Univ. Waterloo, Canada Gergely Zaruba, Univ. Texas at Arlington, USA Jerry Zhao, ICSI-Berkeley, USA --------------000407030200070804030609 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --------------000407030200070804030609-- From mip6-bounces@ietf.org Mon Jun 19 11:38:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsLpR-0007l3-H0; Mon, 19 Jun 2006 11:38:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsLpQ-0007ky-Fb for mip6@ietf.org; Mon, 19 Jun 2006 11:38:16 -0400 Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsLpP-0003y1-1K for mip6@ietf.org; Mon, 19 Jun 2006 11:38:16 -0400 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly04d.srv.mailcontrol.com (MailControl) with SMTP id k5JFcCu7029329 for ; Mon, 19 Jun 2006 16:38:12 +0100 Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 5394_f998f598_ffa3_11da_9bd0_0030482aac25; Mon, 19 Jun 2006 16:57:49 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2006061917380981-563741 ; Mon, 19 Jun 2006 17:38:09 +0200 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: 0.622,BAYES_00: -1.665, SARE_RECV_ADDR: 0.027 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de for mip6@ietf.org; Mon, 19 Jun 2006 17:41:42 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt Thread-Index: AcaP6+cUG5lk9fY0Rle0gdQUNlda+gDsmm4g To: Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4FB8E589@lan-ex-01.panasonic.de> Date: Mon, 19 Jun 2006 17:38:04 +0200 From: "Kilian Weniger" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-07-00-10 (www.mailcontrol.com) on 10.68.0.114 X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, it seems that the draft does not support switching to a HA serving a different than the current home link, i.e., switching to a new primary HoA at the same time. At least the draft prevents the MN from keeping the registration with the old HA, which IMHO would be neccessary in this case in order to keep existing sessions (using the old HoA) alive. The renumbering scenario mentioned in the draft seems to consider renumbering of HA addresses only, not HoAs.=20 Is there any reason for excluding such scenarios? Regards, Kilian > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Mittwoch, 14. Juni 2006 21:50 > To: i-d-announce@ietf.org > Cc: mip6@ietf.org > Subject: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Mobility for IPv6 Working=20 > Group of the IETF. >=20 > Title : Mobility Header Home Agent Switch Message > Author(s) : B. Haley, et al. > Filename : draft-ietf-mip6-ha-switch-00.txt > Pages : 11 > Date : 2006-6-14 > =09 > This document specifies a new Mobility Header message type that can > be used between a home agent and mobile node to signal a=20 > mobile node > that it should acquire a new home agent. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip6-ha-switch-00.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of the message. =20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-mip6-ha-switch-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mip6-ha-switch-00.txt". > =09 > 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=20 > 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. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 12:09:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsMJB-0004RR-3A; Mon, 19 Jun 2006 12:09:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsMJ9-0004RL-JV for mip6@ietf.org; Mon, 19 Jun 2006 12:08:59 -0400 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsMJ8-0008NR-3x for mip6@ietf.org; Mon, 19 Jun 2006 12:08:59 -0400 Received: from taynzmail03.nz-tay.cpqcorp.net (idcmailrelay.wipro.tcpn.com [16.47.4.103]) by atlrel9.hp.com (Postfix) with ESMTP id A56AE35590; Mon, 19 Jun 2006 12:08:57 -0400 (EDT) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id B5B574B01; Mon, 19 Jun 2006 12:08:57 -0400 (EDT) Received: from [16.116.96.215] by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id k5JG8u50002092839; Mon, 19 Jun 2006 12:08:57 -0400 (EDT) Message-ID: <4496CC17.3070105@hp.com> Date: Mon, 19 Jun 2006 12:08:55 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Experimental and Vendor specific messages References: <4491EEF4.5060706@azairenet.com> In-Reply-To: <4491EEF4.5060706@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, > the following two drafts specify experimental and vendor > specific mobility header messages and options. > > http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-experimental-messages-00.txt > > http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-vsm-00.txt The drafts look good. The only thing I would like to see in the MH definitions is the padding and header length requirements, for example: If no data is present in this message, 4 octets of padding are necessary and the Header Len field will be set to 1. -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 12:26:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsMaU-00062e-Sy; Mon, 19 Jun 2006 12:26:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsMaL-00062Q-9B for mip6@ietf.org; Mon, 19 Jun 2006 12:26:45 -0400 Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsMaK-0000Vh-Iw for mip6@ietf.org; Mon, 19 Jun 2006 12:26:45 -0400 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly01d.srv.mailcontrol.com (MailControl) with SMTP id k5JGQPUv010500 for ; Mon, 19 Jun 2006 17:26:25 +0100 Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 6b95_b62c2c88_ffaa_11da_80ca_0030482aac25; Mon, 19 Jun 2006 17:46:02 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2006061918261235-565973 ; Mon, 19 Jun 2006 18:26:12 +0200 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: -0.718,BAYES_00: -1.665, SARE_RECV_ADDR: 0.027, SARE_SUB_RAND_LETTRS2: 1.666, VIRUS_WARNING_NETSKY2: 1 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de for mip6@ietf.org; Mon, 19 Jun 2006 18:29:44 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01) In-Reply-To: <4491E890.6060900@iprg.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01) Thread-Index: AcaQ3BT8kRMF8UoqTeS390XamW4TeQCnHz2Q To: Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4FB8E593@lan-ex-01.panasonic.de> Date: Mon, 19 Jun 2006 18:26:06 +0200 From: "Kilian Weniger" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-07-00-10 (www.mailcontrol.com) on 10.68.0.111 X-Spam-Score: 0.1 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Rajeev, see comments inline > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]=20 > Sent: Freitag, 16. Juni 2006 01:09 > To: Kilian Weniger > Cc: mip6@ietf.org > Subject: Re: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01) >=20 >=20 > Hi Kilian, >=20 > thanks for the input. >=20 >=20 > Kilian Weniger wrote: >=20 > >General > >-------- > > > >- the term "roaming" is used in this draft many times, but=20 > is the term > >(defined in RFC3753) really appropriate here? Shouldn't it=20 > be replaced > >by "handover"? IMHO, the location privacy problem does also exist in > >non-roaming cases (MN moves to different subnet within an operator's > >network, i.e., intra-domain handover). > > > > =20 > > > we are not following the strict definition of "roaming" as in=20 > RFC3753.=20 I see. > Roaming may or may not > have operator intervention. The draft is neutral about it.=20 > Handover is a=20 > special case of mobility in > which you are concerned about existing sessions. So, when a=20 Yes, but it seems to me that in the context of Mobile IPv6 the term "l3 handovers" is often used to describe the event that a MN moves to a new subnet, i.e., even without having an active session (see, for instance, RFC3775 section 11.5.1: "When the mobile node detects an L3 handover, it performs Duplicate Address Detection": DAD should also be done if no active session exists). But I agree, strictly speaking this is not correct. > MN roams, it=20 > could have > existing sessions or not. If you would like me to define the term, I=20 > can. For instance, >=20 > Roaming: The process of moving from one network to another (with or=20 > without existing > sessions). I'm not in favour of using the term "roaming" in a different way than defined in RFC3753, since I was quite confused about the usage of this term in this draft. What do others think?=20 If "l3 handover" is not appropriate, how about "l3 movement" (or introducing a new term)? >=20 >=20 > >Comments on Section 2.1 > >------------ > > > >- The first sentence says > > > > "When a Mobile IP MN roams from its home network to a=20 > visited network, > > use of Care of Address in communication with a=20 > correspondent reveals > > that the MN has roamed."=20 > > > >I think this is a bit vague. First, the problem does not=20 > only exist when > >the MN roams from home to visited network, it also exists if it roams > >from one visited to another visited network. Second, not=20 > only the fact > >is revealed that the MN has roamed/moved, but also where the MN is > >located after the movement. Suggested text: > > > > "When a Mobile IP MN does a handover from its home network=20 > to a visited > >network *or from one visited network to another*, use of=20 > Care of Address > >in communication with a correspondent reveals that the MN=20 > has just done > >a handover *and where the MN is currently topologically located*."=20 > > > > =20 > > > I agree with the first part. The second part is commonly=20 > understood, and=20 > is described in the > Introduction. Perhaps I could add to: >=20 > "Furthermore, a user may not wish to reveal roaming to=20 > correspondent(s).=20 > In Mobile IP, this > translates to the use of Care of Address." >=20 > "As with Home Address, the Care of Address can also reveal the=20 > topological location of the > Mobile Node". ok >=20 > >- location privacy is only compromised if the correspondent=20 > node is able > >to link the HoA to a specific user/user identity. Although this may > >often be the case, this should be explicitly stated (similar=20 > statement > >exists in section 2.2). > > > > =20 > > > This is again common for the entire document. >=20 > From Section 1: >=20 > :..The location privacy problem is particularly applicable to=20 > Mobile IP=20 > where the Home Address on > a visited network can reveal device roaming and, together=20 > with a user=20 > identifier (such as a SIP URI), > can reveal user roaming.." >=20 > >- "to the correspondent node" should be added to the title of the > >section (in section 2.2, the care-of address is disclosed as=20 > well, but > >to on-lookers) > > > > > > =20 > > > Okay. >=20 > >Comments on Section 2.2 > >------------ > > > >- Analog to the comment on section 2.1, the text should consider that > >the problem does also exist when the MN moves from one=20 > visited network > >to another.=20 > > > > =20 > > > Ok. >=20 > >- analog to the comment on section 2.1, "to on-lookers"=20 > should be added > >to the title > > > > =20 > > > Ok. >=20 > >- It should be mentioned that location privacy is only compromised if > >the on-looker is located on the path between MN and HA in=20 > bi-directional > >tunneling mode or on the path between MN and CN in route optimization > >mode.=20 > > > > > > =20 > > > Check. >=20 > >Comments on Section 3 and conclusion > >------------------------ > > > >- The granularity of location information revealed from a care-of > >address depends also on whether a local mobility management=20 > scheme such > >as HMIPv6 or netlmm is used or not. Maybe this should be mentioned > >somewhere. > > > > =20 > > > Well, regardless of the on-link prefix, the granularity points to the=20 > physical address of the > ISP. With more sophisticated tools, one could get a better blueprint,=20 > which is recognized at the > end of 2nd paragraph of Section 3. >=20 > >- The draft concludes that two problems exist: disclosure of=20 > CoA to CN > >and disclosure of HoA to on-lookers. I would like to see=20 > some conclusion > >and discussions of requirements, so that solutions later can=20 > better be > >evaluated against requirements. For instance > >* which level of granularity regarding location privacy is required > >(some argue that the level that netlmm provides is sufficient)?=20 > > =20 > > > We should be able to hide HoA all together and have something to say=20 > about how to use CoA > judiciously if the MN is concerned about revealing the CoA. yes, but I think this requirement is not explicitly stated in the draft. My proposal was to add some text that explicitly states requirements.=20 >=20 > >* it should be possible to combine solutions for hiding CoA=20 > from CN and > >hiding HoA from on-lookers (i.e., provide both simultaneously)=20 > >* Route optimization should certainly be supported in both=20 > cases so that > >delay-sensitive services and efficient routing are possible. > > > > =20 > > > None of these are excluded in the solutions. The only=20 I didn't say that they are excluded. I just proposed to explicitly state requirements, since this may help in developing and evaluating solutions. > requirement I see=20 > is that the solutions > should not require additions to Mobile IP functional=20 > elements. So, you=20 > have a MN, HA and CN. > And you have MIP signaling protocol. What protocol=20 > enhancements we need=20 > to provide location > privacy? (I somehow think that this assumption of MIP model=20 > is clear in=20 > all the protocol work > surrounding MIP. I could make it clear that no new elements=20 > are required) ok (however, it might be difficult to check solutions against this requirement, e.g., how much modifications to the entity "HA" are allowed to still call it "HA"?) >=20 > >- The following paragraph is not really clear to me: "With its > >correspondents, the MN can either communicate directly or > > reverse tunnel its packets through the Home Agent. Using reverse > >tunneling does not reveal the new IP address of the MN, although > >performance may vary depending on the particular scenario. In some > >instances, the performance difference could be noticeable enough to > >serve as a hint to the correspondent."=20 > > > >What exactly is this hint about and how reliable is such=20 > hint? Does it > >mean that the correspondent can find out that the MN is not=20 > located at > >home only based on packet delay? While it might be true in some cases > >that the delay of reverse tunneled packets is high if the MN is away > >from home, this is not generally true, since there are many potential > >factors contributing to the packet delay. E.g., the delay heavily > >depends on the access technology used. When a users changes=20 > from a GPRS > >home network to a WLAN visited network, the packet delay may be much > >higher if the MN is at home compared to when it is located in the > >visited network. Since the correspondent node usually=20 > doesn't know which > >access technology is used by the MN, I do not see how the CN=20 > can derive > >the MN's location from packet delay. > > > > =20 > > > It does not state that the CN can derive MN's location from packet=20 > delay. The hints are just > that; they are not conclusive. If you roam across continents, your CN=20 > may notice the difference. > That's all it is trying to say ("_In some instances_..). I could add=20 > "However, such a difference > is not always conclusive". ok, maybe with some additional text about why it is often not conclusive (e.g., delay varies with access technologies used by MN; CN doesn't know which technology is used by MN) - Kilian >=20 > -Rajeev >=20 >=20 > >- Kilian=20 > > > > > >-----Original Message----- > >From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com]=20 > >Sent: Freitag, 2. Juni 2006 18:01 > >To: mip6@ietf.org > >Subject: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01) > > > > > > > >Hello, > > > >This is the working group last call for I-D: > >draft-ietf-mip6-location-privacy-ps-01.txt (IP Address=20 > Location Privacy > >and Mobile IPv6: Problem Statement) > > > >WG LC will end on June 16th, 06. Please review and send your comments > >before the deadline. > > > >The document is intended to be published as an Informational RFC. > > > >-Chairs > > > >The link for the I-D: > >http://ietf.org/internet-drafts/draft-ietf-mip6-location-priv acy-ps-01.t > >xt > > > > > >_______________________________________________ > >Mip6 mailing list > >Mip6@ietf.org > >https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > >_______________________________________________ > >Mip6 mailing list > >Mip6@ietf.org > >https://www1.ietf.org/mailman/listinfo/mip6 > > =20 > > >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 14:21:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsON5-0007pS-Dw; Mon, 19 Jun 2006 14:21:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsON4-0007pN-VQ for mip6@ietf.org; Mon, 19 Jun 2006 14:21:10 -0400 Received: from ccerelbas04.cce.hp.com ([161.114.21.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsON3-0006xB-Gt for mip6@ietf.org; Mon, 19 Jun 2006 14:21:10 -0400 Received: from mailrelay01.cce.cpqcorp.net (tandem.com [16.47.68.171]) by ccerelbas04.cce.hp.com (Postfix) with ESMTP id 268AE341AD; Mon, 19 Jun 2006 13:21:09 -0500 (CDT) Received: from kitche.zk3.dec.com (kitche4.zk3.dec.com [16.140.160.166]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id D9589C7C9; Mon, 19 Jun 2006 13:21:07 -0500 (CDT) Received: from [16.116.96.215] by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id k5JIL8E0002413674; Mon, 19 Jun 2006 14:21:08 -0400 (EDT) Message-ID: <4496EB13.7090108@hp.com> Date: Mon, 19 Jun 2006 14:21:07 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: Kilian Weniger Subject: Re: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt References: <4D2F935F08D41A4C8866693F4F0D7C4FB8E589@lan-ex-01.panasonic.de> In-Reply-To: <4D2F935F08D41A4C8866693F4F0D7C4FB8E589@lan-ex-01.panasonic.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Kilian, Kilian Weniger wrote: > Hi, > > it seems that the draft does not support switching to a HA serving a > different than the current home link, i.e., switching to a new primary > HoA at the same time. I think we just need to remove or replace sections of the draft that mention the "home link" with something more appropriate, limiting all the HA's to the same link was not the intention. > At least the draft prevents the MN from keeping > the registration with the old HA, which IMHO would be neccessary in this > case in order to keep existing sessions (using the old HoA) alive. The MN should be able to keep it's HoA as long as there is another available HA to switch to that's serving that prefix. > The > renumbering scenario mentioned in the draft seems to consider > renumbering of HA addresses only, not HoAs. The renumbering for the home link can be done with just RFC 3775 messages - Mobile Prefix Solicitation and Advertisement. -Brian > Is there any reason for excluding such scenarios? > > Regards, > > Kilian > >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: Mittwoch, 14. Juni 2006 21:50 >> To: i-d-announce@ietf.org >> Cc: mip6@ietf.org >> Subject: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> This draft is a work item of the Mobility for IPv6 Working >> Group of the IETF. >> >> Title : Mobility Header Home Agent Switch Message >> Author(s) : B. Haley, et al. >> Filename : draft-ietf-mip6-ha-switch-00.txt >> Pages : 11 >> Date : 2006-6-14 >> >> This document specifies a new Mobility Header message type that can >> be used between a home agent and mobile node to signal a >> mobile node >> that it should acquire a new home agent. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mip6-ha-switch-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in >> the body of the message. >> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> >> 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-mip6-ha-switch-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-mip6-ha-switch-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. >> > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 16:03:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsPxc-0004RW-3H; Mon, 19 Jun 2006 16:03:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsPxa-0004RM-QS for mip6@ietf.org; Mon, 19 Jun 2006 16:02:58 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsPxZ-000420-Je for mip6@ietf.org; Mon, 19 Jun 2006 16:02:58 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5JK2Fri020225; Mon, 19 Jun 2006 13:02:15 -0700 (MST) Received: from [10.169.4.182] (mvp-10-169-4-182.corp.mot.com [10.169.4.182]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k5JK2DLw027620; Mon, 19 Jun 2006 15:02:14 -0500 (CDT) Message-ID: <449702C4.1020100@motorola.com> Date: Mon, 19 Jun 2006 22:02:12 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) References: <2EBB8025B6D1BA41B567DB32C1D8DB84A1D8A9@NAEX06.na.qualcomm.com> <4492FB9F.70306@azairenet.com> In-Reply-To: <4492FB9F.70306@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Jari Arkko , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > (trimmed the cc list a bit) >> 2. It allows scenarios such as a MIP4 client in a cellphone, for >> instance, to attach to an IPv6 laptop and provide mobility for both >> devices. The cellphone itself only supports IPv4, while it is performing >> mobility for an IPv6 address that belongs to a host attached to it. > > laptop supporting IPv6 but the cellphone not? come on, I dont > think this is realistic. Why not? It's easier to have an IPv6 stack on the laptop than on the cell phone. I think very many laptops have IPv6 capabilities while only a few cell phones have. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 16:43:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQaO-0006kf-4g; Mon, 19 Jun 2006 16:43:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQaM-0006it-2v; Mon, 19 Jun 2006 16:43:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsQFi-0006vY-9W; Mon, 19 Jun 2006 16:21:42 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsPm2-0005L0-Bw; Mon, 19 Jun 2006 15:51:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5JJo1mU030976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsPl3-0007Yu-On; Mon, 19 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-dsmip-problem-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobility management for Dual stack mobile nodes A Problem Statement Author(s) : H. Soliman, G. Tsirtsis Filename : draft-ietf-mip6-dsmip-problem-02.txt Pages : 7 Date : 2006-6-19 This draft discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of inefficiencies. Deployment and operational issues motivate the use of a single mobility management protocol. This draft discusses such motivations. The draft also hints on how the current [MIPv4] and [MIPv6] protocols could be extended so that they can support mobility management for a dual stack node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-dsmip-problem-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip6-dsmip-problem-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-dsmip-problem-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-19123128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-dsmip-problem-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-dsmip-problem-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-19123128.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Mon Jun 19 19:24:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsT6w-0005WQ-JG; Mon, 19 Jun 2006 19:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsT6v-0005VV-Ho for mip6@ietf.org; Mon, 19 Jun 2006 19:24:49 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsT6u-0000SJ-8N for mip6@ietf.org; Mon, 19 Jun 2006 19:24:49 -0400 Received: by nf-out-0910.google.com with SMTP id q29so71954nfc for ; Mon, 19 Jun 2006 16:24:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C6Y6KAhldHKLOHydq5uTNm2kWB5Vr/TJBnp/4K3wM4ogx+mAUVivYIFg8A/jy5SPH5ixELBi79Vi04nVRsq9R3dv8SyzUV9wz+n+RbUoIcca3sYneDEqYdAuhj66t/mvhhRk8RPzzLlEURIHyzaow2NLZSIaa5o7ZVgX6qrJ+cM= Received: by 10.49.72.13 with SMTP id z13mr5039666nfk; Mon, 19 Jun 2006 16:24:47 -0700 (PDT) Received: by 10.48.12.10 with HTTP; Mon, 19 Jun 2006 16:24:47 -0700 (PDT) Message-ID: <43b91d370606191624w1efa3815tb88873dbd7b0cafa@mail.gmail.com> Date: Mon, 19 Jun 2006 16:24:47 -0700 From: "Samita Chakrabarti" To: "Vijay Devarapalli" Subject: Re: [Mip6] Experimental and Vendor specific messages In-Reply-To: <4491EEF4.5060706@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4491EEF4.5060706@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, I think the experimental and vendor specific message/options would be useful. The drafts talk about node behavior when the node does not understand these messages. How about some texts about node behavior when these option types are unrecognized ? I assume they will be skipped. -Samita On 6/15/06, Vijay Devarapalli wrote: > hello, > > the following two drafts specify experimental and vendor > specific mobility header messages and options. > > http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-experimental-messages-00.txt > http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-vsm-00.txt > > the motivation behind these drafts is that they would > encourage experiments and protocol extensions to Mobile > IPv6. comments would be much appreciated. > > Vijay > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 19:28:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTA4-0007MJ-Bb; Mon, 19 Jun 2006 19:28:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTA3-0007MA-LA for mip6@ietf.org; Mon, 19 Jun 2006 19:28:03 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsT9z-0000aJ-9U for mip6@ietf.org; Mon, 19 Jun 2006 19:28:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Experimental and Vendor specific messages Date: Mon, 19 Jun 2006 16:27:57 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Experimental and Vendor specific messages Thread-Index: AcaT949s0n+cHTE6SzSusTMmy0W0dAAAETAg From: "Vijay Devarapalli" To: "Samita Chakrabarti" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > I think the experimental and vendor specific message/options would be > useful. The drafts talk about node behavior when the node=20 > does not understand > these messages. How about some texts about node behavior when these > option types are unrecognized ? I assume they will be skipped. there is some text on this. Home agent or correspondent node implementations that do not recognize the mobility message type, discard the message and send Binding Error message as described in [2], with the Status field set to 2 (unrecognized MH Type value). Mobile nodes that do not recognize the mobility message type should discard the message and send an ICMP Parameter problem with code 0. Mobility options, by definition, can be skipped if an implementation does not recognize the mobility option type [2]. Vijay >=20 > -Samita >=20 > On 6/15/06, Vijay Devarapalli wrote: > > hello, > > > > the following two drafts specify experimental and vendor > > specific mobility header messages and options. > > > >=20 > http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-exp erimental-messages-00.txt > >=20 > http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-vsm-00.txt > > > > the motivation behind these drafts is that they would > > encourage experiments and protocol extensions to Mobile > > IPv6. comments would be much appreciated. > > > > Vijay > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 19:38:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTJe-0004dz-0N; Mon, 19 Jun 2006 19:37:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTJc-0004Ya-IR for mip6@ietf.org; Mon, 19 Jun 2006 19:37:56 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTJa-0001gr-80 for mip6@ietf.org; Mon, 19 Jun 2006 19:37:56 -0400 Received: by nf-out-0910.google.com with SMTP id q29so72975nfc for ; Mon, 19 Jun 2006 16:37:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=O73enyQXiAre+OgTF5eZksGxvTqX/d9BzClLZaZpJ/MgfBZcl7LcM8PZ0LOISyWpnws3F9tF4Or0FzgPB4qPniuxnj40qWKzjGKKAGRbh+LI4jxpuRCeKpB2vD+R48hWG/Om0nHOPcp8vN4UlP4GT5mE0IJSJo3lPV9Ccn3t/Hw= Received: by 10.49.72.13 with SMTP id z13mr5046974nfk; Mon, 19 Jun 2006 16:37:53 -0700 (PDT) Received: by 10.48.12.10 with HTTP; Mon, 19 Jun 2006 16:37:51 -0700 (PDT) Message-ID: <43b91d370606191637x12fb6881i93693ea25a235eae@mail.gmail.com> Date: Mon, 19 Jun 2006 16:37:51 -0700 From: "Samita Chakrabarti" To: "Vijay Devarapalli" Subject: Re: [Mip6] Experimental and Vendor specific messages In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On 6/19/06, Vijay Devarapalli wrote: > > I think the experimental and vendor specific message/options would be > > useful. The drafts talk about node behavior when the node > > does not understand > > these messages. How about some texts about node behavior when these > > option types are unrecognized ? I assume they will be skipped. > > there is some text on this. > > Home agent or > correspondent node implementations that do not recognize the mobility > message type, discard the message and send Binding Error message as > described in [2], with the Status field set to 2 (unrecognized MH > Type value). Mobile nodes that do not recognize the mobility message > type should discard the message and send an ICMP Parameter problem > with code 0. > Yes, I saw that in the two drafts. I was referring to the option types, not MH types. > Mobility options, by definition, can be skipped if an implementation > does not recognize the mobility option type [2]. Ahh... I missed this line somehow. Looks fine. Thanks, -Samita > > > > > -Samita > > > > On 6/15/06, Vijay Devarapalli wrote: > > > hello, > > > > > > the following two drafts specify experimental and vendor > > > specific mobility header messages and options. > > > > > > > > http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-exp > erimental-messages-00.txt > > > > > http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-vsm-00.txt > > > > > > the motivation behind these drafts is that they would > > > encourage experiments and protocol extensions to Mobile > > > IPv6. comments would be much appreciated. > > > > > > Vijay > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 19:41:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTNI-0001nW-Ek; Mon, 19 Jun 2006 19:41:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTNH-0001nR-St for mip6@ietf.org; Mon, 19 Jun 2006 19:41:43 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTNE-0002Bd-IJ for mip6@ietf.org; Mon, 19 Jun 2006 19:41:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Experimental and Vendor specific messages Date: Mon, 19 Jun 2006 16:41:37 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Experimental and Vendor specific messages Thread-Index: AcaTuq41TXX+ihgpSkiGBHTs5xvDYQAPVeMg From: "Vijay Devarapalli" To: "Brian Haley" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > the following two drafts specify experimental and vendor > > specific mobility header messages and options. > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-exp > erimental-messages-00.txt=20 > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-vsm-00.txt >=20 > The drafts look good. >=20 > The only thing I would like to see in the MH definitions is=20 > the padding=20 > and header length requirements, for example: >=20 > If no data is present in this message, 4 octets of padding are > necessary and the Header Len field will be set to 1. yes. I will add this. Vijay >=20 > -Brian >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 19:45:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTQe-0002OQ-Vr; Mon, 19 Jun 2006 19:45:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTQb-0002NX-3k for mip6@ietf.org; Mon, 19 Jun 2006 19:45:09 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTQZ-0002R2-Qq for mip6@ietf.org; Mon, 19 Jun 2006 19:45:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) Date: Mon, 19 Jun 2006 16:45:06 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) Thread-Index: AcaT21ym7EtvEDlTQPSnTE07p2l6sAAHrdiw From: "Vijay Devarapalli" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Jari Arkko , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org =20 > Vijay Devarapalli wrote: > > (trimmed the cc list a bit) > >> 2. It allows scenarios such as a MIP4 client in a cellphone, for > >> instance, to attach to an IPv6 laptop and provide mobility for both > >> devices. The cellphone itself only supports IPv4, while it=20 > is performing > >> mobility for an IPv6 address that belongs to a host=20 > attached to it.=20 > >=20 > > laptop supporting IPv6 but the cellphone not? come on, I dont > > think this is realistic. >=20 > Why not? It's easier to have an IPv6 stack on the laptop than on the=20 > cell phone. I think very many laptops have IPv6 capabilities=20 > while only=20 > a few cell phones have. let me rephrase. I wanted to talk about laptops/phones using IPv6 rather than having IPv6 capabilities. I still maintain=20 that it is not a realistic scenario. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 20:13:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTrT-0005nc-15; Mon, 19 Jun 2006 20:12:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTrR-0005mq-Lg for mip6@ietf.org; Mon, 19 Jun 2006 20:12:53 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTrQ-00064y-9X for mip6@ietf.org; Mon, 19 Jun 2006 20:12:53 -0400 Received: from [10.1.201.12] ([10.1.201.12]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 17:12:51 -0700 Message-ID: <44973D7B.6030109@azairenet.com> Date: Mon, 19 Jun 2006 17:12:43 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Shinta Sugimoto Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction References: <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> In-Reply-To: <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 00:12:51.0193 (UTC) FILETIME=[44CD7690:01C693FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Shinta Sugimoto wrote: >> The problem here is how does the MN know to "let the >> existing sessions continue with the existing HoA"? If there is no CN's >> address in BUL, surely the MN can choose a suitable HoA. For >> a CN with which it has a binding, it has no reliable way of knowing >> whether there are any ULP sessions. > > If you need to maintain the sessions while changing the HoA > from one to another, I think you need additional mechanism > than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed > to assure the reachability to a given HoA with the current > location of the mobile node (CoA). If the app wants > to change HoAs for some reason (I assume that privacy is the > main interest), there is a need to maintain the mapping of > the identity and the locator of the mobile node. Mobile IPv6 today allows you to use two home addresses at the same time. it also allows you to bind both home addresses to the same CoA. > One option would be to run Shim6 over MIPv6. Such usage has > already been discussed in Shim6 WG. By mobile node establishing > Shim6 context with its HA/CN, it could utilize multiple HoAs > without annoying upper layer protocols. yes, this can be done. but I would like to restrict shim6 usage when mip6 is used to the case where the home link is site multihomed and the mobile node already has the multiple home addresses configured on it. not when the mobile node decides to change its home address. > I have some additional questions: > > - If privacy is the main concern, would you think > http://www.ietf.org/internet-drafts/draft-dupont-mip6-privacyext-03.txt > would help to solve your initial requirement ? If not, could > you please tell me why ? I think its orthogonal. the use of pseudo-HoA instead of the actual HoA is also being worked on in mobopts. > - Do you assume that different HoAs that mobile node may > request are derived from different home prefixes ? Or are you > considering that the node generates HoAs from a single prefix > with privacy extension ? I think its the same prefix, but I guess its better if Rajeev clarifies. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 20:25:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsU3u-0007GU-T4; Mon, 19 Jun 2006 20:25:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsU3t-0007Dz-PP; Mon, 19 Jun 2006 20:25:45 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsU3s-0008F7-BS; Mon, 19 Jun 2006 20:25:45 -0400 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J14007E3UIUEG@mailout3.samsung.com>; Tue, 20 Jun 2006 09:25:42 +0900 (KST) Received: from LocalHost (adsl-75-2-41-177.dsl.ipltin.sbcglobal.net [75.2.41.177]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0J1400782UIUNS@mmp2.samsung.com>; Tue, 20 Jun 2006 09:25:42 +0900 (KST) Date: Tue, 20 Jun 2006 09:25:41 +0900 From: Heejin Jang In-reply-to: To: mip6@ietf.org, dhcwg@ietf.org Message-id: <02ac01c69400$10a1fc40$b129024b@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcWHaBujfUYVBxToQz6PTDoiCWt9P0MlWThAAACQ0bA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Mip6] [Updated] DHCP Option for Home Information Discovery in MIPv6 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello folks, We posted an I-D that proposes new DHCP Options for Home Information Discovery in MIPv6. Kindly note that the previous version of this draft is "draft-jang-dhc-haopt-02.txt" but the name is slightly changed into "draft-jang-mip6-hiopt-00.txt" while keeping almost the same contents. The drafts referencing this draft such as draft-ietf-mip6-bootstrapping-split-02.txt and draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt need to be revised accordingly. We would appreciate to hear your comments. -------------------------------------------------------------------- Document title : DHCP Option for Home Information Discovery in MIPv6 Working group : MIP6 & DHC Authors : Hee Jin Jang, Alper Yegin, JinHyeock Choi and Kuntal Chowdhury Filename : draft-jang-mip6-hiopt-00.txt Abstract : This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home agent address, home address, and home subnet. New DHCP options are defined to carry the information from a DHCP server to the DHCP client running on the mobile node. ----------------------------------------------------------------------- Regards - Heejin Jang _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 21:12:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsUn1-0003L6-Ih; Mon, 19 Jun 2006 21:12:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsUn0-0003Kf-0x; Mon, 19 Jun 2006 21:12:22 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsUmy-0007GP-Ht; Mon, 19 Jun 2006 21:12:22 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5K1CBag000308; Tue, 20 Jun 2006 04:12:16 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 04:12:14 +0300 Received: from [127.0.0.1] ([10.241.53.182]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Jun 2006 04:12:14 +0300 Message-ID: <44974B6A.6060709@iprg.nokia.com> Date: Mon, 19 Jun 2006 21:12:10 -0400 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shinta Sugimoto Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction References: <44862A89.5030201@azairenet.com> <44870922.3040408@iprg.nokia.com> <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> In-Reply-To: <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 01:12:15.0131 (UTC) FILETIME=[91133EB0:01C69406] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: mip6@ietf.org, Vijay Devarapalli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, the purpose here is to list the available options. Perhaps SHIM6 is one option, but there are others to explore. I encourage you to discuss them at the MobOpts meeting. -Rajeev ps: location privacy as such is being discussed in a problem statement draft, and there is also a mobopts drfat on solutions. Please have a look at them. Thanks. Shinta Sugimoto wrote: >Hi Rajeev, > > > >If you need to maintain the sessions while changing the HoA >from one to another, I think you need additional mechanism >than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed >to assure the reachability to a given HoA with the current >location of the mobile node (CoA). If the app wants >to change HoAs for some reason (I assume that privacy is the >main interest), there is a need to maintain the mapping of >the identity and the locator of the mobile node. > >One option would be to run Shim6 over MIPv6. Such usage has >already been discussed in Shim6 WG. By mobile node establishing >Shim6 context with its HA/CN, it could utilize multiple HoAs >without annoying upper layer protocols. However, I am not sure >if it fulfills your requirement especially in terms of privacy >(hiding the identity, which is MN's HoA in this case). >Would you see any problem with this approach ? I see that >signaling overhead may also be a concern (to run both Shim6 >and MIPv6). > >I have some additional questions: > >- If privacy is the main concern, would you think >http://www.ietf.org/internet-drafts/draft-dupont-mip6-privacyext-03.txt >would help to solve your initial requirement ? If not, could >you please tell me why ? >- Do you assume that different HoAs that mobile node may >request are derived from different home prefixes ? Or are you >considering that the node generates HoAs from a single prefix >with privacy extension ? > > >Regards, >Shinta > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 21:17:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsUrz-0005ki-4X; Mon, 19 Jun 2006 21:17:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsUrx-0005kZ-Tk; Mon, 19 Jun 2006 21:17:29 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsUru-0007M2-JV; Mon, 19 Jun 2006 21:17:29 -0400 Received: from [10.1.201.12] ([10.1.201.12]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 18:17:25 -0700 Message-ID: <44974CA3.1090303@azairenet.com> Date: Mon, 19 Jun 2006 18:17:23 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Heejin Jang Subject: Re: [Mip6] [Updated] DHCP Option for Home Information Discovery in MIPv6 References: <02ac01c69400$10a1fc40$b129024b@LocalHost> In-Reply-To: <02ac01c69400$10a1fc40$b129024b@LocalHost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 01:17:25.0805 (UTC) FILETIME=[4A4055D0:01C69407] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: mip6@ietf.org, dhcwg@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Heejin Jang wrote: > Hello folks, > We posted an I-D that proposes new DHCP Options for Home Information > Discovery in MIPv6. > > Kindly note that the previous version of this draft is > "draft-jang-dhc-haopt-02.txt" but the name is slightly changed into > "draft-jang-mip6-hiopt-00.txt" while keeping almost the same contents. > > The drafts referencing this draft such as > draft-ietf-mip6-bootstrapping-split-02.txt and > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt need to be revised > accordingly. > > We would appreciate to hear your comments. when this draft was discussed in the MIP6 bootstrapping design team, many people wanted to integrate the two DHCP options into draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. this was mainly because the options defined in the document have limited applicability beyond the integrated scenario solution document. the only other mechanism is to manually configure the DHCP servers in the visited link with information like home agent address, home address and home prefix. this is a bad idea. there was some opposition and we never reached an agreement. so I suggest including these options into the integrated scenario solution document for these options to get standardized quickly. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 19 23:49:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsXF0-00053p-G5; Mon, 19 Jun 2006 23:49:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsXEz-00053h-6b for mip6@ietf.org; Mon, 19 Jun 2006 23:49:25 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsXEx-00084I-RX for mip6@ietf.org; Mon, 19 Jun 2006 23:49:25 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5K3nKPc012550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Jun 2006 20:49:21 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5K3nHQ2006451; Mon, 19 Jun 2006 20:49:19 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Jun 2006 20:49:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction Date: Mon, 19 Jun 2006 20:49:15 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04F95A@NAEX14.na.qualcomm.com> In-Reply-To: <44973D7B.6030109@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction Thread-Index: AcaUAL9QWavve+sOQwieT0/W54zJugAG6tMA From: "Soliman, Hesham" To: "Vijay Devarapalli" , "Shinta Sugimoto" X-OriginalArrivalTime: 20 Jun 2006 03:49:18.0736 (UTC) FILETIME=[81FB4100:01C6941C] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > One option would be to run Shim6 over MIPv6. Such usage has > > already been discussed in Shim6 WG. By mobile node establishing > > Shim6 context with its HA/CN, it could utilize multiple HoAs > > without annoying upper layer protocols. =20 >=20 > yes, this can be done. but I would like to restrict > shim6 usage when mip6 is used to the case where the > home link is site multihomed and the mobile node already > has the multiple home addresses configured on it. not > when the mobile node decides to change its home address. =3D> There is no difference between the two scenarios.=20 Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 01:42:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsZ0V-0003Ww-79; Tue, 20 Jun 2006 01:42:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsYyh-0002Yv-Tl; Tue, 20 Jun 2006 01:40:43 -0400 Received: from mout.perfora.net ([217.160.230.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsYuc-00039K-3X; Tue, 20 Jun 2006 01:36:31 -0400 Received: from [68.126.198.124] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1FsYuU3mc1-0007WT; Tue, 20 Jun 2006 01:36:27 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" , "'Heejin Jang'" Subject: RE: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 Date: Mon, 19 Jun 2006 22:36:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaUB08iy+3nOaBWTUOhny3TiJoF1QAIaflg In-Reply-To: <44974CA3.1090303@azairenet.com> Message-ID: <0MKp2t-1FsYuU3mc1-0007WT@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: mip6@ietf.org, dhcwg@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay, As far as I remember you were the only one who didn't give up on pushing for integration. It'd only be a circular discussion if I had repeated the reasons for not bundling a bunch of protocol extensions in a single document. But I hope this data point helps: WiMAX Forum NWG architecture is using draft-jang. Alper > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Monday, June 19, 2006 6:17 PM > To: Heejin Jang > Cc: mip6@ietf.org; dhcwg@ietf.org > Subject: Re: [Mip6] [Updated] DHCP Option for Home Information Discovery > inMIPv6 > > Heejin Jang wrote: > > Hello folks, > > We posted an I-D that proposes new DHCP Options for Home Information > > Discovery in MIPv6. > > > > Kindly note that the previous version of this draft is > > "draft-jang-dhc-haopt-02.txt" but the name is slightly changed into > > "draft-jang-mip6-hiopt-00.txt" while keeping almost the same contents. > > > > The drafts referencing this draft such as > > draft-ietf-mip6-bootstrapping-split-02.txt and > > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt need to be revised > > accordingly. > > > > We would appreciate to hear your comments. > > when this draft was discussed in the MIP6 bootstrapping > design team, many people wanted to integrate the two DHCP > options into > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. > this was mainly because the options defined in the document > have limited applicability beyond the integrated scenario > solution document. the only other mechanism is to manually > configure the DHCP servers in the visited link with > information like home agent address, home address and home > prefix. this is a bad idea. > > there was some opposition and we never reached an agreement. > > so I suggest including these options into the integrated > scenario solution document for these options to get > standardized quickly. > > Vijay > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 02:56:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsa9o-0006nW-Ov; Tue, 20 Jun 2006 02:56:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsa9o-0006nR-Bu for mip6@ietf.org; Tue, 20 Jun 2006 02:56:16 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsa9l-000634-G8 for mip6@ietf.org; Tue, 20 Jun 2006 02:56:16 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1500KC9D4DR7@szxga02-in.huawei.com> for mip6@ietf.org; Tue, 20 Jun 2006 15:07:25 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1500K2VD4C91@szxga02-in.huawei.com> for mip6@ietf.org; Tue, 20 Jun 2006 15:07:25 +0800 (CST) Received: from y52774 ([10.164.44.184]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1500CEUCVHI0@szxml04-in.huawei.com> for mip6@ietf.org; Tue, 20 Jun 2006 15:02:08 +0800 (CST) Date: Tue, 20 Jun 2006 14:51:22 +0800 From: Michael Ye Subject: [mip6]:About MN Roaming between different network! To: mip6@ietf.org Message-id: <001501c69435$f14f2030$b82ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaUNfEV+3ynT09BT/mAL9MElhpPLg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, In roaming problem between different network,we must sure what we will do. 1.what will we do? 2.which problems will we do? 3.what are the scenarios we will solve? 4.what new problems will be brought forth for solving these problems? I think, Roming problem will be following: MIPv4 has solved the problem that MN roams in IPv4 network and MIPv6 has solved the one that MN roams in IPv6 network.So when a MN (we hope it is a note with Dual stack) move from IPv6 network to IPv4 network or from IPv4 network to IPv60 network, a new solution must be put forward. How to keep provious connectivity is very important when a MN move from IPv6 network to IPv4 network or from IPv4 network to IPv6 network. connectivity relates to the HoA of MN.So the following three scenarios is necessary: 1)MN has a HA in IPv4 network, (it is that MN has an IPv4 HoA ). 2)MN has a HA in IPv6 network, (it is that MN has an IPv6 HoA ). 3)MN has both. I think , less modifing the current standard is a good idea for solving the roaming. BR, Michael Ye _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 03:38:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsaoy-00034z-O5; Tue, 20 Jun 2006 03:38:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsaow-00034k-9e for mip6@ietf.org; Tue, 20 Jun 2006 03:38:46 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsaoC-0000Wk-T0 for mip6@ietf.org; Tue, 20 Jun 2006 03:38:46 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 1F8954D8AE; Tue, 20 Jun 2006 16:37:54 +0900 (JST) Date: Tue, 20 Jun 2006 10:37:53 +0300 From: Shinta Sugimoto To: Vijay Devarapalli Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction In-Reply-To: <44973D7B.6030109@azairenet.com> References: <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> <44973D7B.6030109@azairenet.com> Message-Id: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, please find my comments inline. On Mon, 19 Jun 2006 17:12:43 -0700 Vijay Devarapalli wrote: > Shinta Sugimoto wrote: > >> The problem here is how does the MN know to "let the > >> existing sessions continue with the existing HoA"? If there is no CN's > >> address in BUL, surely the MN can choose a suitable HoA. For > >> a CN with which it has a binding, it has no reliable way of knowing > >> whether there are any ULP sessions. > > > > If you need to maintain the sessions while changing the HoA > > from one to another, I think you need additional mechanism > > than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed > > to assure the reachability to a given HoA with the current > > location of the mobile node (CoA). If the app wants > > to change HoAs for some reason (I assume that privacy is the > > main interest), there is a need to maintain the mapping of > > the identity and the locator of the mobile node. > > Mobile IPv6 today allows you to use two home addresses > at the same time. it also allows you to bind both home > addresses to the same CoA. Yes, that's true. But then there is a problem to choose which one for which communication. When it comes to agility, it's more problematic. > > One option would be to run Shim6 over MIPv6. Such usage has > > already been discussed in Shim6 WG. By mobile node establishing > > Shim6 context with its HA/CN, it could utilize multiple HoAs > > without annoying upper layer protocols. > > yes, this can be done. but I would like to restrict > shim6 usage when mip6 is used to the case where the > home link is site multihomed and the mobile node already > has the multiple home addresses configured on it. not > when the mobile node decides to change its home address. I think it depends on motivation whether it makes sense to apply Shim6 here. Utilizing Shim6 would allow HoA agility (from ULP point of view). OTOH, Shim6 (in the current form) does not take privacy into consideration very much, actually. So if the motivation is to achieve location privacy (not allowing third party to learn the binding), I think that we may probably need something else. > > > I have some additional questions: > > > > - If privacy is the main concern, would you think > > http://www.ietf.org/internet-drafts/draft-dupont-mip6-privacyext-03.txt > > would help to solve your initial requirement ? If not, could > > you please tell me why ? > > I think its orthogonal. the use of pseudo-HoA instead > of the actual HoA is also being worked on in mobopts. I've read the solution draft from the mobopts and it seems to me that both draft try to achieve the same goal. > > - Do you assume that different HoAs that mobile node may > > request are derived from different home prefixes ? Or are you > > considering that the node generates HoAs from a single prefix > > with privacy extension ? > > I think its the same prefix, but I guess its better if > Rajeev clarifies. Ok, it seems so (HoAs are derived from same prefix). Regards, Shinta _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 04:00:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsbAK-0005mx-Bc; Tue, 20 Jun 2006 04:00:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsbAJ-0005mn-55 for mip6@ietf.org; Tue, 20 Jun 2006 04:00:51 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsb9c-0003xF-Ie for mip6@ietf.org; Tue, 20 Jun 2006 04:00:51 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id AFB464D8CA; Tue, 20 Jun 2006 17:00:04 +0900 (JST) Date: Tue, 20 Jun 2006 11:00:01 +0300 From: Shinta Sugimoto To: Rajeev Koodli Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction In-Reply-To: <44974B6A.6060709@iprg.nokia.com> References: <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> <44974B6A.6060709@iprg.nokia.com> Message-Id: <20060620103743.AA20.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: mip6@ietf.org, Vijay Devarapalli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Rajeev, please find my comments/questions inline. On Mon, 19 Jun 2006 21:12:10 -0400 Rajeev Koodli wrote: > > Hi, > > the purpose here is to list the available options. Perhaps SHIM6 is > one option, but there are others to explore. Ok, I see. > I encourage you to > discuss them at the MobOpts meeting. Yes. > > -Rajeev > > ps: location privacy as such is being discussed in a problem statement > draft, and there is also a mobopts drfat on solutions. Please have a look > at them. Thanks. Thanks for the information. I've just read the ps and solution drafts. Still I am not quite sure if I understand the exact issue being discussed on this thread. Is the issue 1) how to identify correspondent node with whom the mobile node already established a sessoin based on a given HoA, or 2) how to provide HoA agility when the mobile node changes it's HoA from one to another (for privacy reason), or both ? Regards, Shinta _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 04:41:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsbnD-0008Le-Do; Tue, 20 Jun 2006 04:41:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsbnC-0008LX-OM for mip6@ietf.org; Tue, 20 Jun 2006 04:41:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsbOO-0005rY-5N for mip6@ietf.org; Tue, 20 Jun 2006 04:15:24 -0400 Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fsb9u-0001rq-58 for mip6@ietf.org; Tue, 20 Jun 2006 04:00:28 -0400 Received: from rly23d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly23d.srv.mailcontrol.com (MailControl) with ESMTP id k5K80NPs025274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Jun 2006 09:00:24 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly23d.srv.mailcontrol.com (MailControl) id k5K80I3E025171 for mip6@ietf.org; Tue, 20 Jun 2006 09:00:18 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly23d-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id k5K80IoJ025135; Tue, 20 Jun 2006 09:00:18 +0100 (BST) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 73ea_2d0c100c_002d_11db_9ed8_0030482aac25; Tue, 20 Jun 2006 09:19:56 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2006062010001422-590918 ; Tue, 20 Jun 2006 10:00:14 +0200 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: 0.623,BAYES_00: -1.665, SARE_RECV_ADDR: 0.027 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Tue, 20 Jun 2006 10:03:46 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt In-Reply-To: <4496EB13.7090108@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt Thread-Index: AcaTzSuKVYhIRyPPTb2uOOVL0N0awwAasaog To: "Brian Haley" Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4FB8E5D7@lan-ex-01.panasonic.de> Date: Tue, 20 Jun 2006 10:00:08 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-07-00-10 (www.mailcontrol.com) on 10.68.1.133 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Brian, > -----Original Message----- > From: Brian Haley [mailto:brian.haley@hp.com]=20 > Sent: Montag, 19. Juni 2006 20:21 > To: Kilian Weniger > Cc: mip6@ietf.org > Subject: Re: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt >=20 > Hi Kilian, >=20 > Kilian Weniger wrote: > > Hi, > >=20 > > it seems that the draft does not support switching to a HA serving a > > different than the current home link, i.e., switching to a=20 > new primary > > HoA at the same time. >=20 > I think we just need to remove or replace sections of the draft that=20 > mention the "home link" with something more appropriate, limiting all=20 > the HA's to the same link was not the intention. good >=20 > > At least the draft prevents the MN from keeping > > the registration with the old HA, which IMHO would be=20 > neccessary in this > > case in order to keep existing sessions (using the old HoA) alive. >=20 > The MN should be able to keep it's HoA as long as there is another=20 > available HA to switch to that's serving that prefix. The scenario I was talking about is that the switch message sent by the HA directs the MN to a new HA serving a different link, resulting in a new HoA for the MN after bootstrapping with this HA. Section 5.1 (MN operation) says "Upon receipt of a Home Agent Switch message, the mobile node MUST stop using its current home agent for services and MUST delete its home binding by sending a Binding Update message as described in [2]. This acts as an acknowledgement of the Home Agent Switch message." When strictly following the procedure described in the draft, I don't see how the MN can keep its old HoA. The MN must send a BU to delete the binding for the old HoA and cannot skip that, since the BU acts as ack for the switch message. To support the scenario, it should IMHO be possible to keep the registration with the old HA (at least for a certain period of time) if the bootstrapping with the new HA results in a new HoA. The switch message could indicate (e.g., by a flag) whether the old HA is able to keep serving the MN as secondary HA for some time (to keep existing session alive and to keep IP reachability until the new HoA is published). When receiving a switch message with this flag set, the MN would not be required to delete the binding at the old HA immediately (note that strictly speaking this would not be a HA switch, since the registration with the old HA would not be deleted). >=20 > > The > > renumbering scenario mentioned in the draft seems to consider > > renumbering of HA addresses only, not HoAs.=20 >=20 > The renumbering for the home link can be done with just RFC 3775=20 > messages - Mobile Prefix Solicitation and Advertisement. yes, but if the above scenario is supported, renumbering of certain HoAs would also be possible with the switch mechanism only. If the switch mechanism is needed for renumbering is of course another question. -Kilian >=20 > -Brian >=20 >=20 > > Is there any reason for excluding such scenarios? > >=20 > > Regards, > >=20 > > Kilian > >=20 > >> -----Original Message----- > >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > >> Sent: Mittwoch, 14. Juni 2006 21:50 > >> To: i-d-announce@ietf.org > >> Cc: mip6@ietf.org > >> Subject: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt=20 > >> > >> A New Internet-Draft is available from the on-line=20 > >> Internet-Drafts directories. > >> This draft is a work item of the Mobility for IPv6 Working=20 > >> Group of the IETF. > >> > >> Title : Mobility Header Home Agent Switch Message > >> Author(s) : B. Haley, et al. > >> Filename : draft-ietf-mip6-ha-switch-00.txt > >> Pages : 11 > >> Date : 2006-6-14 > >> =09 > >> This document specifies a new Mobility Header message=20 > type that can > >> be used between a home agent and mobile node to signal a=20 > >> mobile node > >> that it should acquire a new home agent. > >> > >> > >> A URL for this Internet-Draft is: > >>=20 > http://www.ietf.org/internet-drafts/draft-ietf-mip6-ha-switch-00.txt > >> > >> To remove yourself from the I-D Announcement list, send a=20 > message to=20 > >> i-d-announce-request@ietf.org with the word unsubscribe in=20 > >> the body of the message. =20 > >> You can also visit=20 > >> https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > >> to change your subscription settings. > >> > >> > >> Internet-Drafts are also available by anonymous FTP. Login=20 > >> with the username > >> "anonymous" and a password of your e-mail address. After=20 > logging in, > >> type "cd internet-drafts" and then > >> "get draft-ietf-mip6-ha-switch-00.txt". > >> > >> A list of Internet-Drafts directories can be found in > >> http://www.ietf.org/shadow.html=20 > >> 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-mip6-ha-switch-00.txt". > >> =09 > >> 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=20 > >> 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. > >> =09 > >> =09 > >> Below is the data which will enable a MIME compliant mail reader > >> implementation to automatically retrieve the ASCII version of the > >> Internet-Draft. > >> > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 06:44:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsdiw-0005if-4E; Tue, 20 Jun 2006 06:44:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsdiv-0005iR-CB for mip6@ietf.org; Tue, 20 Jun 2006 06:44:45 -0400 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsdis-0001WS-OF for mip6@ietf.org; Tue, 20 Jun 2006 06:44:45 -0400 Received: from rodin.i2r.a-star.edu.sg (localhost [127.0.0.1]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id k5KAiYBc021242 for ; Tue, 20 Jun 2006 18:44:34 +0800 (SGT) Received: from newmailhost.i2r.a-star.edu.sg ([192.122.134.76]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id k5KAiY7A021231 for ; Tue, 20 Jun 2006 18:44:34 +0800 (SGT) Received: from mailbe01.teak.local.net ([192.122.134.10]) by mailhost.lit.org.sg (Sun Java System Messaging Server 6.1 HotFix 0.06 (built Nov 11 2004)) with ESMTP id <0J1500BMLN6C6R10@mailhost.lit.org.sg> for mip6@ietf.org; Tue, 20 Jun 2006 18:44:37 +0800 (SGT) Received: from mailfe01.teak.local.net ([192.122.134.9]) by mailbe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 18:44:17 +0800 Received: from D8ZXLJ1S ([192.168.137.186]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 18:44:16 +0800 Date: Tue, 20 Jun 2006 18:44:50 +0800 From: QIU Ying Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction To: Shinta Sugimoto , Rajeev Koodli Message-id: <05c001c69456$8ea368d0$ba89a8c0@D8ZXLJ1S> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> <20060620103743.AA20.SHINTA@sfc.wide.ad.jp> X-OriginalArrivalTime: 20 Jun 2006 10:44:16.0786 (UTC) FILETIME=[7A602F20:01C69456] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mip6@ietf.org, Vijay Devarapalli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, Shinta My cents is also inline. >> ps: location privacy as such is being discussed in a problem statement >> draft, and there is also a mobopts drfat on solutions. Please have a look >> at them. Thanks. > > Thanks for the information. I've just read the ps and solution drafts. Thanks for your attention on the drafts. > > Still I am not quite sure if I understand the exact issue being > discussed on this thread. Is the issue 1) how to identify correspondent > node with whom the mobile node already established a sessoin based on a > given HoA, In MIPv6, after receiving a BU message from MN, the CN check it BU cache. If no entry about the MN, CN create a new entry for the MN. In other word, if there is the MN entry in BU cache, it means the MN has already established a connection. Of course, the entry is not for a specifical session only, it is for the connection between two peers. >or 2) how to provide HoA agility when the mobile node changes > it's HoA from one to another (for privacy reason), or both ? a pseudo HoA is used to replace the actual HoA. pseudo home address = one of home network prefix || Enc(Kph_i, interface ID) More detail please refer to our new version that should be online by the weekend. Regards and Thanks Qiu Ying > > > Regards, > Shinta > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts ------------ Institute For Infocomm Research - Disclaimer ------------- This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you. -------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 07:13:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FseB1-0004SX-3r; Tue, 20 Jun 2006 07:13:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FseAz-0004SR-UU for mip6@ietf.org; Tue, 20 Jun 2006 07:13:45 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fse9q-00039m-UQ for mip6@ietf.org; Tue, 20 Jun 2006 07:13:45 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id CF3724D8AF; Tue, 20 Jun 2006 20:12:30 +0900 (JST) Date: Tue, 20 Jun 2006 14:12:27 +0300 From: Shinta Sugimoto To: QIU Ying Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction In-Reply-To: <05c001c69456$8ea368d0$ba89a8c0@D8ZXLJ1S> References: <20060620103743.AA20.SHINTA@sfc.wide.ad.jp> <05c001c69456$8ea368d0$ba89a8c0@D8ZXLJ1S> Message-Id: <20060620135048.AA2C.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: mip6@ietf.org, mobopts@irtf.org, Rajeev Koodli , Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ying, please find my comments below. On Tue, 20 Jun 2006 18:44:50 +0800 QIU Ying wrote: >=20 > Hi, Shinta >=20 > My cents is also inline. >=20 > >> ps: location privacy as such is being discussed in a problem statement > >> draft, and there is also a mobopts drfat on solutions. Please have a l= ook > >> at them. Thanks. > > > > Thanks for the information. I've just read the ps and solution drafts. >=20 > Thanks for your attention on the drafts. > > > > Still I am not quite sure if I understand the exact issue being > > discussed on this thread. Is the issue 1) how to identify corresponden= t > > node with whom the mobile node already established a sessoin based on a > > given HoA, >=20 > In MIPv6, after receiving a BU message from MN, the CN check it BU cache.= If=20 > no entry about the MN, CN create a new entry for the MN. In other word, i= f=20 > there is the MN entry in BU cache, it means the MN has already establishe= d a=20 > connection. I assume, you are referring to a binding association between the MN and CN by the "connection" in above sentence. > Of course, the entry is not for a specifical session only, it is=20 > for the connection between two peers. Yes. =46rom MN's perspective (also from CN's perspective), it's quite obvious if there has already been a binding association established with a given CN or not, from its BUL (in case of CN, it can be found in BC as you said). What I meant by 1) is how can the MN identify with which CN, it has one or more TCP session which is based on its HoA. Note that I am *not* asking if it's possible or not (I think it's possible, BTW), but I am clarifying if it's the issue being discussed on this thread or not. >=20 > >or 2) how to provide HoA agility when the mobile node changes > > it's HoA from one to another (for privacy reason), or both ? >=20 > a pseudo HoA is used to replace the actual HoA. > pseudo home address =3D one of home network prefix || Enc(Kph_i, interfac= e ID) Ok. > More detail please refer to our new version that should be online by the= =20 > weekend. Ok, thanks. Will check that. Regards, Shinta _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 08:45:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsfc9-0003Yy-DE; Tue, 20 Jun 2006 08:45:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsfc7-0003Yt-Qb for mip6@ietf.org; Tue, 20 Jun 2006 08:45:51 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsfc6-0002Pi-W5 for mip6@ietf.org; Tue, 20 Jun 2006 08:45:51 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 14:45:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) Date: Tue, 20 Jun 2006 14:45:40 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03F1E05E@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) Thread-Index: AcaQ0ZbY1YH1fvzEEdqHQQARJNUNiAC3UJ9A From: To: , , X-OriginalArrivalTime: 20 Jun 2006 12:45:49.0377 (UTC) FILETIME=[75194310:01C69467] X-Spam-Score: 0.2 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Cc: jari.arkko@kolumbus.fi, mccap@lucent.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, > Henrik, >=20 > In the DS-MIP6 case the reasoning for the work has been that=20 > IPv6 native > access is not expected to be ubiquitous and hence given that=20 > the host is DS > and access is IPv4, there is a need to enable MIP6 continuity=20 > while being > attached to a v4 network. The ability to carry IPv4 within=20 > the MIP6 session > is to enable applications and services that are v4 based on=20 > the hosts and is > applicable in the scenario when the host is connected to a=20 > native v6 access > only (which I guess we believe will be the situation at some=20 > point in the > future). So I believe there is a good reason to do this for MIP6. Don't we have this situation in a way already? If I remember correctly e.g. in 2G/3G a DS terminal can open either an IPv4 or IPv6 PDP context. So if you want IPv6 over your cellular you are stuck in IPv6 only access for that context. Of course then it is up to the terminal and/or GGSN implementations whether they allow multiple primary contexts of different IP version (and possibly to the same APN), which might not always be the case.. Jouni >=20 > In the case of IPv4 hosts which are DS and MIP4 enabled, I do=20 > not think that > you have to contend with the fact that you have to deal with=20 > a v6 access > only. Secondly if the v6 stack on the host needs to connect=20 > to a v6 router, > it could just as well use a standard transition mechanism. So=20 > having IPv6 > packets carried over a MIP4 session IMO is not really a=20 > critical need. If > there is a belief that a MIP4 based transition mechanism for=20 > IPv6 is needed, > then fine. I think that would be the only requirement for=20 > such a solution. >=20 > -Raj >=20 >=20 > On 6/15/06 1:46 PM, "ext Henrik Levkowetz"=20 > wrote: >=20 > > Hi James, > >=20 > > on 2006-06-15 19:03 James Kempf said the following: > >> So I'm wondering if there is any work to be done here in=20 > addition to the > >> draft that is currently being worked on in the MIP6 WG? If=20 > the only work > >> involves having someone from the MIP4 WG review the draft,=20 > then is there > >> really need for a new charter item? On the other hand, if=20 > there is need for > >> another document describing the interaction between the=20 > MIP6 transition work > >> and MIP4, then maybe there is need for a new charter item=20 > (but if that is > >> true, I'd say it's a flaw in the MIP6 transition document,=20 > and it should be > >> handled by updating that). > >=20 > > This work item covers the ability of MIPv4 to carry IPv6=20 > packets, and does > > not overlap with the MIP6 work of giving MIPv6 the ability=20 > to carry IPv4 > > packets and run over IPv4 access networks. > >=20 > > Regards, > >=20 > > Henrik > >=20 > >=20 > >> jak > >>=20 > >> ----- Original Message ----- > >> From: "Jari Arkko" > >> To: "Mobile IPv6 Mailing List" > >> Cc: "Peter McCann" ; "Henrik Levkowetz" > >> > >> Sent: Thursday, June 15, 2006 7:49 AM > >> Subject: [Mip6] FW: Internal WG Review: Recharter of=20 > Mobility for IPv4 > >> (mip4) > >>=20 > >>=20 > >>>=20 > >>> FYI -- MIP4 wants to recharter to include work on dual stack > >>> Mobile IPv4 support (item 10 below). Given that MIP6 also > >>> works on related issues I wanted to point you to this update. > >>> Comments welcome. > >>>=20 > >>> --Jari > >>>=20 > >>> IESG Secretary wrote: > >>>=20 > >>>> A new charter for the Mobility for IPv4 (mip4) working=20 > group in the > >>>> Internet > >>>> Area of the IETF is being considered. The draft charter=20 > is provided below > >>>> for > >>>> your review and comment. > >>>>=20 > >>>> Review time is one week. > >>>>=20 > >>>> The IETF Secretariat > >>>>=20 > >>>> +++ > >>>>=20 > >>>> Mobility for IPv4 (mip4) > >>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > >>>>=20 > >>>> Last Modified: 2006-06-13 > >>>>=20 > >>>> Current Status: Active Working Group > >>>>=20 > >>>> Chair(s): > >>>> Peter McCann > >>>> Henrik Levkowetz > >>>>=20 > >>>> Internet Area Director(s): > >>>> Jari Arkko > >>>> Mark Townsley > >>>>=20 > >>>> Internet Area Advisor: > >>>> Jari Arkko > >>>>=20 > >>>> Mailing Lists: > >>>> General Discussion: mip4@ietf.org > >>>> To Subscribe: mip4-request@ietf.org > >>>> In Body: subscribe > >>>> Archive: http://www.ietf.org/mail-archive/web/mip4/index.html > >>>>=20 > >>>> Description of Working Group: > >>>>=20 > >>>> IP mobility support for IPv4 nodes (hosts and routers)=20 > is specified in > >>>> RFC3344. RFC 3344 mobility allows a node to continue using > >>>> its "permanent" home address as it moves around the Internet. The > >>>> Mobile IP protocols support transparency above the IP=20 > layer, including > >>>> maintenance of active TCP connections and UDP port=20 > bindings.Besides > >>>> the basic Mobile IPv4 (MIPv4) protocols, several other=20 > drafts deal > >>>> with concerns such as optimization, security,=20 > extensions, AAA support, > >>>> and deployment issues. > >>>>=20 > >>>> MIPv4 is currently being deployed on a wide basis (e.g.,=20 > in cdma2000 > >>>> networks). The scope of the deployment is on a fairly=20 > large scale and > >>>> accordingly, the MIP4 WG will focus on deployment issues and on > >>>> addressing known deficiencies and shortcomings in the=20 > protocol that > >>>> have come up as a result of deployment experience.=20 > Specifically, the > >>>> working group will complete the work items to facilitate=20 > interactions > >>>> with AAA environments, interactions with enterprise=20 > environments when > >>>> MIPv4 is used therein, and updating existing protocol=20 > specifications > >>>> in accordance with deployment needs and advancing those=20 > protocols that > >>>> are on the standards track. > >>>>=20 > >>>> Work expected to be done by the MIP4 WG as proposed by=20 > this charter is > >>>> as follows: > >>>>=20 > >>>> 1. MIPv4 has been a proposed standard for several years.=20 > It has been > >>>> adopted by other standard development organizations and has been > >>>> deployed commercially. One of the next steps for the WG=20 > is to advance > >>>> the protocol to draft standard status. As part of advancing base > >>>> Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised > >>>> to reflect implementation experience > >>>>=20 > >>>> 2. Work items that are pending from the previous Mobile=20 > IP WG, which > >>>> will be completed by the MIP4 WG, are: > >>>>=20 > >>>> - completion of the MIB for the revised base Mobile IP > >>>> specification (2006bis) > >>>>=20 > >>>> - regional registration draft. > >>>>=20 > >>>> 3. The MIP4 WG will also complete the work on MIPv4 interactions > >>>> in VPN scenarios. This work will involve identifying the=20 > requirements > >>>> and a solution development for MIPv4 operation in the presence > >>>> of IPsec VPNs. > >>>>=20 > >>>> 4. Additionally, a proposal has been made for how MOBIKE=20 > could work > >>>> together with MIPv4. This proposal does not describe any=20 > new protocol, > >>>> but formulates a best current practice for deploying=20 > MOBIKE together > >>>> with MIPv4. The working group will adopt and complete=20 > this document. > >>>>=20 > >>>> 5. Some issues have been raised with respect to RFC3519.=20 > These will be > >>>> identified and addressed as appropriate, through errata, revision > >>>> of RFC 3519, and/or supplemental documents as needed. > >>>>=20 > >>>> 6. It has been proposed that the FMIP protocol, which has been > >>>> standardised for MIPv6 in the MIPSHOP working group,=20 > should also be > >>>> published as an experimental protocol for MIPv4. A draft for this > >>>> exists. The working group will take up and carry this=20 > work forward > >>>> to publication > >>>>=20 > >>>> 7. An extension to carry generic strings in the=20 > Registration Reply > >>>> message has been proposed. The purpose is to supply supplemental > >>>> human-readable information intended to the MN user. The working > >>>> group will complete the specification and applicability=20 > statement of > >>>> such an extension. > >>>>=20 > >>>> 8. RADIUS attributes for MIP4. A set of RADIUS attributes has > >>>> been proposed for MIPv4. > >>>>=20 > >>>> The working group will first produce a requirements=20 > specification, > >>>> describing how the work differs from the requirements in RFC 2977 > >>>> and the functionality provided by RFC 4004 (the MIPv4=20 > Diameter App). > >>>> The reason why this first step is required is that RFC=20 > 3127 pretty > >>>> clearly shows that full 2977 functionality can't be=20 > provided by even > >>>> a considerably extended RADIUS, so we need to match the=20 > requirements > >>>> to what can be done within RADIUS. > >>>>=20 > >>>> Provided the requirements work finds approval with ADs=20 > and radext, > >>>> the workgroup will complete the specification of MIPv4 RADIUS > >>>> attributes, solicit feedback from the Radius Extensions=20 > WG, adjust, > >>>> and submit this for publication. > >>>>=20 > >>>> 9. MIPv4 Extension for Configuration Options. > >>>>=20 > >>>> Several drafts have proposed extensions to help improve=20 > configuration > >>>> of MIPv4 clients. The latest proposal is for a general=20 > configuration > >>>> option extension which could carry information such as e.g., DNS > >>>> address and DHCP server address. The working group will take on > >>>> and complete one proposal for a configuration option extension. > >>>>=20 > >>>> 10. Dual-stack Support > >>>>=20 > >>>> There have been several proposals for how to enable an IPv6 > >>>> connection over a network that supports Mobile IPv4. The > >>>> basic idea is to include an IPv6 address in the Mobile IPv4 > >>>> signaling messages. The working group will take on and complete > >>>> one proposal for IPv6 over Mobile IPv4. > >>>>=20 > >>>> Goals and Milestones: > >>>>=20 > >>>> Done AAA Keys for MIPv4 to IESG > >>>> Done MIPv4 VPN interaction problem statement to IESG > >>>> Done Low latency handover to experimental > >>>> Done Experimental MIPv4 message and extensions draft to IESG > >>>> Done Dynamic Home Agent assignment protocol solution to IESG > >>>> Done Revised MIPv4 Challenge/Response (3012bis) to IESG > >>>> Done Regional registration document to IESG > >>>> Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT=20 > WG for comment > >>>> Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.)=20 > to the IESG > >>>> May 2006 MIPv4 Mobike interaction (BCP) to the IESG > >>>> May 2006 MIPv4 VPN interaction (BCP) to the IESG > >>>> May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment > >>>> Jun 2006 Revised MIPv4 specification to IESG for Draft Std. > >>>> Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG > >>>> Aug 2006 MIPv4 Extension for Config. Options (Proposed=20 > Std.) to the IESG > >>>> Sep 2006 FMIPv4 (Experimental) to the IESG > >>>> Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG > >>>> Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG > >>>> Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG > >>>> Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG > >>>>=20 > >>>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> _______________________________________________ > >>> Mip6 mailing list > >>> Mip6@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mip6 > >>>=20 > >>=20 > >>=20 > >>=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 13:50:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskN4-0002xl-Fr; Tue, 20 Jun 2006 13:50:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskN3-0002x0-3t for mip6@ietf.org; Tue, 20 Jun 2006 13:50:37 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FskJl-00053S-43 for mip6@ietf.org; Tue, 20 Jun 2006 13:47:14 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 10:47:12 -0700 Message-ID: <4498342D.2030708@azairenet.com> Date: Tue, 20 Jun 2006 10:45:17 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction References: <7EB20EA0938B4D42A2D82689365C9B7A04F95A@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04F95A@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 17:47:12.0185 (UTC) FILETIME=[8F4ACA90:01C69491] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > > One option would be to run Shim6 over MIPv6. Such usage has > > > already been discussed in Shim6 WG. By mobile node establishing > > > Shim6 context with its HA/CN, it could utilize multiple HoAs > > > without annoying upper layer protocols. > > > > yes, this can be done. but I would like to restrict > > shim6 usage when mip6 is used to the case where the > > home link is site multihomed and the mobile node already > > has the multiple home addresses configured on it. not > > when the mobile node decides to change its home address. > > => There is no difference between the two scenarios. your reply is too cryptic. when shim6 is used, one cannot start using another address without first adding that address to the list of addresses that the HA/CN need to be aware of (basically add to the shim6 state). also, if both home addresses are from the same prefix, shim6 shouldn't be used. if the home link is multihomed and the mobile node has multiple home addresses from the different prefixes, then shim6 is applicable. ofcourse, one can do all this with shim6, but then quoting you "shim6 is trying to solve world hunger". ;) (hope you don't mind it). Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 13:50:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskNC-0003Be-0f; Tue, 20 Jun 2006 13:50:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskNA-00037Q-Ae; Tue, 20 Jun 2006 13:50:44 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FskN8-0005Wd-VM; Tue, 20 Jun 2006 13:50:44 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 10:50:42 -0700 Message-ID: <44983503.6050703@azairenet.com> Date: Tue, 20 Jun 2006 10:48:51 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Subject: Re: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 References: <0MKp2t-1FsYuU3mc1-0007WT@mrelay.perfora.net> In-Reply-To: <0MKp2t-1FsYuU3mc1-0007WT@mrelay.perfora.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 17:50:42.0079 (UTC) FILETIME=[0C6612F0:01C69492] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: mip6@ietf.org, 'Heejin Jang' , dhcwg@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alper Yegin wrote: > Vijay, > > As far as I remember you were the only one who didn't give up on pushing for > integration. I think you remember wrong. It'd only be a circular discussion if I had repeated the > reasons for not bundling a bunch of protocol extensions in a single > document. let the MIP6 WG hear the arguments again, since we couldn't reach a conclusion in the design team. > But I hope this data point helps: WiMAX Forum NWG architecture is using > draft-jang. in what context and how are they planning to use it? the WiMAX forum NWG can still use the DHCP options wherever they are defined. Vijay > > Alper > > > >>-----Original Message----- >>From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >>Sent: Monday, June 19, 2006 6:17 PM >>To: Heejin Jang >>Cc: mip6@ietf.org; dhcwg@ietf.org >>Subject: Re: [Mip6] [Updated] DHCP Option for Home Information Discovery >>inMIPv6 >> >>Heejin Jang wrote: >> >>>Hello folks, >>>We posted an I-D that proposes new DHCP Options for Home Information >>>Discovery in MIPv6. >>> >>>Kindly note that the previous version of this draft is >>>"draft-jang-dhc-haopt-02.txt" but the name is slightly changed into >>>"draft-jang-mip6-hiopt-00.txt" while keeping almost the same contents. >>> >>>The drafts referencing this draft such as >>>draft-ietf-mip6-bootstrapping-split-02.txt and >>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt need to be revised >>>accordingly. >>> >>>We would appreciate to hear your comments. >> >>when this draft was discussed in the MIP6 bootstrapping >>design team, many people wanted to integrate the two DHCP >>options into >>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. >>this was mainly because the options defined in the document >>have limited applicability beyond the integrated scenario >>solution document. the only other mechanism is to manually >>configure the DHCP servers in the visited link with >>information like home agent address, home address and home >>prefix. this is a bad idea. >> >>there was some opposition and we never reached an agreement. >> >>so I suggest including these options into the integrated >>scenario solution document for these options to get >>standardized quickly. >> >>Vijay >> >>_______________________________________________ >>Mip6 mailing list >>Mip6@ietf.org >>https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 13:56:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskSG-0006iE-FD; Tue, 20 Jun 2006 13:56:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FskSF-0006hL-Q5 for mip6@ietf.org; Tue, 20 Jun 2006 13:55:59 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FskSE-0006aT-84 for mip6@ietf.org; Tue, 20 Jun 2006 13:55:59 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 10:55:57 -0700 Message-ID: <4498363E.4050702@azairenet.com> Date: Tue, 20 Jun 2006 10:54:06 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shinta Sugimoto Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction References: <20060619095506.AA0E.SHINTA@sfc.wide.ad.jp> <44973D7B.6030109@azairenet.com> <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> In-Reply-To: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 17:55:57.0270 (UTC) FILETIME=[C8446760:01C69492] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Shinta Sugimoto wrote: >> >>>>The problem here is how does the MN know to "let the >>>>existing sessions continue with the existing HoA"? If there is no CN's >>>>address in BUL, surely the MN can choose a suitable HoA. For >>>>a CN with which it has a binding, it has no reliable way of knowing >>>>whether there are any ULP sessions. >>> >>>If you need to maintain the sessions while changing the HoA >>>from one to another, I think you need additional mechanism >>>than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed >>>to assure the reachability to a given HoA with the current >>>location of the mobile node (CoA). If the app wants >>>to change HoAs for some reason (I assume that privacy is the >>>main interest), there is a need to maintain the mapping of >>>the identity and the locator of the mobile node. >> >>Mobile IPv6 today allows you to use two home addresses >>at the same time. it also allows you to bind both home >>addresses to the same CoA. > > > Yes, that's true. But then there is a problem to choose > which one for which communication. When it comes to agility, > it's more problematic. actually we are not looking for address agility here. we want the mobile node to change its home address and while changing it allow existing sessions using the old home address to continue and start using the new home address for new sessions. not sure if shim6 addresses this. >>>One option would be to run Shim6 over MIPv6. Such usage has >>>already been discussed in Shim6 WG. By mobile node establishing >>>Shim6 context with its HA/CN, it could utilize multiple HoAs >>>without annoying upper layer protocols. >> >>yes, this can be done. but I would like to restrict >>shim6 usage when mip6 is used to the case where the >>home link is site multihomed and the mobile node already >>has the multiple home addresses configured on it. not >>when the mobile node decides to change its home address. > > > I think it depends on motivation whether it makes sense > to apply Shim6 here. Utilizing Shim6 would allow HoA agility > (from ULP point of view). see above. >>>I have some additional questions: >>> >>>- If privacy is the main concern, would you think >>>http://www.ietf.org/internet-drafts/draft-dupont-mip6-privacyext-03.txt >>>would help to solve your initial requirement ? If not, could >>>you please tell me why ? >> >>I think its orthogonal. the use of pseudo-HoA instead >>of the actual HoA is also being worked on in mobopts. > > > I've read the solution draft from the mobopts > > and it seems to me that both draft try to achieve the same goal. there were a bunch of solution drafts on mip6 privacy (I think four of them). draft-irtf-mobopts-location-privacy-solutions-01.txt, is trying to come up with one solution. >>>- Do you assume that different HoAs that mobile node may >>>request are derived from different home prefixes ? Or are you >>>considering that the node generates HoAs from a single prefix >>>with privacy extension ? >> >>I think its the same prefix, but I guess its better if >>Rajeev clarifies. > > Ok, it seems so (HoAs are derived from same prefix). see my reply to Hesham. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 14:27:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fskwu-0001OC-Lb; Tue, 20 Jun 2006 14:27:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fskwt-0001Je-1D; Tue, 20 Jun 2006 14:27:39 -0400 Received: from mout.perfora.net ([217.160.230.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fskwr-0002LY-OR; Tue, 20 Jun 2006 14:27:39 -0400 Received: from [68.126.201.46] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1Fskwf2rab-0000pr; Tue, 20 Jun 2006 14:27:30 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" Subject: RE: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 Date: Tue, 20 Jun 2006 11:27:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaUkgzyKo2E0mALQn2E2eB58MMfPQAAlbgA In-Reply-To: <44983503.6050703@azairenet.com> Message-ID: <0MKoyl-1Fskwf2rab-0000pr@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: mip6@ietf.org, 'Heejin Jang' , dhcwg@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > Vijay, > > > > As far as I remember you were the only one who didn't give up on pushing > for > > integration. > > I think you remember wrong. Can we hear from someone else who insists we shall bundle up the I-Ds? > It'd only be a circular discussion if I had repeated the > > reasons for not bundling a bunch of protocol extensions in a single > > document. > > let the MIP6 WG hear the arguments again, since we couldn't > reach a conclusion in the design team. You really want us to circle around, don't you :-) > > But I hope this data point helps: WiMAX Forum NWG architecture is using > > draft-jang. > > in what context and how are they planning to use it? The MIP info is brought to the DHCP server via RADIUS and delivered to the MN via DHCP. > the > WiMAX forum NWG can still use the DHCP options wherever > they are defined. Yes. And WiMAX Forum could also use it even if IETF had concatenated all of the RFCs and I-Ds under a single document too.... This I-D being referenced whereas the draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt wasn't is a solid proof that the former I-D is useful without having to be integrated into the latter. > >>the only other mechanism is to manually > >>configure the DHCP servers in the visited link with > >>information like home agent address, home address and home > >>prefix. this is a bad idea. You know that one does not have to put DHCP servers on every subnet, instead one can rely on DHCP relays. And that's the used technique for many enterprise networks. So, I don't see why this is a bad idea. Alper > > Vijay > > > > > Alper > > > > > > > >>-----Original Message----- > >>From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > >>Sent: Monday, June 19, 2006 6:17 PM > >>To: Heejin Jang > >>Cc: mip6@ietf.org; dhcwg@ietf.org > >>Subject: Re: [Mip6] [Updated] DHCP Option for Home Information Discovery > >>inMIPv6 > >> > >>Heejin Jang wrote: > >> > >>>Hello folks, > >>>We posted an I-D that proposes new DHCP Options for Home Information > >>>Discovery in MIPv6. > >>> > >>>Kindly note that the previous version of this draft is > >>>"draft-jang-dhc-haopt-02.txt" but the name is slightly changed into > >>>"draft-jang-mip6-hiopt-00.txt" while keeping almost the same contents. > >>> > >>>The drafts referencing this draft such as > >>>draft-ietf-mip6-bootstrapping-split-02.txt and > >>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt need to be revised > >>>accordingly. > >>> > >>>We would appreciate to hear your comments. > >> > >>when this draft was discussed in the MIP6 bootstrapping > >>design team, many people wanted to integrate the two DHCP > >>options into > >>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. > >>this was mainly because the options defined in the document > >>have limited applicability beyond the integrated scenario > >>solution document. the only other mechanism is to manually > >>configure the DHCP servers in the visited link with > >>information like home agent address, home address and home > >>prefix. this is a bad idea. > >> > >>there was some opposition and we never reached an agreement. > >> > >>so I suggest including these options into the integrated > >>scenario solution document for these options to get > >>standardized quickly. > >> > >>Vijay > >> > >>_______________________________________________ > >>Mip6 mailing list > >>Mip6@ietf.org > >>https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 14:44:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FslD8-0002WJ-7V; Tue, 20 Jun 2006 14:44:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FslD7-0002W9-9U; Tue, 20 Jun 2006 14:44:25 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FslD5-0003uR-UZ; Tue, 20 Jun 2006 14:44:25 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 11:44:22 -0700 Message-ID: <44984198.3050502@azairenet.com> Date: Tue, 20 Jun 2006 11:42:32 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Subject: Re: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 References: <0MKoyl-1Fskwf2rab-0000pr@mrelay.perfora.net> In-Reply-To: <0MKoyl-1Fskwf2rab-0000pr@mrelay.perfora.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 18:44:23.0198 (UTC) FILETIME=[8C55D3E0:01C69499] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: mip6@ietf.org, 'Heejin Jang' , dhcwg@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alper Yegin wrote: >>It'd only be a circular discussion if I had repeated the >> >>>reasons for not bundling a bunch of protocol extensions in a single >>>document. >> >>let the MIP6 WG hear the arguments again, since we couldn't >>reach a conclusion in the design team. > > > You really want us to circle around, don't you :-) well, now you want the MIP6 WG to adopt draft-jang as a WG document, right? then you need to make a case for it. >>>But I hope this data point helps: WiMAX Forum NWG architecture is using >>>draft-jang. >> >>in what context and how are they planning to use it? > > > The MIP info is brought to the DHCP server via RADIUS and delivered to the > MN via DHCP. this is very bad. the draft that describes how to use DHCPv6 for MIP6 bootstrapping is draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. not *any other* draft. WiMAX NWG needs to be told that. the following figure in draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt very important for someone to understand how to use DHCPv6 for MIP6 bootstrapping. The following diagram shows the network elements and layout in the integrated scenario: | ASP(/MSP) | ASA/MSA(/MSP) | | +-------+ | +-------+ | | | | | |AAAV |-----------|--------|AAAH | | | | | | | | | | | +-------+ | +-------+ | | | | | | | | | | | | | | +-----+ +------+ | +----+ | | |DHCP | | | MN |------| NAS/|----|Server| | +----+ |Relay| | | | +-----+ +------+ | | | +--------+ | +--------+ | HA | | | HA | | in ASP | | |in MSP | +--------+ | +--------+ >>the >>WiMAX forum NWG can still use the DHCP options wherever >>they are defined. > > Yes. And WiMAX Forum could also use it even if IETF had concatenated all of > the RFCs and I-Ds under a single document too.... This I-D being referenced > whereas the draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt wasn't is a > solid proof that the former I-D is useful without having to be integrated > into the latter. I am afraid the WiMAX NWG is referring to the wrong document. the use of DHCPv6 for MIP6 bootstrapping is defined in draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. >>>>the only other mechanism is to manually >>>>configure the DHCP servers in the visited link with >>>>information like home agent address, home address and home >>>>prefix. this is a bad idea. > > > You know that one does not have to put DHCP servers on every subnet, instead > one can rely on DHCP relays. And that's the used technique for many > enterprise networks. So, I don't see why this is a bad idea. and DHCP relay messages cross firewalls and network boundaries? come on... Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 14:52:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FslKX-0000Er-27; Tue, 20 Jun 2006 14:52:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FslKV-0000Em-LE for mip6@ietf.org; Tue, 20 Jun 2006 14:52:03 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FslKU-0005R9-6p for mip6@ietf.org; Tue, 20 Jun 2006 14:52:03 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5KIpwtR008393; Tue, 20 Jun 2006 21:51:58 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 21:51:58 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:51:53 -0500 Received: from 172.19.244.70 ([172.19.244.70]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Jun 2006 18:51:53 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 20 Jun 2006 13:52:04 -0500 From: Basavaraj Patil To: Message-ID: Thread-Topic: Conclusion of the tunnel mode option discussion in I-D: draft-ietf-mip6-ikev2-ipsec-06 Thread-Index: AcaUmp7+3ZySagCNEdu6mAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 18:51:53.0768 (UTC) FILETIME=[98E55A80:01C6949A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ext Jari Arkko , ext Vijay Devarapalli , "ext Soliman, Hesham" Subject: [Mip6] Conclusion of the tunnel mode option discussion in I-D: draft-ietf-mip6-ikev2-ipsec-06 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org During the WG last call of I-D: draft-ietf-mip6-ikev2-ipsec-06.txt, Hesham had raised an issue about the support for using IPsec in tunnel mode for securing the BU/BAck messages. http://www1.ietf.org/mail-archive/web/mip6/current/msg04383.html The chairs have come to the conclusion from the discussion and the arguments (offline and on the list) that incorporating text that explains the tunnel mode operation makes sense and hence will be kept in the I-D. It should be noted that the tunnel mode support is optional and the default method will continue to be the one mandated in RFC3775 (i.e ESP in transport mode for securing BU/BAck). -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 15:35:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsm0j-0002K1-0l; Tue, 20 Jun 2006 15:35:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsm0i-0002JH-A2 for mip6@ietf.org; Tue, 20 Jun 2006 15:35:40 -0400 Received: from ccerelbas01.cce.hp.com ([161.114.21.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsm0g-00012P-TY for mip6@ietf.org; Tue, 20 Jun 2006 15:35:40 -0400 Received: from mailrelay01.cce.cpqcorp.net (relay.cpqcorp.net [16.47.68.171]) by ccerelbas01.cce.hp.com (Postfix) with ESMTP id 6E6D934132; Tue, 20 Jun 2006 14:35:36 -0500 (CDT) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 3F986C871; Tue, 20 Jun 2006 14:35:35 -0500 (CDT) Received: from [16.116.96.215] by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id k5KJZZ50001695625; Tue, 20 Jun 2006 15:35:35 -0400 (EDT) Message-ID: <44984E06.3030009@hp.com> Date: Tue, 20 Jun 2006 15:35:34 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: Kilian Weniger Subject: Re: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt References: <4D2F935F08D41A4C8866693F4F0D7C4FB8E5D7@lan-ex-01.panasonic.de> In-Reply-To: <4D2F935F08D41A4C8866693F4F0D7C4FB8E5D7@lan-ex-01.panasonic.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Kilian, >>> At least the draft prevents the MN from keeping >>> the registration with the old HA, which IMHO would be >> neccessary in this >>> case in order to keep existing sessions (using the old HoA) alive. >> The MN should be able to keep it's HoA as long as there is another >> available HA to switch to that's serving that prefix. The HA being switched-to should be serving the same set of prefixes as the current HA, we'll need to add some text to say that SHOULD be the default, else there will be loss of connectivity to the HoA. > The scenario I was talking about is that the switch message sent by the > HA directs the MN to a new HA serving a different link, resulting in a > new HoA for the MN after bootstrapping with this HA. Section 5.1 (MN > operation) says > > "Upon receipt of a Home Agent Switch message, the mobile node MUST > stop using its current home agent for services and MUST delete its > home binding by sending a Binding Update message as described in [2]. > This acts as an acknowledgement of the Home Agent Switch message." > > When strictly following the procedure described in the draft, I don't > see how the MN can keep its old HoA. The MN must send a BU to delete the > binding for the old HoA and cannot skip that, since the BU acts as ack > for the switch message. As I said above, the intention is the new HA should support the HoA. > To support the scenario, it should IMHO be possible to keep the > registration with the old HA (at least for a certain period of time) if > the bootstrapping with the new HA results in a new HoA. The switch > message could indicate (e.g., by a flag) whether the old HA is able to > keep serving the MN as secondary HA for some time (to keep existing > session alive and to keep IP reachability until the new HoA is > published). When receiving a switch message with this flag set, the MN > would not be required to delete the binding at the old HA immediately > (note that strictly speaking this would not be a HA switch, since the > registration with the old HA would not be deleted). The HA is sending the switch message because it can't continue to act as the HA for this MN, so keeping the binding around is not an option. >>> The >>> renumbering scenario mentioned in the draft seems to consider >>> renumbering of HA addresses only, not HoAs. >> The renumbering for the home link can be done with just RFC 3775 >> messages - Mobile Prefix Solicitation and Advertisement. > > yes, but if the above scenario is supported, renumbering of certain HoAs > would also be possible with the switch mechanism only. If the switch > mechanism is needed for renumbering is of course another question. I don't want to burden HA switch with network renumbering, Section 10.6 and 11.4.3 of RFC 3775 already cover this. -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 16:01:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmPB-0006hi-O9; Tue, 20 Jun 2006 16:00:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmGY-0005I0-EY; Tue, 20 Jun 2006 15:52:02 -0400 Received: from mout.perfora.net ([217.160.230.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsmGV-00040n-WE; Tue, 20 Jun 2006 15:52:01 -0400 Received: from [68.126.201.46] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1FsmGM247b-0001nW; Tue, 20 Jun 2006 15:51:55 -0400 From: "Alper Yegin" To: "'Vijay Devarapalli'" Subject: RE: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 Date: Tue, 20 Jun 2006 12:51:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaUmYzQzlntmOahRaWY/z+pBD3OOAACSPUA In-Reply-To: <44984198.3050502@azairenet.com> Message-ID: <0MKp2t-1FsmGM247b-0001nW@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: mip6@ietf.org, 'Heejin Jang' , dhcwg@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > You know that one does not have to put DHCP servers on every subnet, > instead > > one can rely on DHCP relays. And that's the used technique for many > > enterprise networks. So, I don't see why this is a bad idea. > > and DHCP relay messages cross firewalls and network boundaries? > come on... I'm not talking about deploying DHCP across the Internet. Please see my text above: enterprise networks. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 16:15:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsmcl-0002fp-K8; Tue, 20 Jun 2006 16:14:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsmcj-0002fX-Kb for mip6@ietf.org; Tue, 20 Jun 2006 16:14:57 -0400 Received: from web60313.mail.yahoo.com ([209.73.178.136]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fsmch-0007Hy-2Y for mip6@ietf.org; Tue, 20 Jun 2006 16:14:57 -0400 Received: (qmail 962 invoked by uid 60001); 20 Jun 2006 20:14:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RXC6TfbIXJT6s/eK40eW5auUOLH7ek+ucXCxoHSU9UC4Jfe6R2wzcl5oVIAKZls6+hoFB9NsL49DEnntjlWwIlx0rM7aRJsBWJBoYm5V7VBLMJ6SekuCM9ZZy9IspCHl0jJzY9pq6MtIlg/5RFmsOe8SXcCVRWMZJK5Rt525AU0= ; Message-ID: <20060620201454.957.qmail@web60313.mail.yahoo.com> Received: from [12.129.211.52] by web60313.mail.yahoo.com via HTTP; Tue, 20 Jun 2006 13:14:54 PDT Date: Tue, 20 Jun 2006 13:14:54 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 To: Vijay Devarapalli , Alper Yegin In-Reply-To: <44984198.3050502@azairenet.com> MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: mip6@ietf.org, Heejin Jang , dhcwg@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0927258879==" Errors-To: mip6-bounces@ietf.org --===============0927258879== Content-Type: multipart/alternative; boundary="0-729382611-1150834494=:95704" --0-729382611-1150834494=:95704 Content-Type: text/plain; charset=us-ascii Hi Vijay, In the current NWG document only draft-jang-dhc-haopt-01.txt is referred and draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt is not. The latter draft requires DHCP server to provide the bootstrap info while as Alper said in WiMAX forum NWG's current draft, the info is provided by the AAA server to the DHCP relay and then all you need is draft-jang. It seems like NWG is introducing yet another method of bootstrapping and is not following your advise. Regards, --behcet ----- Original Message ---- From: Vijay Devarapalli To: Alper Yegin Cc: mip6@ietf.org; Heejin Jang ; dhcwg@ietf.org Sent: Tuesday, June 20, 2006 1:42:32 PM Subject: Re: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 Alper Yegin wrote: >>It'd only be a circular discussion if I had repeated the >> >>>reasons for not bundling a bunch of protocol extensions in a single >>>document. >> >>let the MIP6 WG hear the arguments again, since we couldn't >>reach a conclusion in the design team. > > > You really want us to circle around, don't you :-) well, now you want the MIP6 WG to adopt draft-jang as a WG document, right? then you need to make a case for it. >>>But I hope this data point helps: WiMAX Forum NWG architecture is using >>>draft-jang. >> >>in what context and how are they planning to use it? > > > The MIP info is brought to the DHCP server via RADIUS and delivered to the > MN via DHCP. this is very bad. the draft that describes how to use DHCPv6 for MIP6 bootstrapping is draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. not *any other* draft. WiMAX NWG needs to be told that. the following figure in draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt very important for someone to understand how to use DHCPv6 for MIP6 bootstrapping. The following diagram shows the network elements and layout in the integrated scenario: | ASP(/MSP) | ASA/MSA(/MSP) | | +-------+ | +-------+ | | | | | |AAAV |-----------|--------|AAAH | | | | | | | | | | | +-------+ | +-------+ | | | | | | | | | | | | | | +-----+ +------+ | +----+ | | |DHCP | | | MN |------| NAS/|----|Server| | +----+ |Relay| | | | +-----+ +------+ | | | +--------+ | +--------+ | HA | | | HA | | in ASP | | |in MSP | +--------+ | +--------+ >>the >>WiMAX forum NWG can still use the DHCP options wherever >>they are defined. > > Yes. And WiMAX Forum could also use it even if IETF had concatenated all of > the RFCs and I-Ds under a single document too.... This I-D being referenced > whereas the draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt wasn't is a > solid proof that the former I-D is useful without having to be integrated > into the latter. I am afraid the WiMAX NWG is referring to the wrong document. the use of DHCPv6 for MIP6 bootstrapping is defined in draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. >>>>the only other mechanism is to manually >>>>configure the DHCP servers in the visited link with >>>>information like home agent address, home address and home >>>>prefix. this is a bad idea. > > > You know that one does not have to put DHCP servers on every subnet, instead > one can rely on DHCP relays. And that's the used technique for many > enterprise networks. So, I don't see why this is a bad idea. and DHCP relay messages cross firewalls and network boundaries? come on... Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --0-729382611-1150834494=:95704 Content-Type: text/html; charset=us-ascii
Hi Vijay,
  In the current NWG document only draft-jang-dhc-haopt-01.txt is referred and draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt is not. The latter draft requires DHCP server to provide the bootstrap info while as Alper said in WiMAX forum NWG's current draft, the info is provided by the AAA server to the DHCP relay and then all you need is draft-jang. It seems like NWG is introducing yet another method of bootstrapping and is not following your advise.
Regards,

--behcet

----- Original Message ----
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
To: Alper Yegin <alper.yegin@yegin.org>
Cc: mip6@ietf.org; Heejin Jang <heejin.jang@samsung.com>; dhcwg@ietf.org
Sent: Tuesday, June 20, 2006 1:42:32 PM
Subject: Re: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6

Alper Yegin wrote:

>>It'd only be a circular discussion if I had repeated the
>>
>>>reasons for not bundling a bunch of protocol extensions in a single
>>>document.
>>
>>let the MIP6 WG hear the arguments again, since we couldn't
>>reach a conclusion in the design team.
>
>
> You really want us to circle around, don't you :-)

well, now you want the MIP6 WG to adopt draft-jang as a WG document,
right? then you need to make a case for it.

>>>But I hope this data point helps: WiMAX Forum NWG architecture is using
>>>draft-jang.
>>
>>in what context and how are they planning to use it?
>
>
> The MIP info is brought to the DHCP server via RADIUS and delivered to the
> MN via DHCP.

this is very bad. the draft that describes how to use DHCPv6 for MIP6
bootstrapping is draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt.
not *any other* draft. WiMAX NWG needs to be told that. the following
figure in draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt very
important for someone to understand how to use DHCPv6 for MIP6
bootstrapping.

    The following diagram shows the network elements and layout in the
    integrated scenario:


                                       |
                   ASP(/MSP)           |   ASA/MSA(/MSP)
                                       |
                                       |
                   +-------+           |        +-------+
                   |       |           |        |       |
                   |AAAV   |-----------|--------|AAAH   |
                   |       |           |        |       |
                   |       |           |        |       |
                   +-------+           |        +-------+
                       |               |
                       |               |
                       |               |
                       |               |
                       |               |
                       |               |
                       |               |
                   +-----+    +------+ |
       +----+      |     |    |DHCP  | |
       | MN |------| NAS/|----|Server| |
       +----+      |Relay|    |      | |
                   +-----+    +------+ |
                                       |
                                       |
                   +--------+          |      +--------+
                   | HA     |          |      | HA     |
                   | in ASP |          |      |in MSP  |
                   +--------+          |      +--------+


>>the
>>WiMAX forum NWG can still use the DHCP options wherever
>>they are defined.
>
> Yes. And WiMAX Forum could also use it even if IETF had concatenated all of
> the RFCs and I-Ds under a single document too.... This I-D being referenced
> whereas the draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt wasn't is a
> solid proof that the former I-D is useful without having to be integrated
> into the latter.

I am afraid the WiMAX NWG is referring to the wrong document. the
use of DHCPv6 for MIP6 bootstrapping is defined in
draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt.

>>>>the only other mechanism is to manually
>>>>configure the DHCP servers in the visited link with
>>>>information like home agent address, home address and home
>>>>prefix. this is a bad idea.
>
>
> You know that one does not have to put DHCP servers on every subnet, instead
> one can rely on DHCP relays. And that's the used technique for many
> enterprise networks. So, I don't see why this is a bad idea.

and DHCP relay messages cross firewalls and network boundaries?
come on...

Vijay

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6

--0-729382611-1150834494=:95704-- --===============0927258879== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0927258879==-- From mip6-bounces@ietf.org Tue Jun 20 16:20:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmiY-0003w3-Nk; Tue, 20 Jun 2006 16:20:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmiX-0003vo-7V for mip6@ietf.org; Tue, 20 Jun 2006 16:20:57 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsmiW-0007yl-Ne for mip6@ietf.org; Tue, 20 Jun 2006 16:20:57 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 13:21:22 -0700 Message-ID: <44985831.3060407@azairenet.com> Date: Tue, 20 Jun 2006 13:18:57 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Behcet Sarikaya Subject: Re: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 References: <20060620201454.957.qmail@web60313.mail.yahoo.com> In-Reply-To: <20060620201454.957.qmail@web60313.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 20:21:22.0235 (UTC) FILETIME=[18C068B0:01C694A7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: mip6@ietf.org, Heejin Jang X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org dropped DHC WG from the cc list. Behcet Sarikaya wrote: > Hi Vijay, > In the current NWG document only draft-jang-dhc-haopt-01.txt is > referred and draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt is not. > The latter draft requires DHCP server to provide the bootstrap info > while as Alper said in WiMAX forum NWG's current draft, the info is > provided by the AAA server to the DHCP relay and then all you need is > draft-jang. draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt also assumes that a AAA protocol carries MIP6 bootstrap infrom the home AAA server to the DHCPv6 server in the visited link. after that DHCP is used by the mobile node to get the MIP6 bootstrap info from the DHCP server. > It seems like NWG is introducing yet another method of > bootstrapping and is not following your advise. :) Vijay > Regards, > > --behcet > > ----- Original Message ---- > From: Vijay Devarapalli > To: Alper Yegin > Cc: mip6@ietf.org; Heejin Jang ; dhcwg@ietf.org > Sent: Tuesday, June 20, 2006 1:42:32 PM > Subject: Re: [Mip6] [Updated] DHCP Option for Home Information Discovery > inMIPv6 > > Alper Yegin wrote: > > >>It'd only be a circular discussion if I had repeated the > >> > >>>reasons for not bundling a bunch of protocol extensions in a single > >>>document. > >> > >>let the MIP6 WG hear the arguments again, since we couldn't > >>reach a conclusion in the design team. > > > > > > You really want us to circle around, don't you :-) > > well, now you want the MIP6 WG to adopt draft-jang as a WG document, > right? then you need to make a case for it. > > >>>But I hope this data point helps: WiMAX Forum NWG architecture is using > >>>draft-jang. > >> > >>in what context and how are they planning to use it? > > > > > > The MIP info is brought to the DHCP server via RADIUS and delivered > to the > > MN via DHCP. > > this is very bad. the draft that describes how to use DHCPv6 for MIP6 > bootstrapping is draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. > not *any other* draft. WiMAX NWG needs to be told that. the following > figure in draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt very > important for someone to understand how to use DHCPv6 for MIP6 > bootstrapping. > > The following diagram shows the network elements and layout in the > integrated scenario: > > > | > ASP(/MSP) | ASA/MSA(/MSP) > | > | > +-------+ | +-------+ > | | | | | > |AAAV |-----------|--------|AAAH | > | | | | | > | | | | | > +-------+ | +-------+ > | | > | | > | | > | | > | | > | | > | | > +-----+ +------+ | > +----+ | | |DHCP | | > | MN |------| NAS/|----|Server| | > +----+ |Relay| | | | > +-----+ +------+ | > | > | > +--------+ | +--------+ > | HA | | | HA | > | in ASP | | |in MSP | > +--------+ | +--------+ > > > >>the > >>WiMAX forum NWG can still use the DHCP options wherever > >>they are defined. > > > > Yes. And WiMAX Forum could also use it even if IETF had concatenated > all of > > the RFCs and I-Ds under a single document too.... This I-D being > referenced > > whereas the draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt > wasn't is a > > solid proof that the former I-D is useful without having to be integrated > > into the latter. > > I am afraid the WiMAX NWG is referring to the wrong document. the > use of DHCPv6 for MIP6 bootstrapping is defined in > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. > > >>>>the only other mechanism is to manually > >>>>configure the DHCP servers in the visited link with > >>>>information like home agent address, home address and home > >>>>prefix. this is a bad idea. > > > > > > You know that one does not have to put DHCP servers on every subnet, > instead > > one can rely on DHCP relays. And that's the used technique for many > > enterprise networks. So, I don't see why this is a bad idea. > > and DHCP relay messages cross firewalls and network boundaries? > come on... > > Vijay > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 16:31:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsmsu-0000AY-8q; Tue, 20 Jun 2006 16:31:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsmss-00009e-Eu for mip6@ietf.org; Tue, 20 Jun 2006 16:31:38 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsmsr-0001N6-1J for mip6@ietf.org; Tue, 20 Jun 2006 16:31:38 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5KKVW7W021049 for ; Tue, 20 Jun 2006 23:31:36 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 23:31:31 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 15:31:20 -0500 Received: from 172.19.244.70 ([172.19.244.70]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Jun 2006 20:31:18 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 20 Jun 2006 15:31:28 -0500 From: Basavaraj Patil To: Message-ID: Thread-Topic: Request for slots on agenda for MIP6 WG meeting at IETF66 Thread-Index: AcaUqIHQwHK0uQCbEdu6mAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 20:31:20.0577 (UTC) FILETIME=[7D642710:01C694A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Mip6] Request for slots on agenda for MIP6 WG meeting at IETF66 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, If you need a timeslot on the agenda for the MIP6 WG meeting at IETF66, please send a note to the chairs including the following information: 0. Time needed 1. I-D name 2. If it is not a WG document, explain how this is within the scope of the WG charter -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 17:01:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsnM8-0000Rp-Hl; Tue, 20 Jun 2006 17:01:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsnM6-0000RX-MD for mip6@ietf.org; Tue, 20 Jun 2006 17:01:50 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsnM4-0000RQ-Qd for mip6@ietf.org; Tue, 20 Jun 2006 17:01:50 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5KKeg0j025402; Tue, 20 Jun 2006 23:40:43 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 23:40:43 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 15:40:39 -0500 Received: from 172.19.244.70 ([172.19.244.70]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Jun 2006 20:40:38 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 20 Jun 2006 15:40:49 -0500 Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) From: Basavaraj Patil To: "ext jouni.korhonen@teliasonera.com" , Levkowetz , Message-ID: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) Thread-Index: AcaQ0ZbY1YH1fvzEEdqHQQARJNUNiAC3UJ9AAD69t1c= In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E03F1E05E@SEHAN021MB.tcad.telia.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 20:40:39.0181 (UTC) FILETIME=[CA585BD0:01C694A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Jari Arkko , mccap@lucent.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Jouni, Inline: On 6/20/06 7:45 AM, "ext jouni.korhonen@teliasonera.com" wrote: > Hi Raj, > >> Henrik, >> >> In the DS-MIP6 case the reasoning for the work has been that >> IPv6 native >> access is not expected to be ubiquitous and hence given that >> the host is DS >> and access is IPv4, there is a need to enable MIP6 continuity >> while being >> attached to a v4 network. The ability to carry IPv4 within >> the MIP6 session >> is to enable applications and services that are v4 based on >> the hosts and is >> applicable in the scenario when the host is connected to a >> native v6 access >> only (which I guess we believe will be the situation at some >> point in the >> future). So I believe there is a good reason to do this for MIP6. > > Don't we have this situation in a way already? If I remember correctly > e.g. in 2G/3G a DS terminal can open either an IPv4 or IPv6 PDP context. > So if you want IPv6 over your cellular you are stuck in IPv6 only > access for that context. Of course then it is up to the terminal > and/or GGSN implementations whether they allow multiple primary > contexts of different IP version (and possibly to the same APN), > which might not always be the case.. Current terminals can have multiple PDP contexts for sure. I am not sure if a terminal can establish an IPv4/v6 PDP context to the same APN. I don't know if this works or if this is not allowed for some reason. But it is a limitation if an APN does not allow multiple IP version PDP contexts for the same host... And in such a case, I agree that if you have an IPvX PDP context, you would want to carry the other IP version over that. However in the context of GPRS, I think that would be a suboptimal solution. Rather I would think that having the APN support multiple PDP contexts for the same host with different IP versions would a cleaner solution. -Raj > > Jouni > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 21:21:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsrPF-0004VA-Vb; Tue, 20 Jun 2006 21:21:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsrPE-0004T0-Rv for mip6@ietf.org; Tue, 20 Jun 2006 21:21:20 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsrPD-0005qW-4A for mip6@ietf.org; Tue, 20 Jun 2006 21:21:20 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1600FT5S5L2D@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 21 Jun 2006 09:29:45 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1600C2XS5KYN@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 21 Jun 2006 09:29:45 +0800 (CST) Received: from w50392 ([10.164.45.52]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1600JVZS7ZJ2@szxml04-in.huawei.com> for mip6@ietf.org; Wed, 21 Jun 2006 09:31:13 +0800 (CST) Date: Wed, 21 Jun 2006 09:20:28 +0800 From: Tom Wan Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) To: Basavaraj Patil , jouni.korhonen@teliasonera.com, Levkowetz , kempf@docomolabs-usa.com Message-id: <002b01c694d0$e1d55200$6e2ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Jari Arkko , mccap@lucent.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org As we know, there are two ip protocols: ipv4 and ipv6. IMO, when mobile entity with dual stack roams between the two kinds of networks, we must consider the following problems before we consider a solution: 1. What are the possible scenarios? I think there are three categories of scenarios. 1) HA is in the IPv4 network, and supports only ipv4 protocol (it means MN has an IPv4 HoA ). 2) HA is in the IPv6 network, and supports only ipv6 protocol (it means MN has an IPv6 HoA ). 3) HA is in the ipv4/ipv6 mixed network, and supports ipv4/ipv6 protocols(it means MN has ipv4/ipv6 HOA). 2. What are the features and real problems of these scenarios? In some scenarios, MN can communicate with HA directly. But in other scenarios, MN can not communicate with HA directly. Mechanism may be needed to help MN communicate with HA. In some scenarios, MN can not get ipv4 home address from HA. Mechanism may be needed to help MN traverse ipv6 packet across ipv4 network. In some scenarios, MN can not get ipv6 home address from HA. Mechanism may be needed to help MN traverse ipv4 packet across ipv6 network. In some scenarios, MN needs to keep its ipv4 communication with CN. In some scenarios, MN needs to keep its ipv6 communication with CN. These problems must be considered. 3. What are the restrictions of solutions? As modifications to mip4 and mip6 protocols are criticized, the solution should do few modifications to mip4/mip6 protocols. As NAT/PT will lead to many security problems, NAT/PT should not be considered as the unique mechanism. IMO, I think we should consider the possible scenarios firstly. Only when we have consider the scenarios clearly, can we consider a proper solution. > However in the context of GPRS, I think that would be a suboptimal > solution. > Rather I would think that having the APN support multiple PDP contexts for > the same host with different IP versions would a cleaner solution. ===> This is a good idea.But I am afraid that this assumption only fits for some scenarios. If we assume so, the solution based on this assumption can only solve few scenarios. So I think we should not focuse on assumptions firstly. We should focuse on the possible scenarios firstly. The scenario analysis project should be our current work. Solutions and assumptions should not be considered currently. BR Tom _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 20 23:53:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FstmX-0004CN-Ns; Tue, 20 Jun 2006 23:53:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FstmX-0004CI-3W for mip6@ietf.org; Tue, 20 Jun 2006 23:53:33 -0400 Received: from av12-1-sn2.hy.skanova.net ([81.228.8.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FstmT-000315-Jk for mip6@ietf.org; Tue, 20 Jun 2006 23:53:33 -0400 Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id DE31038004; Wed, 21 Jun 2006 05:53:28 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id CE1E237E7C; Wed, 21 Jun 2006 05:53:28 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id F2F7137E42; Wed, 21 Jun 2006 05:53:27 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FstmQ-0003gO-2w; Wed, 21 Jun 2006 05:53:27 +0200 Message-ID: <4498C2AB.5030505@levkowetz.com> Date: Wed, 21 Jun 2006 05:53:15 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Tom Wan Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) References: <002b01c694d0$e1d55200$6e2ea40a@china.huawei.com> In-Reply-To: <002b01c694d0$e1d55200$6e2ea40a@china.huawei.com> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Jari Arkko , mccap@lucent.com, Basavaraj Patil , mip6@ietf.org, kempf@docomolabs-usa.com, jouni.korhonen@teliasonera.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0284853444==" Errors-To: mip6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0284853444== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB28F89CAB7272B753DF50B31" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB28F89CAB7272B753DF50B31 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tom, Please check out draft-larsson-v6ops-mip-scenarios-01: http://tools.ietf.org/html/draft-larsson-v6ops-mip-scenarios Henrik on 2006-06-21 03:20 Tom Wan said the following: > As we know, there are two ip protocols: ipv4 and ipv6. IMO, when mobile= =20 > entity with dual stack roams between the two kinds of networks, we mus= t=20 > consider the following problems before we consider a solution: >=20 > 1. What are the possible scenarios? > I think there are three categories of scenarios. > 1) HA is in the IPv4 network, and supports only ipv4 protocol (it means= MN=20 > has an IPv4 HoA ). > 2) HA is in the IPv6 network, and supports only ipv6 protocol (it means= MN=20 > has an IPv6 HoA ). > 3) HA is in the ipv4/ipv6 mixed network, and supports ipv4/ipv6 protoco= ls(it=20 > means MN has ipv4/ipv6 HOA). >=20 > 2. What are the features and real problems of these scenarios? > In some scenarios, MN can communicate with HA directly. But in other=20 > scenarios, MN can not communicate with HA directly. Mechanism may be ne= eded=20 > to help MN communicate with HA. > In some scenarios, MN can not get ipv4 home address from HA. Mechanism = may=20 > be needed to help MN traverse ipv6 packet across ipv4 network. > In some scenarios, MN can not get ipv6 home address from HA. Mechanism = may=20 > be needed to help MN traverse ipv4 packet across ipv6 network. > In some scenarios, MN needs to keep its ipv4 communication with CN. > In some scenarios, MN needs to keep its ipv6 communication with CN. > These problems must be considered. >=20 >=20 > 3. What are the restrictions of solutions? > As modifications to mip4 and mip6 protocols are criticized, the solutio= n=20 > should do few modifications to mip4/mip6 protocols. > As NAT/PT will lead to many security problems, NAT/PT should not be=20 > considered as the unique mechanism. >=20 > IMO, I think we should consider the possible scenarios firstly. > Only when we have consider the scenarios clearly, can we consider a pro= per=20 > solution. >=20 >=20 >> However in the context of GPRS, I think that would be a suboptimal=20 >> solution. >> Rather I would think that having the APN support multiple PDP contexts= for >> the same host with different IP versions would a cleaner solution. >=20 > =3D=3D=3D> This is a good idea.But I am afraid that this assumption onl= y fits for=20 > some scenarios. > If we assume so, the solution based on this assumption can only solve f= ew=20 > scenarios. > So I think we should not focuse on assumptions firstly. We should focus= e on=20 > the possible > scenarios firstly. The scenario analysis project should be our current= =20 > work. > Solutions and assumptions should not be considered currently. >=20 >=20 > BR > Tom >=20 >=20 >=20 --------------enigB28F89CAB7272B753DF50B31 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEmMK1eVhrtTJkXCMRAnvuAJ9n2bgj1p4L+AN4wmViGH8EDGlo8QCgukVg GAUfcTcrlb5GlM4HNVmGRCw= =t7wi -----END PGP SIGNATURE----- --------------enigB28F89CAB7272B753DF50B31-- --===============0284853444== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0284853444==-- From mip6-bounces@ietf.org Wed Jun 21 01:55:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsvg7-0007dz-9u; Wed, 21 Jun 2006 01:55:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsvfx-0007Yb-Kd for mip6@ietf.org; Wed, 21 Jun 2006 01:54:53 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsvZ0-0005EX-0P for mip6@ietf.org; Wed, 21 Jun 2006 01:47:43 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1700K1X4DCX7@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 21 Jun 2006 13:53:37 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J17007N44DCP5@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 21 Jun 2006 13:53:36 +0800 (CST) Received: from y52774 ([10.164.44.201]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1700KMC4FPVW@szxml04-in.huawei.com> for mip6@ietf.org; Wed, 21 Jun 2006 13:55:05 +0800 (CST) Date: Wed, 21 Jun 2006 13:44:17 +0800 From: Michael Ye Subject: RE: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) In-reply-to: <4498C2AB.5030505@levkowetz.com> To: 'Henrik Levkowetz' , 'Tom Wan' Message-id: <003b01c694f5$bcaa8cf0$c92ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcaU57rcjLi+3kklThO+yEw8WCpa9gADWKdw X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: 'Jari Arkko' , mccap@lucent.com, 'Basavaraj Patil' , mip6@ietf.org, kempf@docomolabs-usa.com, jouni.korhonen@teliasonera.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Henrik, I have read your the draft. BR, Michael -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com] Sent: Wednesday, June 21, 2006 11:53 AM To: Tom Wan Cc: Jari Arkko; mccap@lucent.com; Basavaraj Patil; mip6@ietf.org; kempf@docomolabs-usa.com; jouni.korhonen@teliasonera.com Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) Hi Tom, Please check out draft-larsson-v6ops-mip-scenarios-01: http://tools.ietf.org/html/draft-larsson-v6ops-mip-scenarios Henrik on 2006-06-21 03:20 Tom Wan said the following: > As we know, there are two ip protocols: ipv4 and ipv6. IMO, when > mobile entity with dual stack roams between the two kinds of > networks, we must consider the following problems before we consider a solution: > > 1. What are the possible scenarios? > I think there are three categories of scenarios. > 1) HA is in the IPv4 network, and supports only ipv4 protocol (it > means MN has an IPv4 HoA ). > 2) HA is in the IPv6 network, and supports only ipv6 protocol (it > means MN has an IPv6 HoA ). > 3) HA is in the ipv4/ipv6 mixed network, and supports ipv4/ipv6 > protocols(it means MN has ipv4/ipv6 HOA). > > 2. What are the features and real problems of these scenarios? > In some scenarios, MN can communicate with HA directly. But in other > scenarios, MN can not communicate with HA directly. Mechanism may be > needed to help MN communicate with HA. > In some scenarios, MN can not get ipv4 home address from HA. Mechanism > may be needed to help MN traverse ipv6 packet across ipv4 network. > In some scenarios, MN can not get ipv6 home address from HA. Mechanism > may be needed to help MN traverse ipv4 packet across ipv6 network. > In some scenarios, MN needs to keep its ipv4 communication with CN. > In some scenarios, MN needs to keep its ipv6 communication with CN. > These problems must be considered. > > > 3. What are the restrictions of solutions? > As modifications to mip4 and mip6 protocols are criticized, the > solution should do few modifications to mip4/mip6 protocols. > As NAT/PT will lead to many security problems, NAT/PT should not be > considered as the unique mechanism. > > IMO, I think we should consider the possible scenarios firstly. > Only when we have consider the scenarios clearly, can we consider a > proper solution. > > >> However in the context of GPRS, I think that would be a suboptimal >> solution. >> Rather I would think that having the APN support multiple PDP >> contexts for the same host with different IP versions would a cleaner solution. > > ===> This is a good idea.But I am afraid that this assumption only > fits for some scenarios. > If we assume so, the solution based on this assumption can only solve > few scenarios. > So I think we should not focuse on assumptions firstly. We should > focuse on the possible scenarios firstly. The scenario analysis > project should be our current work. > Solutions and assumptions should not be considered currently. > > > BR > Tom > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 03:20:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsx1A-0003N1-C8; Wed, 21 Jun 2006 03:20:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsx19-0003LL-10 for mip6@ietf.org; Wed, 21 Jun 2006 03:20:51 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsx17-0007ys-O9 for mip6@ietf.org; Wed, 21 Jun 2006 03:20:51 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1700AOG8SRWR@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 21 Jun 2006 15:29:15 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J17005TK8SQJI@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 21 Jun 2006 15:29:15 +0800 (CST) Received: from w50392 ([10.164.45.52]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1700LYO8V8SA@szxml04-in.huawei.com> for mip6@ietf.org; Wed, 21 Jun 2006 15:30:45 +0800 (CST) Date: Wed, 21 Jun 2006 15:19:59 +0800 From: Tom Wan Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) To: Michael Ye , 'Henrik Levkowetz' Message-id: <006201c69503$1b531cb0$6e2ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <003b01c694f5$bcaa8cf0$c92ca40a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: 'Jari Arkko' , mccap@lucent.com, 'Basavaraj Patil' , mip6@ietf.org, kempf@docomolabs-usa.com, jouni.korhonen@teliasonera.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org HI, Henrik: I read your draft just now. It is really a good job. I have the same opinion as mentioned in your draft. You do not only discuss the virtues of these drafts but also their drawbacks. You mentioned 3 cases in your draft: o Case I (MIPv4-based): Mobile IPv4 is already deployed in an operator's/ISP's networks, and a solution is needed to allow Mobile IPv4 to work over both IPv4 and IPv6 address spaces. o Case II (MIPv6-based): Mobile IPv4 is not deployed, but the operator/ISP plans to deploy Mobile IPv6 directly, and needs a solution to allow Mobile IPv6 to work over both IPv4 and IPv6 networks. o Case III (MIPv4-MIPv6): Mobile IPv4 is deployed by an operator/ISP who now plans to migrate to Mobile IPv6, and therefore needs a solution for Mobile IPv4-Mobile IPv6 migration. It seemed that we have the similar opinion. These cases are mentioned in my draft too. I think dsmip6 is focusing on CaseIII, and my solution is related to case I and II. They will not contradict with each other. And maybe we should consider a perfect solution that can solve case I,II,III simultaneously. And the solution should be simple. I think dsmip+ the concept of FHA and temporary home address can solve this problem perfectly. What is your opinion? BR Tom ----- Original Message ----- From: "Michael Ye" To: "'Henrik Levkowetz'" ; "'Tom Wan'" Cc: "'Jari Arkko'" ; ; "'Basavaraj Patil'" ; ; ; Sent: Wednesday, June 21, 2006 1:44 PM Subject: RE: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) > > Hi Henrik, > I have read your the draft. > > BR, > Michael > > > > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Wednesday, June 21, 2006 11:53 AM > To: Tom Wan > Cc: Jari Arkko; mccap@lucent.com; Basavaraj Patil; mip6@ietf.org; > kempf@docomolabs-usa.com; jouni.korhonen@teliasonera.com > Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for > IPv4(mip4) > > Hi Tom, > > Please check out draft-larsson-v6ops-mip-scenarios-01: > > http://tools.ietf.org/html/draft-larsson-v6ops-mip-scenarios > > > > Henrik > > > > on 2006-06-21 03:20 Tom Wan said the following: >> As we know, there are two ip protocols: ipv4 and ipv6. IMO, when >> mobile entity with dual stack roams between the two kinds of >> networks, we must consider the following problems before we consider a > solution: >> >> 1. What are the possible scenarios? >> I think there are three categories of scenarios. >> 1) HA is in the IPv4 network, and supports only ipv4 protocol (it >> means MN has an IPv4 HoA ). >> 2) HA is in the IPv6 network, and supports only ipv6 protocol (it >> means MN has an IPv6 HoA ). >> 3) HA is in the ipv4/ipv6 mixed network, and supports ipv4/ipv6 >> protocols(it means MN has ipv4/ipv6 HOA). >> >> 2. What are the features and real problems of these scenarios? >> In some scenarios, MN can communicate with HA directly. But in other >> scenarios, MN can not communicate with HA directly. Mechanism may be >> needed to help MN communicate with HA. >> In some scenarios, MN can not get ipv4 home address from HA. Mechanism >> may be needed to help MN traverse ipv6 packet across ipv4 network. >> In some scenarios, MN can not get ipv6 home address from HA. Mechanism >> may be needed to help MN traverse ipv4 packet across ipv6 network. >> In some scenarios, MN needs to keep its ipv4 communication with CN. >> In some scenarios, MN needs to keep its ipv6 communication with CN. >> These problems must be considered. >> >> >> 3. What are the restrictions of solutions? >> As modifications to mip4 and mip6 protocols are criticized, the >> solution should do few modifications to mip4/mip6 protocols. >> As NAT/PT will lead to many security problems, NAT/PT should not be >> considered as the unique mechanism. >> >> IMO, I think we should consider the possible scenarios firstly. >> Only when we have consider the scenarios clearly, can we consider a >> proper solution. >> >> >>> However in the context of GPRS, I think that would be a suboptimal >>> solution. >>> Rather I would think that having the APN support multiple PDP >>> contexts for the same host with different IP versions would a cleaner > solution. >> >> ===> This is a good idea.But I am afraid that this assumption only >> fits for some scenarios. >> If we assume so, the solution based on this assumption can only solve >> few scenarios. >> So I think we should not focuse on assumptions firstly. We should >> focuse on the possible scenarios firstly. The scenario analysis >> project should be our current work. >> Solutions and assumptions should not be considered currently. >> >> >> BR >> Tom >> >> >> > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 03:45:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsxPL-0002z2-My; Wed, 21 Jun 2006 03:45:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsxPK-0002va-39 for mip6@ietf.org; Wed, 21 Jun 2006 03:45:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsxPK-0002HA-14 for mip6@ietf.org; Wed, 21 Jun 2006 03:45:50 -0400 Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsxM3-0008Hg-Nu for mip6@ietf.org; Wed, 21 Jun 2006 03:42:29 -0400 Received: from rly02d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly02d.srv.mailcontrol.com (MailControl) with ESMTP id k5L7gPs3004226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 21 Jun 2006 08:42:26 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly02d.srv.mailcontrol.com (MailControl) id k5L7fqP9003474 for mip6@ietf.org; Wed, 21 Jun 2006 08:41:52 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly02d-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id k5L7fplG003429; Wed, 21 Jun 2006 08:41:52 +0100 (BST) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 6e6a_c6e82546_00f3_11db_97dc_0030482aac25; Wed, 21 Jun 2006 09:01:34 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2006062109414806-651011 ; Wed, 21 Jun 2006 09:41:48 +0200 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: 0.609,BAYES_00: -1.665, SARE_RECV_ADDR: 0.027 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 21 Jun 2006 09:45:19 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt In-Reply-To: <44984E06.3030009@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt Thread-Index: AcaUoMGTw2sK4nIcTRa89iWS3WtgYgAX1ETg To: "Brian Haley" Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4FC562B6@lan-ex-01.panasonic.de> Date: Wed, 21 Jun 2006 09:41:41 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-07-00-10 (www.mailcontrol.com) on 10.68.1.112 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Brian, > -----Original Message----- > From: Brian Haley [mailto:brian.haley@hp.com]=20 > Sent: Dienstag, 20. Juni 2006 21:36 > To: Kilian Weniger > Cc: mip6@ietf.org > Subject: Re: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt >=20 > Hi Kilian, >=20 > >>> At least the draft prevents the MN from keeping > >>> the registration with the old HA, which IMHO would be=20 > >> neccessary in this > >>> case in order to keep existing sessions (using the old HoA) alive. > >> The MN should be able to keep it's HoA as long as there is another=20 > >> available HA to switch to that's serving that prefix. >=20 > The HA being switched-to should be serving the same set of=20 > prefixes as=20 > the current HA, we'll need to add some text to say that SHOULD be the=20 > default, else there will be loss of connectivity to the HoA. ok, now I understand your intention. =20 Note that there would not necessarily be a loss of connectivity if the MN would be allowed to keep the registration with the old HA (which I was proposing). The old HA could indicate (by a flag in the switch message) if it is able to continue to serve as HA for the MN. Scenarios I have in mind are that the network (i.e., HA) can direct the MN to another HA on a different link (e.g., to a more local HA), which is better with respect to optimized routing or for load balancing between HAs on different links.=20 >=20 > > The scenario I was talking about is that the switch message=20 > sent by the > > HA directs the MN to a new HA serving a different link,=20 > resulting in a > > new HoA for the MN after bootstrapping with this HA. Section 5.1 (MN > > operation) says > >=20 > > "Upon receipt of a Home Agent Switch message, the mobile node MUST > > stop using its current home agent for services and MUST=20 > delete its > > home binding by sending a Binding Update message as=20 > described in [2]. > > This acts as an acknowledgement of the Home Agent Switch=20 > message." > >=20 > > When strictly following the procedure described in the=20 > draft, I don't > > see how the MN can keep its old HoA. The MN must send a BU=20 > to delete the > > binding for the old HoA and cannot skip that, since the BU=20 > acts as ack > > for the switch message. >=20 > As I said above, the intention is the new HA should support the HoA. >=20 > > To support the scenario, it should IMHO be possible to keep the > > registration with the old HA (at least for a certain period=20 > of time) if > > the bootstrapping with the new HA results in a new HoA. The switch > > message could indicate (e.g., by a flag) whether the old HA=20 > is able to > > keep serving the MN as secondary HA for some time (to keep existing > > session alive and to keep IP reachability until the new HoA is > > published). When receiving a switch message with this flag=20 > set, the MN > > would not be required to delete the binding at the old HA=20 > immediately > > (note that strictly speaking this would not be a HA switch,=20 > since the > > registration with the old HA would not be deleted). >=20 > The HA is sending the switch message because it can't=20 > continue to act as=20 > the HA for this MN, so keeping the binding around is not an option. First of all note that in some cases in the current draft, the old HA would probably be able to continue to acts as HA to some extent (e.g., load balancing). But if the old HA cannot continue to act as HA (e.g., because it will be shut down), keeping the binding in this HA is of course not an option. The modification I had in mind just extends the applicability of the switch mechanism by allowing the HA to send switch messages to direct the MN to a HA serving a different link and continue to serve as secondary HA (e.g., for the scenarios I mentioned above).=20 >=20 > >>> The > >>> renumbering scenario mentioned in the draft seems to consider > >>> renumbering of HA addresses only, not HoAs.=20 > >> The renumbering for the home link can be done with just RFC 3775=20 > >> messages - Mobile Prefix Solicitation and Advertisement. > >=20 > > yes, but if the above scenario is supported, renumbering of=20 > certain HoAs > > would also be possible with the switch mechanism only. If the switch > > mechanism is needed for renumbering is of course another question. >=20 > I don't want to burden HA switch with network renumbering,=20 > Section 10.6=20 > and 11.4.3 of RFC 3775 already cover this. My intention was not to support HoA renumbering with the switch mechanism, it would just be a side-effect of the modification I proposed... -Kilian >=20 > -Brian >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 04:17:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsxu7-0005Em-9q; Wed, 21 Jun 2006 04:17:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsxu5-0005EY-Gq for mip6@ietf.org; Wed, 21 Jun 2006 04:17:37 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsxu4-0006F1-4q for mip6@ietf.org; Wed, 21 Jun 2006 04:17:37 -0400 Received: by nf-out-0910.google.com with SMTP id c29so60519nfb for ; Wed, 21 Jun 2006 01:17:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=A3gOD1Kz89SkJ4QNqNHn4FpLNjr6vwuWm8h/JeDHPFld1YYUCqFYmex5UGxF7OP9CxY7j5viAXG1EpRwd0+lgv/YhYkRiy1lYRwy4OLPFua1KkwefBAbvQVSkKzjGQswgD0vzXi2jabjIXIx71lfxmGsgViUCIiCIKsH4MA55HE= Received: by 10.49.58.3 with SMTP id l3mr318517nfk; Wed, 21 Jun 2006 01:17:35 -0700 (PDT) Received: by 10.49.40.17 with HTTP; Wed, 21 Jun 2006 01:17:34 -0700 (PDT) Message-ID: Date: Wed, 21 Jun 2006 10:17:35 +0200 From: "Gerardo Giaretta" To: "Alper Yegin" Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 In-Reply-To: <0MKoyl-1Fskwf2rab-0000pr@mrelay.perfora.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44983503.6050703@azairenet.com> <0MKoyl-1Fskwf2rab-0000pr@mrelay.perfora.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: mip6@ietf.org, dhcwg@ietf.org, Heejin Jang X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alper, just one question below in order to understand if there is a real technical reason to keep the docs separated.. > > > But I hope this data point helps: WiMAX Forum NWG architecture is using > > > draft-jang. > > > > in what context and how are they planning to use it? > > The MIP info is brought to the DHCP server via RADIUS and delivered to the > MN via DHCP. > Can you please explain which are the technical differences between the solution in the DT draft for integrated scenario and the solution developped in WiMAX? I guess in WiMAX MIP info are brought to DHCP relay (i.e. NAS) and then draft-jang is applied. Is this really different from what is described in the DT draft? --Gerardo > > the > > WiMAX forum NWG can still use the DHCP options wherever > > they are defined. > > Yes. And WiMAX Forum could also use it even if IETF had concatenated all of > the RFCs and I-Ds under a single document too.... This I-D being referenced > whereas the draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt wasn't is a > solid proof that the former I-D is useful without having to be integrated > into the latter. > > > > >>the only other mechanism is to manually > > >>configure the DHCP servers in the visited link with > > >>information like home agent address, home address and home > > >>prefix. this is a bad idea. > > > You know that one does not have to put DHCP servers on every subnet, instead > one can rely on DHCP relays. And that's the used technique for many > enterprise networks. So, I don't see why this is a bad idea. > > Alper > > > > > > > > Vijay > > > > > > > > Alper > > > > > > > > > > > >>-----Original Message----- > > >>From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > >>Sent: Monday, June 19, 2006 6:17 PM > > >>To: Heejin Jang > > >>Cc: mip6@ietf.org; dhcwg@ietf.org > > >>Subject: Re: [Mip6] [Updated] DHCP Option for Home Information Discovery > > >>inMIPv6 > > >> > > >>Heejin Jang wrote: > > >> > > >>>Hello folks, > > >>>We posted an I-D that proposes new DHCP Options for Home Information > > >>>Discovery in MIPv6. > > >>> > > >>>Kindly note that the previous version of this draft is > > >>>"draft-jang-dhc-haopt-02.txt" but the name is slightly changed into > > >>>"draft-jang-mip6-hiopt-00.txt" while keeping almost the same contents. > > >>> > > >>>The drafts referencing this draft such as > > >>>draft-ietf-mip6-bootstrapping-split-02.txt and > > >>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt need to be revised > > >>>accordingly. > > >>> > > >>>We would appreciate to hear your comments. > > >> > > >>when this draft was discussed in the MIP6 bootstrapping > > >>design team, many people wanted to integrate the two DHCP > > >>options into > > >>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. > > >>this was mainly because the options defined in the document > > >>have limited applicability beyond the integrated scenario > > >>solution document. the only other mechanism is to manually > > >>configure the DHCP servers in the visited link with > > >>information like home agent address, home address and home > > >>prefix. this is a bad idea. > > >> > > >>there was some opposition and we never reached an agreement. > > >> > > >>so I suggest including these options into the integrated > > >>scenario solution document for these options to get > > >>standardized quickly. > > >> > > >>Vijay > > >> > > >>_______________________________________________ > > >>Mip6 mailing list > > >>Mip6@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 05:13:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsymP-0007qa-RD; Wed, 21 Jun 2006 05:13:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsymO-0007md-26 for mip6@ietf.org; Wed, 21 Jun 2006 05:13:44 -0400 Received: from av11-2-sn2.hy.skanova.net ([81.228.8.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsymN-00039M-FK for mip6@ietf.org; Wed, 21 Jun 2006 05:13:44 -0400 Received: by av11-2-sn2.hy.skanova.net (Postfix, from userid 502) id A37B63837B; Wed, 21 Jun 2006 11:13:42 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-2-sn2.hy.skanova.net (Postfix) with ESMTP id 91BEC3810B; Wed, 21 Jun 2006 11:13:42 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 8AAF237E4D; Wed, 21 Jun 2006 11:13:40 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FsymG-00062X-Dh; Wed, 21 Jun 2006 11:13:39 +0200 Message-ID: <44990DC0.3050908@levkowetz.com> Date: Wed, 21 Jun 2006 11:13:36 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Tom Wan Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4) References: <003b01c694f5$bcaa8cf0$c92ca40a@china.huawei.com> <006201c69503$1b531cb0$6e2ea40a@china.huawei.com> In-Reply-To: <006201c69503$1b531cb0$6e2ea40a@china.huawei.com> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: 'Jari Arkko' , mccap@lucent.com, 'Basavaraj Patil' , mip6@ietf.org, kempf@docomolabs-usa.com, jouni.korhonen@teliasonera.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0992074298==" Errors-To: mip6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0992074298== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig038779EBAAE70A3C30E630F4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig038779EBAAE70A3C30E630F4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tom, on 2006-06-21 09:19 Tom Wan said the following: > HI, Henrik: >=20 > I read your draft just now. It is really a good job. > I have the same opinion as mentioned in your draft. > You do not only discuss the virtues of these drafts but also > their drawbacks. >=20 > You mentioned 3 cases in your draft: > o Case I (MIPv4-based): Mobile IPv4 is already deployed in an > operator's/ISP's networks, and a solution is needed to allow > Mobile IPv4 to work over both IPv4 and IPv6 address spaces. > o Case II (MIPv6-based): Mobile IPv4 is not deployed, but the > operator/ISP plans to deploy Mobile IPv6 directly, and needs a > solution to allow Mobile IPv6 to work over both IPv4 and IPv6 > networks. > o Case III (MIPv4-MIPv6): Mobile IPv4 is deployed by an operator/ISP > who now plans to migrate to Mobile IPv6, and therefore needs a > solution for Mobile IPv4-Mobile IPv6 migration. >=20 > It seemed that we have the similar opinion. These cases are mentioned i= n my=20 > draft too. >=20 >=20 > I think dsmip6 is focusing on CaseIII, and my solution is related to ca= se I=20 > and II. No, DSMIPv6 handles case II, DSMIPv4 handles case I. If there are aspect= s of case III that need protocol support, rather than simply parallel deplo= yment of MIPv4 and MIPv6 in the HA, and migration of the clients, then that wou= ld need a separate draft. > They will not contradict with each other. And maybe we should consider = a=20 > perfect > solution that can solve case I,II,III simultaneously. And the solution = > should be simple. I think that for I and II we should stick with the proposed DSMIPv4 and v= 6. > I think dsmip+ the concept of FHA and temporary home address can solve = this > problem perfectly. I'm not convinced there is a problem for the migration case, but if there= is a draft which cleanly addresses case III and explains why there is a problem, I'd try to find time to read it. Regards, Henrik > What is your opinion? >=20 > BR > Tom >=20 > ----- Original Message -----=20 > From: "Michael Ye" > To: "'Henrik Levkowetz'" ; "'Tom Wan'"=20 > > Cc: "'Jari Arkko'" ; ; "'Basa= varaj=20 > Patil'" ; ;=20 > ; > Sent: Wednesday, June 21, 2006 1:44 PM > Subject: RE: [Mip6] FW: Internal WG Review: Recharter of Mobility for=20 > IPv4(mip4) >=20 >=20 >> >> Hi Henrik, >> I have read your the draft. >> >> BR, >> Michael >> >> >> >> -----Original Message----- >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> Sent: Wednesday, June 21, 2006 11:53 AM >> To: Tom Wan >> Cc: Jari Arkko; mccap@lucent.com; Basavaraj Patil; mip6@ietf.org; >> kempf@docomolabs-usa.com; jouni.korhonen@teliasonera.com >> Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for >> IPv4(mip4) >> >> Hi Tom, >> >> Please check out draft-larsson-v6ops-mip-scenarios-01: >> >> http://tools.ietf.org/html/draft-larsson-v6ops-mip-scenarios >> >> >> >> Henrik >> >> >> >> on 2006-06-21 03:20 Tom Wan said the following: >>> As we know, there are two ip protocols: ipv4 and ipv6. IMO, when >>> mobile entity with dual stack roams between the two kinds of >>> networks, we must consider the following problems before we consider = a >> solution: >>> >>> 1. What are the possible scenarios? >>> I think there are three categories of scenarios. >>> 1) HA is in the IPv4 network, and supports only ipv4 protocol (it >>> means MN has an IPv4 HoA ). >>> 2) HA is in the IPv6 network, and supports only ipv6 protocol (it >>> means MN has an IPv6 HoA ). >>> 3) HA is in the ipv4/ipv6 mixed network, and supports ipv4/ipv6 >>> protocols(it means MN has ipv4/ipv6 HOA). >>> >>> 2. What are the features and real problems of these scenarios? >>> In some scenarios, MN can communicate with HA directly. But in other >>> scenarios, MN can not communicate with HA directly. Mechanism may be >>> needed to help MN communicate with HA. >>> In some scenarios, MN can not get ipv4 home address from HA. Mechanis= m >>> may be needed to help MN traverse ipv6 packet across ipv4 network. >>> In some scenarios, MN can not get ipv6 home address from HA. Mechanis= m >>> may be needed to help MN traverse ipv4 packet across ipv6 network. >>> In some scenarios, MN needs to keep its ipv4 communication with CN. >>> In some scenarios, MN needs to keep its ipv6 communication with CN. >>> These problems must be considered. >>> >>> >>> 3. What are the restrictions of solutions? >>> As modifications to mip4 and mip6 protocols are criticized, the >>> solution should do few modifications to mip4/mip6 protocols. >>> As NAT/PT will lead to many security problems, NAT/PT should not be >>> considered as the unique mechanism. >>> >>> IMO, I think we should consider the possible scenarios firstly. >>> Only when we have consider the scenarios clearly, can we consider a >>> proper solution. >>> >>> >>>> However in the context of GPRS, I think that would be a suboptimal >>>> solution. >>>> Rather I would think that having the APN support multiple PDP >>>> contexts for the same host with different IP versions would a cleane= r >> solution. >>> >>> =3D=3D=3D> This is a good idea.But I am afraid that this assumption o= nly >>> fits for some scenarios. >>> If we assume so, the solution based on this assumption can only solve= >>> few scenarios. >>> So I think we should not focuse on assumptions firstly. We should >>> focuse on the possible scenarios firstly. The scenario analysis >>> project should be our current work. >>> Solutions and assumptions should not be considered currently. >>> >>> >>> BR >>> Tom >>> >>> >>> >> >> >> >>=20 >=20 >=20 >=20 --------------enig038779EBAAE70A3C30E630F4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEmQ3AeVhrtTJkXCMRAlOlAKC813UJOsc6CTplK+WGprucTo6PSACcC+c1 YFQYKZTUr+WoWHlj0e+MEHI= =/w7o -----END PGP SIGNATURE----- --------------enig038779EBAAE70A3C30E630F4-- --===============0992074298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0992074298==-- From mip6-bounces@ietf.org Wed Jun 21 05:21:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsytf-0003RX-Pb; Wed, 21 Jun 2006 05:21:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsytf-0003RS-AK for mip6@ietf.org; Wed, 21 Jun 2006 05:21:15 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsytc-0003RS-Q5 for mip6@ietf.org; Wed, 21 Jun 2006 05:21:15 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5L9Kwns025636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 02:20:58 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5L9KtLA025770; Wed, 21 Jun 2006 02:20:56 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 02:20:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Date: Wed, 21 Jun 2006 02:20:53 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA35@NAEX14.na.qualcomm.com> In-Reply-To: <006201c69503$1b531cb0$6e2ea40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Thread-Index: AcaVBbmBtH6ZNxORSQG1f38PARy0pQADgLqQ From: "Soliman, Hesham" To: "Tom Wan" , "Michael Ye" , "Henrik Levkowetz" X-OriginalArrivalTime: 21 Jun 2006 09:20:55.0173 (UTC) FILETIME=[FF985B50:01C69513] X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: Jari Arkko , mccap@lucent.com, Basavaraj Patil , mip6@ietf.org, kempf@docomolabs-usa.com, jouni.korhonen@teliasonera.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > I read your draft just now. It is really a good job. > I have the same opinion as mentioned in your draft. > You do not only discuss the virtues of these drafts but also > their drawbacks. >=20 > You mentioned 3 cases in your draft: > o Case I (MIPv4-based): Mobile IPv4 is already deployed in an > operator's/ISP's networks, and a solution is needed to allow > Mobile IPv4 to work over both IPv4 and IPv6 address spaces. > o Case II (MIPv6-based): Mobile IPv4 is not deployed, but the > operator/ISP plans to deploy Mobile IPv6 directly, and needs a > solution to allow Mobile IPv6 to work over both IPv4 and IPv6 > networks. > o Case III (MIPv4-MIPv6): Mobile IPv4 is deployed by an operator/ISP > who now plans to migrate to Mobile IPv6, and therefore needs a > solution for Mobile IPv4-Mobile IPv6 migration. >=20 > It seemed that we have the similar opinion. These cases are=20 > mentioned in my=20 > draft too. >=20 >=20 > I think dsmip6 is focusing on CaseIII, and my solution is=20 > related to case I=20 > and II. > They will not contradict with each other. And maybe we=20 > should consider a=20 > perfect > solution that can solve case I,II,III simultaneously. And=20 > the solution=20 > should be simple. >=20 > I think dsmip+ the concept of FHA and temporary home address=20 > can solve this > problem perfectly. >=20 > What is your opinion? =3D> DSMIPv6 solves cases II and III for MIPv6. DSMIPv4 solves cases I = and III for MIPv4. Obviously case 2 is specific to MIPv6 so DSMIPv4 would not help in that scenario. So I don't agree with your conclusion about the applicability of dsmip. Hesham >=20 > BR > Tom >=20 > ----- Original Message -----=20 > From: "Michael Ye" > To: "'Henrik Levkowetz'" ; "'Tom Wan'"=20 > > Cc: "'Jari Arkko'" ;=20 > ; "'Basavaraj=20 > Patil'" ; ;=20 > ; > Sent: Wednesday, June 21, 2006 1:44 PM > Subject: RE: [Mip6] FW: Internal WG Review: Recharter of=20 > Mobility for=20 > IPv4(mip4) >=20 >=20 > > > > Hi Henrik, > > I have read your the draft. > > > > BR, > > Michael > > > > > > > > -----Original Message----- > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > Sent: Wednesday, June 21, 2006 11:53 AM > > To: Tom Wan > > Cc: Jari Arkko; mccap@lucent.com; Basavaraj Patil; mip6@ietf.org; > > kempf@docomolabs-usa.com; jouni.korhonen@teliasonera.com > > Subject: Re: [Mip6] FW: Internal WG Review: Recharter of=20 > Mobility for > > IPv4(mip4) > > > > Hi Tom, > > > > Please check out draft-larsson-v6ops-mip-scenarios-01: > > > > http://tools.ietf.org/html/draft-larsson-v6ops-mip-scenarios > > > > > > > > Henrik > > > > > > > > on 2006-06-21 03:20 Tom Wan said the following: > >> As we know, there are two ip protocols: ipv4 and ipv6. IMO, when > >> mobile entity with dual stack roams between the two kinds of > >> networks, we must consider the following problems before=20 > we consider a > > solution: > >> > >> 1. What are the possible scenarios? > >> I think there are three categories of scenarios. > >> 1) HA is in the IPv4 network, and supports only ipv4 protocol (it > >> means MN has an IPv4 HoA ). > >> 2) HA is in the IPv6 network, and supports only ipv6 protocol (it > >> means MN has an IPv6 HoA ). > >> 3) HA is in the ipv4/ipv6 mixed network, and supports ipv4/ipv6 > >> protocols(it means MN has ipv4/ipv6 HOA). > >> > >> 2. What are the features and real problems of these scenarios? > >> In some scenarios, MN can communicate with HA directly.=20 > But in other > >> scenarios, MN can not communicate with HA directly.=20 > Mechanism may be > >> needed to help MN communicate with HA. > >> In some scenarios, MN can not get ipv4 home address from=20 > HA. Mechanism > >> may be needed to help MN traverse ipv6 packet across ipv4 network. > >> In some scenarios, MN can not get ipv6 home address from=20 > HA. Mechanism > >> may be needed to help MN traverse ipv4 packet across ipv6 network. > >> In some scenarios, MN needs to keep its ipv4=20 > communication with CN. > >> In some scenarios, MN needs to keep its ipv6=20 > communication with CN. > >> These problems must be considered. > >> > >> > >> 3. What are the restrictions of solutions? > >> As modifications to mip4 and mip6 protocols are criticized, the > >> solution should do few modifications to mip4/mip6 protocols. > >> As NAT/PT will lead to many security problems, NAT/PT=20 > should not be > >> considered as the unique mechanism. > >> > >> IMO, I think we should consider the possible scenarios firstly. > >> Only when we have consider the scenarios clearly, can we=20 > consider a > >> proper solution. > >> > >> > >>> However in the context of GPRS, I think that would be a=20 > suboptimal > >>> solution. > >>> Rather I would think that having the APN support multiple PDP > >>> contexts for the same host with different IP versions=20 > would a cleaner > > solution. > >> > >> =3D=3D=3D> This is a good idea.But I am afraid that this = assumption only > >> fits for some scenarios. > >> If we assume so, the solution based on this assumption=20 > can only solve > >> few scenarios. > >> So I think we should not focuse on assumptions firstly. We should > >> focuse on the possible scenarios firstly. The scenario analysis > >> project should be our current work. > >> Solutions and assumptions should not be considered currently. > >> > >> > >> BR > >> Tom > >> > >> > >> > > > > > > > >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 05:46:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FszHf-0002qM-57; Wed, 21 Jun 2006 05:46:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FszHd-0002qB-9N for mip6@ietf.org; Wed, 21 Jun 2006 05:46:01 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FszHb-0008GD-Vp for mip6@ietf.org; Wed, 21 Jun 2006 05:46:01 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5L9jnJN026872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 02:45:50 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5L9jl7I021878; Wed, 21 Jun 2006 02:45:48 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 02:45:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Date: Wed, 21 Jun 2006 02:45:47 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA38@NAEX14.na.qualcomm.com> In-Reply-To: <005101c69515$8d1a4a00$6e2ea40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Thread-Index: AcaVFZVjxQazyL6iS9uv2brSZmwyMwAAaktA From: "Soliman, Hesham" To: "Tom Wan" , "Michael Ye" , "Henrik Levkowetz" X-OriginalArrivalTime: 21 Jun 2006 09:45:47.0611 (UTC) FILETIME=[792852B0:01C69517] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Jari Arkko , mccap@lucent.com, Basavaraj Patil , mip6@ietf.org, kempf@docomolabs-usa.com, jouni.korhonen@teliasonera.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > =3D> DSMIPv6 solves cases II and III for MIPv6. DSMIPv4 solves=20 > cases I and > III for MIPv4. Obviously case 2 is specific to MIPv6 so DSMIPv4 would > not help in that scenario. So I don't agree with your=20 > conclusion about > the applicability of dsmip. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D> >=20 > In the current dsmip draft in the WG, If you want dsmip6 to=20 > support caseII,=20 > then HA must > support both mip4 and mip6 protocols.=20 =3D> No, the HA only supports MIPv6. The HA supports IPv6 and IPv4 of course not MIPv4.=20 Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 06:01:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FszW9-0002xj-Ea; Wed, 21 Jun 2006 06:01:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FszW7-0002xZ-Uf for mip6@ietf.org; Wed, 21 Jun 2006 06:00:59 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FszW6-0001vZ-27 for mip6@ietf.org; Wed, 21 Jun 2006 06:00:59 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J17006MCFQ7SA@szxga01-in.huawei.com> for mip6@ietf.org; Wed, 21 Jun 2006 17:58:56 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1700CMHFQ72C@szxga01-in.huawei.com> for mip6@ietf.org; Wed, 21 Jun 2006 17:58:55 +0800 (CST) Received: from w50392 ([10.164.45.52]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1700N2SG5A0M@szxml04-in.huawei.com> for mip6@ietf.org; Wed, 21 Jun 2006 18:08:00 +0800 (CST) Date: Wed, 21 Jun 2006 17:57:13 +0800 From: Tom Wan Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) To: "Soliman, Hesham" , Michael Ye , Henrik Levkowetz Message-id: <006801c69519$1253ca40$6e2ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <7EB20EA0938B4D42A2D82689365C9B7A04FA38@NAEX14.na.qualcomm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Jari Arkko , mccap@lucent.com, Basavaraj Patil , mip6@ietf.org, kempf@docomolabs-usa.com, jouni.korhonen@teliasonera.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The problem in CaseIII is that MN must keep connection of both ipv4 home address and ipv6 home address. It must register to HA both IPv4 home address and ipv6 home address. The problem In caseI and CASEII is that MN need only register its ipv4 or ipv6 home address. This is the difference. In CASEI and CASEII, if we assume HA must support both mip4 and mip6 protocols, it means that if the operator wants to deploy ipv6 network, the ipv6 network must support ipv4 protocol. it is impossible. I think the real difference between CASEI and CASEII and CASEII is that what kind of ip protocol the home network is running. If the operator runs only ipv6 protocol in one home network, to support dsmip6, the operator must deploy ipv4 protocol in that network I think it is impossible because ipv4 address is a scarce resource,and operators may not be able to assign every HA an ipv4 address pool. I think CASEII means the home network supports only ipv6 protocol. CASEI means home network supports only ipv4 network. If you think that CASEI and CASEII does not mean home network must support ipv4 and ipv6 network. Then we must consider new solution to solve the scenarios defined in my draft. I think their may be a difference between the CASE definition of your draft and our draft. Then our draft and dsmip protocol solves different problems. IMO, some networks support both ipv4 and ipv6, some networks support only ipv4 and some networks support only ipv6. These sceanrios are all possible, and mobility management are all needed BR Tom ----- Original Message ----- From: "Soliman, Hesham" To: "Tom Wan" ; "Michael Ye" ; "Henrik Levkowetz" Cc: "Jari Arkko" ; ; "Basavaraj Patil" ; ; ; Sent: Wednesday, June 21, 2006 5:45 PM Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) > => DSMIPv6 solves cases II and III for MIPv6. DSMIPv4 solves > cases I and > III for MIPv4. Obviously case 2 is specific to MIPv6 so DSMIPv4 would > not help in that scenario. So I don't agree with your > conclusion about > the applicability of dsmip. > > ========> > > In the current dsmip draft in the WG, If you want dsmip6 to > support caseII, > then HA must > support both mip4 and mip6 protocols. => No, the HA only supports MIPv6. The HA supports IPv6 and IPv4 of course not MIPv4. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 06:15:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fszji-0002zr-7i; Wed, 21 Jun 2006 06:15:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fszjg-0002xs-Ep for mip6@ietf.org; Wed, 21 Jun 2006 06:15:00 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsziL-0002HD-2L for mip6@ietf.org; Wed, 21 Jun 2006 06:15:00 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 32EE34CE7A; Wed, 21 Jun 2006 19:13:32 +0900 (JST) Date: Wed, 21 Jun 2006 13:13:34 +0300 From: Shinta Sugimoto To: Vijay Devarapalli Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction In-Reply-To: <4498363E.4050702@azairenet.com> References: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> <4498363E.4050702@azairenet.com> Message-Id: <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, please find my further comments inline. On Tue, 20 Jun 2006 10:54:06 -0700 Vijay Devarapalli wrote: > Shinta Sugimoto wrote: > > >> > >>>>The problem here is how does the MN know to "let the > >>>>existing sessions continue with the existing HoA"? If there is no CN's > >>>>address in BUL, surely the MN can choose a suitable HoA. For > >>>>a CN with which it has a binding, it has no reliable way of knowing > >>>>whether there are any ULP sessions. > >>> > >>>If you need to maintain the sessions while changing the HoA > >>>from one to another, I think you need additional mechanism > >>>than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed > >>>to assure the reachability to a given HoA with the current > >>>location of the mobile node (CoA). If the app wants > >>>to change HoAs for some reason (I assume that privacy is the > >>>main interest), there is a need to maintain the mapping of > >>>the identity and the locator of the mobile node. > >> > >>Mobile IPv6 today allows you to use two home addresses > >>at the same time. it also allows you to bind both home > >>addresses to the same CoA. > > > > > > Yes, that's true. But then there is a problem to choose > > which one for which communication. When it comes to agility, > > it's more problematic. > > actually we are not looking for address agility here. we want > the mobile node to change its home address and while changing > it allow existing sessions using the old home address to > continue and start using the new home address for new sessions. I see. Now I understand that address agility is not the main issue here. If I understand the above correctly, the issue is more about how to handle pseudo-HoA especially for correspondents of the mobile node, and how to minimize the impact to the existing communication. Now I have another question. Looking into the solution draft (draft-irtf-mobopts-location-privacy-solutions-01) it seems to me that a pseudo-HoA is derived from mobile node's home prefix and it is actually a globally unique IPv6 address. If I understand the role of pseudo-HoA correctly, it aims to serve as a tag to locate the real HoA for the MN. If so, I am afraid that it may not be necessary to generate a pseudo-HoA in form of IPv6 address. In particular, there is no need to contain the home prefix which could be of interest for an eavesdropper to identify the mobile node. Am I missing something ? > not sure if shim6 addresses this. AFAICT, Shim6 does not provide any exact solution for this particular issue. However, there has been privacy analysis made for Shim6 (see Marcelo's draft for detail). http://www.ietf.org/internet-drafts/draft-bagnulo-shim6-privacy-00.txt But in general, I think the requirements and prerequisite for the privacy are a bit different in MIPv6 and Shim6. > > >>>One option would be to run Shim6 over MIPv6. Such usage has > >>>already been discussed in Shim6 WG. By mobile node establishing > >>>Shim6 context with its HA/CN, it could utilize multiple HoAs > >>>without annoying upper layer protocols. > >> > >>yes, this can be done. but I would like to restrict > >>shim6 usage when mip6 is used to the case where the > >>home link is site multihomed and the mobile node already > >>has the multiple home addresses configured on it. not > >>when the mobile node decides to change its home address. > > > > > > I think it depends on motivation whether it makes sense > > to apply Shim6 here. Utilizing Shim6 would allow HoA agility > > (from ULP point of view). > > see above. > > >>>I have some additional questions: > >>> > >>>- If privacy is the main concern, would you think > >>>http://www.ietf.org/internet-drafts/draft-dupont-mip6-privacyext-03.txt > >>>would help to solve your initial requirement ? If not, could > >>>you please tell me why ? > >> > >>I think its orthogonal. the use of pseudo-HoA instead > >>of the actual HoA is also being worked on in mobopts. > > > > > > I've read the solution draft from the mobopts > > > > and it seems to me that both draft try to achieve the same goal. > > there were a bunch of solution drafts on mip6 privacy (I > think four of them). draft-irtf-mobopts-location-privacy-solutions-01.txt, > is trying to come up with one solution. Ok. Thanks for the clarification. > > >>>- Do you assume that different HoAs that mobile node may > >>>request are derived from different home prefixes ? Or are you > >>>considering that the node generates HoAs from a single prefix > >>>with privacy extension ? > >> > >>I think its the same prefix, but I guess its better if > >>Rajeev clarifies. > > > > Ok, it seems so (HoAs are derived from same prefix). > > see my reply to Hesham. Ok. Regards, Shinta _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 06:45:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0Cg-0004wq-3G; Wed, 21 Jun 2006 06:44:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0Ce-0004wk-La for mip6@ietf.org; Wed, 21 Jun 2006 06:44:56 -0400 Received: from av11-2-sn2.hy.skanova.net ([81.228.8.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft0Cd-0003Xo-6d for mip6@ietf.org; Wed, 21 Jun 2006 06:44:56 -0400 Received: by av11-2-sn2.hy.skanova.net (Postfix, from userid 502) id A83EA38008; Wed, 21 Jun 2006 12:44:54 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av11-2-sn2.hy.skanova.net (Postfix) with ESMTP id 9863A37FE5; Wed, 21 Jun 2006 12:44:54 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 5E7DE37E4B; Wed, 21 Jun 2006 12:44:54 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1Ft0Ca-0004Cl-EC; Wed, 21 Jun 2006 12:44:54 +0200 Message-ID: <44992324.2010308@levkowetz.com> Date: Wed, 21 Jun 2006 12:44:52 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Tom Wan Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA38@NAEX14.na.qualcomm.com> <006801c69519$1253ca40$6e2ea40a@china.huawei.com> In-Reply-To: <006801c69519$1253ca40$6e2ea40a@china.huawei.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Tom, Snipping the Cc: list, as all these people are on the MIP6 list anyway. on 2006-06-21 11:57 Tom Wan said the following: > The problem in CaseIII is that MN must keep connection of both ipv4 home > address and ipv6 home address. > It must register to HA both IPv4 home address and ipv6 home address. > The problem In caseI and CASEII is that MN need only register its ipv4 or > ipv6 home address. > This is the difference. No, sorry. This is incorrect. In all 3 cases you want to support both an IPv4 and IPv6 home address. The difference is whether you use MIPv4 or MIPv6 for that. You still haven't responded to my comments about your case III. Henrik > In CASEI and CASEII, if we assume HA must support both mip4 and mip6 > protocols, it means that > if the operator wants to deploy ipv6 network, the ipv6 network must support > ipv4 protocol. > > it is impossible. > I think the real difference between CASEI and CASEII and CASEII is that what > kind of ip protocol the home network > is running. > > If the operator runs only ipv6 protocol in one home network, to support > dsmip6, the operator must > deploy ipv4 protocol in that network I think it is impossible because ipv4 > address is a scarce resource,and operators may not be able to > assign every HA an ipv4 address pool. > > I think CASEII means the home network supports only ipv6 protocol. CASEI > means home network supports only ipv4 > network. > > > If you think that CASEI and CASEII does not mean home network must support > ipv4 and ipv6 network. > Then we must consider new solution to solve the scenarios defined in my > draft. > > I think their may be a difference between the CASE definition of your draft > and our draft. > Then our draft and dsmip protocol solves different problems. > IMO, some networks support both ipv4 and ipv6, some networks support only > ipv4 and some networks support only ipv6. > These sceanrios are all possible, and mobility management are all needed > > BR > Tom > > ----- Original Message ----- > From: "Soliman, Hesham" > To: "Tom Wan" ; "Michael Ye" > ; "Henrik Levkowetz" > Cc: "Jari Arkko" ; ; "Basavaraj > Patil" ; ; > ; > Sent: Wednesday, June 21, 2006 5:45 PM > Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for > IPv4(mip4) > > > > > => DSMIPv6 solves cases II and III for MIPv6. DSMIPv4 solves > > cases I and > > III for MIPv4. Obviously case 2 is specific to MIPv6 so DSMIPv4 would > > not help in that scenario. So I don't agree with your > > conclusion about > > the applicability of dsmip. > > > > ========> > > > > In the current dsmip draft in the WG, If you want dsmip6 to > > support caseII, > > then HA must > > support both mip4 and mip6 protocols. > > => No, the HA only supports MIPv6. The HA supports IPv6 and IPv4 of > course not MIPv4. > > Hesham > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 06:54:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0Lj-0001PG-0W; Wed, 21 Jun 2006 06:54:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0Li-0001Mr-Du for mip6@ietf.org; Wed, 21 Jun 2006 06:54:18 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft0Lh-00059T-2E for mip6@ietf.org; Wed, 21 Jun 2006 06:54:18 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LArwco026054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 03:53:58 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LArqWN004923; Wed, 21 Jun 2006 03:53:53 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 03:53:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Date: Wed, 21 Jun 2006 03:53:51 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA3A@NAEX14.na.qualcomm.com> In-Reply-To: <006801c69519$1253ca40$6e2ea40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Thread-Index: AcaVGRn21yfB6Wx6RBy/3M9qJ4IbswABx6KQ From: "Soliman, Hesham" To: "Tom Wan" , "Michael Ye" , "Henrik Levkowetz" X-OriginalArrivalTime: 21 Jun 2006 10:53:52.0743 (UTC) FILETIME=[FC15FF70:01C69520] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Jari Arkko , mccap@lucent.com, Basavaraj Patil , mip6@ietf.org, kempf@docomolabs-usa.com, jouni.korhonen@teliasonera.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > In CASEI and CASEII, if we assume HA must support both mip4 and mip6=20 > protocols, it means that > if the operator wants to deploy ipv6 network, the ipv6=20 > network must support=20 > ipv4 protocol. =3D> Sorry, you keep repeating that the operator must support MIPv6 and MIPv4 and I already explained that the whole point of DSMIP is to avoid that. So your concern is not applicable to dsmip solutions. A dual stack is certainly needed if you want to support IPv4 and IPv6 home addresses. If you don't, then don't support a dual stack network, dsmip allows for that too. But FWIW, the commonly agreed on transition scenario in IETF now is a dual stack scenario.=20 > If the operator runs only ipv6 protocol in one home network,=20 > to support=20 > dsmip6, the operator must > deploy ipv4 protocol in that network I think it is=20 > impossible because ipv4=20 > address is a scarce resource,and operators may not be able to > assign every HA an ipv4 address pool. =3D> They would do it with private addresses, and they will suffer (hopefully not for too long) the same problems associated with private addresses that we suffer today. > I think CASEII means the home network supports only ipv6=20 > protocol. CASEI=20 > means home network supports only ipv4 > network. =3D> If you use dsmip, then there would be no relationship between the = MIP version and the IP protocol version.=20 > If you think that CASEI and CASEII does not mean home=20 > network must support=20 > ipv4 and ipv6 network. =3D> I didn't say that, please look at my response again. Hesham > ----- Original Message -----=20 > From: "Soliman, Hesham" > To: "Tom Wan" ; "Michael Ye"=20 > ; "Henrik Levkowetz" > Cc: "Jari Arkko" ;=20 > ; "Basavaraj=20 > Patil" ; ;=20 > ; > Sent: Wednesday, June 21, 2006 5:45 PM > Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for=20 > IPv4(mip4) >=20 >=20 >=20 > > =3D> DSMIPv6 solves cases II and III for MIPv6. DSMIPv4 solves > > cases I and > > III for MIPv4. Obviously case 2 is specific to MIPv6 so=20 > DSMIPv4 would > > not help in that scenario. So I don't agree with your > > conclusion about > > the applicability of dsmip. > > > > =3D=3D=3D=3D=3D=3D=3D=3D> > > > > In the current dsmip draft in the WG, If you want dsmip6 to > > support caseII, > > then HA must > > support both mip4 and mip6 protocols. >=20 > =3D> No, the HA only supports MIPv6. The HA supports IPv6 and IPv4 of > course not MIPv4. >=20 > Hesham >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 06:58:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0Pc-0004vS-Ny; Wed, 21 Jun 2006 06:58:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0Pb-0004vN-Kl for mip6@ietf.org; Wed, 21 Jun 2006 06:58:19 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft0Pa-0005kU-AW for mip6@ietf.org; Wed, 21 Jun 2006 06:58:19 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LAwFHd026231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 03:58:16 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LAwFHd015203; Wed, 21 Jun 2006 03:58:15 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 03:58:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction Date: Wed, 21 Jun 2006 03:58:13 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA3B@NAEX14.na.qualcomm.com> In-Reply-To: <4498342D.2030708@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction Thread-Index: AcaUkZjsu/9iQGBqRYCAAKL6E3yXaQAj6qtg From: "Soliman, Hesham" To: "Vijay Devarapalli" X-OriginalArrivalTime: 21 Jun 2006 10:58:14.0746 (UTC) FILETIME=[98407BA0:01C69521] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > =3D> There is no difference between the two scenarios.=20 >=20 > your reply is too cryptic. >=20 > when shim6 is used, one cannot start using another address > without first adding that address to the list of addresses > that the HA/CN need to be aware of (basically add to the > shim6 state). =3D> Of course, which is doable in both scenarios. >=20 > also, if both home addresses are from the same prefix, > shim6 shouldn't be used.=20 ^^^^^^^^^ =3D> that's your opinion, but the point is it can be used just as easily whether it's the same prefix or a different one. It actually makes sense to use on solution for both cases. if the home link is multihomed > and the mobile node has multiple home addresses from the > different prefixes, then shim6 is applicable. =3D> It's applicable in both cases, you want to use it in one case.=20 Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 07:00:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0RV-0006Cs-7q; Wed, 21 Jun 2006 07:00:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0RU-0006Cf-B2 for mip6@ietf.org; Wed, 21 Jun 2006 07:00:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FszPM-0001Dz-2i for mip6@ietf.org; Wed, 21 Jun 2006 05:54:00 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FszAa-000232-IH for mip6@ietf.org; Wed, 21 Jun 2006 05:38:47 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J17000CTEWTGC@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 21 Jun 2006 17:41:17 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J17004S6EWSPW@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 21 Jun 2006 17:41:17 +0800 (CST) Received: from w50392 ([10.164.45.52]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1700FDPEK0HE@szxml03-in.huawei.com> for mip6@ietf.org; Wed, 21 Jun 2006 17:33:38 +0800 (CST) Date: Wed, 21 Jun 2006 17:32:01 +0800 From: Tom Wan Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) To: "Soliman, Hesham" , Michael Ye , Henrik Levkowetz Message-id: <005101c69515$8d1a4a00$6e2ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <7EB20EA0938B4D42A2D82689365C9B7A04FA35@NAEX14.na.qualcomm.com> X-Spam-Score: -2.1 (--) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Cc: Jari Arkko , mccap@lucent.com, Basavaraj Patil , mip6@ietf.org, kempf@docomolabs-usa.com, jouni.korhonen@teliasonera.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org ----- Original Message ----- From: "Soliman, Hesham" To: "Tom Wan" ; "Michael Ye" ; "Henrik Levkowetz" Cc: "Jari Arkko" ; ; "Basavaraj Patil" ; ; ; Sent: Wednesday, June 21, 2006 5:20 PM Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) > I read your draft just now. It is really a good job. > I have the same opinion as mentioned in your draft. > You do not only discuss the virtues of these drafts but also > their drawbacks. > > You mentioned 3 cases in your draft: > o Case I (MIPv4-based): Mobile IPv4 is already deployed in an > operator's/ISP's networks, and a solution is needed to allow > Mobile IPv4 to work over both IPv4 and IPv6 address spaces. > o Case II (MIPv6-based): Mobile IPv4 is not deployed, but the > operator/ISP plans to deploy Mobile IPv6 directly, and needs a > solution to allow Mobile IPv6 to work over both IPv4 and IPv6 > networks. > o Case III (MIPv4-MIPv6): Mobile IPv4 is deployed by an operator/ISP > who now plans to migrate to Mobile IPv6, and therefore needs a > solution for Mobile IPv4-Mobile IPv6 migration. > > It seemed that we have the similar opinion. These cases are > mentioned in my > draft too. > > > I think dsmip6 is focusing on CaseIII, and my solution is > related to case I > and II. > They will not contradict with each other. And maybe we > should consider a > perfect > solution that can solve case I,II,III simultaneously. And > the solution > should be simple. > > I think dsmip+ the concept of FHA and temporary home address > can solve this > problem perfectly. > > What is your opinion? => DSMIPv6 solves cases II and III for MIPv6. DSMIPv4 solves cases I and III for MIPv4. Obviously case 2 is specific to MIPv6 so DSMIPv4 would not help in that scenario. So I don't agree with your conclusion about the applicability of dsmip. ========> In the current dsmip draft in the WG, If you want dsmip6 to support caseII, then HA must support both mip4 and mip6 protocols. It is different from the caseII. caseII does not assume that HA must support both mip4 and mip6 protocols.So I do not think that dsmip6 solves CASEII. >Case II (MIPv6-based): Mobile IPv4 is not deployed, but the > operator/ISP plans to deploy Mobile IPv6 directly, and needs a > solution to allow Mobile IPv6 to work over both IPv4 and IPv6 > networks. Hesham > > BR > Tom > > ----- Original Message ----- > From: "Michael Ye" > To: "'Henrik Levkowetz'" ; "'Tom Wan'" > > Cc: "'Jari Arkko'" ; > ; "'Basavaraj > Patil'" ; ; > ; > Sent: Wednesday, June 21, 2006 1:44 PM > Subject: RE: [Mip6] FW: Internal WG Review: Recharter of > Mobility for > IPv4(mip4) > > > > > > Hi Henrik, > > I have read your the draft. > > > > BR, > > Michael > > > > > > > > -----Original Message----- > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > Sent: Wednesday, June 21, 2006 11:53 AM > > To: Tom Wan > > Cc: Jari Arkko; mccap@lucent.com; Basavaraj Patil; mip6@ietf.org; > > kempf@docomolabs-usa.com; jouni.korhonen@teliasonera.com > > Subject: Re: [Mip6] FW: Internal WG Review: Recharter of > Mobility for > > IPv4(mip4) > > > > Hi Tom, > > > > Please check out draft-larsson-v6ops-mip-scenarios-01: > > > > http://tools.ietf.org/html/draft-larsson-v6ops-mip-scenarios > > > > > > > > Henrik > > > > > > > > on 2006-06-21 03:20 Tom Wan said the following: > >> As we know, there are two ip protocols: ipv4 and ipv6. IMO, when > >> mobile entity with dual stack roams between the two kinds of > >> networks, we must consider the following problems before > we consider a > > solution: > >> > >> 1. What are the possible scenarios? > >> I think there are three categories of scenarios. > >> 1) HA is in the IPv4 network, and supports only ipv4 protocol (it > >> means MN has an IPv4 HoA ). > >> 2) HA is in the IPv6 network, and supports only ipv6 protocol (it > >> means MN has an IPv6 HoA ). > >> 3) HA is in the ipv4/ipv6 mixed network, and supports ipv4/ipv6 > >> protocols(it means MN has ipv4/ipv6 HOA). > >> > >> 2. What are the features and real problems of these scenarios? > >> In some scenarios, MN can communicate with HA directly. > But in other > >> scenarios, MN can not communicate with HA directly. > Mechanism may be > >> needed to help MN communicate with HA. > >> In some scenarios, MN can not get ipv4 home address from > HA. Mechanism > >> may be needed to help MN traverse ipv6 packet across ipv4 network. > >> In some scenarios, MN can not get ipv6 home address from > HA. Mechanism > >> may be needed to help MN traverse ipv4 packet across ipv6 network. > >> In some scenarios, MN needs to keep its ipv4 > communication with CN. > >> In some scenarios, MN needs to keep its ipv6 > communication with CN. > >> These problems must be considered. > >> > >> > >> 3. What are the restrictions of solutions? > >> As modifications to mip4 and mip6 protocols are criticized, the > >> solution should do few modifications to mip4/mip6 protocols. > >> As NAT/PT will lead to many security problems, NAT/PT > should not be > >> considered as the unique mechanism. > >> > >> IMO, I think we should consider the possible scenarios firstly. > >> Only when we have consider the scenarios clearly, can we > consider a > >> proper solution. > >> > >> > >>> However in the context of GPRS, I think that would be a > suboptimal > >>> solution. > >>> Rather I would think that having the APN support multiple PDP > >>> contexts for the same host with different IP versions > would a cleaner > > solution. > >> > >> ===> This is a good idea.But I am afraid that this assumption only > >> fits for some scenarios. > >> If we assume so, the solution based on this assumption > can only solve > >> few scenarios. > >> So I think we should not focuse on assumptions firstly. We should > >> focuse on the possible scenarios firstly. The scenario analysis > >> project should be our current work. > >> Solutions and assumptions should not be considered currently. > >> > >> > >> BR > >> Tom > >> > >> > >> > > > > > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 08:37:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft1x3-0000rm-JP; Wed, 21 Jun 2006 08:36:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft1x1-0000rg-P8 for mip6@ietf.org; Wed, 21 Jun 2006 08:36:55 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft1x0-0008TA-EU for mip6@ietf.org; Wed, 21 Jun 2006 08:36:55 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LCaqAv004919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 05:36:53 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LCaq0D000295; Wed, 21 Jun 2006 05:36:52 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 05:36:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Date: Wed, 21 Jun 2006 05:36:49 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA41@NAEX14.na.qualcomm.com> In-Reply-To: <44993505.2030702@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Thread-Index: AcaVKoupqb7gL56xQpeIUmj2+oTokgABFqqA From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 21 Jun 2006 12:36:51.0564 (UTC) FILETIME=[5EF342C0:01C6952F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org =20 > >> In CASEI and CASEII, if we assume HA must support both mip4 and > >> mip6 protocols, it means that if the operator wants to deploy ipv6 > >> network, the ipv6 network must support ipv4 protocol. > >=20 > > =3D> Sorry, you keep repeating that the operator must=20 > support MIPv6 and > > MIPv4 and I already explained that the whole point of DSMIP is to > > avoid that. So your concern is not applicable to dsmip solutions. A > > dual stack is certainly needed if you want to support IPv4 and IPv6 > > home addresses. If you don't, then don't support a dual stack > > network, dsmip allows for that too. >=20 > Using DS-MIPv6 requires the HA to run both IPv4 and IPv6. =20 > This does not > scale to an IPv6-only HA infrastructure. =3D> Huh? what do you mean by "scale" ? Needless to say there won't be much IPv6-only networks around in the near term. >=20 > >> If the operator runs only ipv6 protocol in one home network, to > >> support dsmip6, the operator must deploy ipv4 protocol in that > >> network I think it is impossible because ipv4 address is a scarce > >> resource,and operators may not be able to assign every HA an ipv4 > >> address pool. > >=20 > > =3D> They would do it with private addresses, and they will suffer=20 > > (hopefully not for too long) the same problems associated with > > private addresses that we suffer today. >=20 > I don't get the message here... Does this mean that=20 > deploying DS-MIPv6 > on an IPv6 HA infrastructure requires IPv4 _and_ a NAT? =3D> No it means that deploying a dual stack network will most likely imply the use of private IPv4 addresses and NATs. At least in large networks.=20 Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 09:12:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2V7-0005JO-DH; Wed, 21 Jun 2006 09:12:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2V6-0005JJ-4b for mip6@ietf.org; Wed, 21 Jun 2006 09:12:08 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2V4-00029K-PM for mip6@ietf.org; Wed, 21 Jun 2006 09:12:08 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k5LDC0E6021028; Wed, 21 Jun 2006 06:12:04 -0700 (MST) Received: from [10.19.252.31] (mvp-10-19-252-31.corp.mot.com [10.19.252.31]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k5LDBvT2024749; Wed, 21 Jun 2006 08:11:58 -0500 (CDT) Message-ID: <4499459C.6000100@motorola.com> Date: Wed, 21 Jun 2006 15:11:56 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA41@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FA41@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > >>>> In CASEI and CASEII, if we assume HA must support both mip4 and >>>> mip6 protocols, it means that if the operator wants to deploy >>>> ipv6 network, the ipv6 network must support ipv4 protocol. >>> >>> => Sorry, you keep repeating that the operator must >> support MIPv6 and >>> MIPv4 and I already explained that the whole point of DSMIP is to >>> avoid that. So your concern is not applicable to dsmip >>> solutions. A dual stack is certainly needed if you want to >>> support IPv4 and IPv6 home addresses. If you don't, then don't >>> support a dual stack network, dsmip allows for that too. >> >> Using DS-MIPv6 requires the HA to run both IPv4 and IPv6. This does >> not scale to an IPv6-only HA infrastructure. > > => Huh? what do you mean by "scale"? I mean an IPv6-only network is very large. If only its borders support IPv4 and IPv6 then all routers inside can't be HAs whose nodes attach to IPv4-only networks. > Needless to say there won't be much IPv6-only networks around in the > near term. There are currently more IPv6-only routers deployed than MIP6 MNs. An operator can't hold back the migration of its infrastructure network to IPv6, just because some other operators offer IPv4-only access. Or, DS-MIPv6 is just that. An operator running DS-MIP6 for its MNs can't operate an IPv6-only infra if its MNs connect to another operator's IPv4-only network. >>> => They would do it with private addresses, and they will suffer >>> (hopefully not for too long) the same problems associated with >>> private addresses that we suffer today. >> >> I don't get the message here... Does this mean that deploying >> DS-MIPv6 on an IPv6 HA infrastructure requires IPv4 _and_ a NAT? > > => No it means that deploying a dual stack network will most likely > imply the use of private IPv4 addresses and NATs. At least in large > networks. Ok, got it. It is still possible to have a MIP6 MN with an IPv4 stack, connecting to an IPv4-only network, use NAT traversal, and its operator not be forced to dual-stack all the HAs, just a "gateway" farm. And that is not DS-MIPv6, and no NAT. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 09:32:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2oO-0002Pz-67; Wed, 21 Jun 2006 09:32:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2oM-0002Ps-M7 for mip6@ietf.org; Wed, 21 Jun 2006 09:32:02 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2oL-0003Z3-AC for mip6@ietf.org; Wed, 21 Jun 2006 09:32:02 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LDVxOj008550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 06:32:00 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LDVwcx014881; Wed, 21 Jun 2006 06:31:59 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 06:31:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Date: Wed, 21 Jun 2006 06:31:56 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA47@NAEX14.na.qualcomm.com> In-Reply-To: <4499459C.6000100@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Thread-Index: AcaVNFkqp98OpJhwSZCZt2JMbMe9AQAAjlrw From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 21 Jun 2006 13:31:58.0817 (UTC) FILETIME=[123A0510:01C69537] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > =3D> Huh? what do you mean by "scale"? >=20 > I mean an IPv6-only network is very large. If only its=20 > borders support > IPv4 and IPv6 then all routers inside can't be HAs whose=20 > nodes attach to > IPv4-only networks. =3D> Please tell me exactly what the scalability concerns are. I can't follow the above. > It is still possible to have a MIP6 MN with an IPv4 stack,=20 > connecting to > an IPv4-only network, use NAT traversal, and its operator=20 > not be forced > to dual-stack all the HAs, just a "gateway" farm. And that is not > DS-MIPv6, and no NAT. =3D> You're right that's not DSMIPv6. We chose a different path, which achieves the same result. Instead of requiring a "gateway farm" we reuse the HA.=20 Hesham >=20 > Alex >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 09:37:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2tt-0005yc-4h; Wed, 21 Jun 2006 09:37:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2tr-0005yJ-5E for mip6@ietf.org; Wed, 21 Jun 2006 09:37:43 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2tp-0004P8-UE for mip6@ietf.org; Wed, 21 Jun 2006 09:37:43 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5LDbf2b007932; Wed, 21 Jun 2006 06:37:41 -0700 (MST) Received: from [10.19.252.31] (mvp-10-19-252-31.corp.mot.com [10.19.252.31]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k5LDbeOL006297; Wed, 21 Jun 2006 08:37:40 -0500 (CDT) Message-ID: <44994BA2.1010603@motorola.com> Date: Wed, 21 Jun 2006 15:37:38 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA47@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FA47@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > >>> => Huh? what do you mean by "scale"? >> >> I mean an IPv6-only network is very large. If only its borders >> support IPv4 and IPv6 then all routers inside can't be HAs whose >> nodes attach to IPv4-only networks. > > => Please tell me exactly what the scalability concerns are. I can't > follow the above. With DS-MIPv6, the size of the operator's IPv6 infra can not grow larger ("scale") than what the IPv4 protocol allows. Does that makes sense? >> It is still possible to have a MIP6 MN with an IPv4 stack, >> connecting to an IPv4-only network, use NAT traversal, and its >> operator not be forced to dual-stack all the HAs, just a "gateway" >> farm. And that is not DS-MIPv6, and no NAT. > > => You're right that's not DSMIPv6. We chose a different path, which > achieves the same result. Instead of requiring a "gateway farm" we > reuse the HA. I agree, DS-MIPv6 makes sense in initial deployments but is not a long-term migration path because holds back the operator from deploying an IPv6-only infra. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 09:58:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3Dh-0001Be-Ts; Wed, 21 Jun 2006 09:58:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3Dg-0001BT-Mq for mip6@ietf.org; Wed, 21 Jun 2006 09:58:12 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3Df-0006aI-BO for mip6@ietf.org; Wed, 21 Jun 2006 09:58:12 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LDwA78009863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 06:58:10 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LDw9nc018823; Wed, 21 Jun 2006 06:58:09 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 06:58:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Date: Wed, 21 Jun 2006 06:58:08 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA51@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FA47@NAEX14.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Thread-Index: AcaVNFkqp98OpJhwSZCZt2JMbMe9AQAAjlrwAADz1zA= From: "Tsirtsis, George" To: "Soliman, Hesham" , "Alexandru Petrescu" X-OriginalArrivalTime: 21 Jun 2006 13:58:09.0196 (UTC) FILETIME=[BA3ED6C0:01C6953A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I have nothing against gateway farms and they can certainly used like that. Problem is that the end node needs to either be preconfigured with them or have yet another way to discover them, a way to create a security association with them, a way to deal with failures etc etc. Re-using the HAs makes some sense in that respect. > -----Original Message----- > From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] > Sent: Wednesday, June 21, 2006 9:32 AM > To: Alexandru Petrescu > Cc: mip6@ietf.org > Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for > IPv4(mip4) >=20 >=20 >=20 > > > =3D> Huh? what do you mean by "scale"? > > > > I mean an IPv6-only network is very large. If only its > > borders support > > IPv4 and IPv6 then all routers inside can't be HAs whose > > nodes attach to > > IPv4-only networks. >=20 > =3D> Please tell me exactly what the scalability concerns are. I can't > follow the above. >=20 >=20 > > It is still possible to have a MIP6 MN with an IPv4 stack, > > connecting to > > an IPv4-only network, use NAT traversal, and its operator > > not be forced > > to dual-stack all the HAs, just a "gateway" farm. And that is not > > DS-MIPv6, and no NAT. >=20 > =3D> You're right that's not DSMIPv6. We chose a different path, which > achieves the same result. Instead of requiring a "gateway farm" we reuse > the HA. >=20 > Hesham >=20 >=20 >=20 > > > > Alex > > >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 10:14:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3St-0004D3-Tl; Wed, 21 Jun 2006 10:13:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3Ss-0004Cy-MG for mip6@ietf.org; Wed, 21 Jun 2006 10:13:54 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3Sr-0007cC-Ba for mip6@ietf.org; Wed, 21 Jun 2006 10:13:54 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k5LEDqWe028995; Wed, 21 Jun 2006 07:13:52 -0700 (MST) Received: from [10.19.252.31] (mvp-10-19-252-31.corp.mot.com [10.19.252.31]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k5LEDoqk014073; Wed, 21 Jun 2006 09:13:51 -0500 (CDT) Message-ID: <4499541C.5080205@motorola.com> Date: Wed, 21 Jun 2006 16:13:48 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA51@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FA51@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: mip6@ietf.org, "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Tsirtsis, George wrote: > I have nothing against gateway farms and they can certainly used like > that. Problem is that the end node needs to either be preconfigured > with them or have yet another way to discover them, a way to create a > security association with them, a way to deal with failures etc etc. > Re-using the HAs makes some sense in that respect. "Gateway" farms can simply be 6to4 Relays. They have their anycast discovery mechanisms. However doesn't work behind NAT. "Gateway" farms can be Teredo Servers, or STUN Servers. These don't have a over-the-Internet discovery mechanisms, they should be pre-configured on the MNs. But I don't see what's the complain about. DS-MIPv6 can't "discover" its HAs either, DHAAD is for IPv6 only. IPv6 split bootstrapping doesn't work over IPv4. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 10:30:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3j6-0005jK-SG; Wed, 21 Jun 2006 10:30:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3j4-0005jF-Tx for mip6@ietf.org; Wed, 21 Jun 2006 10:30:38 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3j3-0008Uz-JD for mip6@ietf.org; Wed, 21 Jun 2006 10:30:38 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LEUXsD012504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 07:30:33 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LEUVl4026713; Wed, 21 Jun 2006 07:30:32 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 07:30:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Date: Wed, 21 Jun 2006 07:30:30 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA59@NAEX14.na.qualcomm.com> In-Reply-To: <4499541C.5080205@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Thread-Index: AcaVPQnLnWjmxNj2RnGK7ErKugaq4gAAfOTg From: "Tsirtsis, George" To: "Alexandru Petrescu" X-OriginalArrivalTime: 21 Jun 2006 14:30:31.0705 (UTC) FILETIME=[40123090:01C6953F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: mip6@ietf.org, "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org There is no complaint. I am simply pointing out that if you use HAs and a Gateway (of whatever form) you have to discover, manage and secure two entities instead of one.=20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Wednesday, June 21, 2006 10:14 AM > To: Tsirtsis, George > Cc: Soliman, Hesham; mip6@ietf.org > Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for > IPv4(mip4) >=20 > Tsirtsis, George wrote: > > I have nothing against gateway farms and they can certainly used like > > that. Problem is that the end node needs to either be preconfigured > > with them or have yet another way to discover them, a way to create a > > security association with them, a way to deal with failures etc etc. > > Re-using the HAs makes some sense in that respect. >=20 > "Gateway" farms can simply be 6to4 Relays. They have their anycast > discovery mechanisms. However doesn't work behind NAT. "Gateway" farms > can be Teredo Servers, or STUN Servers. These don't have a > over-the-Internet discovery mechanisms, they should be pre-configured on > the MNs. >=20 > But I don't see what's the complain about. >=20 > DS-MIPv6 can't "discover" its HAs either, DHAAD is for IPv6 only. >=20 > IPv6 split bootstrapping doesn't work over IPv4. >=20 > Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 10:32:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3l4-0007Ib-4h; Wed, 21 Jun 2006 10:32:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3l2-0007GU-C5 for mip6@ietf.org; Wed, 21 Jun 2006 10:32:40 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3l0-0000JO-3a for mip6@ietf.org; Wed, 21 Jun 2006 10:32:40 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5LEWbPi020138; Wed, 21 Jun 2006 07:32:37 -0700 (MST) Received: from [10.19.252.31] (mvp-10-19-252-31.corp.mot.com [10.19.252.31]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k5LEWaYA019864; Wed, 21 Jun 2006 09:32:36 -0500 (CDT) Message-ID: <44995882.1050609@motorola.com> Date: Wed, 21 Jun 2006 16:32:34 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA59@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FA59@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: mip6@ietf.org, "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Tsirtsis, George wrote: > There is no complaint. I am simply pointing out that if you use HAs and > a Gateway (of whatever form) you have to discover, manage and secure two > entities instead of one. Ok, just to say that DS-MIPv6 also has to discover its HAs, currently DS-MIPv6 MN can't discover its HA. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 10:35:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3nY-0000Ob-3n; Wed, 21 Jun 2006 10:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3nX-0000OO-IN for mip6@ietf.org; Wed, 21 Jun 2006 10:35:15 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3nV-0000c2-8B for mip6@ietf.org; Wed, 21 Jun 2006 10:35:15 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LEZBkB008342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 07:35:12 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LEZBoE025063; Wed, 21 Jun 2006 07:35:11 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 07:35:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Date: Wed, 21 Jun 2006 07:35:09 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA5B@NAEX14.na.qualcomm.com> In-Reply-To: <44995882.1050609@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Thread-Index: AcaVP5YfuL/x1YgnRuO5kqQ3TjSRUAAAEmwg From: "Tsirtsis, George" To: "Alexandru Petrescu" X-OriginalArrivalTime: 21 Jun 2006 14:35:10.0937 (UTC) FILETIME=[E6819C90:01C6953F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: mip6@ietf.org, "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Nobody is perfect :-) > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Wednesday, June 21, 2006 10:33 AM > To: Tsirtsis, George > Cc: Soliman, Hesham; mip6@ietf.org > Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for > IPv4(mip4) >=20 > Tsirtsis, George wrote: > > There is no complaint. I am simply pointing out that if you use HAs and > > a Gateway (of whatever form) you have to discover, manage and secure two > > entities instead of one. >=20 > Ok, just to say that DS-MIPv6 also has to discover its HAs, currently > DS-MIPv6 MN can't discover its HA. >=20 > Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 10:42:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3uz-0006H9-TO; Wed, 21 Jun 2006 10:42:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3uy-0006H4-R0 for mip6@ietf.org; Wed, 21 Jun 2006 10:42:56 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3ux-0001R4-HJ for mip6@ietf.org; Wed, 21 Jun 2006 10:42:56 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LEgrKd013447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 07:42:54 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LEgqjc022127; Wed, 21 Jun 2006 07:42:53 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 07:42:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Date: Wed, 21 Jun 2006 07:42:45 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA61@NAEX14.na.qualcomm.com> In-Reply-To: <4499541C.5080205@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Thread-Index: AcaVPQnLnWjmxNj2RnGK7ErKugaq4gAA7oZg From: "Soliman, Hesham" To: "Alexandru Petrescu" , "Tsirtsis, George" X-OriginalArrivalTime: 21 Jun 2006 14:42:52.0655 (UTC) FILETIME=[F9B62FF0:01C69540] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alex, please read the draft again....sigh=20 > DS-MIPv6 can't "discover" its HAs either, DHAAD is for IPv6 only. =3D> Read section 2.1 Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 10:58:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4AB-0008Fh-Jg; Wed, 21 Jun 2006 10:58:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4AA-0008Fc-Lm for mip6@ietf.org; Wed, 21 Jun 2006 10:58:38 -0400 Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4A9-0006KD-9L for mip6@ietf.org; Wed, 21 Jun 2006 10:58:38 -0400 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by warlock.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LEeeAn028561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Jun 2006 07:40:40 -0700 (PDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LEed5M013317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 07:40:39 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LEebAd029009; Wed, 21 Jun 2006 07:40:38 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 07:40:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Date: Wed, 21 Jun 2006 07:40:36 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA5F@NAEX14.na.qualcomm.com> In-Reply-To: <44994BA2.1010603@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Thread-Index: AcaVN+fTAynAH23WRg+xxXKlLS21PwACGnfA From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 21 Jun 2006 14:40:38.0541 (UTC) FILETIME=[A9C603D0:01C69540] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > >>> =3D> Huh? what do you mean by "scale"? > >>=20 > >> I mean an IPv6-only network is very large. If only its borders=20 > >> support IPv4 and IPv6 then all routers inside can't be HAs whose=20 > >> nodes attach to IPv4-only networks. > >=20 > > =3D> Please tell me exactly what the scalability concerns=20 > are. I can't=20 > > follow the above. >=20 > With DS-MIPv6, the size of the operator's IPv6 infra can not=20 > grow larger > ("scale") than what the IPv4 protocol allows. Does that makes sense? =3D> No it doesn't. DSMIPv6 does NOT limit the operator from deploying IPv6 only. The desire to do that is completely orthogonal to DSMIPv6. If you want to deploy IPv6 only without regard to IPv4 CNs then you would only use MIPv6, or you might use NAT-PT, but that's not the IETF's recommendation. DSMIPv6 is designed for roaming to IPv4 networks with MIPv6, or for using an IPv4 HoA with MIPv6. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 11:02:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4De-0001O5-Gg; Wed, 21 Jun 2006 11:02:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4Dc-0001O0-GT for mip6@ietf.org; Wed, 21 Jun 2006 11:02:12 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4Db-0006dt-9R for mip6@ietf.org; Wed, 21 Jun 2006 11:02:12 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5LF2Bmw027166; Wed, 21 Jun 2006 08:02:11 -0700 (MST) Received: from [10.19.252.31] (mvp-10-19-252-31.corp.mot.com [10.19.252.31]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k5LF29Rs010917; Wed, 21 Jun 2006 10:02:10 -0500 (CDT) Message-ID: <44995F6F.4090303@motorola.com> Date: Wed, 21 Jun 2006 17:02:07 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA61@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FA61@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > Alex, please read the draft again....sigh > >> DS-MIPv6 can't "discover" its HAs either, DHAAD is for IPv6 only. > > => Read section 2.1 Section 2.1 describes how the DS-MIPv6 MN discovers its HA by using DNS. An MIPv6 node with IPv4 stack and v4 traversal can also "discover" the address of the v4-v6 transition server this way. The Server can be Teredo, STUN or other. Both are RFCs spec'ed and implemented. Anything can be "discovered" that way, just feed its name in the DNS and specify that the administrator is responsible to put there the right A or AAAA address. I was thinking you people talk discovery in the terms of DHAAD, which is different than DNS-based. Check Router Discovery, DHCP Server discovery, DHAAD and 6to4 Relay discovery. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 11:54:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft52T-0006F7-IT; Wed, 21 Jun 2006 11:54:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft52R-000662-HA for mip6@ietf.org; Wed, 21 Jun 2006 11:54:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4He-0006qR-HP for mip6@ietf.org; Wed, 21 Jun 2006 11:06:22 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ft44I-0006fZ-Ig for mip6@ietf.org; Wed, 21 Jun 2006 10:52:35 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5LEqTfL024749; Wed, 21 Jun 2006 07:52:29 -0700 (MST) Received: from [10.19.252.31] (mvp-10-19-252-31.corp.mot.com [10.19.252.31]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k5LEqSbc005196; Wed, 21 Jun 2006 09:52:28 -0500 (CDT) Message-ID: <44995D2A.9040600@motorola.com> Date: Wed, 21 Jun 2006 16:52:26 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA5F@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FA5F@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: -2.4 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: >>>>> => Huh? what do you mean by "scale"? >>>> >>>> I mean an IPv6-only network is very large. If only its borders >>>> support IPv4 and IPv6 then all routers inside can't be HAs >>>> whose nodes attach to IPv4-only networks. >>> >>> => Please tell me exactly what the scalability concerns >> are. I can't >>> follow the above. >> >> With DS-MIPv6, the size of the operator's IPv6 infra can not grow >> larger ("scale") than what the IPv4 protocol allows. Does that >> makes sense? > > => No it doesn't. DSMIPv6 does NOT limit the operator from deploying > IPv6 only. The desire to do that is completely orthogonal to > DSMIPv6. If you want to deploy IPv6 only without regard to IPv4 CNs > then you would only use MIPv6, One operator can consider the IPv4 CNs, deploy its IPv6-only infrastructure, with MIPv6 HAs within it, with MNs running MIP6 and NAT Traversal. DS-MIPv6 doesn't allow that. > or you might use NAT-PT, but that's not the IETF's recommendation. I wasn't talking NAT-PT. And what's _not_ the IETF recommendation? I don't get it. The IETF recommendation is to not use NAT-PT? I guess the IETF recommendation _is_ to use existing IPv6 transition mechanisms wherever appropriate. > DSMIPv6 is designed for roaming to IPv4 networks with MIPv6, or for > using an IPv4 HoA with MIPv6. The first goal looks good. The second is not necessary and I don't know who asks for it. If you remove the second goal (and let MIPv4 do it) then one can get IPv6-only infrastructures for DS-MIPv6. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 12:34:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5ek-0006Sm-Mt; Wed, 21 Jun 2006 12:34:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5ej-0006R2-2Y for mip6@ietf.org; Wed, 21 Jun 2006 12:34:17 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5eh-0005yS-Mp for mip6@ietf.org; Wed, 21 Jun 2006 12:34:17 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LGYESB024498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 09:34:15 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LGXfTp005092; Wed, 21 Jun 2006 09:34:14 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 09:34:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Date: Wed, 21 Jun 2006 09:34:12 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA76@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FA5F@NAEX14.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Thread-Index: AcaVN+fTAynAH23WRg+xxXKlLS21PwACGnfAAAPyzhA= From: "Tsirtsis, George" To: "Soliman, Hesham" , "Alexandru Petrescu" X-OriginalArrivalTime: 21 Jun 2006 16:34:13.0696 (UTC) FILETIME=[87EC2400:01C69550] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The IPv4 address allocation part of DS-MIPv6 solution has the same limitations an IPv4 deployment has. The operator may not have enough public IPv4 addresses for everyone so it might use private IPv4 (and NATs) instead. I do not see IPv4 operators today not being able to expand their networks because of this. Why would that be the case in DS-MIPv6?? > -----Original Message----- > From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] > Sent: Wednesday, June 21, 2006 10:41 AM > To: Alexandru Petrescu > Cc: mip6@ietf.org > Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for > IPv4(mip4) >=20 >=20 > > >>> =3D> Huh? what do you mean by "scale"? > > >> > > >> I mean an IPv6-only network is very large. If only its borders > > >> support IPv4 and IPv6 then all routers inside can't be HAs whose > > >> nodes attach to IPv4-only networks. > > > > > > =3D> Please tell me exactly what the scalability concerns > > are. I can't > > > follow the above. > > > > With DS-MIPv6, the size of the operator's IPv6 infra can not > > grow larger > > ("scale") than what the IPv4 protocol allows. Does that makes sense? >=20 > =3D> No it doesn't. DSMIPv6 does NOT limit the operator from deploying > IPv6 only. > The desire to do that is completely orthogonal to DSMIPv6. If you want > to deploy IPv6 only without regard to IPv4 CNs then you would only use > MIPv6, or you might use NAT-PT, but that's not the IETF's > recommendation. DSMIPv6 is designed for roaming to IPv4 networks with > MIPv6, or for using an IPv4 HoA with MIPv6. >=20 > Hesham >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 13:37:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6dO-0005Ip-PJ; Wed, 21 Jun 2006 13:36:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6dN-0005IQ-8L for mip6@ietf.org; Wed, 21 Jun 2006 13:36:57 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft6dL-0005Sl-Ur for mip6@ietf.org; Wed, 21 Jun 2006 13:36:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction Date: Wed, 21 Jun 2006 10:36:52 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction Thread-Index: AcaUkZjsu/9iQGBqRYCAAKL6E3yXaQAj6qtgAA3nIiA= From: "Vijay Devarapalli" To: "Soliman, Hesham" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > > =3D> There is no difference between the two scenarios.=20 > >=20 > > your reply is too cryptic. > >=20 > > when shim6 is used, one cannot start using another address > > without first adding that address to the list of addresses > > that the HA/CN need to be aware of (basically add to the > > shim6 state). >=20 > =3D> Of course, which is doable in both scenarios. >=20 > >=20 > > also, if both home addresses are from the same prefix, > > shim6 shouldn't be used.=20 > ^^^^^^^^^ > =3D> that's your opinion, but the point is it can be used just as = easily > whether it's the same prefix or a different one. It actually=20 > makes sense > to use on solution for both cases. >=20 >=20 > if the home link is multihomed > > and the mobile node has multiple home addresses from the > > different prefixes, then shim6 is applicable. >=20 > =3D> It's applicable in both cases, you want to use it in one case.=20 yes. in my first reply to Shinta, I had said, I=20 _would like_ to restrict the use of shim6 when MIP6 is used to the scenario when the home link is multihomed. this is one of the reasons why folks are still=20 confused about the role of shim6 (see recent=20 discussion on the shim6 mailing list).=20 Vijay >=20 > Hesham >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 14:19:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7IN-0001H9-8r; Wed, 21 Jun 2006 14:19:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7IM-0001H4-Ti for mip6@ietf.org; Wed, 21 Jun 2006 14:19:18 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft7IL-0001Jt-DL for mip6@ietf.org; Wed, 21 Jun 2006 14:19:18 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 11:19:15 -0700 Message-ID: <44998D31.3050801@azairenet.com> Date: Wed, 21 Jun 2006 11:17:21 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA51@NAEX14.na.qualcomm.com> <4499541C.5080205@motorola.com> In-Reply-To: <4499541C.5080205@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 18:19:15.0353 (UTC) FILETIME=[3400B090:01C6955F] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mip6@ietf.org, "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > Tsirtsis, George wrote: > >> I have nothing against gateway farms and they can certainly used like >> that. Problem is that the end node needs to either be preconfigured >> with them or have yet another way to discover them, a way to create a >> security association with them, a way to deal with failures etc etc. >> Re-using the HAs makes some sense in that respect. > > > "Gateway" farms can simply be 6to4 Relays. They have their anycast > discovery mechanisms. However doesn't work behind NAT. "Gateway" farms > can be Teredo Servers, or STUN Servers. These don't have a > over-the-Internet discovery mechanisms, they should be pre-configured on > the MNs. > > But I don't see what's the complain about. > > DS-MIPv6 can't "discover" its HAs either, DHAAD is for IPv6 only. > > IPv6 split bootstrapping doesn't work over IPv4. draft-ietf-mip6-nemo-v4traversal-01.txt extends the split scenario bootstrapping mechanism to discover HA's IPv4 address. see section 2.1. there was also a proposal to extend DHAAD to return HA's IPv4 address in addition to the IPv6 address. but the design team decided not to include this. HA discovery through DNS was considered sufficient. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 14:47:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7jz-00020t-FY; Wed, 21 Jun 2006 14:47:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7jx-00020k-PX for mip6@ietf.org; Wed, 21 Jun 2006 14:47:49 -0400 Received: from outbound-cpk.frontbridge.com ([207.46.163.16] helo=outbound2-cpk-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft7jw-0004Ld-8Q for mip6@ietf.org; Wed, 21 Jun 2006 14:47:49 -0400 Received: from outbound2-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-cpk-R.bigfish.com (Postfix) with ESMTP id 95CB7A437E7; Wed, 21 Jun 2006 18:47:50 +0000 (UTC) Received: from mail60-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound2-cpk.bigfish.com (Postfix) with ESMTP id 8E51AA43288; Wed, 21 Jun 2006 18:47:50 +0000 (UTC) Received: from mail60-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail60-cpk-R.bigfish.com (Postfix) with ESMTP id 0326141C614; Wed, 21 Jun 2006 18:47:43 +0000 (UTC) X-BigFish: V Received: by mail60-cpk (MessageSwitch) id 1150915645319650_24171; Wed, 21 Jun 2006 18:47:25 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail60-cpk.bigfish.com (Postfix) with ESMTP id CE03741E2DB; Wed, 21 Jun 2006 18:47:24 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k5LIlRAg018059; Wed, 21 Jun 2006 13:47:27 -0500 (CDT) Received: from pdawg05a.ad.sprint.com (PDAWG05A.corp.sprint.com [10.122.2.38]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k5LIlMg02541; Wed, 21 Jun 2006 13:47:26 -0500 (CDT) Received: from PLSWB09C.ad.sprint.com ([208.10.70.239]) by pdawg05a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 13:47:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) Date: Wed, 21 Jun 2006 13:47:20 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) Thread-Index: AcaQ0ZbY1YH1fvzEEdqHQQARJNUNiAC3UJ9AAD69t1cALi3UkA== From: "Zhang, Qiang [NTK]" To: "Basavaraj Patil" , , "Levkowetz" , X-OriginalArrivalTime: 21 Jun 2006 18:47:22.0011 (UTC) FILETIME=[215446B0:01C69563] X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Jari Arkko , mccap@lucent.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Raj, Jouni, FYI, the new 3gpp2 and 3gpp wireless IP standards have the requirements for PDSN, GGSN to support simultaneous data context be it combination of simple IPv4, IPv6, MIPv4, MIPv6, a reference doc http://www.3gpp2.org/Public_html/specs/X.S0011-002-D_v1.0_060301.pdf=20 I guess it is more an implementation issue now. As Soliman pointed out, if dual stacks are taken care of separately (specially do-able in controlled carrier environment), the DSMIP won't be necessarily applicable Qiang -----Original Message----- From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com]=20 Sent: Tuesday, June 20, 2006 4:41 PM To: ext jouni.korhonen@teliasonera.com; Levkowetz; kempf@docomolabs-usa.com Cc: Jari Arkko; mccap@lucent.com; mip6@ietf.org Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) Hi Jouni, Inline: On 6/20/06 7:45 AM, "ext jouni.korhonen@teliasonera.com" wrote: > Hi Raj, >=20 >> Henrik, >>=20 >> In the DS-MIP6 case the reasoning for the work has been that >> IPv6 native >> access is not expected to be ubiquitous and hence given that >> the host is DS >> and access is IPv4, there is a need to enable MIP6 continuity >> while being >> attached to a v4 network. The ability to carry IPv4 within >> the MIP6 session >> is to enable applications and services that are v4 based on >> the hosts and is >> applicable in the scenario when the host is connected to a >> native v6 access >> only (which I guess we believe will be the situation at some >> point in the >> future). So I believe there is a good reason to do this for MIP6. >=20 > Don't we have this situation in a way already? If I remember correctly > e.g. in 2G/3G a DS terminal can open either an IPv4 or IPv6 PDP context. > So if you want IPv6 over your cellular you are stuck in IPv6 only > access for that context. Of course then it is up to the terminal > and/or GGSN implementations whether they allow multiple primary > contexts of different IP version (and possibly to the same APN), > which might not always be the case.. Current terminals can have multiple PDP contexts for sure. I am not sure if a terminal can establish an IPv4/v6 PDP context to the same APN. I don't know if this works or if this is not allowed for some reason. But it is a limitation if an APN does not allow multiple IP version PDP contexts for the same host... And in such a case, I agree that if you have an IPvX PDP context, you would want to carry the other IP version over that. However in the context of GPRS, I think that would be a suboptimal solution. Rather I would think that having the APN support multiple PDP contexts for the same host with different IP versions would a cleaner solution. -Raj >=20 > Jouni >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 16:12:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft948-0004sx-8Y; Wed, 21 Jun 2006 16:12:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8p4-0004Iv-8a for mip6@ietf.org; Wed, 21 Jun 2006 15:57:10 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft8p0-0005Xs-Ad for mip6@ietf.org; Wed, 21 Jun 2006 15:57:07 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5LJuucT026519; Wed, 21 Jun 2006 12:57:00 -0700 (MST) Received: from [10.129.40.246] ([10.129.40.246]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k5LJusrJ010941; Wed, 21 Jun 2006 14:56:55 -0500 (CDT) Message-ID: <4499A485.7070206@motorola.com> Date: Wed, 21 Jun 2006 21:56:53 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA51@NAEX14.na.qualcomm.com> <4499541C.5080205@motorola.com> <44998D31.3050801@azairenet.com> In-Reply-To: <44998D31.3050801@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: mip6@ietf.org, "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Tsirtsis, George wrote: >> >>> I have nothing against gateway farms and they can certainly used >>> like that. Problem is that the end node needs to either be >>> preconfigured with them or have yet another way to discover them, >>> a way to create a security association with them, a way to deal >>> with failures etc etc. Re-using the HAs makes some sense in that >>> respect. >> >> >> "Gateway" farms can simply be 6to4 Relays. They have their anycast >> discovery mechanisms. However doesn't work behind NAT. "Gateway" >> farms can be Teredo Servers, or STUN Servers. These don't have a >> over-the-Internet discovery mechanisms, they should be >> pre-configured on the MNs. >> >> But I don't see what's the complain about. >> >> DS-MIPv6 can't "discover" its HAs either, DHAAD is for IPv6 only. >> >> IPv6 split bootstrapping doesn't work over IPv4. > > draft-ietf-mip6-nemo-v4traversal-01.txt extends the split scenario > bootstrapping mechanism to discover HA's IPv4 address. see section > 2.1. That should be re-named from "discovery" to "DNS resolution". Other "discovery" mechanisms (DHCP Server discovery, DHAADiscovery, MLDiscovery, ND router discovery) don't rely on DNS to discover. I know of no discovery relying on DNS, you may know better - please let me know. Resolving the DNS name can happen also to find out a 6to4 Relay, but in practice different people provide different Relays and there's no centralized point who could manage a generic say 6to4.net address. If one would like HA service to be offered by various servers controlled independently then one can't rely on DNS resolution for discovery. > there was also a proposal to extend DHAAD to return HA's IPv4 address > in addition to the IPv6 address. Sounds as a good idea, except the DHAAD messaging should happen over a form of IPv4 anycast addressing which doesn't seem to exist. Or the use of an IPv4 multicast address was proposed? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 16:22:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9DQ-0007Go-0c; Wed, 21 Jun 2006 16:22:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9DO-0007Gg-Pg for mip6@ietf.org; Wed, 21 Jun 2006 16:22:18 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft9DN-0007n6-D2 for mip6@ietf.org; Wed, 21 Jun 2006 16:22:18 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k5LKM5mU010841; Wed, 21 Jun 2006 13:22:05 -0700 (MST) Received: from [10.129.40.246] ([10.129.40.246]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k5LKM3uV005474; Wed, 21 Jun 2006 15:22:04 -0500 (CDT) Message-ID: <4499AA6A.90801@motorola.com> Date: Wed, 21 Jun 2006 22:22:02 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA76@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FA76@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: mip6@ietf.org, "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Tsirtsis, George wrote: > The IPv4 address allocation part of DS-MIPv6 solution has the same > limitations an IPv4 deployment has. The operator may not have enough > public IPv4 addresses for everyone so it might use private IPv4 (and > NATs) instead.[...] Why would that [not] be the case in DS-MIPv6?? An operator using NATs to offer IPv4 home addresses do so without offering reachability at that permanent IPv4 home address. Would DS-MIPv6 allow this? I really think we should come back to original requirements and goals here... The problem is simple: offer session continuity and reachability at permanent IPv4 and IPv6 addresses. > I do not see IPv4 operators today not being able to expand their > networks because of this. Even if an operator uses the entire class A (24bits), and the class B (20bits), and the class C (16bits) allocated by IANA for private IPv4 addresses, their number does not amount to what IPv6 80bits has to offer. The private IPv4 address space is defined in rfc1918. The IPv6 address space is in rfc3513. Alex > >> -----Original Message----- From: Soliman, Hesham >> [mailto:hsoliman@qualcomm.com] Sent: Wednesday, June 21, 2006 10:41 >> AM To: Alexandru Petrescu Cc: mip6@ietf.org Subject: RE: [Mip6] >> FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) >> >> >>>>>> => Huh? what do you mean by "scale"? >>>>> >>>>> I mean an IPv6-only network is very large. If only its >>>>> borders support IPv4 and IPv6 then all routers inside can't >>>>> be HAs whose nodes attach to IPv4-only networks. >>>> >>>> => Please tell me exactly what the scalability concerns >>> are. I can't >>>> follow the above. >>> >>> With DS-MIPv6, the size of the operator's IPv6 infra can not grow >>> larger ("scale") than what the IPv4 protocol allows. Does that >>> makes > sense? >> => No it doesn't. DSMIPv6 does NOT limit the operator from >> deploying IPv6 only. The desire to do that is completely orthogonal >> to DSMIPv6. If you want to deploy IPv6 only without regard to IPv4 >> CNs then you would only use MIPv6, or you might use NAT-PT, but >> that's not the IETF's recommendation. DSMIPv6 is designed for >> roaming to IPv4 networks with MIPv6, or for using an IPv4 HoA with >> MIPv6. >> >> Hesham >> >> _______________________________________________ Mip6 mailing list >> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 17:04:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9sZ-0001vs-Vk; Wed, 21 Jun 2006 17:04:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9sZ-0001vn-C4 for mip6@ietf.org; Wed, 21 Jun 2006 17:04:51 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft9sX-0005OE-RG for mip6@ietf.org; Wed, 21 Jun 2006 17:04:51 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 14:04:48 -0700 Message-ID: <4499B3F7.6040906@azairenet.com> Date: Wed, 21 Jun 2006 14:02:47 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA51@NAEX14.na.qualcomm.com> <4499541C.5080205@motorola.com> <44998D31.3050801@azairenet.com> <4499A485.7070206@motorola.com> In-Reply-To: <4499A485.7070206@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 21:04:48.0947 (UTC) FILETIME=[54E2D830:01C69576] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: mip6@ietf.org, "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: >>>> I have nothing against gateway farms and they can certainly used >>>> like that. Problem is that the end node needs to either be >>>> preconfigured with them or have yet another way to discover them, >>>> a way to create a security association with them, a way to deal >>>> with failures etc etc. Re-using the HAs makes some sense in that >>>> respect. >>> >>> >>> >>> "Gateway" farms can simply be 6to4 Relays. They have their anycast >>> discovery mechanisms. However doesn't work behind NAT. "Gateway" >>> farms can be Teredo Servers, or STUN Servers. These don't have a >>> over-the-Internet discovery mechanisms, they should be >>> pre-configured on the MNs. >>> >>> But I don't see what's the complain about. >>> >>> DS-MIPv6 can't "discover" its HAs either, DHAAD is for IPv6 only. >>> >>> IPv6 split bootstrapping doesn't work over IPv4. >> >> >> draft-ietf-mip6-nemo-v4traversal-01.txt extends the split scenario >> bootstrapping mechanism to discover HA's IPv4 address. see section 2.1. > > > That should be re-named from "discovery" to "DNS resolution". Other > "discovery" mechanisms (DHCP Server discovery, DHAADiscovery, > MLDiscovery, ND router discovery) don't rely on DNS to discover. I know > of no discovery relying on DNS, you may know better - please let me know. > > Resolving the DNS name can happen also to find out a 6to4 Relay, but in > practice different people provide different Relays and there's no > centralized point who could manage a generic say 6to4.net address. > > If one would like HA service to be offered by various servers > controlled independently then one can't rely on DNS resolution for > discovery. note that HA discovery throught DNS is not mandated. you can use your favorite mechanism (deployment specific) to configure the mobile node with the HA information. >> there was also a proposal to extend DHAAD to return HA's IPv4 address >> in addition to the IPv6 address. > > > Sounds as a good idea, except the DHAAD messaging should happen over a > form of IPv4 anycast addressing which doesn't seem to exist. Or the use > of an IPv4 multicast address was proposed? the solution was limited to performing DHAAD only when the MN is attached to an IPv6 access network. there was no extension to DHAAD to work over IPv4. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 17:10:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9xW-0006mO-RG; Wed, 21 Jun 2006 17:09:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9xU-0006lF-UZ for mip6@ietf.org; Wed, 21 Jun 2006 17:09:56 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft9xT-00065z-FU for mip6@ietf.org; Wed, 21 Jun 2006 17:09:56 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5LL9seP019757 for ; Thu, 22 Jun 2006 00:09:54 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 00:09:54 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 16:09:51 -0500 Received: from 172.19.244.70 ([172.19.244.70]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Jun 2006 21:09:51 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 21 Jun 2006 16:10:03 -0500 From: Basavaraj Patil To: Message-ID: Thread-Topic: Draft agenda for MIP6 WG meeting at IETF66 Thread-Index: AcaVdxATTlnOJwFqEduj0wARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 21:09:51.0577 (UTC) FILETIME=[09448490:01C69577] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org THURSDAY, July 13, 2006 0900-1130 Morning Session I Room 518AB ========================================= 1. Agenda review, Blue sheets and volunteers for taking notes and Jabber scribe 5 Mins 2. WG status and I-Ds update 10 Mins 3. Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) I-D: draft-ietf-mip6-nemo-v4traversal-01.txt Hesham Soliman 15 Mins 4. Mobility management for Dual stack mobile nodes: A Problem Statement I-D: draft-ietf-mip6-dsmip-problem-02.txt Hesham Soliman 5 Mins 5. Charter discussion 15 Mins Chairs Non-WG items: A. Vendor specific and experimental message types I-D: draft-devarapalli-mip6-vsm-00.txt draft-devarapalli-mip6-experimental-messages-00.txt Vijay Devarapalli 15 Mins B. Bootstrapping for the authentication option protocol I-D: draft-devarapalli-mip6-authprotocol-bootstrap-00.txt C. DHCP Option for Home Information Discovery in MIPv6 I-D: draft-jang-mip6-hiopt-00.txt Heejin Jiang 10 Mins D. Scenario analysis and problem statement of the dual-stack mobile entity roaming in the ipv4 and ipv6 network I-D: draft-wan-mip6-nemo-dsanalysis-00.txt Tom Wan 10 Mins _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 17:42:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAT8-0003Wk-Ai; Wed, 21 Jun 2006 17:42:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtASk-0003SU-1f for mip6@ietf.org; Wed, 21 Jun 2006 17:42:14 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtAEq-0007ZL-6x for mip6@ietf.org; Wed, 21 Jun 2006 17:27:53 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k5LLRlja021935; Wed, 21 Jun 2006 14:27:51 -0700 (MST) Received: from [10.129.40.246] ([10.129.40.246]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k5LLRiZl001013; Wed, 21 Jun 2006 16:27:45 -0500 (CDT) Message-ID: <4499B9D0.2090504@motorola.com> Date: Wed, 21 Jun 2006 23:27:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FAE0@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FAE0@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: mip6@ietf.org, "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Tsirtsis, George wrote: >> An operator using NATs to offer IPv4 home addresses do so without >> offering reachability at that permanent IPv4 home address. Would >> DS-MIPv6 allow this? >> > > Sure it does. Ok, so DS-MIPv6 does not have as a goal to offer reachable IPv4 Home Addresses for Mobile Nodes. >> I really think we should come back to original requirements and >> goals here... The problem is simple: offer session continuity and >> reachability at permanent IPv4 and IPv6 addresses. >> > > I do not think that "permanent" IPv4 addresses is a goal. Good to know DS-MIPv6 does not try to offer reachable IPv4 home addresses. > If we could give permanent IPv4 addresses we would not have to spend > 10 years on IPv6. :-) > All we need is to allow DS nodes to be able to communicate with the > IPv4 internet while they are moving around. If the HoA is behind NAT, thus not reachable, it's little useful for HA to maintain associations IPv4 CoA-HoA, because HA would not receive packets initiated by CN, even though HA would know where to forward the IPv4 traffic (the CoA). There are particular apps where traffic is initiated by IPv4 HoA towards IPv4 CN. In this case the MN could as well use its IPv4 CoA for initiation and not reverse tunnel to HA. In those two cases I don't see the need for DS-MIPv6 HA to maintain associations IPv4 HoA-CoA. > The IPv6 part of the stack offers the permanent address the end node > needs. Yes, the permanent reachable IPv6 home address for session continuity, but not the v4 address. >>> I do not see IPv4 operators today not being able to expand their >>> networks because of this. >> Even if an operator uses the entire class A (24bits), and the class >> B (20bits), and the class C (16bits) allocated by IANA for private >> IPv4 addresses, their number does not amount to what IPv6 80bits >> has to offer. The private IPv4 address space is defined in >> rfc1918. The IPv6 address space is in rfc3513. >> > > The Internet today has done fine with this space and I have yet to > find a company that is running out of private address space to use. Right, I agree with it. And many infrastructures use several levels of NATs and MPLS. > BTW, IPv6 does not offer 80bits to anyone since most allocations are > supposed to be /64 or larger. 80bit space is larger than 64bit space, ok. A company asking for an IPv6 prefix from a RIR could easily get 80bit space (i.e. a /48 prefix). If it can't then just use 6to4 - that can. Besides, a more motivated company would manage 6to4 relays for itself in which case it could get 80bit space times the number of IPv4 addresses it already has, that's really big. An even more motivated would propose a 6to4 method that wouldn't require the 32bits of the IPv4 address to be public, but private, just like in NAT, so it could build its own IPv6 128bit space, as big as the Internet, and still not reachable from it :-) Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 17:42:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtATH-0003e9-Ao; Wed, 21 Jun 2006 17:42:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtASW-0003Gm-Gn for mip6@ietf.org; Wed, 21 Jun 2006 17:42:00 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtAQl-0001Wj-QH for mip6@ietf.org; Wed, 21 Jun 2006 17:40:13 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5LLe6aK009788; Thu, 22 Jun 2006 00:40:07 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 00:40:03 +0300 Received: from [127.0.0.1] ([10.241.161.123]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 22 Jun 2006 00:40:02 +0300 Message-ID: <4499BCAB.7080107@iprg.nokia.com> Date: Wed, 21 Jun 2006 17:39:55 -0400 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kilian Weniger Subject: Re: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01) References: <4D2F935F08D41A4C8866693F4F0D7C4FB8E593@lan-ex-01.panasonic.de> In-Reply-To: <4D2F935F08D41A4C8866693F4F0D7C4FB8E593@lan-ex-01.panasonic.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 21:40:03.0037 (UTC) FILETIME=[40FB60D0:01C6957B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Kilian, Kilian Weniger wrote: > >>Roaming: The process of moving from one network to another (with or >>without existing >>sessions). >> >> > >I'm not in favour of using the term "roaming" in a different way than >defined in RFC3753, since I was quite confused about the usage of this >term in this draft. What do others think? >If "l3 handover" is not appropriate, how about "l3 movement" (or >introducing a new term)? > > > We are using the word in its literal sense. I for one was not thinking about 3753, and I propose we move forward with the addition of above sentence to the draft. (It's kind of late for this discussion at LC). >>We should be able to hide HoA all together and have something to say >>about how to use CoA >>judiciously if the MN is concerned about revealing the CoA. >> >> > >yes, but I think this requirement is not explicitly stated in the draft. >My proposal was to add some text that explicitly states requirements. > > > I would like it to be as flexible as possible, yet be within the existing MIP framework of functional elements (i.e., MN, HA and CN). >I didn't say that they are excluded. I just proposed to explicitly state >requirements, since this may help in developing and evaluating >solutions. > > > See above. >ok (however, it might be difficult to check solutions against this >requirement, e.g., how much modifications to the entity "HA" are allowed >to still call it "HA"?) > > > hmm.. I am inclined to thinking that protocol extensions are what we work on. If there are new functional elements, that's outside the scope. So, I propose adding the following: "The solutions to the location privacy problem described in this document should be new protocols or existing protocol enhancements within the current Mobile IPv6 framework involving the Mobile Node, the Home Agent and the Correspondent Node." >ok, maybe with some additional text about why it is often not conclusive >(e.g., delay varies with access technologies used by MN; CN doesn't know >which technology is used by MN) > > > > Okay. Thanks, -Rajeev >- Kilian > > > >>-Rajeev >> >> >> >> >>>- Kilian >>> >>> >>>-----Original Message----- >>>From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] >>>Sent: Freitag, 2. Juni 2006 18:01 >>>To: mip6@ietf.org >>>Subject: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01) >>> >>> >>> >>>Hello, >>> >>>This is the working group last call for I-D: >>>draft-ietf-mip6-location-privacy-ps-01.txt (IP Address >>> >>> >>Location Privacy >> >> >>>and Mobile IPv6: Problem Statement) >>> >>>WG LC will end on June 16th, 06. Please review and send your comments >>>before the deadline. >>> >>>The document is intended to be published as an Informational RFC. >>> >>>-Chairs >>> >>>The link for the I-D: >>>http://ietf.org/internet-drafts/draft-ietf-mip6-location-priv >>> >>> >acy-ps-01.t > > >>>xt >>> >>> >>>_______________________________________________ >>>Mip6 mailing list >>>Mip6@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mip6 >>> >>> >>> >>>_______________________________________________ >>>Mip6 mailing list >>>Mip6@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mip6 >>> >>> >>> >>> >> >>_______________________________________________ >>Mip6 mailing list >>Mip6@ietf.org >>https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> >> > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 17:43:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtATw-00042m-Gi; Wed, 21 Jun 2006 17:43:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtATu-0003zz-1N for mip6@ietf.org; Wed, 21 Jun 2006 17:43:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtATt-0002Ye-W4 for mip6@ietf.org; Wed, 21 Jun 2006 17:43:26 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtAJR-0006zS-Ps for mip6@ietf.org; Wed, 21 Jun 2006 17:32:38 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k5LLWVUw006249; Wed, 21 Jun 2006 14:32:31 -0700 (MST) Received: from [10.129.40.246] ([10.129.40.246]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k5LLWSXx004547; Wed, 21 Jun 2006 16:32:29 -0500 (CDT) Message-ID: <4499BAEB.7020408@motorola.com> Date: Wed, 21 Jun 2006 23:32:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA51@NAEX14.na.qualcomm.com> <4499541C.5080205@motorola.com> <44998D31.3050801@azairenet.com> <4499A485.7070206@motorola.com> <4499B3F7.6040906@azairenet.com> In-Reply-To: <4499B3F7.6040906@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: -2.6 (--) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: mip6@ietf.org, "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >>>>> I have nothing against gateway farms and they can certainly >>>>> used like that. Problem is that the end node needs to either >>>>> be preconfigured with them or have yet another way to >>>>> discover them, a way to create a security association with >>>>> them, a way to deal with failures etc etc. Re-using the HAs >>>>> makes some sense in that respect. >>>> >>>> >>>> >>>> "Gateway" farms can simply be 6to4 Relays. They have their >>>> anycast discovery mechanisms. However doesn't work behind NAT. >>>> "Gateway" farms can be Teredo Servers, or STUN Servers. These >>>> don't have a over-the-Internet discovery mechanisms, they >>>> should be pre-configured on the MNs. >>>> >>>> But I don't see what's the complain about. >>>> >>>> DS-MIPv6 can't "discover" its HAs either, DHAAD is for IPv6 >>>> only. >>>> >>>> IPv6 split bootstrapping doesn't work over IPv4. >>> >>> >>> draft-ietf-mip6-nemo-v4traversal-01.txt extends the split >>> scenario bootstrapping mechanism to discover HA's IPv4 address. >>> see section 2.1. >> >> >> That should be re-named from "discovery" to "DNS resolution". Other >> "discovery" mechanisms (DHCP Server discovery, DHAADiscovery, >> MLDiscovery, ND router discovery) don't rely on DNS to discover. I >> know of no discovery relying on DNS, you may know better - please >> let me know. >> >> Resolving the DNS name can happen also to find out a 6to4 Relay, >> but in practice different people provide different Relays and >> there's no centralized point who could manage a generic say >> 6to4.net address. >> >> If one would like HA service to be offered by various servers >> controlled independently then one can't rely on DNS resolution for >> discovery. > > note that HA discovery throught DNS is not mandated. you can use your > favorite mechanism (deployment specific) to configure the mobile > node with the HA information. Ok. Some deployments will use pre-configured information on the mobile. >>> there was also a proposal to extend DHAAD to return HA's IPv4 >>> address in addition to the IPv6 address. >> >> >> Sounds as a good idea, except the DHAAD messaging should happen >> over a form of IPv4 anycast addressing which doesn't seem to exist. >> Or the use of an IPv4 multicast address was proposed? > > the solution was limited to performing DHAAD only when the MN is > attached to an IPv6 access network. there was no extension to DHAAD > to work over IPv4. That sounds like an even better idea. When attached to an IPv6 network use DHAAD to discover both the v4 and the v6 home agent addresses. There would be a need for the IPv4 and IPv6 HAs to talk to each other, inform their addresses, but that would be feasible by extending the RA part and/or other inter-HA synch protocol. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 17:48:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAYx-0000Dt-Rp; Wed, 21 Jun 2006 17:48:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAYx-0000Df-Af; Wed, 21 Jun 2006 17:48:39 -0400 Received: from mout.perfora.net ([217.160.230.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtAYw-0002nc-TR; Wed, 21 Jun 2006 17:48:39 -0400 Received: from [207.62.244.239] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1FtAYX2m3k-0000p1; Wed, 21 Jun 2006 17:48:19 -0400 From: "Alper Yegin" To: "'Gerardo Giaretta'" Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 Date: Wed, 21 Jun 2006 14:48:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaVCycchFzw3sAFQCKFlQQFEfTSIQAb+y/g In-Reply-To: Message-ID: <0MKoyl-1FtAYX2m3k-0000p1@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: mip6@ietf.org, dhcwg@ietf.org, 'Heejin Jang' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Gerardo, I think it helps to understand the components of the full picture. [a] Delivery of the info from home AAA to the NAS [b] Delivery of the info from the NAS (DHCP relay) to the DHCP server. [c] Delivery of the info from the DHCP server to the DHCP client [d] Plumbing of all these components [a], [b], and [c] are all protocol work. [d] is just informational. The document draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt covers [b] and [d]. WiMAX does not use [b]. For that there is no need to have a normative reference to draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. It could have an informative reference to it, but it does not have to. Alper > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Wednesday, June 21, 2006 1:18 AM > To: Alper Yegin > Cc: Vijay Devarapalli; mip6@ietf.org; Heejin Jang; dhcwg@ietf.org > Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home Information > Discovery inMIPv6 > > Alper, > > just one question below in order to understand if there is a real > technical reason to keep the docs separated.. > > > > > But I hope this data point helps: WiMAX Forum NWG architecture is > using > > > > draft-jang. > > > > > > in what context and how are they planning to use it? > > > > The MIP info is brought to the DHCP server via RADIUS and delivered to > the > > MN via DHCP. > > > > Can you please explain which are the technical differences between the > solution in the DT draft for integrated scenario and the solution > developped in WiMAX? > > I guess in WiMAX MIP info are brought to DHCP relay (i.e. NAS) and > then draft-jang is applied. Is this really different from what is > described in the DT draft? > > --Gerardo > > > > the > > > WiMAX forum NWG can still use the DHCP options wherever > > > they are defined. > > > > Yes. And WiMAX Forum could also use it even if IETF had concatenated all > of > > the RFCs and I-Ds under a single document too.... This I-D being > referenced > > whereas the draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt wasn't > is a > > solid proof that the former I-D is useful without having to be > integrated > > into the latter. > > > > > > > >>the only other mechanism is to manually > > > >>configure the DHCP servers in the visited link with > > > >>information like home agent address, home address and home > > > >>prefix. this is a bad idea. > > > > > > You know that one does not have to put DHCP servers on every subnet, > instead > > one can rely on DHCP relays. And that's the used technique for many > > enterprise networks. So, I don't see why this is a bad idea. > > > > Alper > > > > > > > > > > > > > > Vijay > > > > > > > > > > > Alper > > > > > > > > > > > > > > > >>-----Original Message----- > > > >>From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > > >>Sent: Monday, June 19, 2006 6:17 PM > > > >>To: Heejin Jang > > > >>Cc: mip6@ietf.org; dhcwg@ietf.org > > > >>Subject: Re: [Mip6] [Updated] DHCP Option for Home Information > Discovery > > > >>inMIPv6 > > > >> > > > >>Heejin Jang wrote: > > > >> > > > >>>Hello folks, > > > >>>We posted an I-D that proposes new DHCP Options for Home > Information > > > >>>Discovery in MIPv6. > > > >>> > > > >>>Kindly note that the previous version of this draft is > > > >>>"draft-jang-dhc-haopt-02.txt" but the name is slightly changed into > > > >>>"draft-jang-mip6-hiopt-00.txt" while keeping almost the same > contents. > > > >>> > > > >>>The drafts referencing this draft such as > > > >>>draft-ietf-mip6-bootstrapping-split-02.txt and > > > >>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt need to be > revised > > > >>>accordingly. > > > >>> > > > >>>We would appreciate to hear your comments. > > > >> > > > >>when this draft was discussed in the MIP6 bootstrapping > > > >>design team, many people wanted to integrate the two DHCP > > > >>options into > > > >>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. > > > >>this was mainly because the options defined in the document > > > >>have limited applicability beyond the integrated scenario > > > >>solution document. the only other mechanism is to manually > > > >>configure the DHCP servers in the visited link with > > > >>information like home agent address, home address and home > > > >>prefix. this is a bad idea. > > > >> > > > >>there was some opposition and we never reached an agreement. > > > >> > > > >>so I suggest including these options into the integrated > > > >>scenario solution document for these options to get > > > >>standardized quickly. > > > >> > > > >>Vijay > > > >> > > > >>_______________________________________________ > > > >>Mip6 mailing list > > > >>Mip6@ietf.org > > > >>https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 18:03:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAmw-0007TK-Jx; Wed, 21 Jun 2006 18:03:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAmv-0007T2-9x for mip6@ietf.org; Wed, 21 Jun 2006 18:03:05 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtAmt-0003Ey-Tg for mip6@ietf.org; Wed, 21 Jun 2006 18:03:05 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 15:02:57 -0700 Message-ID: <4499C19F.3050707@azairenet.com> Date: Wed, 21 Jun 2006 15:01:03 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shinta Sugimoto Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction References: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> <4498363E.4050702@azairenet.com> <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> In-Reply-To: <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 22:02:57.0857 (UTC) FILETIME=[74704310:01C6957E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Shinta Sugimoto wrote: >>>>>>The problem here is how does the MN know to "let the >>>>>>existing sessions continue with the existing HoA"? If there is no CN's >>>>>>address in BUL, surely the MN can choose a suitable HoA. For >>>>>>a CN with which it has a binding, it has no reliable way of knowing >>>>>>whether there are any ULP sessions. >>>>> >>>>>If you need to maintain the sessions while changing the HoA >>>> >>>>>from one to another, I think you need additional mechanism >>>> >>>>>than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed >>>>>to assure the reachability to a given HoA with the current >>>>>location of the mobile node (CoA). If the app wants >>>>>to change HoAs for some reason (I assume that privacy is the >>>>>main interest), there is a need to maintain the mapping of >>>>>the identity and the locator of the mobile node. >>>> >>>>Mobile IPv6 today allows you to use two home addresses >>>>at the same time. it also allows you to bind both home >>>>addresses to the same CoA. >>> >>> >>>Yes, that's true. But then there is a problem to choose >>>which one for which communication. When it comes to agility, >>>it's more problematic. >> >>actually we are not looking for address agility here. we want >>the mobile node to change its home address and while changing >>it allow existing sessions using the old home address to >>continue and start using the new home address for new sessions. > > > I see. Now I understand that address agility is not the main > issue here. If I understand the above correctly, the issue > is more about how to handle pseudo-HoA especially for correspondents > of the mobile node, and how to minimize the impact to the > existing communication. its not even about privacy. its about the mobile node deciding to change home addresses, while minimizing impact on existing sessions. new sessions would be started with the new HoA. for a short period there will be two home addresses with some sessions based on the old HoA and some on the new HoA. > Now I have another question. Looking into the solution draft > (draft-irtf-mobopts-location-privacy-solutions-01) it seems to me > that a pseudo-HoA is derived from mobile node's home prefix > and it is actually a globally unique IPv6 address. If I understand > the role of pseudo-HoA correctly, it aims to serve as a tag to > locate the real HoA for the MN. If so, I am afraid that it may > not be necessary to generate a pseudo-HoA in form of IPv6 address. > In particular, there is no need to contain the home prefix which > could be of interest for an eavesdropper to identify the mobile > node. Am I missing something ? I would actually wait for version 02, which should be out next week before we discuss further. I wasn't very happy with version 01. regarding the pseudo-HoA, it can be any 128 bit value. does not have to have the home prefix. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 18:11:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAvL-0007UK-4t; Wed, 21 Jun 2006 18:11:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAvK-0007T7-CJ; Wed, 21 Jun 2006 18:11:46 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtAvJ-0003aW-RC; Wed, 21 Jun 2006 18:11:46 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 15:11:44 -0700 Message-ID: <4499C3AE.1030903@azairenet.com> Date: Wed, 21 Jun 2006 15:09:50 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 References: <0MKoyl-1FtAYX2m3k-0000p1@mrelay.perfora.net> In-Reply-To: <0MKoyl-1FtAYX2m3k-0000p1@mrelay.perfora.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 22:11:44.0930 (UTC) FILETIME=[AE993820:01C6957F] X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: mip6@ietf.org, 'Heejin Jang' , dhcwg@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alper Yegin wrote: > Gerardo, > > I think it helps to understand the components of the full picture. > > [a] Delivery of the info from home AAA to the NAS > [b] Delivery of the info from the NAS (DHCP relay) to the DHCP server. > [c] Delivery of the info from the DHCP server to the DHCP client > [d] Plumbing of all these components > > > [a], [b], and [c] are all protocol work. [d] is just informational. > > The document draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt covers [b] > and [d]. section 3.6 and 3.7 of draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt seem to describe [c]. Vijay > > WiMAX does not use [b]. For that there is no need to have a normative > reference to draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. It could > have an informative reference to it, but it does not have to. > > Alper > > > > > > > >>-----Original Message----- >>From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] >>Sent: Wednesday, June 21, 2006 1:18 AM >>To: Alper Yegin >>Cc: Vijay Devarapalli; mip6@ietf.org; Heejin Jang; dhcwg@ietf.org >>Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home Information >>Discovery inMIPv6 >> >>Alper, >> >>just one question below in order to understand if there is a real >>technical reason to keep the docs separated.. >> >> >>>>>But I hope this data point helps: WiMAX Forum NWG architecture is >> >>using >> >>>>>draft-jang. >>>> >>>>in what context and how are they planning to use it? >>> >>>The MIP info is brought to the DHCP server via RADIUS and delivered to >> >>the >> >>>MN via DHCP. >>> >> >>Can you please explain which are the technical differences between the >>solution in the DT draft for integrated scenario and the solution >>developped in WiMAX? >> >>I guess in WiMAX MIP info are brought to DHCP relay (i.e. NAS) and >>then draft-jang is applied. Is this really different from what is >>described in the DT draft? >> >>--Gerardo >> >> >>>>the >>>>WiMAX forum NWG can still use the DHCP options wherever >>>>they are defined. >>> >>>Yes. And WiMAX Forum could also use it even if IETF had concatenated all >> >>of >> >>>the RFCs and I-Ds under a single document too.... This I-D being >> >>referenced >> >>>whereas the draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt wasn't >> >>is a >> >>>solid proof that the former I-D is useful without having to be >> >>integrated >> >>>into the latter. >>> >>> >>> >>>>>>the only other mechanism is to manually >>>>>>configure the DHCP servers in the visited link with >>>>>>information like home agent address, home address and home >>>>>>prefix. this is a bad idea. >>> >>> >>>You know that one does not have to put DHCP servers on every subnet, >> >>instead >> >>>one can rely on DHCP relays. And that's the used technique for many >>>enterprise networks. So, I don't see why this is a bad idea. >>> >>>Alper >>> >>> >>> >>> >>> >>>>Vijay >>>> >>>> >>>>>Alper >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >>>>>>Sent: Monday, June 19, 2006 6:17 PM >>>>>>To: Heejin Jang >>>>>>Cc: mip6@ietf.org; dhcwg@ietf.org >>>>>>Subject: Re: [Mip6] [Updated] DHCP Option for Home Information >> >>Discovery >> >>>>>>inMIPv6 >>>>>> >>>>>>Heejin Jang wrote: >>>>>> >>>>>> >>>>>>>Hello folks, >>>>>>>We posted an I-D that proposes new DHCP Options for Home >> >>Information >> >>>>>>>Discovery in MIPv6. >>>>>>> >>>>>>>Kindly note that the previous version of this draft is >>>>>>>"draft-jang-dhc-haopt-02.txt" but the name is slightly changed into >>>>>>>"draft-jang-mip6-hiopt-00.txt" while keeping almost the same >> >>contents. >> >>>>>>>The drafts referencing this draft such as >>>>>>>draft-ietf-mip6-bootstrapping-split-02.txt and >>>>>>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt need to be >> >>revised >> >>>>>>>accordingly. >>>>>>> >>>>>>>We would appreciate to hear your comments. >>>>>> >>>>>>when this draft was discussed in the MIP6 bootstrapping >>>>>>design team, many people wanted to integrate the two DHCP >>>>>>options into >>>>>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. >>>>>>this was mainly because the options defined in the document >>>>>>have limited applicability beyond the integrated scenario >>>>>>solution document. the only other mechanism is to manually >>>>>>configure the DHCP servers in the visited link with >>>>>>information like home agent address, home address and home >>>>>>prefix. this is a bad idea. >>>>>> >>>>>>there was some opposition and we never reached an agreement. >>>>>> >>>>>>so I suggest including these options into the integrated >>>>>>scenario solution document for these options to get >>>>>>standardized quickly. >>>>>> >>>>>>Vijay >>>>>> >>>>>>_______________________________________________ >>>>>>Mip6 mailing list >>>>>>Mip6@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/mip6 >>>>> >>>>> >>> >>> >>>_______________________________________________ >>>dhcwg mailing list >>>dhcwg@ietf.org >>>https://www1.ietf.org/mailman/listinfo/dhcwg >>> > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 18:24:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtB7b-0001iy-N3; Wed, 21 Jun 2006 18:24:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtB7a-0001im-Ja; Wed, 21 Jun 2006 18:24:26 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtB7Z-0004FP-6z; Wed, 21 Jun 2006 18:24:26 -0400 Message-ID: <03df01c69581$8c845380$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alper Yegin" , "'Gerardo Giaretta'" References: <0MKoyl-1FtAYX2m3k-0000p1@mrelay.perfora.net> Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home InformationDiscovery inMIPv6 Date: Wed, 21 Jun 2006 15:25:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: mip6@ietf.org, 'Heejin Jang' , dhcwg@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alper, > I think it helps to understand the components of the full picture. > > [a] Delivery of the info from home AAA to the NAS > [b] Delivery of the info from the NAS (DHCP relay) to the DHCP server. > [c] Delivery of the info from the DHCP server to the DHCP client > [d] Plumbing of all these components > > > [a], [b], and [c] are all protocol work. [d] is just informational. > > The document draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt covers > [b] > and [d]. > > WiMAX does not use [b]. For that there is no need to have a normative > reference to draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. It could > have an informative reference to it, but it does not have to. > I think this is a very good and clear description. Lately, I've become really interested in seeing IETF do stuff that actually gets deployed. So, given that WiMax Forum doesn't need [b], do you think they might be willing to reference this document (and thereby we could see it deployed) if [b] were deleted? jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 18:29:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtBCF-0002db-Mc; Wed, 21 Jun 2006 18:29:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtBCE-0002dW-UM for mip6@ietf.org; Wed, 21 Jun 2006 18:29:14 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtBCA-0004Ln-Hz for mip6@ietf.org; Wed, 21 Jun 2006 18:29:14 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k5LMT5EE027988; Wed, 21 Jun 2006 15:29:09 -0700 (MST) Received: from [10.129.40.246] ([10.129.40.246]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k5LMT3xR013143; Wed, 21 Jun 2006 17:29:04 -0500 (CDT) Message-ID: <4499C82E.7020303@motorola.com> Date: Thu, 22 Jun 2006 00:29:02 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Basavaraj Patil wrote: > THURSDAY, July 13, 2006 0900-1130 Morning Session I Room 518AB > > ========================================= > > 1. Agenda review, Blue sheets and volunteers for taking notes and > Jabber scribe 5 Mins > > 2. WG status and I-Ds update 10 Mins > > 3. Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) > I-D: draft-ietf-mip6-nemo-v4traversal-01.txt > > Hesham Soliman 15 Mins The DS-MIPv6 draft has 7 authors on the frontpage. That was discussed as a potential issue with a guideline that would suggest only 5 authors there. Among other, not following the suggestion has some practical consequences (AUTH48 time takes longer). I don't see why presenting this draft at IETF in its current form. Or maybe there are plans to update it for this? > 4. Mobility management for Dual stack mobile nodes: A Problem > Statement I-D: draft-ietf-mip6-dsmip-problem-02.txt > > Hesham Soliman 5 Mins AD asked for a problem statement for the MIP4-MIP6 space. However, this draft does not contain the original problem statement of draft-wakikawa-nemo-v4tunnel-01.txt (namely multiple encapsulation). Additionally, all the list discussion since last IETF around problem statement is not reflected in this draft. I don't see why presenting it. Or maybe there are plans to update it for this? It's hard to have a meaningful discussion during the WG meeting when the email discussion prior to it is not taken into account. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 19:14:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtBtm-0007BG-AL; Wed, 21 Jun 2006 19:14:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtBtl-0007B6-Jh; Wed, 21 Jun 2006 19:14:13 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtBtk-0006pF-9q; Wed, 21 Jun 2006 19:14:13 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 16:14:09 -0700 Message-ID: <4499D24F.9030603@azairenet.com> Date: Wed, 21 Jun 2006 16:12:15 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home InformationDiscovery inMIPv6 References: <0MKoyl-1FtAYX2m3k-0000p1@mrelay.perfora.net> <03df01c69581$8c845380$026115ac@dcml.docomolabsusa.com> In-Reply-To: <03df01c69581$8c845380$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 23:14:09.0327 (UTC) FILETIME=[666EDBF0:01C69588] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mip6@ietf.org, 'Heejin Jang' , dhcwg@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org James Kempf wrote: > Hi Alper, > >> I think it helps to understand the components of the full picture. >> >> [a] Delivery of the info from home AAA to the NAS >> [b] Delivery of the info from the NAS (DHCP relay) to the DHCP server. >> [c] Delivery of the info from the DHCP server to the DHCP client >> [d] Plumbing of all these components >> >> >> [a], [b], and [c] are all protocol work. [d] is just informational. >> >> The document draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt >> covers [b] >> and [d]. >> >> WiMAX does not use [b]. For that there is no need to have a normative >> reference to draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. It >> could >> have an informative reference to it, but it does not have to. >> > > I think this is a very good and clear description. > > Lately, I've become really interested in seeing IETF do stuff that > actually gets deployed. this is hard. IETF does not move fast enough when somebody sees a problem in a particular deployment. we are better off designing good solutions. ;) So, given that WiMax Forum doesn't need [b], do > you think they might be willing to reference this document (and thereby > we could see it deployed) if [b] were deleted? draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt specifies [b] because someone brought up an issue of the NAS and the DHCP server being not on the same box. [b] is not used if the NAS and the DHCP server are on the same box. it would be good to know if in WiMAX the NAS and the DHCP server are on the same box? Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 19:17:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtBwd-0007dG-Bf; Wed, 21 Jun 2006 19:17:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtBwc-0007dA-3g for mip6@ietf.org; Wed, 21 Jun 2006 19:17:10 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtBwa-0006tJ-Mc for mip6@ietf.org; Wed, 21 Jun 2006 19:17:10 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 16:17:07 -0700 Message-ID: <4499D301.1080502@azairenet.com> Date: Wed, 21 Jun 2006 16:15:13 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 References: <4499C82E.7020303@motorola.com> In-Reply-To: <4499C82E.7020303@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 23:17:07.0656 (UTC) FILETIME=[D0B9B480:01C69588] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > Basavaraj Patil wrote: > >> THURSDAY, July 13, 2006 0900-1130 Morning Session I Room 518AB >> >> ========================================= >> >> 1. Agenda review, Blue sheets and volunteers for taking notes and >> Jabber scribe 5 Mins >> >> 2. WG status and I-Ds update 10 Mins >> >> 3. Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) I-D: >> draft-ietf-mip6-nemo-v4traversal-01.txt >> >> Hesham Soliman 15 Mins > > > The DS-MIPv6 draft has 7 authors on the frontpage. That was discussed > as a potential issue with a guideline that would suggest only 5 authors > there. its only a guideline. if all the people did contribute, I see nothing wrong in including all of them. I mentioned this during NETLMM problem statement discussion too. Among other, not following the suggestion has some practical > consequences (AUTH48 time takes longer). > > I don't see why presenting this draft at IETF in its current form. Or > maybe there are plans to update it for this? in general a draft should never be "presented". meeting time is for resolving issues. Vijay >> 4. Mobility management for Dual stack mobile nodes: A Problem >> Statement I-D: draft-ietf-mip6-dsmip-problem-02.txt >> >> Hesham Soliman 5 Mins > > > AD asked for a problem statement for the MIP4-MIP6 space. > > However, this draft does not contain the original problem statement of > draft-wakikawa-nemo-v4tunnel-01.txt (namely multiple encapsulation). > Additionally, all the list discussion since last IETF around problem > statement is not reflected in this draft. > > I don't see why presenting it. Or maybe there are plans to update it > for this? > > It's hard to have a meaningful discussion during the WG meeting when the > email discussion prior to it is not taken into account. > > Alex > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 20:04:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCgF-0006bb-67; Wed, 21 Jun 2006 20:04:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCgD-0006bM-4R for mip6@ietf.org; Wed, 21 Jun 2006 20:04:17 -0400 Received: from web60320.mail.yahoo.com ([209.73.178.128]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FtCgC-0000vr-Gv for mip6@ietf.org; Wed, 21 Jun 2006 20:04:17 -0400 Received: (qmail 13982 invoked by uid 60001); 22 Jun 2006 00:04:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=L/fPfQRTyd3Lq17ss1ExFtFO+IYpCizpsq0HodvteFEjGLoV5KNNPkgut5+lstrwiljGG6hw//oYPqPU7P4cznN6cHhwBd9Fj5poL+cNgILPm+j/ArQJcVQxrcE2SNO8hF1eh15mjYrQxKbj4bB11ZE2lmd2/5KKtl0A0p6QszM= ; Message-ID: <20060622000416.13980.qmail@web60320.mail.yahoo.com> Received: from [12.129.211.52] by web60320.mail.yahoo.com via HTTP; Wed, 21 Jun 2006 17:04:16 PDT Date: Wed, 21 Jun 2006 17:04:16 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 To: Alper Yegin , Gerardo Giaretta In-Reply-To: <0MKoyl-1FtAYX2m3k-0000p1@mrelay.perfora.net> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: mip6@ietf.org, Heejin Jang , dhcwg@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1756776807==" Errors-To: mip6-bounces@ietf.org --===============1756776807== Content-Type: multipart/alternative; boundary="0-1280103246-1150934656=:12329" --0-1280103246-1150934656=:12329 Content-Type: text/plain; charset=us-ascii Hi Vijay, The idea in the present WiMAX document is quite simple: it uses EAP-PKMv2 (which is like 802.11i) authentication and during EAP transaction, they assume that AAA server determines that the MS is a CMIPv6 authorized user based on the AAA profile and it will include all the so-called bootstrapping info in the Access-Accept. Then MS can use RFC 3736 to make a DHCP Information Request to DHCP Relay colocated with NAS and use draft-jang (extended now with HoA) and receive all the info to configure MIP6. No DHCP server is involved. In this setup can you make a case for draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt? Regards, --behcet ----- Original Message ---- From: Alper Yegin To: Gerardo Giaretta Cc: mip6@ietf.org; dhcwg@ietf.org; Heejin Jang Sent: Wednesday, June 21, 2006 4:48:10 PM Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 Gerardo, I think it helps to understand the components of the full picture. [a] Delivery of the info from home AAA to the NAS [b] Delivery of the info from the NAS (DHCP relay) to the DHCP server. [c] Delivery of the info from the DHCP server to the DHCP client [d] Plumbing of all these components [a], [b], and [c] are all protocol work. [d] is just informational. The document draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt covers [b] and [d]. WiMAX does not use [b]. For that there is no need to have a normative reference to draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. It could have an informative reference to it, but it does not have to. Alper > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Wednesday, June 21, 2006 1:18 AM > To: Alper Yegin > Cc: Vijay Devarapalli; mip6@ietf.org; Heejin Jang; dhcwg@ietf.org > Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home Information > Discovery inMIPv6 > > Alper, > > just one question below in order to understand if there is a real > technical reason to keep the docs separated.. > > > > > But I hope this data point helps: WiMAX Forum NWG architecture is > using > > > > draft-jang. > > > > > > in what context and how are they planning to use it? > > > > The MIP info is brought to the DHCP server via RADIUS and delivered to > the > > MN via DHCP. > > > > Can you please explain which are the technical differences between the > solution in the DT draft for integrated scenario and the solution > developped in WiMAX? > > I guess in WiMAX MIP info are brought to DHCP relay (i.e. NAS) and > then draft-jang is applied. Is this really different from what is > described in the DT draft? > > --Gerardo > > > > the > > > WiMAX forum NWG can still use the DHCP options wherever > > > they are defined. > > > > Yes. And WiMAX Forum could also use it even if IETF had concatenated all > of > > the RFCs and I-Ds under a single document too.... This I-D being > referenced > > whereas the draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt wasn't > is a > > solid proof that the former I-D is useful without having to be > integrated > > into the latter. > > > > > > > >>the only other mechanism is to manually > > > >>configure the DHCP servers in the visited link with > > > >>information like home agent address, home address and home > > > >>prefix. this is a bad idea. > > > > > > You know that one does not have to put DHCP servers on every subnet, > instead > > one can rely on DHCP relays. And that's the used technique for many > > enterprise networks. So, I don't see why this is a bad idea. > > > > Alper > > > > > > > > > > > > > > Vijay > > > > > > > > > > > Alper > > > > > > > > > > > > > > > >>-----Original Message----- > > > >>From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > > >>Sent: Monday, June 19, 2006 6:17 PM > > > >>To: Heejin Jang > > > >>Cc: mip6@ietf.org; dhcwg@ietf.org > > > >>Subject: Re: [Mip6] [Updated] DHCP Option for Home Information > Discovery > > > >>inMIPv6 > > > >> > > > >>Heejin Jang wrote: > > > >> > > > >>>Hello folks, > > > >>>We posted an I-D that proposes new DHCP Options for Home > Information > > > >>>Discovery in MIPv6. > > > >>> > > > >>>Kindly note that the previous version of this draft is > > > >>>"draft-jang-dhc-haopt-02.txt" but the name is slightly changed into > > > >>>"draft-jang-mip6-hiopt-00.txt" while keeping almost the same > contents. > > > >>> > > > >>>The drafts referencing this draft such as > > > >>>draft-ietf-mip6-bootstrapping-split-02.txt and > > > >>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt need to be > revised > > > >>>accordingly. > > > >>> > > > >>>We would appreciate to hear your comments. > > > >> > > > >>when this draft was discussed in the MIP6 bootstrapping > > > >>design team, many people wanted to integrate the two DHCP > > > >>options into > > > >>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. > > > >>this was mainly because the options defined in the document > > > >>have limited applicability beyond the integrated scenario > > > >>solution document. the only other mechanism is to manually > > > >>configure the DHCP servers in the visited link with > > > >>information like home agent address, home address and home > > > >>prefix. this is a bad idea. > > > >> > > > >>there was some opposition and we never reached an agreement. > > > >> > > > >>so I suggest including these options into the integrated > > > >>scenario solution document for these options to get > > > >>standardized quickly. > > > >> > > > >>Vijay > > > >> > > > >>_______________________________________________ > > > >>Mip6 mailing list > > > >>Mip6@ietf.org > > > >>https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --0-1280103246-1150934656=:12329 Content-Type: text/html; charset=us-ascii
Hi Vijay,
The idea in the present WiMAX document is quite simple:
it uses EAP-PKMv2 (which is like 802.11i) authentication and during EAP transaction, they assume that AAA server determines that the MS is a CMIPv6 authorized user based on the AAA profile and it will include all the so-called bootstrapping info in the Access-Accept. Then MS can  use RFC 3736 to make a DHCP Information Request to DHCP Relay colocated with NAS and use draft-jang (extended now with HoA) and receive all the info to configure MIP6.  No DHCP server is involved.
  In this setup can you make a case for draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt?

Regards,

--behcet

----- Original Message ----
From: Alper Yegin <alper.yegin@yegin.org>
To: Gerardo Giaretta <gerardo.giaretta@gmail.com>
Cc: mip6@ietf.org; dhcwg@ietf.org; Heejin Jang <heejin.jang@samsung.com>
Sent: Wednesday, June 21, 2006 4:48:10 PM
Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6

Gerardo,

I think it helps to understand the components of the full picture.

[a] Delivery of the info from home AAA to the NAS
[b] Delivery of the info from the NAS (DHCP relay) to the DHCP server.
[c] Delivery of the info from the DHCP server to the DHCP client
[d] Plumbing of all these components


[a], [b], and [c] are all protocol work. [d] is just informational.

The document draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt covers [b]
and [d].

WiMAX does not use [b]. For that there is no need to have a normative
reference to draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. It could
have an informative reference to it, but it does not have to.

Alper






> -----Original Message-----
> From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]
> Sent: Wednesday, June 21, 2006 1:18 AM
> To: Alper Yegin
> Cc: Vijay Devarapalli; mip6@ietf.org; Heejin Jang; dhcwg@ietf.org
> Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home Information
> Discovery inMIPv6
>
> Alper,
>
> just one question below in order to understand if there is a real
> technical reason to keep the docs separated..
>
> > > > But I hope this data point helps: WiMAX Forum NWG architecture is
> using
> > > > draft-jang.
> > >
> > > in what context and how are they planning to use it?
> >
> > The MIP info is brought to the DHCP server via RADIUS and delivered to
> the
> > MN via DHCP.
> >
>
> Can you please explain which are the technical differences between the
> solution in the DT draft for integrated scenario and the solution
> developped in WiMAX?
>
> I guess in WiMAX MIP info are brought to DHCP relay (i.e. NAS) and
> then draft-jang is applied. Is this really different from what is
> described in the DT draft?
>
> --Gerardo
>
> > > the
> > > WiMAX forum NWG can still use the DHCP options wherever
> > > they are defined.
> >
> > Yes. And WiMAX Forum could also use it even if IETF had concatenated all
> of
> > the RFCs and I-Ds under a single document too.... This I-D being
> referenced
> > whereas the draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt wasn't
> is a
> > solid proof that the former I-D is useful without having to be
> integrated
> > into the latter.
> >
> >
> > > >>the only other mechanism is to manually
> > > >>configure the DHCP servers in the visited link with
> > > >>information like home agent address, home address and home
> > > >>prefix. this is a bad idea.
> >
> >
> > You know that one does not have to put DHCP servers on every subnet,
> instead
> > one can rely on DHCP relays. And that's the used technique for many
> > enterprise networks. So, I don't see why this is a bad idea.
> >
> > Alper
> >
> >
> >
> >
> > >
> > > Vijay
> > >
> > > >
> > > > Alper
> > > >
> > > >
> > > >
> > > >>-----Original Message-----
> > > >>From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]
> > > >>Sent: Monday, June 19, 2006 6:17 PM
> > > >>To: Heejin Jang
> > > >>Cc: mip6@ietf.org; dhcwg@ietf.org
> > > >>Subject: Re: [Mip6] [Updated] DHCP Option for Home Information
> Discovery
> > > >>inMIPv6
> > > >>
> > > >>Heejin Jang wrote:
> > > >>
> > > >>>Hello folks,
> > > >>>We posted an I-D that proposes new DHCP Options for Home
> Information
> > > >>>Discovery in MIPv6.
> > > >>>
> > > >>>Kindly note that the previous version of this draft is
> > > >>>"draft-jang-dhc-haopt-02.txt" but the name is slightly changed into
> > > >>>"draft-jang-mip6-hiopt-00.txt" while keeping almost the same
> contents.
> > > >>>
> > > >>>The drafts referencing this draft such as
> > > >>>draft-ietf-mip6-bootstrapping-split-02.txt and
> > > >>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt need to be
> revised
> > > >>>accordingly.
> > > >>>
> > > >>>We would appreciate to hear your comments.
> > > >>
> > > >>when this draft was discussed in the MIP6 bootstrapping
> > > >>design team, many people wanted to integrate the two DHCP
> > > >>options into
> > > >>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt.
> > > >>this was mainly because the options defined in the document
> > > >>have limited applicability beyond the integrated scenario
> > > >>solution document. the only other mechanism is to manually
> > > >>configure the DHCP servers in the visited link with
> > > >>information like home agent address, home address and home
> > > >>prefix. this is a bad idea.
> > > >>
> > > >>there was some opposition and we never reached an agreement.
> > > >>
> > > >>so I suggest including these options into the integrated
> > > >>scenario solution document for these options to get
> > > >>standardized quickly.
> > > >>
> > > >>Vijay
> > > >>
> > > >>_______________________________________________
> > > >>Mip6 mailing list
> > > >>Mip6@ietf.org
> > > >>https://www1.ietf.org/mailman/listinfo/mip6
> > > >
> > > >
> >
> >
> >
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> >


_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6

--0-1280103246-1150934656=:12329-- --===============1756776807== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1756776807==-- From mip6-bounces@ietf.org Wed Jun 21 20:22:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCxE-00055s-Ff; Wed, 21 Jun 2006 20:21:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCxC-00055b-6a for mip6@ietf.org; Wed, 21 Jun 2006 20:21:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft9Sv-0001WX-EZ for mip6@ietf.org; Wed, 21 Jun 2006 16:38:21 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ft9OP-0004cs-G5 for mip6@ietf.org; Wed, 21 Jun 2006 16:33:43 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LKXetL019582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 13:33:40 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LKXMpx002287; Wed, 21 Jun 2006 13:33:39 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 13:33:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Date: Wed, 21 Jun 2006 13:33:26 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FAE0@NAEX14.na.qualcomm.com> In-Reply-To: <4499AA6A.90801@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Thread-Index: AcaVcG6Fk4CEN9XjRECrEQQHLtMmgAAAGeFA From: "Tsirtsis, George" To: "Alexandru Petrescu" X-OriginalArrivalTime: 21 Jun 2006 20:33:28.0343 (UTC) FILETIME=[F3F57270:01C69571] X-Spam-Score: -2.3 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mip6@ietf.org, "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Wednesday, June 21, 2006 4:22 PM > To: Tsirtsis, George > Cc: Soliman, Hesham; mip6@ietf.org > Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for > IPv4(mip4) >=20 > Tsirtsis, George wrote: > > The IPv4 address allocation part of DS-MIPv6 solution has the same > > limitations an IPv4 deployment has. The operator may not have enough > > public IPv4 addresses for everyone so it might use private IPv4 (and > > NATs) instead.[...] Why would that [not] be the case in DS-MIPv6?? >=20 > An operator using NATs to offer IPv4 home addresses do so without > offering reachability at that permanent IPv4 home address. Would > DS-MIPv6 allow this? >=20 Sure it does. > I really think we should come back to original requirements and goals > here... The problem is simple: offer session continuity and > reachability at permanent IPv4 and IPv6 addresses. >=20 I do not think that "permanent" IPv4 addresses is a goal. If we could give permanent IPv4 addresses we would not have to spend 10 years on IPv6. All we need is to allow DS nodes to be able to communicate with the IPv4 internet while they are moving around. The IPv6 part of the stack offers the permanent address the end node needs. > > I do not see IPv4 operators today not being able to expand their > > networks because of this. >=20 > Even if an operator uses the entire class A (24bits), and the class B > (20bits), and the class C (16bits) allocated by IANA for private IPv4 > addresses, their number does not amount to what IPv6 80bits has to > offer. The private IPv4 address space is defined in rfc1918. The IPv6 > address space is in rfc3513. >=20 The Internet today has done fine with this space and I have yet to find a company that is running out of private address space to use. BTW, IPv6 does not offer 80bits to anyone since most allocations are supposed to be /64 or larger. > Alex >=20 >=20 >=20 > > > >> -----Original Message----- From: Soliman, Hesham > >> [mailto:hsoliman@qualcomm.com] Sent: Wednesday, June 21, 2006 10:41 > >> AM To: Alexandru Petrescu Cc: mip6@ietf.org Subject: RE: [Mip6] > >> FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) > >> > >> > >>>>>> =3D> Huh? what do you mean by "scale"? > >>>>> > >>>>> I mean an IPv6-only network is very large. If only its > >>>>> borders support IPv4 and IPv6 then all routers inside can't > >>>>> be HAs whose nodes attach to IPv4-only networks. > >>>> > >>>> =3D> Please tell me exactly what the scalability concerns > >>> are. I can't > >>>> follow the above. > >>> > >>> With DS-MIPv6, the size of the operator's IPv6 infra can not grow > >>> larger ("scale") than what the IPv4 protocol allows. Does that > >>> makes > > sense? > >> =3D> No it doesn't. DSMIPv6 does NOT limit the operator from > >> deploying IPv6 only. The desire to do that is completely orthogonal > >> to DSMIPv6. If you want to deploy IPv6 only without regard to IPv4 > >> CNs then you would only use MIPv6, or you might use NAT-PT, but > >> that's not the IETF's recommendation. DSMIPv6 is designed for > >> roaming to IPv4 networks with MIPv6, or for using an IPv4 HoA with > >> MIPv6. > >> > >> Hesham > >> > >> _______________________________________________ Mip6 mailing list > >> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 21:04:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDce-0004sO-Lq; Wed, 21 Jun 2006 21:04:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtDcc-0004sJ-Uf for mip6@ietf.org; Wed, 21 Jun 2006 21:04:38 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtDcb-0004uh-6w for mip6@ietf.org; Wed, 21 Jun 2006 21:04:38 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J18009ZLMCXPD@szxga02-in.huawei.com> for mip6@ietf.org; Thu, 22 Jun 2006 09:19:45 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1800LQAMCWW5@szxga02-in.huawei.com> for mip6@ietf.org; Thu, 22 Jun 2006 09:19:45 +0800 (CST) Received: from y52774 ([10.164.44.201]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J18006WDM41MM@szxml04-in.huawei.com> for mip6@ietf.org; Thu, 22 Jun 2006 09:14:29 +0800 (CST) Date: Thu, 22 Jun 2006 09:03:41 +0800 From: Michael Ye Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) In-reply-to: <44995882.1050609@motorola.com> To: 'Alexandru Petrescu' , "'Tsirtsis, George'" Message-id: <000b01c69597$b3c880e0$c92ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcaVQjjNzz1GK9fPREqB7u4HRaA3mQAVEtJw X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mip6@ietf.org, "'Soliman, Hesham'" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] Sent: Wednesday, June 21, 2006 10:33 PM To: Tsirtsis, George Cc: mip6@ietf.org; Soliman, Hesham Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Tsirtsis, George wrote: > There is no complaint. I am simply pointing out that if you use HAs > and a Gateway (of whatever form) you have to discover, manage and > secure two entities instead of one. Ok, just to say that DS-MIPv6 also has to discover its HAs, currently DS-MIPv6 MN can't discover its HA. ==>Yes,DS-MIPv6 MN must discover its HA when it moves into the heterogeneous network even in same network. ==>So maintaining its connectivity must base on the HA (or HoA). Alex Michael _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 21:29:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtE0Y-0006Rj-Pd; Wed, 21 Jun 2006 21:29:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtE0X-0006RY-1v for mip6@ietf.org; Wed, 21 Jun 2006 21:29:21 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtE0V-0006Gj-Lg for mip6@ietf.org; Wed, 21 Jun 2006 21:29:21 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5M1THFL014926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 21 Jun 2006 18:29:18 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5M1TGsD012617 for ; Wed, 21 Jun 2006 18:29:17 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 18:29:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) Date: Wed, 21 Jun 2006 18:29:13 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FB4E@NAEX14.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) Thread-Index: AcaQ0ZbY1YH1fvzEEdqHQQARJNUNiAC3UJ9AAD69t1cALi3UkAAOHX2Q From: "Soliman, Hesham" To: X-OriginalArrivalTime: 22 Jun 2006 01:29:15.0902 (UTC) FILETIME=[465409E0:01C6959B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > I guess it is more an implementation issue now. As Soliman=20 > pointed out, > if dual stacks are taken care of separately (specially do-able in > controlled carrier environment), the DSMIP won't be necessarily > applicable =3D> I guess you're referring to something I said? I don't recall saying anything similar to your understanding above. I think this is a miunderstanding Hesham >=20 > Qiang >=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com]=20 > Sent: Tuesday, June 20, 2006 4:41 PM > To: ext jouni.korhonen@teliasonera.com; Levkowetz; > kempf@docomolabs-usa.com > Cc: Jari Arkko; mccap@lucent.com; mip6@ietf.org > Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility > forIPv4(mip4) >=20 >=20 > Hi Jouni, >=20 > Inline: >=20 > On 6/20/06 7:45 AM, "ext jouni.korhonen@teliasonera.com" > wrote: >=20 > > Hi Raj, > >=20 > >> Henrik, > >>=20 > >> In the DS-MIP6 case the reasoning for the work has been that > >> IPv6 native > >> access is not expected to be ubiquitous and hence given that > >> the host is DS > >> and access is IPv4, there is a need to enable MIP6 continuity > >> while being > >> attached to a v4 network. The ability to carry IPv4 within > >> the MIP6 session > >> is to enable applications and services that are v4 based on > >> the hosts and is > >> applicable in the scenario when the host is connected to a > >> native v6 access > >> only (which I guess we believe will be the situation at some > >> point in the > >> future). So I believe there is a good reason to do this for MIP6. > >=20 > > Don't we have this situation in a way already? If I=20 > remember correctly > > e.g. in 2G/3G a DS terminal can open either an IPv4 or IPv6 PDP > context. > > So if you want IPv6 over your cellular you are stuck in IPv6 only > > access for that context. Of course then it is up to the terminal > > and/or GGSN implementations whether they allow multiple primary > > contexts of different IP version (and possibly to the same APN), > > which might not always be the case.. >=20 > Current terminals can have multiple PDP contexts for sure. I=20 > am not sure > if > a terminal can establish an IPv4/v6 PDP context to the same=20 > APN. I don't > know if this works or if this is not allowed for some=20 > reason. But it is > a > limitation if an APN does not allow multiple IP version PDP=20 > contexts for > the > same host... And in such a case, I agree that if you have an IPvX PDP > context, you would want to carry the other IP version over that. >=20 > However in the context of GPRS, I think that would be a suboptimal > solution. > Rather I would think that having the APN support multiple=20 > PDP contexts > for > the same host with different IP versions would a cleaner solution. >=20 > -Raj >=20 > >=20 > > Jouni > >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 21:46:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtEGl-0004Mo-M2; Wed, 21 Jun 2006 21:46:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtEGj-0004Ej-UA for mip6@ietf.org; Wed, 21 Jun 2006 21:46:05 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtEGi-0007gD-Gm for mip6@ietf.org; Wed, 21 Jun 2006 21:46:05 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5M1k3Tv016018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 18:46:03 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5M1k0P3013548; Wed, 21 Jun 2006 18:46:02 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 18:46:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 Date: Wed, 21 Jun 2006 18:45:58 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FB50@NAEX14.na.qualcomm.com> In-Reply-To: <4499C82E.7020303@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 Thread-Index: AcaVhJs0lUbIFB6eSLaYMHF22+c5uwAFv6og From: "Soliman, Hesham" To: "Alexandru Petrescu" , "Basavaraj Patil" X-OriginalArrivalTime: 22 Jun 2006 01:46:00.0392 (UTC) FILETIME=[9D0D0C80:01C6959D] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > The DS-MIPv6 draft has 7 authors on the frontpage. That was=20 > discussed > as a potential issue with a guideline that would suggest=20 > only 5 authors > there. Among other, not following the suggestion has some practical > consequences (AUTH48 time takes longer). =3D> What does this have to do with the agenda???=20 >=20 > I don't see why presenting this draft at IETF in its current=20 > form. Or > maybe there are plans to update it for this? =3D> We may or may not. This has nothing to do with the technical discussion in the draft. >=20 > > 4. Mobility management for Dual stack mobile nodes: A Problem=20 > > Statement I-D: draft-ietf-mip6-dsmip-problem-02.txt > >=20 > > Hesham Soliman 5 Mins >=20 > AD asked for a problem statement for the MIP4-MIP6 space. >=20 > However, this draft does not contain the original problem=20 > statement of > draft-wakikawa-nemo-v4tunnel-01.txt (namely multiple encapsulation). > Additionally, all the list discussion since last IETF around problem > statement is not reflected in this draft. =3D> Please be specific. What comments were made on this draft and not included? >=20 > I don't see why presenting it. Or maybe there are plans to update it > for this? >=20 > It's hard to have a meaningful discussion during the WG=20 > meeting when the > email discussion prior to it is not taken into account. =3D> Informed comments about the technical content of drafts the email discussion will be easily reflected in the drafts. Comments about the number of authors and confusion about what the solution does or does not do is generally hard to reflect in the technical content of the draft. Without being specific about what was apparently "ignored" (according to your comment above), I really can't do anything to address your comment. Of course not every comment made will be reflected in the draft because it might be wrong or unsuitable. But, in any case, I haven't seen any comments from you on the problem statement that were simply "ignored"!=20 Also FYI, this is not a "presentation" of a draft, this is to discuss the state of this draft after it was updated by comments from Pekka S, Jari and others.=20 Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 22:39:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtF5w-0002SW-0Q; Wed, 21 Jun 2006 22:39:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtF5u-0002SM-Eg for mip6@ietf.org; Wed, 21 Jun 2006 22:38:58 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtF5s-0003sI-UV for mip6@ietf.org; Wed, 21 Jun 2006 22:38:58 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J18002CZQGXEK@szxga02-in.huawei.com> for mip6@ietf.org; Thu, 22 Jun 2006 10:48:33 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1800KJSQGX6V@szxga02-in.huawei.com> for mip6@ietf.org; Thu, 22 Jun 2006 10:48:33 +0800 (CST) Received: from w50392 ([10.164.45.90]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J18006OMQ85H9@szxml04-in.huawei.com> for mip6@ietf.org; Thu, 22 Jun 2006 10:43:18 +0800 (CST) Date: Thu, 22 Jun 2006 10:32:31 +0800 From: Tom Wan Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) To: "Soliman, Hesham" , mip6@ietf.org Message-id: <015b01c695a4$1cd87200$6e2ea40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <7EB20EA0938B4D42A2D82689365C9B7A04FB4E@NAEX14.na.qualcomm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, Soliman: I think we should not consider a solution currently. We must answer this question firstly: should home network support both ipv4 and ipv6 protocol? I think there are three categories of scenarios: home network supports ipv4 only home network supports ipv6 only home network supports both ipv4 and ipv6. I think they all possible scenarios.The reason is that ietf should not require the operator that all their HAs must support both ipv4 and ipv6.It is up to the operators. DSmip requries that home network must support both ipv4 and ipv6. surely,It can solve problems in scenario 3. But how about the other two scenarios? I think we should consider all possible scenarios firstly before we consider a unified solution. These scenarios are mentioned in my draft, would you mind discussing these scenarios with me?Thanks. BR Tom _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 23:08:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFYQ-0002A4-TQ; Wed, 21 Jun 2006 23:08:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFYP-00029r-Hq; Wed, 21 Jun 2006 23:08:25 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtFYO-0006Ax-7E; Wed, 21 Jun 2006 23:08:25 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 867B990021; Wed, 21 Jun 2006 23:08:20 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31838-02; Wed, 21 Jun 2006 23:08:19 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP; Wed, 21 Jun 2006 23:08:19 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Jun 2006 23:05:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option forHome InformationDiscovery inMIPv6 Date: Wed, 21 Jun 2006 23:05:21 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D73C51C2@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] RE: [Mip6] [Updated] DHCP Option forHome InformationDiscovery inMIPv6 Thread-Index: AcaVinZ57ztYBVdZTviFjaaYYyn1KAAHkwmg From: "Chowdhury, Kuntal" To: "Vijay Devarapalli" , "James Kempf" X-OriginalArrivalTime: 22 Jun 2006 03:05:21.0366 (UTC) FILETIME=[B2D00760:01C695A8] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: mip6@ietf.org, Heejin Jang , dhcwg@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, In WiMAX...the NAS and the DHCP-proxy are collocated. Hence [b] is not necessary in WiMAX. -Kuntal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Wednesday, June 21, 2006 6:12 PM > To: James Kempf > Cc: mip6@ietf.org; 'Heejin Jang'; dhcwg@ietf.org > Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option forHome > InformationDiscovery inMIPv6 >=20 > James Kempf wrote: > > Hi Alper, > > > >> I think it helps to understand the components of the full picture. > >> > >> [a] Delivery of the info from home AAA to the NAS > >> [b] Delivery of the info from the NAS (DHCP relay) to the DHCP server. > >> [c] Delivery of the info from the DHCP server to the DHCP client > >> [d] Plumbing of all these components > >> > >> > >> [a], [b], and [c] are all protocol work. [d] is just informational. > >> > >> The document draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt > >> covers [b] > >> and [d]. > >> > >> WiMAX does not use [b]. For that there is no need to have a normative > >> reference to draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. It > >> could > >> have an informative reference to it, but it does not have to. > >> > > > > I think this is a very good and clear description. > > > > Lately, I've become really interested in seeing IETF do stuff that > > actually gets deployed. >=20 > this is hard. IETF does not move fast enough when somebody > sees a problem in a particular deployment. we are better off > designing good solutions. ;) >=20 > So, given that WiMax Forum doesn't need [b], do > > you think they might be willing to reference this document (and thereby > > we could see it deployed) if [b] were deleted? >=20 > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt specifies > [b] because someone brought up an issue of the NAS and the > DHCP server being not on the same box. [b] is not used if > the NAS and the DHCP server are on the same box. it would be > good to know if in WiMAX the NAS and the DHCP server are on > the same box? >=20 > Vijay >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 23:19:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFj5-0007a8-5R; Wed, 21 Jun 2006 23:19:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFj4-0007a0-HN for mip6@ietf.org; Wed, 21 Jun 2006 23:19:26 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtFj2-0008KG-JY for mip6@ietf.org; Wed, 21 Jun 2006 23:19:26 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J180047RRXRXS@szxga01-in.huawei.com> for mip6@ietf.org; Thu, 22 Jun 2006 11:20:16 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J18006S2RXR70@szxga01-in.huawei.com> for mip6@ietf.org; Thu, 22 Jun 2006 11:20:15 +0800 (CST) Received: from y52774 ([10.164.44.201]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J180065NSCTMM@szxml04-in.huawei.com> for mip6@ietf.org; Thu, 22 Jun 2006 11:29:20 +0800 (CST) Date: Thu, 22 Jun 2006 11:18:31 +0800 From: Michael Ye Subject: RE: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) In-reply-to: <015b01c695a4$1cd87200$6e2ea40a@china.huawei.com> To: 'Tom Wan' , "'Soliman, Hesham'" , mip6@ietf.org Message-id: <002101c695aa$89c759c0$c92ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcaVp4bI9azmVF63QPCsnMNW2R96wQAAL4xA X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi All, Yes, I must consider all possible scenarios before making a solution. If there are unclear in possible scenarios,we should come back the previous discussions for solveing the problems. BR, Michael -----Original Message----- From: Tom Wan [mailto:wanchangsheng@huawei.com] Sent: Thursday, June 22, 2006 10:33 AM To: Soliman, Hesham; mip6@ietf.org Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) Hi, Soliman: I think we should not consider a solution currently. We must answer this question firstly: should home network support both ipv4 and ipv6 protocol? I think there are three categories of scenarios: home network supports ipv4 only home network supports ipv6 only home network supports both ipv4 and ipv6. I think they all possible scenarios.The reason is that ietf should not require the operator that all their HAs must support both ipv4 and ipv6.It is up to the operators. DSmip requries that home network must support both ipv4 and ipv6. surely,It can solve problems in scenario 3. But how about the other two scenarios? I think we should consider all possible scenarios firstly before we consider a unified solution. These scenarios are mentioned in my draft, would you mind discussing these scenarios with me?Thanks. BR Tom _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 21 23:58:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtGL8-0005fK-R5; Wed, 21 Jun 2006 23:58:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtGL7-0005fF-01 for mip6@ietf.org; Wed, 21 Jun 2006 23:58:45 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtGL5-0006E7-KU for mip6@ietf.org; Wed, 21 Jun 2006 23:58:44 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5M3we8C029631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 20:58:40 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5M3vqao009503; Wed, 21 Jun 2006 20:58:37 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 20:58:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Date: Wed, 21 Jun 2006 20:58:10 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FB59@NAEX14.na.qualcomm.com> In-Reply-To: <4499B9D0.2090504@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Thread-Index: AcaVeZVAj5YxDBL5SjS1WZ/LhziEdgANeQUQ From: "Soliman, Hesham" To: "Alexandru Petrescu" , "Tsirtsis, George" X-OriginalArrivalTime: 22 Jun 2006 03:58:13.0266 (UTC) FILETIME=[15698F20:01C695B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Tsirtsis, George wrote: > >> An operator using NATs to offer IPv4 home addresses do so without=20 > >> offering reachability at that permanent IPv4 home address. Would=20 > >> DS-MIPv6 allow this? > >>=20 > >=20 > > Sure it does. >=20 > Ok, so DS-MIPv6 does not have as a goal to offer reachable IPv4 Home > Addresses for Mobile Nodes. =3D> You can't conclude that from the response above. DSMIP does allow a MN to have an IPv4 HoA but it's not mandatory. So if you want to use IPv6-only HoAs then you can use DSMIPv6 to roam in IPv4 networks. If you want to use IPv6 and IPv4 HoAs you can use DSMIPv6 for both IPv4 HoA and CoA. I really can't explain this any more than that. > >=20 > > I do not think that "permanent" IPv4 addresses is a goal. >=20 > Good to know DS-MIPv6 does not try to offer reachable IPv4=20 > home addresses. =3D> Somehow you replaced "permanent" with "reachable". DSMIPv6 allows a MN to have an IPv4 address (private or public is irrelevant to DSMIPv6). Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 00:39:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtGyt-0003M3-0G; Thu, 22 Jun 2006 00:39:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtGyr-0003Lr-Sc for mip6@ietf.org; Thu, 22 Jun 2006 00:39:49 -0400 Received: from otm-mgo00.iij.ad.jp ([210.138.20.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtGyp-0005Ln-91 for mip6@ietf.org; Thu, 22 Jun 2006 00:39:49 -0400 Received: OTM-MO(otm-mgo00) id k5M4dgDw083890; Thu, 22 Jun 2006 13:39:42 +0900 (JST) Received: OTM-MIX(otm-mix01) id k5M4dgm1091383; Thu, 22 Jun 2006 13:39:42 +0900 (JST) Received: from [192.168.64.81] (n064-h081-dhcp.osaka.iij.ad.jp [192.168.64.81]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp) id k5M4dfXl003473 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 22 Jun 2006 13:39:42 +0900 (JST) In-Reply-To: <4499C19F.3050707@azairenet.com> References: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> <4498363E.4050702@azairenet.com> <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> <4499C19F.3050707@azairenet.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <69816405-8861-4B68-B9DA-6E133DFB4E73@iijlab.net> Content-Transfer-Encoding: 7bit From: Keiichi SHIMA Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction Date: Thu, 22 Jun 2006 13:39:44 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, On 2006/06/22, at 7:01, Vijay Devarapalli wrote: > Shinta Sugimoto wrote: > >>>>>>> The problem here is how does the MN know to "let the >>>>>>> existing sessions continue with the existing HoA"? If there >>>>>>> is no CN's >>>>>>> address in BUL, surely the MN can choose a suitable HoA. For >>>>>>> a CN with which it has a binding, it has no reliable way of >>>>>>> knowing >>>>>>> whether there are any ULP sessions. >>>>>> >>>>>> If you need to maintain the sessions while changing the HoA >>>>> >>>>>> from one to another, I think you need additional mechanism >>>>> >>>>>> than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed >>>>>> to assure the reachability to a given HoA with the current >>>>>> location of the mobile node (CoA). If the app wants >>>>>> to change HoAs for some reason (I assume that privacy is the >>>>>> main interest), there is a need to maintain the mapping of >>>>>> the identity and the locator of the mobile node. >>>>> >>>>> Mobile IPv6 today allows you to use two home addresses >>>>> at the same time. it also allows you to bind both home >>>>> addresses to the same CoA. >>>> >>>> >>>> Yes, that's true. But then there is a problem to choose >>>> which one for which communication. When it comes to agility, >>>> it's more problematic. >>> >>> actually we are not looking for address agility here. we want >>> the mobile node to change its home address and while changing >>> it allow existing sessions using the old home address to >>> continue and start using the new home address for new sessions. >> I see. Now I understand that address agility is not the main >> issue here. If I understand the above correctly, the issue >> is more about how to handle pseudo-HoA especially for correspondents >> of the mobile node, and how to minimize the impact to the >> existing communication. > > its not even about privacy. its about the mobile node deciding > to change home addresses, while minimizing impact on existing > sessions. new sessions would be started with the new HoA. for > a short period there will be two home addresses with some > sessions based on the old HoA and some on the new HoA. What does 'minimizing impact on sessions'? Does it mean session continuity? Then, I have a simple question that why do we need to provide session continuity when home address changes? A home address is the identifier of the end node. If it changed, then the sessions related to the identifier should be terminated. If we can change from one home address to another home address, then why do we need Mobile IP? Or does the discussion is for a new mobility mechanism other than MIP based? # or I am misunderstanding...? --- Keiichi SHIMA IIJ Research Laboratory WIDE Project _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 03:37:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtJkp-00052z-84; Thu, 22 Jun 2006 03:37:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtJkn-00052p-EX for mip6@ietf.org; Thu, 22 Jun 2006 03:37:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtJ2W-0007WD-6H for mip6@ietf.org; Thu, 22 Jun 2006 02:51:44 -0400 Received: from [144.189.100.101] (helo=motgate2.mot.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtIn1-0006ar-Az for mip6@ietf.org; Thu, 22 Jun 2006 02:35:51 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k5M6Twxh012380; Wed, 21 Jun 2006 23:29:58 -0700 (MST) Received: from [10.129.40.231] ([10.129.40.231]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k5M6TurU022430; Thu, 22 Jun 2006 01:29:57 -0500 (CDT) Message-ID: <449A38E3.8050207@motorola.com> Date: Thu, 22 Jun 2006 08:29:55 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FB59@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FB59@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: -2.6 (--) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: >> Tsirtsis, George wrote: >>>> An operator using NATs to offer IPv4 home addresses do so >>>> without offering reachability at that permanent IPv4 home >>>> address. Would DS-MIPv6 allow this? >>>> >>> >>> Sure it does. >> >> Ok, so DS-MIPv6 does not have as a goal to offer reachable IPv4 >> Home Addresses for Mobile Nodes. > > => You can't conclude that from the response above. DSMIP does allow > a MN to have an IPv4 HoA but it's not mandatory. So if you want to > use IPv6-only HoAs then you can use DSMIPv6 to roam in IPv4 networks. > If you want to use IPv6 and IPv4 HoAs you can use DSMIPv6 for both > IPv4 HoA and CoA. I really can't explain this any more than that. Hesham, if we discuss this with a goals perspective, do you think DS-MIPv6 has among its goals to offer session continuity and reachability at a permanent IPv4 HoA? It seems the reachability part is not really a goal. That is good to know. It's useless to continue claiming features as if one were trying to sell a protocol based on its wide range of features. Does the protocol have _any_ shortcoming? >>> I do not think that "permanent" IPv4 addresses is a goal. >> >> Good to know DS-MIPv6 does not try to offer reachable IPv4 home >> addresses. > > => Somehow you replaced "permanent" with "reachable". YEs, because somehow my correspondent considered that NAT can't offer "permanent" addresses while it actually can't offer "reachable" addresses. MAkes sense? Quoting the whole discussion can help. Directly replacing avoided me asking whether he meant "permanent" or "reachable", I'm sure he meant reachable. > DSMIPv6 allows a MN to have an IPv4 address (private or public is > irrelevant to DSMIPv6). I think DS-MIPv6 wouldn't work when the IPv4 HoA is private (thus not reachable) because the HA is behind NAT, so the BU (encapsulated in IPv4) wouldn't reach the HA, right? Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 03:39:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtJmI-0005AB-48; Thu, 22 Jun 2006 03:39:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtJmG-0005A1-Lu; Thu, 22 Jun 2006 03:39:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtIkY-0005Z6-FU; Thu, 22 Jun 2006 02:33:10 -0400 Received: from mout.perfora.net ([217.160.230.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtIVN-0006OM-JU; Thu, 22 Jun 2006 02:17:31 -0400 Received: from [68.126.210.18] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1FtIV206Uy-0001lW; Thu, 22 Jun 2006 02:17:14 -0400 From: "Alper Yegin" To: "'James Kempf'" , "'Gerardo Giaretta'" Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home InformationDiscovery inMIPv6 Date: Wed, 21 Jun 2006 23:17:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaVgXOiRxRHpOnsSnCvZFo7al/AqQAPAEqA In-Reply-To: <03df01c69581$8c845380$026115ac@dcml.docomolabsusa.com> Message-ID: <0MKp2t-1FtIV206Uy-0001lW@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: -2.4 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: mip6@ietf.org, 'Heejin Jang' , dhcwg@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi James, > Hi Alper, > > > I think it helps to understand the components of the full picture. > > > > [a] Delivery of the info from home AAA to the NAS > > [b] Delivery of the info from the NAS (DHCP relay) to the DHCP server. > > [c] Delivery of the info from the DHCP server to the DHCP client > > [d] Plumbing of all these components > > > > > > [a], [b], and [c] are all protocol work. [d] is just informational. > > > > The document draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt covers > > [b] > > and [d]. > > > > WiMAX does not use [b]. For that there is no need to have a normative > > reference to draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. It > could > > have an informative reference to it, but it does not have to. > > > > I think this is a very good and clear description. > > Lately, I've become really interested in seeing IETF do stuff that > actually > gets deployed. So, given that WiMax Forum doesn't need [b], do you think > they might be willing to reference this document (and thereby we could see > it deployed) if [b] were deleted? I presume you are suggesting splitting [b] from the draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt to a separate document. In fact this was my original proposal: To have separate documents. At the end of the day, what matters for interoperability is [a], [b], and [c]. These are the components we want the SDOs to use (normatively referenced). [d] is informational. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 03:39:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtJmK-0005Ed-M8; Thu, 22 Jun 2006 03:39:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtJmJ-0005D3-28 for mip6@ietf.org; Thu, 22 Jun 2006 03:39:03 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtJmG-0007XS-Mz for mip6@ietf.org; Thu, 22 Jun 2006 03:39:03 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5M7cwuC006073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Jun 2006 00:38:59 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5M7cv2b002392; Thu, 22 Jun 2006 00:38:57 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 00:38:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Date: Thu, 22 Jun 2006 00:38:54 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FB66@NAEX14.na.qualcomm.com> In-Reply-To: <449A38E3.8050207@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) Thread-Index: AcaVye47aIjTD3DeTKm2ckwWbKN7DAABDOKA From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 22 Jun 2006 07:38:56.0742 (UTC) FILETIME=[EB23A060:01C695CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org =20 > > =3D> You can't conclude that from the response above. DSMIP=20 > does allow=20 > > a MN to have an IPv4 HoA but it's not mandatory. So if you want to=20 > > use IPv6-only HoAs then you can use DSMIPv6 to roam in=20 > IPv4 networks. > > If you want to use IPv6 and IPv4 HoAs you can use DSMIPv6=20 > for both=20 > > IPv4 HoA and CoA. I really can't explain this any more than that. >=20 > Hesham, if we discuss this with a goals perspective, do you think > DS-MIPv6 has among its goals to offer session continuity and > reachability at a permanent IPv4 HoA? It seems the=20 > reachability part is > not really a goal. That is good to know. =3D> You've lumped about 10 features in one statement. Here are the two goals of DSMIPv6:=20 1. Allow a mobile node to have IPv4 and IPv6 HoA simultaneously. 2. Allow a MN to have an IPv4.=20 To be realistic, goal 2) requires NAT traversal since a lot of networks use private addresses. That's it. These are the two goals.=20 >=20 > It's useless to continue claiming features as if one were=20 > trying to sell > a protocol based on its wide range of features. =20 =3D> It's actually useless to keep repeating the same thing once a = month. Please be constructive and help in reducing the amount of repetition here. > > DSMIPv6 allows a MN to have an IPv4 address (private or public is=20 > > irrelevant to DSMIPv6). >=20 > I think DS-MIPv6 wouldn't work when the IPv4 HoA is private (thus not > reachable) because the HA is behind NAT, so the BU (encapsulated in > IPv4) wouldn't reach the HA, right? =3D> Please read the draft. It's not possible to have a discussion when you keep claiming things that are easily nullified by reading the document.=20 Hesham >=20 > Alex >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 04:42:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtKl8-0006j7-IH; Thu, 22 Jun 2006 04:41:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtKl7-0006j2-RQ for mip6@ietf.org; Thu, 22 Jun 2006 04:41:53 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtJhy-0005WQ-83 for mip6@ietf.org; Thu, 22 Jun 2006 03:34:34 -0400 Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtJSz-0007DQ-21 for mip6@ietf.org; Thu, 22 Jun 2006 03:19:06 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 91A364CE7E; Thu, 22 Jun 2006 16:18:56 +0900 (JST) Date: Thu, 22 Jun 2006 10:18:59 +0300 From: Shinta Sugimoto To: Vijay Devarapalli Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction In-Reply-To: <4499C19F.3050707@azairenet.com> References: <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> <4499C19F.3050707@azairenet.com> Message-Id: <20060622100958.AA6B.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On Wed, 21 Jun 2006 15:01:03 -0700 Vijay Devarapalli wrote: > Shinta Sugimoto wrote: > > >>>>>>The problem here is how does the MN know to "let the > >>>>>>existing sessions continue with the existing HoA"? If there is no CN's > >>>>>>address in BUL, surely the MN can choose a suitable HoA. For > >>>>>>a CN with which it has a binding, it has no reliable way of knowing > >>>>>>whether there are any ULP sessions. > >>>>> > >>>>>If you need to maintain the sessions while changing the HoA > >>>> > >>>>>from one to another, I think you need additional mechanism > >>>> > >>>>>than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed > >>>>>to assure the reachability to a given HoA with the current > >>>>>location of the mobile node (CoA). If the app wants > >>>>>to change HoAs for some reason (I assume that privacy is the > >>>>>main interest), there is a need to maintain the mapping of > >>>>>the identity and the locator of the mobile node. > >>>> > >>>>Mobile IPv6 today allows you to use two home addresses > >>>>at the same time. it also allows you to bind both home > >>>>addresses to the same CoA. > >>> > >>> > >>>Yes, that's true. But then there is a problem to choose > >>>which one for which communication. When it comes to agility, > >>>it's more problematic. > >> > >>actually we are not looking for address agility here. we want > >>the mobile node to change its home address and while changing > >>it allow existing sessions using the old home address to > >>continue and start using the new home address for new sessions. > > > > > > I see. Now I understand that address agility is not the main > > issue here. If I understand the above correctly, the issue > > is more about how to handle pseudo-HoA especially for correspondents > > of the mobile node, and how to minimize the impact to the > > existing communication. > > its not even about privacy. its about the mobile node deciding > to change home addresses, while minimizing impact on existing > sessions. new sessions would be started with the new HoA. for > a short period there will be two home addresses with some > sessions based on the old HoA and some on the new HoA. If I understand it correctly, upper layer protocol continue to use *same* HoA even if the pseudo-HoA is changed, right ? Pseudo-HoA that appears in RH2/HAO is expected to be updated accordingly. So, I am afraid that "changing HoA" is a bit misleading explanation in this case. > > > Now I have another question. Looking into the solution draft > > (draft-irtf-mobopts-location-privacy-solutions-01) it seems to me > > that a pseudo-HoA is derived from mobile node's home prefix > > and it is actually a globally unique IPv6 address. If I understand > > the role of pseudo-HoA correctly, it aims to serve as a tag to > > locate the real HoA for the MN. If so, I am afraid that it may > > not be necessary to generate a pseudo-HoA in form of IPv6 address. > > In particular, there is no need to contain the home prefix which > > could be of interest for an eavesdropper to identify the mobile > > node. Am I missing something ? > > I would actually wait for version 02, which should be out next > week before we discuss further. I wasn't very happy with > version 01. Ok, let's wait for the next version of the solution draft then resume discussion. > > regarding the pseudo-HoA, it can be any 128 bit value. does > not have to have the home prefix. Ok. Regards, Shinta _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 05:55:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtLua-00069b-M2; Thu, 22 Jun 2006 05:55:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtLuZ-00069W-JN for mip6@ietf.org; Thu, 22 Jun 2006 05:55:43 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtLuY-0000mf-5I for mip6@ietf.org; Thu, 22 Jun 2006 05:55:43 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5M9tdao024082; Thu, 22 Jun 2006 02:55:39 -0700 (MST) Received: from [10.19.249.159] (mvp-10-19-249-159.corp.mot.com [10.19.249.159]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k5M9tcTk012919; Thu, 22 Jun 2006 04:55:38 -0500 (CDT) Message-ID: <449A6919.1030302@motorola.com> Date: Thu, 22 Jun 2006 11:55:37 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FB66@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FB66@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > > > > > > => You can't conclude that from the response above. DSMIP > > does allow > > > a MN to have an IPv4 HoA but it's not mandatory. So if you want to > > > use IPv6-only HoAs then you can use DSMIPv6 to roam in > > IPv4 networks. > > > If you want to use IPv6 and IPv4 HoAs you can use DSMIPv6 > > for both > > > IPv4 HoA and CoA. I really can't explain this any more than that. > > > > Hesham, if we discuss this with a goals perspective, do you think > > DS-MIPv6 has among its goals to offer session continuity and > > reachability at a permanent IPv4 HoA? It seems the > > reachability part is > > not really a goal. That is good to know. > > => You've lumped about 10 features in one statement. Here are the two > goals of DSMIPv6: > 1. Allow a mobile node to have IPv4 and IPv6 HoA simultaneously. > 2. Allow a MN to have an IPv4. > To be realistic, goal 2) requires NAT traversal since a lot of networks > use private addresses. That's it. These are the two goals. Ok, if the IPv4 HoA is behind NAT I don't think DS-MIPv6' NAT Traversal can help with it. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 07:09:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtN3c-0002QE-9c; Thu, 22 Jun 2006 07:09:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtN3b-0002Q9-13 for mip6@ietf.org; Thu, 22 Jun 2006 07:09:07 -0400 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtN3Y-0004Bj-6S for mip6@ietf.org; Thu, 22 Jun 2006 07:09:07 -0400 Received: from rodin.i2r.a-star.edu.sg (localhost [127.0.0.1]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id k5MB8qRq025636 for ; Thu, 22 Jun 2006 19:08:52 +0800 (SGT) Received: from newmailhost.i2r.a-star.edu.sg ([192.122.134.76]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id k5MB8qkR025630 for ; Thu, 22 Jun 2006 19:08:52 +0800 (SGT) Received: from mailbe01.teak.local.net ([192.122.134.10]) by mailhost.lit.org.sg (Sun Java System Messaging Server 6.1 HotFix 0.06 (built Nov 11 2004)) with ESMTP id <0J1900MVFDMY9P10@mailhost.lit.org.sg> for mip6@ietf.org; Thu, 22 Jun 2006 19:08:58 +0800 (SGT) Received: from mailfe01.teak.local.net ([192.122.134.9]) by mailbe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 19:08:39 +0800 Received: from D8ZXLJ1S ([192.168.137.186]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 19:08:39 +0800 Date: Thu, 22 Jun 2006 19:09:13 +0800 From: QIU Ying Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction To: Keiichi SHIMA , Vijay Devarapalli Message-id: <091901c695ec$4b251620$ba89a8c0@D8ZXLJ1S> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> <69816405-8861-4B68-B9DA-6E133DFB4E73@iijlab.net> X-OriginalArrivalTime: 22 Jun 2006 11:08:39.0107 (UTC) FILETIME=[36D02930:01C695EC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, all, My comments is at the bottom. a long quotation. ----- Original Message ----- From: "Keiichi SHIMA" To: "Vijay Devarapalli" Cc: ; "Rajeev Koodli" ; Sent: Thursday, June 22, 2006 12:39 PM Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction > Hi all, > > On 2006/06/22, at 7:01, Vijay Devarapalli wrote: > >> Shinta Sugimoto wrote: >> >>>>>>>> The problem here is how does the MN know to "let the >>>>>>>> existing sessions continue with the existing HoA"? If there is no >>>>>>>> CN's >>>>>>>> address in BUL, surely the MN can choose a suitable HoA. For >>>>>>>> a CN with which it has a binding, it has no reliable way of >>>>>>>> knowing >>>>>>>> whether there are any ULP sessions. >>>>>>> >>>>>>> If you need to maintain the sessions while changing the HoA >>>>>> >>>>>>> from one to another, I think you need additional mechanism >>>>>> >>>>>>> than plain MIPv6. MIP (no matter IPv6 or IPv4) is designed >>>>>>> to assure the reachability to a given HoA with the current >>>>>>> location of the mobile node (CoA). If the app wants >>>>>>> to change HoAs for some reason (I assume that privacy is the >>>>>>> main interest), there is a need to maintain the mapping of >>>>>>> the identity and the locator of the mobile node. >>>>>> >>>>>> Mobile IPv6 today allows you to use two home addresses >>>>>> at the same time. it also allows you to bind both home >>>>>> addresses to the same CoA. >>>>> >>>>> >>>>> Yes, that's true. But then there is a problem to choose >>>>> which one for which communication. When it comes to agility, >>>>> it's more problematic. >>>> >>>> actually we are not looking for address agility here. we want >>>> the mobile node to change its home address and while changing >>>> it allow existing sessions using the old home address to >>>> continue and start using the new home address for new sessions. >>> I see. Now I understand that address agility is not the main >>> issue here. If I understand the above correctly, the issue >>> is more about how to handle pseudo-HoA especially for correspondents >>> of the mobile node, and how to minimize the impact to the >>> existing communication. >> >> its not even about privacy. its about the mobile node deciding >> to change home addresses, while minimizing impact on existing >> sessions. new sessions would be started with the new HoA. for >> a short period there will be two home addresses with some >> sessions based on the old HoA and some on the new HoA. > > What does 'minimizing impact on sessions'? Does it mean session > continuity? Yes. > Then, I have a simple question that why do we need to provide session > continuity when home address changes? A home address is the identifier > of the end node. Yes, it is the key point. In normal MIP6, the identity HoA is always bound with CoA. However, for the privacy reason, we must break the relationship CoA and HoA in an eavesdropper perspective. It is why we need change the HoA. In fact, to change the HoA does means to change the owner, it just change the ones mask. > If it changed, then the sessions related to the identifier should be > terminated. If we can change from one home address to another home > address, then why do we need Mobile IP? Home address indicate the owner of the CoA. MN is not able to get a packet with HoA as the destination address. Mobile IP ensure the direct connection between MN and CN. > Or does the discussion is for a new mobility mechanism other than MIP > based? It follows the mechanism of RFC3775 and 3776. Regards Qiu Ying > > # or I am misunderstanding...? > > > --- > Keiichi SHIMA > IIJ Research Laboratory > WIDE Project > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts ------------ Institute For Infocomm Research - Disclaimer ------------- This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you. -------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 07:31:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNPV-0004pB-4W; Thu, 22 Jun 2006 07:31:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtNPU-0004p1-5o for mip6@ietf.org; Thu, 22 Jun 2006 07:31:44 -0400 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtNPR-0005n4-JB for mip6@ietf.org; Thu, 22 Jun 2006 07:31:44 -0400 Received: from rodin.i2r.a-star.edu.sg (localhost [127.0.0.1]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id k5MBVUea029073 for ; Thu, 22 Jun 2006 19:31:30 +0800 (SGT) Received: from newmailhost.i2r.a-star.edu.sg ([192.122.134.76]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id k5MBVUYB029060 for ; Thu, 22 Jun 2006 19:31:30 +0800 (SGT) Received: from mailbe01.teak.local.net ([192.122.134.10]) by mailhost.lit.org.sg (Sun Java System Messaging Server 6.1 HotFix 0.06 (built Nov 11 2004)) with ESMTP id <0J1900M1YEON9P20@mailhost.lit.org.sg> for mip6@ietf.org; Thu, 22 Jun 2006 19:31:35 +0800 (SGT) Received: from mailfe01.teak.local.net ([192.122.134.9]) by mailbe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 19:31:16 +0800 Received: from D8ZXLJ1S ([192.168.137.186]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 19:31:16 +0800 Date: Thu, 22 Jun 2006 19:31:50 +0800 From: QIU Ying Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction To: Vijay Devarapalli , Shinta Sugimoto Message-id: <091e01c695ef$744c07e0$ba89a8c0@D8ZXLJ1S> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> <4499C19F.3050707@azairenet.com> X-OriginalArrivalTime: 22 Jun 2006 11:31:16.0620 (UTC) FILETIME=[5FF434C0:01C695EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, Shinta and Vijay I skip some old quotation for easy read >> Now I have another question. Looking into the solution draft >> (draft-irtf-mobopts-location-privacy-solutions-01) it seems to me >> that a pseudo-HoA is derived from mobile node's home prefix >> and it is actually a globally unique IPv6 address. If I understand >> the role of pseudo-HoA correctly, it aims to serve as a tag to >> locate the real HoA for the MN. If so, I am afraid that it may >> not be necessary to generate a pseudo-HoA in form of IPv6 address. RFC3775 requires that option/routing address must be a routable address. So a random number as the destination option is not acceptable. >> In particular, there is no need to contain the home prefix which >> could be of interest for an eavesdropper to identify the mobile >> node. Am I missing something ? So we need multi home prefix to generate the psuedo HoA to delude the eavesdroppers. The reason of the psuedo HoA with home prefix is that the psuedo HoA in both HoTI/HoT and BU must be the same, while the HoT must be routed to the home agent. > I would actually wait for version 02, which should be out next > week before we discuss further. I wasn't very happy with > version 01. Hope the version 02 do not disappoint you :-) Regards Qiu Ying > regarding the pseudo-HoA, it can be any 128 bit value. does > not have to have the home prefix. > > Vijay > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts ------------ Institute For Infocomm Research - Disclaimer ------------- This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you. -------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 08:42:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOVm-0007Ti-97; Thu, 22 Jun 2006 08:42:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOVd-0007Fd-MF for mip6@ietf.org; Thu, 22 Jun 2006 08:42:09 -0400 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtOQ6-0000Yj-5R for mip6@ietf.org; Thu, 22 Jun 2006 08:37:20 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 72E554CC4D; Thu, 22 Jun 2006 21:36:18 +0900 (JST) Date: Thu, 22 Jun 2006 15:36:20 +0300 From: Shinta Sugimoto To: QIU Ying Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction In-Reply-To: <091e01c695ef$744c07e0$ba89a8c0@D8ZXLJ1S> References: <4499C19F.3050707@azairenet.com> <091e01c695ef$744c07e0$ba89a8c0@D8ZXLJ1S> Message-Id: <20060622150758.AA71.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: mip6@ietf.org, mobopts@irtf.org, Rajeev Koodli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ying, Thanks for your clarification. Please find my comments inline. On Thu, 22 Jun 2006 19:31:50 +0800 QIU Ying wrote: > > Hi, Shinta and Vijay > > I skip some old quotation for easy read > > >> Now I have another question. Looking into the solution draft > >> (draft-irtf-mobopts-location-privacy-solutions-01) it seems to me > >> that a pseudo-HoA is derived from mobile node's home prefix > >> and it is actually a globally unique IPv6 address. If I understand > >> the role of pseudo-HoA correctly, it aims to serve as a tag to > >> locate the real HoA for the MN. If so, I am afraid that it may > >> not be necessary to generate a pseudo-HoA in form of IPv6 address. > > RFC3775 requires that option/routing address must be a routable address. So > a random number as the destination option is not acceptable. Correct. And it's mainly for security reason. RH2 and HAO DSTOPT are MIPv6 specific, and they are processed only by the final destination. So, in order to extend the MIPv6 protocol for privacy support, I think exceptionional cases shall be made. And I am afraid that the version 01 actually suggests to include encrypted HoA E(Kbm, HoA) in the HAO destination option, doesn't it ? > > >> In particular, there is no need to contain the home prefix which > >> could be of interest for an eavesdropper to identify the mobile > >> node. Am I missing something ? > > So we need multi home prefix to generate the psuedo HoA to delude the > eavesdroppers. I am sorry, but I failed to understand why multiple home prefix is needed to achieve the goal (privacy). Could you please elaborate ? > The reason of the psuedo HoA with home prefix is that the > psuedo HoA in both HoTI/HoT and BU must be the same, while the HoT must be > routed to the home agent. Could you please explain why does the draft suggest to modify the way of CN trasmitting HoT to the MN ? In plain MIPv6, HoT is sent by the CN to the MN's HoA (to be set as the destination address). Then we can expect that the HoT message is protected by the IPsec tunnel established between the MN and HA. Is there any problem with that ? > > > I would actually wait for version 02, which should be out next > > week before we discuss further. I wasn't very happy with > > version 01. > > Hope the version 02 do not disappoint you :-) No, I am not disappointed at all, it's an interesting draft. Regards, Shinta _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 13:11:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSiP-0002OZ-Ah; Thu, 22 Jun 2006 13:11:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSiN-0002NR-Rp for mip6@ietf.org; Thu, 22 Jun 2006 13:11:35 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtSiM-0001Qh-Dl for mip6@ietf.org; Thu, 22 Jun 2006 13:11:35 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5MHBU3q020845 for ; Thu, 22 Jun 2006 20:11:33 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 20:10:31 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 12:10:31 -0500 Received: from 172.19.244.64 ([172.19.244.64]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Jun 2006 17:10:31 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 22 Jun 2006 12:10:43 -0500 From: Basavaraj Patil To: Message-ID: Thread-Topic: Note on the draft agenda for MIP6 WG meeting at IETF66 Thread-Index: AcaWHstDCdaeVgISEdubNwARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Jun 2006 17:10:31.0592 (UTC) FILETIME=[C4767280:01C6961E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Mip6] Note on the draft agenda for MIP6 WG meeting at IETF66 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, The latest revision of the agenda is at: http://www3.ietf.org/proceedings/06jul/agenda/mip6.txt This is a draft agenda and will be revised. Please note that the agenda items listed under Non-WG items may be dropped based on the relevance of the I-D to the WG charter, time constraints and discussion of the I-D on the mailing list. -BPa _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 13:20:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSqp-0000Ah-1j; Thu, 22 Jun 2006 13:20:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSqn-0000Ac-Q0 for mip6@ietf.org; Thu, 22 Jun 2006 13:20:17 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtSqm-0001wH-AT for mip6@ietf.org; Thu, 22 Jun 2006 13:20:17 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5MHKE6D030960; Thu, 22 Jun 2006 20:20:15 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 20:20:12 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 12:20:10 -0500 Received: from 172.19.244.64 ([172.19.244.64]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Jun 2006 17:20:09 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 22 Jun 2006 12:20:21 -0500 Subject: Re: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 From: Basavaraj Patil To: ext Alexandru Petrescu Message-ID: Thread-Topic: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 Thread-Index: AcaWICPGYoZEIQITEdubNwARJNUNiA== In-Reply-To: <4499C82E.7020303@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Jun 2006 17:20:10.0430 (UTC) FILETIME=[1D7A1DE0:01C69620] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Inline: On 6/21/06 5:29 PM, "ext Alexandru Petrescu" wrote: > Basavaraj Patil wrote: >> THURSDAY, July 13, 2006 0900-1130 Morning Session I Room 518AB >> >> ========================================= >> >> 1. Agenda review, Blue sheets and volunteers for taking notes and >> Jabber scribe 5 Mins >> >> 2. WG status and I-Ds update 10 Mins >> >> 3. Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) >> I-D: draft-ietf-mip6-nemo-v4traversal-01.txt >> >> Hesham Soliman 15 Mins > > The DS-MIPv6 draft has 7 authors on the frontpage. That was discussed > as a potential issue with a guideline that would suggest only 5 authors > there. Among other, not following the suggestion has some practical > consequences (AUTH48 time takes longer). As you noted, it is a "guideline" and NOT a rule. > > I don't see why presenting this draft at IETF in its current form. Or > maybe there are plans to update it for this? The I-D in its current form is good for WG discussion. There will be revisions before it goes to WG LC. But at this point, I see no reason for it not being on the agenda. What is the specific concern that you have? > >> 4. Mobility management for Dual stack mobile nodes: A Problem >> Statement I-D: draft-ietf-mip6-dsmip-problem-02.txt >> >> Hesham Soliman 5 Mins > > AD asked for a problem statement for the MIP4-MIP6 space. This I-D has existed as a MIP6 WG I-D for a long time. This has got nothing to do with the AD asking for a problem statement from the work being done in MIP4. So lets not confuse the issue. > > However, this draft does not contain the original problem statement of > draft-wakikawa-nemo-v4tunnel-01.txt (namely multiple encapsulation). > Additionally, all the list discussion since last IETF around problem > statement is not reflected in this draft. > > I don't see why presenting it. Or maybe there are plans to update it > for this? The I-D has been revised and changes will be discussed. How this work will proceed is a matter of discussion by the WG. Will it be updated before IETF66? No. > > It's hard to have a meaningful discussion during the WG meeting when the > email discussion prior to it is not taken into account. The email discussion on the MIP6 ML was about the rechartering of MIP4 and specifically the proposal to work on an equivalent solution that exists in MIP6 for DS nodes for MIP4 hosts. We will not be discussing this in the MIP6 WG. -Raj > > Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 13:24:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSuX-0001x2-H0; Thu, 22 Jun 2006 13:24:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSuW-0001sa-A0 for mip6@ietf.org; Thu, 22 Jun 2006 13:24:08 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtSuV-00022k-02 for mip6@ietf.org; Thu, 22 Jun 2006 13:24:08 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 10:24:05 -0700 Message-ID: <449AD1BC.9070606@azairenet.com> Date: Thu, 22 Jun 2006 10:22:04 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keiichi SHIMA Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction References: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> <4498363E.4050702@azairenet.com> <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> <4499C19F.3050707@azairenet.com> <69816405-8861-4B68-B9DA-6E133DFB4E73@iijlab.net> In-Reply-To: <69816405-8861-4B68-B9DA-6E133DFB4E73@iijlab.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2006 17:24:05.0096 (UTC) FILETIME=[A9594E80:01C69620] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mip6@ietf.org, Rajeev Koodli , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Keiichi SHIMA wrote: >> its not even about privacy. its about the mobile node deciding >> to change home addresses, while minimizing impact on existing >> sessions. new sessions would be started with the new HoA. for >> a short period there will be two home addresses with some >> sessions based on the old HoA and some on the new HoA. > > > What does 'minimizing impact on sessions'? Does it mean session > continuity? just let the sessions on the old HoA continue for a while (not forever though). > Then, I have a simple question that why do we need to provide session > continuity when home address changes? A home address is the identifier > of the end node. If it changed, then the sessions related to the > identifier should be terminated. thats one option. another option is to let the use of old HoA and the new HoA for a while. > If we can change from one home > address to another home address, then why do we need Mobile IP? > > Or does the discussion is for a new mobility mechanism other than MIP > based? > > # or I am misunderstanding...? we need to go back to the original mail from Rajeev and figure out what problem we are trying to solve. this thread has been too long. :) Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 13:57:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTQR-00064w-2s; Thu, 22 Jun 2006 13:57:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTQP-00064k-Cj; Thu, 22 Jun 2006 13:57:05 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtTQO-0003m4-QI; Thu, 22 Jun 2006 13:57:05 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 10:57:02 -0700 Message-ID: <449AD979.4000902@azairenet.com> Date: Thu, 22 Jun 2006 10:55:05 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Behcet Sarikaya Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 References: <20060622000416.13980.qmail@web60320.mail.yahoo.com> In-Reply-To: <20060622000416.13980.qmail@web60320.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2006 17:57:02.0640 (UTC) FILETIME=[440E9300:01C69625] X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: mip6@ietf.org, Heejin Jang , dhcwg@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Behcet Sarikaya wrote: > Hi Vijay, > The idea in the present WiMAX document is quite simple: > it uses EAP-PKMv2 (which is like 802.11i) authentication and during EAP > transaction, they assume that AAA server determines that the MS is a > CMIPv6 authorized user based on the AAA profile and it will include all > the so-called bootstrapping info in the Access-Accept. Then MS can use > RFC 3736 to make a DHCP Information Request to DHCP Relay colocated with > NAS and use draft-jang (extended now with HoA) and receive all the info > to configure MIP6. the DHCP Relay replies to the MN without relaying the DHCP request from the MN to a DHCP server? this is not allowed with the current IETF specs. > In this setup can you make a case for > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt? as far as I am concerned, draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt is the document that describes how to use DHCPv6 for MIPv6 bootstrapping. as for the setup in the WiMAX NWG, it is something that doesn't conform to the IETF DHCP specs. Vijay > > Regards, > > --behcet > > ----- Original Message ---- > From: Alper Yegin > To: Gerardo Giaretta > Cc: mip6@ietf.org; dhcwg@ietf.org; Heejin Jang > Sent: Wednesday, June 21, 2006 4:48:10 PM > Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home > Information Discovery inMIPv6 > > Gerardo, > > I think it helps to understand the components of the full picture. > > [a] Delivery of the info from home AAA to the NAS > [b] Delivery of the info from the NAS (DHCP relay) to the DHCP server. > [c] Delivery of the info from the DHCP server to the DHCP client > [d] Plumbing of all these components > > > [a], [b], and [c] are all protocol work. [d] is just informational. > > The document draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt covers [b] > and [d]. > > WiMAX does not use [b]. For that there is no need to have a normative > reference to draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. It could > have an informative reference to it, but it does not have to. > > Alper > > > > > > > > -----Original Message----- > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > Sent: Wednesday, June 21, 2006 1:18 AM > > To: Alper Yegin > > Cc: Vijay Devarapalli; mip6@ietf.org; Heejin Jang; dhcwg@ietf.org > > Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home > Information > > Discovery inMIPv6 > > > > Alper, > > > > just one question below in order to understand if there is a real > > technical reason to keep the docs separated.. > > > > > > > But I hope this data point helps: WiMAX Forum NWG architecture is > > using > > > > > draft-jang. > > > > > > > > in what context and how are they planning to use it? > > > > > > The MIP info is brought to the DHCP server via RADIUS and delivered to > > the > > > MN via DHCP. > > > > > > > Can you please explain which are the technical differences between the > > solution in the DT draft for integrated scenario and the solution > > developped in WiMAX? > > > > I guess in WiMAX MIP info are brought to DHCP relay (i.e. NAS) and > > then draft-jang is applied. Is this really different from what is > > described in the DT draft? > > > > --Gerardo > > > > > > the > > > > WiMAX forum NWG can still use the DHCP options wherever > > > > they are defined. > > > > > > Yes. And WiMAX Forum could also use it even if IETF had > concatenated all > > of > > > the RFCs and I-Ds under a single document too.... This I-D being > > referenced > > > whereas the draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt wasn't > > is a > > > solid proof that the former I-D is useful without having to be > > integrated > > > into the latter. > > > > > > > > > > >>the only other mechanism is to manually > > > > >>configure the DHCP servers in the visited link with > > > > >>information like home agent address, home address and home > > > > >>prefix. this is a bad idea. > > > > > > > > > You know that one does not have to put DHCP servers on every subnet, > > instead > > > one can rely on DHCP relays. And that's the used technique for many > > > enterprise networks. So, I don't see why this is a bad idea. > > > > > > Alper > > > > > > > > > > > > > > > > > > > > Vijay > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > >>-----Original Message----- > > > > >>From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > > > >>Sent: Monday, June 19, 2006 6:17 PM > > > > >>To: Heejin Jang > > > > >>Cc: mip6@ietf.org; dhcwg@ietf.org > > > > >>Subject: Re: [Mip6] [Updated] DHCP Option for Home Information > > Discovery > > > > >>inMIPv6 > > > > >> > > > > >>Heejin Jang wrote: > > > > >> > > > > >>>Hello folks, > > > > >>>We posted an I-D that proposes new DHCP Options for Home > > Information > > > > >>>Discovery in MIPv6. > > > > >>> > > > > >>>Kindly note that the previous version of this draft is > > > > >>>"draft-jang-dhc-haopt-02.txt" but the name is slightly changed > into > > > > >>>"draft-jang-mip6-hiopt-00.txt" while keeping almost the same > > contents. > > > > >>> > > > > >>>The drafts referencing this draft such as > > > > >>>draft-ietf-mip6-bootstrapping-split-02.txt and > > > > >>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt need to be > > revised > > > > >>>accordingly. > > > > >>> > > > > >>>We would appreciate to hear your comments. > > > > >> > > > > >>when this draft was discussed in the MIP6 bootstrapping > > > > >>design team, many people wanted to integrate the two DHCP > > > > >>options into > > > > >>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. > > > > >>this was mainly because the options defined in the document > > > > >>have limited applicability beyond the integrated scenario > > > > >>solution document. the only other mechanism is to manually > > > > >>configure the DHCP servers in the visited link with > > > > >>information like home agent address, home address and home > > > > >>prefix. this is a bad idea. > > > > >> > > > > >>there was some opposition and we never reached an agreement. > > > > >> > > > > >>so I suggest including these options into the integrated > > > > >>scenario solution document for these options to get > > > > >>standardized quickly. > > > > >> > > > > >>Vijay > > > > >> > > > > >>_______________________________________________ > > > > >>Mip6 mailing list > > > > >>Mip6@ietf.org > > > > >>https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 14:28:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTuP-0001EG-6v; Thu, 22 Jun 2006 14:28:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTuO-0001EB-Et for mip6@ietf.org; Thu, 22 Jun 2006 14:28:04 -0400 Received: from web60323.mail.yahoo.com ([209.73.178.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FtTuN-0006FE-5g for mip6@ietf.org; Thu, 22 Jun 2006 14:28:04 -0400 Received: (qmail 96417 invoked by uid 60001); 22 Jun 2006 18:28:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=M9wMerc42z4FHADNqnrumg5Seq6ywuCzhEZ3gJBWfEQ3nvPLrEu4uLu+Bm2KtzeRpbrs9NBDpKF5ZYmHV/A6jZgnsnAYrVB6G8Ww5WksTocPIjm7KkPHwBmaBDqlk/cMqMY++HRZHkqn0SR+qYQ6oaEJojv22kefUYgrQY9dhHQ= ; Message-ID: <20060622182802.96413.qmail@web60323.mail.yahoo.com> Received: from [12.129.211.52] by web60323.mail.yahoo.com via HTTP; Fri, 23 Jun 2006 02:28:02 CST Date: Fri, 23 Jun 2006 02:28:02 +0800 (CST) From: Behcet Sarikaya Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 To: Vijay Devarapalli In-Reply-To: <449AD979.4000902@azairenet.com> MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1115676512==" Errors-To: mip6-bounces@ietf.org --===============1115676512== Content-Type: multipart/alternative; boundary="0-1036218581-1151000882=:94453" --0-1036218581-1151000882=:94453 Content-Type: text/plain; charset=us-ascii If DHCP relay has the information locally cached, why should it relay the request to DHCP server? DHCP server should be sync'ed, but that can be done separately. DNS servers work this way also, right? Regards, --behcet ----- Original Message ---- From: Vijay Devarapalli To: Behcet Sarikaya Cc: Alper Yegin ; Gerardo Giaretta ; mip6@ietf.org; Heejin Jang ; dhcwg@ietf.org Sent: Thursday, June 22, 2006 12:55:05 PM Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 Behcet Sarikaya wrote: > Hi Vijay, > The idea in the present WiMAX document is quite simple: > it uses EAP-PKMv2 (which is like 802.11i) authentication and during EAP > transaction, they assume that AAA server determines that the MS is a > CMIPv6 authorized user based on the AAA profile and it will include all > the so-called bootstrapping info in the Access-Accept. Then MS can use > RFC 3736 to make a DHCP Information Request to DHCP Relay colocated with > NAS and use draft-jang (extended now with HoA) and receive all the info > to configure MIP6. the DHCP Relay replies to the MN without relaying the DHCP request from the MN to a DHCP server? this is not allowed with the current IETF specs. > In this setup can you make a case for > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt? as far as I am concerned, draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt is the document that describes how to use DHCPv6 for MIPv6 bootstrapping. as for the setup in the WiMAX NWG, it is something that doesn't conform to the IETF DHCP specs. Vijay > > Regards, > > --behcet > > ----- Original Message ---- > From: Alper Yegin > To: Gerardo Giaretta > Cc: mip6@ietf.org; dhcwg@ietf.org; Heejin Jang > Sent: Wednesday, June 21, 2006 4:48:10 PM > Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home > Information Discovery inMIPv6 > > Gerardo, > > I think it helps to understand the components of the full picture. > > [a] Delivery of the info from home AAA to the NAS > [b] Delivery of the info from the NAS (DHCP relay) to the DHCP server. > [c] Delivery of the info from the DHCP server to the DHCP client > [d] Plumbing of all these components > > > [a], [b], and [c] are all protocol work. [d] is just informational. > > The document draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt covers [b] > and [d]. > > WiMAX does not use [b]. For that there is no need to have a normative > reference to draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. It could > have an informative reference to it, but it does not have to. > > Alper > > > > > > > > -----Original Message----- > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > Sent: Wednesday, June 21, 2006 1:18 AM > > To: Alper Yegin > > Cc: Vijay Devarapalli; mip6@ietf.org; Heejin Jang; dhcwg@ietf.org > > Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home > Information > > Discovery inMIPv6 > > > > Alper, > > > > just one question below in order to understand if there is a real > > technical reason to keep the docs separated.. > > > > > > > But I hope this data point helps: WiMAX Forum NWG architecture is > > using > > > > > draft-jang. > > > > > > > > in what context and how are they planning to use it? > > > > > > The MIP info is brought to the DHCP server via RADIUS and delivered to > > the > > > MN via DHCP. > > > > > > > Can you please explain which are the technical differences between the > > solution in the DT draft for integrated scenario and the solution > > developped in WiMAX? > > > > I guess in WiMAX MIP info are brought to DHCP relay (i.e. NAS) and > > then draft-jang is applied. Is this really different from what is > > described in the DT draft? > > > > --Gerardo > > > > > > the > > > > WiMAX forum NWG can still use the DHCP options wherever > > > > they are defined. > > > > > > Yes. And WiMAX Forum could also use it even if IETF had > concatenated all > > of > > > the RFCs and I-Ds under a single document too.... This I-D being > > referenced > > > whereas the draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt wasn't > > is a > > > solid proof that the former I-D is useful without having to be > > integrated > > > into the latter. > > > > > > > > > > >>the only other mechanism is to manually > > > > >>configure the DHCP servers in the visited link with > > > > >>information like home agent address, home address and home > > > > >>prefix. this is a bad idea. > > > > > > > > > You know that one does not have to put DHCP servers on every subnet, > > instead > > > one can rely on DHCP relays. And that's the used technique for many > > > enterprise networks. So, I don't see why this is a bad idea. > > > > > > Alper > > > > > > > > > > > > > > > > > > > > Vijay > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > >>-----Original Message----- > > > > >>From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > > > >>Sent: Monday, June 19, 2006 6:17 PM > > > > >>To: Heejin Jang > > > > >>Cc: mip6@ietf.org; dhcwg@ietf.org > > > > >>Subject: Re: [Mip6] [Updated] DHCP Option for Home Information > > Discovery > > > > >>inMIPv6 > > > > >> > > > > >>Heejin Jang wrote: > > > > >> > > > > >>>Hello folks, > > > > >>>We posted an I-D that proposes new DHCP Options for Home > > Information > > > > >>>Discovery in MIPv6. > > > > >>> > > > > >>>Kindly note that the previous version of this draft is > > > > >>>"draft-jang-dhc-haopt-02.txt" but the name is slightly changed > into > > > > >>>"draft-jang-mip6-hiopt-00.txt" while keeping almost the same > > contents. > > > > >>> > > > > >>>The drafts referencing this draft such as > > > > >>>draft-ietf-mip6-bootstrapping-split-02.txt and > > > > >>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt need to be > > revised > > > > >>>accordingly. > > > > >>> > > > > >>>We would appreciate to hear your comments. > > > > >> > > > > >>when this draft was discussed in the MIP6 bootstrapping > > > > >>design team, many people wanted to integrate the two DHCP > > > > >>options into > > > > >>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. > > > > >>this was mainly because the options defined in the document > > > > >>have limited applicability beyond the integrated scenario > > > > >>solution document. the only other mechanism is to manually > > > > >>configure the DHCP servers in the visited link with > > > > >>information like home agent address, home address and home > > > > >>prefix. this is a bad idea. > > > > >> > > > > >>there was some opposition and we never reached an agreement. > > > > >> > > > > >>so I suggest including these options into the integrated > > > > >>scenario solution document for these options to get > > > > >>standardized quickly. > > > > >> > > > > >>Vijay > > > > >> > > > > >>_______________________________________________ > > > > >>Mip6 mailing list > > > > >>Mip6@ietf.org > > > > >>https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 --0-1036218581-1151000882=:94453 Content-Type: text/html; charset=us-ascii
If DHCP relay has the information locally cached, why should it relay the request to DHCP server? DHCP server should be sync'ed, but that can be done separately.
DNS servers work this way also, right?

Regards,

--behcet
----- Original Message ----
From: Vijay Devarapalli <vijay.devarapalli@AzaireNet.com>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: Alper Yegin <alper.yegin@yegin.org>; Gerardo Giaretta <gerardo.giaretta@gmail.com>; mip6@ietf.org; Heejin Jang <heejin.jang@samsung.com>; dhcwg@ietf.org
Sent: Thursday, June 22, 2006 12:55:05 PM
Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6

Behcet Sarikaya wrote:
> Hi Vijay,
> The idea in the present WiMAX document is quite simple:
> it uses EAP-PKMv2 (which is like 802.11i) authentication and during EAP
> transaction, they assume that AAA server determines that the MS is a
> CMIPv6 authorized user based on the AAA profile and it will include all
> the so-called bootstrapping info in the Access-Accept. Then MS can  use
> RFC 3736 to make a DHCP Information Request to DHCP Relay colocated with
> NAS and use draft-jang (extended now with HoA) and receive all the info
> to configure MIP6.  

the DHCP Relay replies to the MN without relaying the DHCP
request from the MN to a DHCP server? this is not allowed
with the current IETF specs.

>   In this setup can you make a case for
> draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt?

as far as I am concerned,
draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt
is the document that describes how to use DHCPv6 for MIPv6
bootstrapping. as for the setup in the WiMAX NWG, it is
something that doesn't conform to the IETF DHCP specs.

Vijay

>
> Regards,
>
> --behcet
>
> ----- Original Message ----
> From: Alper Yegin <alper.yegin@yegin.org>
> To: Gerardo Giaretta <gerardo.giaretta@gmail.com>
> Cc: mip6@ietf.org; dhcwg@ietf.org; Heejin Jang <heejin.jang@samsung.com>
> Sent: Wednesday, June 21, 2006 4:48:10 PM
> Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home
> Information Discovery inMIPv6
>
> Gerardo,
>
> I think it helps to understand the components of the full picture.
>
> [a] Delivery of the info from home AAA to the NAS
> [b] Delivery of the info from the NAS (DHCP relay) to the DHCP server.
> [c] Delivery of the info from the DHCP server to the DHCP client
> [d] Plumbing of all these components
>
>
> [a], [b], and [c] are all protocol work. [d] is just informational.
>
> The document draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt covers [b]
> and [d].
>
> WiMAX does not use [b]. For that there is no need to have a normative
> reference to draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. It could
> have an informative reference to it, but it does not have to.
>
> Alper
>
>
>
>
>
>
>  > -----Original Message-----
>  > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]
>  > Sent: Wednesday, June 21, 2006 1:18 AM
>  > To: Alper Yegin
>  > Cc: Vijay Devarapalli; mip6@ietf.org; Heejin Jang; dhcwg@ietf.org
>  > Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home
> Information
>  > Discovery inMIPv6
>  >
>  > Alper,
>  >
>  > just one question below in order to understand if there is a real
>  > technical reason to keep the docs separated..
>  >
>  > > > > But I hope this data point helps: WiMAX Forum NWG architecture is
>  > using
>  > > > > draft-jang.
>  > > >
>  > > > in what context and how are they planning to use it?
>  > >
>  > > The MIP info is brought to the DHCP server via RADIUS and delivered to
>  > the
>  > > MN via DHCP.
>  > >
>  >
>  > Can you please explain which are the technical differences between the
>  > solution in the DT draft for integrated scenario and the solution
>  > developped in WiMAX?
>  >
>  > I guess in WiMAX MIP info are brought to DHCP relay (i.e. NAS) and
>  > then draft-jang is applied. Is this really different from what is
>  > described in the DT draft?
>  >
>  > --Gerardo
>  >
>  > > > the
>  > > > WiMAX forum NWG can still use the DHCP options wherever
>  > > > they are defined.
>  > >
>  > > Yes. And WiMAX Forum could also use it even if IETF had
> concatenated all
>  > of
>  > > the RFCs and I-Ds under a single document too.... This I-D being
>  > referenced
>  > > whereas the draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt wasn't
>  > is a
>  > > solid proof that the former I-D is useful without having to be
>  > integrated
>  > > into the latter.
>  > >
>  > >
>  > > > >>the only other mechanism is to manually
>  > > > >>configure the DHCP servers in the visited link with
>  > > > >>information like home agent address, home address and home
>  > > > >>prefix. this is a bad idea.
>  > >
>  > >
>  > > You know that one does not have to put DHCP servers on every subnet,
>  > instead
>  > > one can rely on DHCP relays. And that's the used technique for many
>  > > enterprise networks. So, I don't see why this is a bad idea.
>  > >
>  > > Alper
>  > >
>  > >
>  > >
>  > >
>  > > >
>  > > > Vijay
>  > > >
>  > > > >
>  > > > > Alper
>  > > > >
>  > > > >
>  > > > >
>  > > > >>-----Original Message-----
>  > > > >>From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]
>  > > > >>Sent: Monday, June 19, 2006 6:17 PM
>  > > > >>To: Heejin Jang
>  > > > >>Cc: mip6@ietf.org; dhcwg@ietf.org
>  > > > >>Subject: Re: [Mip6] [Updated] DHCP Option for Home Information
>  > Discovery
>  > > > >>inMIPv6
>  > > > >>
>  > > > >>Heejin Jang wrote:
>  > > > >>
>  > > > >>>Hello folks,
>  > > > >>>We posted an I-D that proposes new DHCP Options for Home
>  > Information
>  > > > >>>Discovery in MIPv6.
>  > > > >>>
>  > > > >>>Kindly note that the previous version of this draft is
>  > > > >>>"draft-jang-dhc-haopt-02.txt" but the name is slightly changed
> into
>  > > > >>>"draft-jang-mip6-hiopt-00.txt" while keeping almost the same
>  > contents.
>  > > > >>>
>  > > > >>>The drafts referencing this draft such as
>  > > > >>>draft-ietf-mip6-bootstrapping-split-02.txt and
>  > > > >>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt need to be
>  > revised
>  > > > >>>accordingly.
>  > > > >>>
>  > > > >>>We would appreciate to hear your comments.
>  > > > >>
>  > > > >>when this draft was discussed in the MIP6 bootstrapping
>  > > > >>design team, many people wanted to integrate the two DHCP
>  > > > >>options into
>  > > > >>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt.
>  > > > >>this was mainly because the options defined in the document
>  > > > >>have limited applicability beyond the integrated scenario
>  > > > >>solution document. the only other mechanism is to manually
>  > > > >>configure the DHCP servers in the visited link with
>  > > > >>information like home agent address, home address and home
>  > > > >>prefix. this is a bad idea.
>  > > > >>
>  > > > >>there was some opposition and we never reached an agreement.
>  > > > >>
>  > > > >>so I suggest including these options into the integrated
>  > > > >>scenario solution document for these options to get
>  > > > >>standardized quickly.
>  > > > >>
>  > > > >>Vijay
>  > > > >>
>  > > > >>_______________________________________________
>  > > > >>Mip6 mailing list
>  > > > >>Mip6@ietf.org
>  > > > >>https://www1.ietf.org/mailman/listinfo/mip6
>  > > > >
>  > > > >
>  > >
>  > >
>  > >
>  > > _______________________________________________
>  > > dhcwg mailing list
>  > > dhcwg@ietf.org
>  > > https://www1.ietf.org/mailman/listinfo/dhcwg
>  > >
>
>
> _______________________________________________
> Mip6 mailing list
> Mip6@ietf.org
> https://www1.ietf.org/mailman/listinfo/mip6
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mip6 mailing list
> Mip6@ietf.org
> https://www1.ietf.org/mailman/listinfo/mip6




--0-1036218581-1151000882=:94453-- --===============1115676512== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1115676512==-- From mip6-bounces@ietf.org Thu Jun 22 14:45:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUBR-00066Z-5L; Thu, 22 Jun 2006 14:45:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUBQ-00063Z-BN for mip6@ietf.org; Thu, 22 Jun 2006 14:45:40 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUBP-00084y-Ld for mip6@ietf.org; Thu, 22 Jun 2006 14:45:40 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 11:45:36 -0700 Message-ID: <449AE4DB.3080901@azairenet.com> Date: Thu, 22 Jun 2006 11:43:39 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Behcet Sarikaya Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home Information Discovery inMIPv6 References: <20060622182802.96413.qmail@web60323.mail.yahoo.com> In-Reply-To: <20060622182802.96413.qmail@web60323.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2006 18:45:36.0689 (UTC) FILETIME=[0CF72A10:01C6962C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Behcet Sarikaya wrote: > If DHCP relay has the information locally cached, why should it relay > the request to DHCP server? DHCP server should be sync'ed, but that can > be done separately. thats how DHCP is defined. relay agents are supposed to relay the DHCP requests from clients to the appropriate DHCP servers and the replies from the servers to the clients. I don't know which DHCP RFC specifies the relay agent functionality. > DNS servers work this way also, right? DNS is a totally different protocol. no relevance here. Vijay > > Regards, > > --behcet > ----- Original Message ---- > From: Vijay Devarapalli > To: Behcet Sarikaya > Cc: Alper Yegin ; Gerardo Giaretta > ; mip6@ietf.org; Heejin Jang > ; dhcwg@ietf.org > Sent: Thursday, June 22, 2006 12:55:05 PM > Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home > Information Discovery inMIPv6 > > Behcet Sarikaya wrote: > > Hi Vijay, > > The idea in the present WiMAX document is quite simple: > > it uses EAP-PKMv2 (which is like 802.11i) authentication and during EAP > > transaction, they assume that AAA server determines that the MS is a > > CMIPv6 authorized user based on the AAA profile and it will include all > > the so-called bootstrapping info in the Access-Accept. Then MS can use > > RFC 3736 to make a DHCP Information Request to DHCP Relay colocated with > > NAS and use draft-jang (extended now with HoA) and receive all the info > > to configure MIP6. > > the DHCP Relay replies to the MN without relaying the DHCP > request from the MN to a DHCP server? this is not allowed > with the current IETF specs. > > > In this setup can you make a case for > > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt? > > as far as I am concerned, > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt > is the document that describes how to use DHCPv6 for MIPv6 > bootstrapping. as for the setup in the WiMAX NWG, it is > something that doesn't conform to the IETF DHCP specs. > > Vijay > > > > > Regards, > > > > --behcet > > > > ----- Original Message ---- > > From: Alper Yegin > > To: Gerardo Giaretta > > Cc: mip6@ietf.org; dhcwg@ietf.org; Heejin Jang > > Sent: Wednesday, June 21, 2006 4:48:10 PM > > Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home > > Information Discovery inMIPv6 > > > > Gerardo, > > > > I think it helps to understand the components of the full picture. > > > > [a] Delivery of the info from home AAA to the NAS > > [b] Delivery of the info from the NAS (DHCP relay) to the DHCP server. > > [c] Delivery of the info from the DHCP server to the DHCP client > > [d] Plumbing of all these components > > > > > > [a], [b], and [c] are all protocol work. [d] is just informational. > > > > The document draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt > covers [b] > > and [d]. > > > > WiMAX does not use [b]. For that there is no need to have a normative > > reference to draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. It > could > > have an informative reference to it, but it does not have to. > > > > Alper > > > > > > > > > > > > > > > -----Original Message----- > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > Sent: Wednesday, June 21, 2006 1:18 AM > > > To: Alper Yegin > > > Cc: Vijay Devarapalli; mip6@ietf.org; Heejin Jang; dhcwg@ietf.org > > > Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home > > Information > > > Discovery inMIPv6 > > > > > > Alper, > > > > > > just one question below in order to understand if there is a real > > > technical reason to keep the docs separated.. > > > > > > > > > But I hope this data point helps: WiMAX Forum NWG > architecture is > > > using > > > > > > draft-jang. > > > > > > > > > > in what context and how are they planning to use it? > > > > > > > > The MIP info is brought to the DHCP server via RADIUS and > delivered to > > > the > > > > MN via DHCP. > > > > > > > > > > Can you please explain which are the technical differences between the > > > solution in the DT draft for integrated scenario and the solution > > > developped in WiMAX? > > > > > > I guess in WiMAX MIP info are brought to DHCP relay (i.e. NAS) and > > > then draft-jang is applied. Is this really different from what is > > > described in the DT draft? > > > > > > --Gerardo > > > > > > > > the > > > > > WiMAX forum NWG can still use the DHCP options wherever > > > > > they are defined. > > > > > > > > Yes. And WiMAX Forum could also use it even if IETF had > > concatenated all > > > of > > > > the RFCs and I-Ds under a single document too.... This I-D being > > > referenced > > > > whereas the draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt > wasn't > > > is a > > > > solid proof that the former I-D is useful without having to be > > > integrated > > > > into the latter. > > > > > > > > > > > > > >>the only other mechanism is to manually > > > > > >>configure the DHCP servers in the visited link with > > > > > >>information like home agent address, home address and home > > > > > >>prefix. this is a bad idea. > > > > > > > > > > > > You know that one does not have to put DHCP servers on every subnet, > > > instead > > > > one can rely on DHCP relays. And that's the used technique for many > > > > enterprise networks. So, I don't see why this is a bad idea. > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > Vijay > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > >>-----Original Message----- > > > > > >>From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > > > > >>Sent: Monday, June 19, 2006 6:17 PM > > > > > >>To: Heejin Jang > > > > > >>Cc: mip6@ietf.org; dhcwg@ietf.org > > > > > >>Subject: Re: [Mip6] [Updated] DHCP Option for Home Information > > > Discovery > > > > > >>inMIPv6 > > > > > >> > > > > > >>Heejin Jang wrote: > > > > > >> > > > > > >>>Hello folks, > > > > > >>>We posted an I-D that proposes new DHCP Options for Home > > > Information > > > > > >>>Discovery in MIPv6. > > > > > >>> > > > > > >>>Kindly note that the previous version of this draft is > > > > > >>>"draft-jang-dhc-haopt-02.txt" but the name is slightly changed > > into > > > > > >>>"draft-jang-mip6-hiopt-00.txt" while keeping almost the same > > > contents. > > > > > >>> > > > > > >>>The drafts referencing this draft such as > > > > > >>>draft-ietf-mip6-bootstrapping-split-02.txt and > > > > > >>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt need to be > > > revised > > > > > >>>accordingly. > > > > > >>> > > > > > >>>We would appreciate to hear your comments. > > > > > >> > > > > > >>when this draft was discussed in the MIP6 bootstrapping > > > > > >>design team, many people wanted to integrate the two DHCP > > > > > >>options into > > > > > >>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. > > > > > >>this was mainly because the options defined in the document > > > > > >>have limited applicability beyond the integrated scenario > > > > > >>solution document. the only other mechanism is to manually > > > > > >>configure the DHCP servers in the visited link with > > > > > >>information like home agent address, home address and home > > > > > >>prefix. this is a bad idea. > > > > > >> > > > > > >>there was some opposition and we never reached an agreement. > > > > > >> > > > > > >>so I suggest including these options into the integrated > > > > > >>scenario solution document for these options to get > > > > > >>standardized quickly. > > > > > >> > > > > > >>Vijay > > > > > >> > > > > > >>_______________________________________________ > > > > > >>Mip6 mailing list > > > > > >>Mip6@ietf.org > > > > > >>https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > dhcwg mailing list > > > > dhcwg@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 17:27:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtWiN-0002Mf-S2; Thu, 22 Jun 2006 17:27:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtWiM-0002MZ-Ro for mip6@ietf.org; Thu, 22 Jun 2006 17:27:50 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtWiL-0005ti-Cx for mip6@ietf.org; Thu, 22 Jun 2006 17:27:50 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5MLRb7m017175; Fri, 23 Jun 2006 00:27:38 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 00:27:37 +0300 Received: from [127.0.0.1] ([10.241.53.137]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 23 Jun 2006 00:27:37 +0300 Message-ID: <449B0B43.8020202@iprg.nokia.com> Date: Thu, 22 Jun 2006 17:27:31 -0400 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mobopts] Re: [Mip6] MIP and Upper Layer Protocol interaction References: <20060620094301.AA1A.SHINTA@sfc.wide.ad.jp> <4498363E.4050702@azairenet.com> <20060620222316.AA37.SHINTA@sfc.wide.ad.jp> <4499C19F.3050707@azairenet.com> <69816405-8861-4B68-B9DA-6E133DFB4E73@iijlab.net> <449AD1BC.9070606@azairenet.com> In-Reply-To: <449AD1BC.9070606@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2006 21:27:37.0436 (UTC) FILETIME=[AEFB71C0:01C69642] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mip6@ietf.org, Keiichi SHIMA , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > >> Then, I have a simple question that why do we need to provide >> session continuity when home address changes? A home address is >> the identifier of the end node. If it changed, then the sessions >> related to the identifier should be terminated. > > > thats one option. another option is to let the use of old > HoA and the new HoA for a while. > yes, how to allow a previous HoA to be used while using a different HoA for new sessions. >> If we can change from one home address to another home address, then >> why do we need Mobile IP? >> >> Or does the discussion is for a new mobility mechanism other than >> MIP based? >> >> # or I am misunderstanding...? > > > we need to go back to the original mail from Rajeev and > figure out what problem we are trying to solve. this thread > has been too long. :) > I guess we never really ran into this issue within the realm of MIP.. However, there is no reason why you cannot use a different HoA. If you have dynamic HoA assignment which happens to take place when the MN is using a previous (dynamically assigned) HoA, you have this problem. We can argue that you can make the HoA effectively the same across the assignments, but that is not the only solution we should have. Anyway, this has been a good discussion so far. We should summarize and continue at Mobopts meeting in Montreal. Regards, -Rajeev > Vijay > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 21:15:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtaGk-0006fh-L4; Thu, 22 Jun 2006 21:15:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtaGi-0006dr-WE for mip6@ietf.org; Thu, 22 Jun 2006 21:15:33 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtaGh-00060r-HU for mip6@ietf.org; Thu, 22 Jun 2006 21:15:32 -0400 Received: from wei.isi.edu (wei.isi.edu [128.9.160.23]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5N1F0p00506 for ; Thu, 22 Jun 2006 18:15:00 -0700 (PDT) From: Wei Ye To: mip6@ietf.org Content-Type: text/plain; charset=UTF-8 Date: Thu, 22 Jun 2006 18:14:55 -0700 Message-Id: <1151025295.3070.56.camel@wei.isi.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: weiye@isi.edu Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by boreas.isi.edu id k5N1F0p00506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Subject: [Mip6] CFP: ACM Workshop on Underwater Networks (WUWNet 2006) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Our Apologies if you have received multiple copies of the CFP. Volkan Rodoplu and Wei Ye WUWNet 2006 Publicity Co-Chairs ----------------------------------------------------- The First ACM International Workshop on UnderWater Networks (WUWNet 2006) http://wuwnet.engr.uconn.edu/ In conjunction with ACM MobiCom 2006 September 25, 2006 Los Angeles, California, USA Sponsored by ACM SIGMOBILE Technical Co-Sponsorship: IEEE Oceanographic Engineering Society Financial Support Pending From: MIT SeaGrant, Boeing, DARPA ----------------------------------------------------- Important Dates *************** Submission deadline: June 30, 2006 Acceptance notification: July 28, 2006 Camera-ready version: August 11, 2006 Workshop date: September 25, 2006 Overview & Scope **************** The oceans cover 71% of the earth's surface and represent one of the least explored frontiers, yet the oceans are integral to climate regulation, nutrient production, oil retrieval and transportation. As such, there is significant interest in monitoring aquatic environments for scientific, environmental, commercial, safety, and military reasons. While there is a need for highly precise, real-time, fine grained spatio-temporal sampling of the ocean environment, current methods such as remote telemetry and sequential local sensing cannot satisfy current needs, let alone future needs. The notion of an underwater network is relatively new due to the lack of maturity of underwater acoustic communication. However, networks are necessary in order to achieve the monitoring goals noted above. The physical challenges of acoustic underwater communication require us to completely re-think how a network should be designed and deployed in this environment. Challenges to be overcome by underwater acoustic modem and network designers include: severely limited range-dependent bandwidth and attenuation, extensive time-varying multipath propagation, and low speed of sound propagation in water resulting in long propagation delays. Moreover, a unique feature of underwater networks is that the environment is constantly mobile, naturally causing the node passive mobility. All the above distinct features of underwater networks yield new challenges for every level of the network protocol suite. The goal of the proposed workshop is to bring together researchers and practioners in areas relevant to underwater networks. Thus, many layers of the "stack" from the physical layer to the application layer will be represented. The objective is to serve as a forum for presenting state of the art research, exchanging ideas and experiences, and facilitating interaction and collaboration. The workshop will span one day, including presentations of technical papers, tutorial/survey papers, a panel session and a poster/demo session. Submissions for regular technical papers and poster/demo extended abstracts should describe original research, not published or currently under review for other workshops, conferences, or journals. Topics of interest include, but are not limited to: - Network architecture design - Efficient acoustic communications - Cooperative underwater communications - Medium access control - Routing and forwarding - Reliable data transfer - Security and robustness - Power management - Data storage and management - Localization and synchronization - Data fusion, dissemination, tracking - Network modeling and simulations - Capacity analysis - New techniques for aquatic applications - New applications for underwater networks Submission Guidelines ********************* All paper submissions will be handled electronically. Papers must be in PDF format, no longer than 8 pages for regular papers (10 pages for tutorial/survey papers and 4 pages for poster/demo papers), and must follow ACM single-space, double-column format, 10 pt. Submitted papers will be judged based on their quality and novelty through a rigorous review process. Over-length papers will be automatically rejected. Detailed instructions for paper submission are posted on the workshop website. Organizing Committee ******************** General Co-chairs: Jun-Hong Cui (University of Connecticut) Urbashi Mitra (University of Southern California) Technical Program Co-chairs: Kevin Fall (Intel Research, Berkeley) Milica Stojanovic (MIT/WHOI) Publicity Co-chairs: Volkan Rodoplu (University of California, Santa Barbara) Wei Ye (USC/ISI) Treasurer: Shengli Zhou (University of Connecticut) Publications Chair: Xiuzhen Cheng (George Washington University) Technical Program Committee *************************** Ian Akyildiz (Georgia Institute of Technology) Lee Freitag (Woods Hole Oceanographic Institution) Mario Gerla (University of California, Los Angeles) Jo=C3=A3o Pedro Gomes (Instituto Superior T=C3=A9cnico, Portugal) John Heidemann (USC/ISI) Ronald A. Iltis (University of California, Santa Barbara) Jim Kurose (University of Massachusetts, Amherst) Mehul Motani (National University of Singapore) Joseph A. Rice (Naval Postgraduate School) Daniela Rus (Massachusetts Institute of Technology) Mani Srivastava (University of California, Los Angeles) Yongguang Zhang (Microsoft Research Asia, China) Michele Zorzi (Universita'di Ferrara, Italy) _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 22 22:22:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtbJS-0005tx-4K; Thu, 22 Jun 2006 22:22:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtbJQ-0005t0-I8; Thu, 22 Jun 2006 22:22:24 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtbJN-0006Y1-UF; Thu, 22 Jun 2006 22:22:24 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 21D7190045; Thu, 22 Jun 2006 22:22:17 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25628-01; Thu, 22 Jun 2006 22:22:15 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP; Thu, 22 Jun 2006 22:22:15 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Jun 2006 22:19:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home InformationDiscovery inMIPv6 Date: Thu, 22 Jun 2006 22:19:15 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D73C51DD@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home InformationDiscovery inMIPv6 Thread-Index: AcaWJ1At3e9b1E8eTceNcRUoaUj47wAQ6ahA From: "Chowdhury, Kuntal" To: "Vijay Devarapalli" , "Behcet Sarikaya" X-OriginalArrivalTime: 23 Jun 2006 02:19:16.0236 (UTC) FILETIME=[6D146CC0:01C6966B] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: mip6@ietf.org, Heejin Jang , dhcwg@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Sorry, I am not getting this. Why are we dragging WiMAX and 3GPP2 references to justify the need for basic DHCP op-codes for HoA/HL/HA info? draft-jang-mip6-hiopt-00.txt defines the DHCPv6 op-codes for HA, HoA and HL info. draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt is the MIP6 bootstrapping solution that leverages DHCPv6 for HA/HL bootstrapping.=20 There are tons of I-Ds and solutions in IETF that leverage other I-Ds. So, what is so special here? The decision to NOT merge these I-Ds was taken in the bootstrap DT. Why are we wasting people's time here to revisit basic decisions? -Kuntal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Thursday, June 22, 2006 12:55 PM > To: Behcet Sarikaya > Cc: mip6@ietf.org; Heejin Jang; dhcwg@ietf.org > Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home > InformationDiscovery inMIPv6 >=20 > Behcet Sarikaya wrote: > > Hi Vijay, > > The idea in the present WiMAX document is quite simple: > > it uses EAP-PKMv2 (which is like 802.11i) authentication and during EAP > > transaction, they assume that AAA server determines that the MS is a > > CMIPv6 authorized user based on the AAA profile and it will include all > > the so-called bootstrapping info in the Access-Accept. Then MS can use > > RFC 3736 to make a DHCP Information Request to DHCP Relay colocated with > > NAS and use draft-jang (extended now with HoA) and receive all the info > > to configure MIP6. >=20 > the DHCP Relay replies to the MN without relaying the DHCP > request from the MN to a DHCP server? this is not allowed > with the current IETF specs. >=20 > > In this setup can you make a case for > > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt? >=20 > as far as I am concerned, > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt > is the document that describes how to use DHCPv6 for MIPv6 > bootstrapping. as for the setup in the WiMAX NWG, it is > something that doesn't conform to the IETF DHCP specs. >=20 > Vijay >=20 > > > > Regards, > > > > --behcet > > > > ----- Original Message ---- > > From: Alper Yegin > > To: Gerardo Giaretta > > Cc: mip6@ietf.org; dhcwg@ietf.org; Heejin Jang > > Sent: Wednesday, June 21, 2006 4:48:10 PM > > Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home > > Information Discovery inMIPv6 > > > > Gerardo, > > > > I think it helps to understand the components of the full picture. > > > > [a] Delivery of the info from home AAA to the NAS > > [b] Delivery of the info from the NAS (DHCP relay) to the DHCP server. > > [c] Delivery of the info from the DHCP server to the DHCP client > > [d] Plumbing of all these components > > > > > > [a], [b], and [c] are all protocol work. [d] is just informational. > > > > The document draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt covers > [b] > > and [d]. > > > > WiMAX does not use [b]. For that there is no need to have a normative > > reference to draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. It > could > > have an informative reference to it, but it does not have to. > > > > Alper > > > > > > > > > > > > > > > -----Original Message----- > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > Sent: Wednesday, June 21, 2006 1:18 AM > > > To: Alper Yegin > > > Cc: Vijay Devarapalli; mip6@ietf.org; Heejin Jang; dhcwg@ietf.org > > > Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home > > Information > > > Discovery inMIPv6 > > > > > > Alper, > > > > > > just one question below in order to understand if there is a real > > > technical reason to keep the docs separated.. > > > > > > > > > But I hope this data point helps: WiMAX Forum NWG architecture > is > > > using > > > > > > draft-jang. > > > > > > > > > > in what context and how are they planning to use it? > > > > > > > > The MIP info is brought to the DHCP server via RADIUS and delivered > to > > > the > > > > MN via DHCP. > > > > > > > > > > Can you please explain which are the technical differences between > the > > > solution in the DT draft for integrated scenario and the solution > > > developped in WiMAX? > > > > > > I guess in WiMAX MIP info are brought to DHCP relay (i.e. NAS) and > > > then draft-jang is applied. Is this really different from what is > > > described in the DT draft? > > > > > > --Gerardo > > > > > > > > the > > > > > WiMAX forum NWG can still use the DHCP options wherever > > > > > they are defined. > > > > > > > > Yes. And WiMAX Forum could also use it even if IETF had > > concatenated all > > > of > > > > the RFCs and I-Ds under a single document too.... This I-D being > > > referenced > > > > whereas the draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt > wasn't > > > is a > > > > solid proof that the former I-D is useful without having to be > > > integrated > > > > into the latter. > > > > > > > > > > > > > >>the only other mechanism is to manually > > > > > >>configure the DHCP servers in the visited link with > > > > > >>information like home agent address, home address and home > > > > > >>prefix. this is a bad idea. > > > > > > > > > > > > You know that one does not have to put DHCP servers on every subnet, > > > instead > > > > one can rely on DHCP relays. And that's the used technique for many > > > > enterprise networks. So, I don't see why this is a bad idea. > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > Vijay > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > >>-----Original Message----- > > > > > >>From: Vijay Devarapalli > [mailto:vijay.devarapalli@azairenet.com] > > > > > >>Sent: Monday, June 19, 2006 6:17 PM > > > > > >>To: Heejin Jang > > > > > >>Cc: mip6@ietf.org; dhcwg@ietf.org > > > > > >>Subject: Re: [Mip6] [Updated] DHCP Option for Home Information > > > Discovery > > > > > >>inMIPv6 > > > > > >> > > > > > >>Heejin Jang wrote: > > > > > >> > > > > > >>>Hello folks, > > > > > >>>We posted an I-D that proposes new DHCP Options for Home > > > Information > > > > > >>>Discovery in MIPv6. > > > > > >>> > > > > > >>>Kindly note that the previous version of this draft is > > > > > >>>"draft-jang-dhc-haopt-02.txt" but the name is slightly changed > > into > > > > > >>>"draft-jang-mip6-hiopt-00.txt" while keeping almost the same > > > contents. > > > > > >>> > > > > > >>>The drafts referencing this draft such as > > > > > >>>draft-ietf-mip6-bootstrapping-split-02.txt and > > > > > >>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt need to be > > > revised > > > > > >>>accordingly. > > > > > >>> > > > > > >>>We would appreciate to hear your comments. > > > > > >> > > > > > >>when this draft was discussed in the MIP6 bootstrapping > > > > > >>design team, many people wanted to integrate the two DHCP > > > > > >>options into > > > > > >>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt. > > > > > >>this was mainly because the options defined in the document > > > > > >>have limited applicability beyond the integrated scenario > > > > > >>solution document. the only other mechanism is to manually > > > > > >>configure the DHCP servers in the visited link with > > > > > >>information like home agent address, home address and home > > > > > >>prefix. this is a bad idea. > > > > > >> > > > > > >>there was some opposition and we never reached an agreement. > > > > > >> > > > > > >>so I suggest including these options into the integrated > > > > > >>scenario solution document for these options to get > > > > > >>standardized quickly. > > > > > >> > > > > > >>Vijay > > > > > >> > > > > > >>_______________________________________________ > > > > > >>Mip6 mailing list > > > > > >>Mip6@ietf.org > > > > > >>https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > dhcwg mailing list > > > > dhcwg@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 23 03:34:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtgBa-00059j-K7; Fri, 23 Jun 2006 03:34:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtgBZ-00059e-Lh for mip6@ietf.org; Fri, 23 Jun 2006 03:34:37 -0400 Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtgBY-0001ya-9X for mip6@ietf.org; Fri, 23 Jun 2006 03:34:37 -0400 Received: from rly35d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly35d.srv.mailcontrol.com (MailControl) with ESMTP id k5N7YZ1r032331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Jun 2006 08:34:35 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly35d.srv.mailcontrol.com (MailControl) id k5N7Y3r0031687 for mip6@ietf.org; Fri, 23 Jun 2006 08:34:03 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly35d-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id k5N7Y3Xj031638; Fri, 23 Jun 2006 08:34:03 +0100 (BST) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 4e83_09a8d366_0285_11db_814d_0030482aac25; Fri, 23 Jun 2006 08:53:55 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2006062309335932-774067 ; Fri, 23 Jun 2006 09:33:59 +0200 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: 0.596,BAYES_00: -1.665, SARE_RECV_ADDR: 0.027 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Fri, 23 Jun 2006 09:37:33 +0200 MIME-Version: 1.0 Subject: RE: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <4D2F935F08D41A4C8866693F4F0D7C4FC562B6@lan-ex-01.panasonic.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt Thread-Index: AcaUoMGTw2sK4nIcTRa89iWS3WtgYgAX1ETgAGU4tsA= To: "Brian Haley" Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4FC564FB@lan-ex-01.panasonic.de> Date: Fri, 23 Jun 2006 09:33:54 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MailControl A-07-00-10 (www.mailcontrol.com) on 10.68.1.145 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Brian, In my last mail I described scenarios that the current draft does not support (see snippet below) and sketched an extension to support such scenarios. What do you and the authors of the draft think about this? For instance, shouldn't load balancing between HAs serving different links be supported? MN could obtain a new HoA from the new HA and keep the old HA/HoA as secondary for existing sessions only (e.g., old IPv6 HoA is moved to deprecated state, new one to preferred state)?=20 - Kilian > Scenarios > I have in mind are that the network (i.e., HA) can direct the MN to > another HA on a different link (e.g., to a more local HA), which is > better with respect to optimized routing or for load balancing between > HAs on different links.=20 > ... > The modification I had in mind just extends the applicability of the > switch mechanism by allowing the HA to send switch messages to direct > the MN to a HA serving a different link and continue to serve as > secondary HA. >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 23 03:44:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtgLH-0000GL-9K; Fri, 23 Jun 2006 03:44:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtgLF-0000GA-QY for mip6@ietf.org; Fri, 23 Jun 2006 03:44:37 -0400 Received: from static-ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FtgLE-00062i-1k for mip6@ietf.org; Fri, 23 Jun 2006 03:44:37 -0400 Received: (qmail 2471 invoked from network); 23 Jun 2006 07:44:32 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;473b0c3da25e9ca60cd2d3197c03c8d6; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by static-ip-11-194-65-202.rev.dyxnet.com with SMTP; 23 Jun 2006 07:44:32 -0000 Received: (qmail 29529 invoked from network); 23 Jun 2006 07:44:29 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;351d0769a75deb15e39bdf3f94d2950b; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 23 Jun 2006 07:44:29 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 15:41:26 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain;charset="utf-7" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 23 Jun 2006 15:41:14 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38FD20D5@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: +AFs-Mip6+AF0- RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt Thread-Index: AcaUoMGTw2sK4nIcTRa89iWS3WtgYgAX1ETgAGU4tsAAANSUAA+AD0APQ- From: "+ACI-DENG, HUI -HCHBJ+ACI-" To: "Kilian Weniger" , "Brian Haley" X-OriginalArrivalTime: 23 Jun 2006 07:41:26.0757 (UTC) FILETIME=[6EF7D950:01C69698] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1151048669.701-29523-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.02/0.08 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1151048671.968-2445-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.01/0.01 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: mip6@ietf.org Subject: [Mip6] RE: +AFs-Mip6+AF0- RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Could you help to elaborate how IKE/IPsec SA could work in this scenario? is that session based or address based? -Hui +AD4- -----Original Message----- +AD4- From: Kilian Weniger +AFs-mailto:Kilian.Weniger+AEA-eu.panasonic.com+AF0- +AD4- Sent: 2006+XnQ-6+Zwg-23+ZeU- 15:34 +AD4- To: Brian Haley +AD4- Cc: mip6+AEA-ietf.org +AD4- Subject: RE: +AFs-Mip6+AF0- RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt +AD4- +AD4- +AD4- Brian, +AD4- +AD4- In my last mail I described scenarios that the current draft +AD4- does not support (see snippet below) and sketched an +AD4- extension to support such scenarios. What do you and the +AD4- authors of the draft think about this? For instance, +AD4- shouldn't load balancing between HAs serving different links +AD4- be supported? MN could obtain a new HoA from the new HA and +AD4- keep the old HA/HoA as secondary for existing sessions only +AD4- (e.g., old IPv6 HoA is moved to deprecated state, new one to +AD4- preferred state)? +AD4- +AD4- - Kilian +AD4- +AD4- +AD4- +AD4- Scenarios +AD4- +AD4- I have in mind are that the network (i.e., HA) can direct the MN to +AD4- +AD4- another HA on a different link (e.g., to a more local HA), which is +AD4- +AD4- better with respect to optimized routing or for load +AD4- balancing between +AD4- +AD4- HAs on different links. ... +AD4- +AD4- The modification I had in mind just extends the applicability of the +AD4- +AD4- switch mechanism by allowing the HA to send switch messages +AD4- to direct +AD4- +AD4- the MN to a HA serving a different link and continue to serve as +AD4- +AD4- secondary HA. +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- +AD4- Mip6 mailing list +AD4- Mip6+AEA-ietf.org +AD4- https://www1.ietf.org/mailman/listinfo/mip6 +AD4- Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 23 04:05:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftgf9-0004UP-Gc; Fri, 23 Jun 2006 04:05:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftgf8-0004UK-Ih for mip6@ietf.org; Fri, 23 Jun 2006 04:05:10 -0400 Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftgf7-0008Am-31 for mip6@ietf.org; Fri, 23 Jun 2006 04:05:10 -0400 Received: from rly19d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly19d.srv.mailcontrol.com (MailControl) with ESMTP id k5N858mf029510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Jun 2006 09:05:08 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly19d.srv.mailcontrol.com (MailControl) id k5N84Beu027707 for mip6@ietf.org; Fri, 23 Jun 2006 09:04:11 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly19d-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id k5N84BDa027693; Fri, 23 Jun 2006 09:04:11 +0100 (BST) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 4ed9_3f8516b2_0289_11db_8623_0030482aac25; Fri, 23 Jun 2006 09:24:03 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2006062310040483-776297 ; Fri, 23 Jun 2006 10:04:04 +0200 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: 0.589,BAYES_00: -1.665, SARE_RECV_ADDR: 0.027 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Fri, 23 Jun 2006 10:07:37 +0200 MIME-Version: 1.0 Subject: RE: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <834B54D356AA8F46B9B233DD88BEAA38FD20D5@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt Thread-Index: AcaUoMGTw2sK4nIcTRa89iWS3WtgYgAX1ETgAGU4tsAAANSUAA+AD0APD39tohA= To: "DENG, HUI -HCHBJ" , "Kilian Weniger" , "Brian Haley" Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4FC5650A@lan-ex-01.panasonic.de> Date: Fri, 23 Jun 2006 10:03:58 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-2022-JP" X-Scanned-By: MailControl A-07-00-10 (www.mailcontrol.com) on 10.68.1.129 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hui, The MN would setup Ipsec SAs using IKE with the second HA (which is located on a different link than the first HA). The new Ipsec Sas would be based on the new HoA (whose prefix is not served by the first HA). The IPSec Sas with the first (old) HA are still setup based on the old HoA. Can you elaborate what would be the issue with that? -Kilian > -----Original Message----- > From: "DENG, HUI -HCHBJ" [mailto:hdeng@hitachi.cn] > Sent: Freitag, 23. Juni 2006 09:41 > To: Kilian Weniger; Brian Haley > Cc: mip6@ietf.org > Subject: RE: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt > > > Could you help to elaborate how IKE/IPsec SA could work in > this scenario? > is that session based or address based? > > -Hui > > > -----Original Message----- > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > Sent: 2006年6月23日 15:34 > > To: Brian Haley > > Cc: mip6@ietf.org > > Subject: RE: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt > > > > > > Brian, > > > > In my last mail I described scenarios that the current draft > > does not support (see snippet below) and sketched an > > extension to support such scenarios. What do you and the > > authors of the draft think about this? For instance, > > shouldn't load balancing between HAs serving different links > > be supported? MN could obtain a new HoA from the new HA and > > keep the old HA/HoA as secondary for existing sessions only > > (e.g., old IPv6 HoA is moved to deprecated state, new one to > > preferred state)? > > > > - Kilian > > > > > > > Scenarios > > > I have in mind are that the network (i.e., HA) can direct > the MN to > > > another HA on a different link (e.g., to a more local > HA), which is > > > better with respect to optimized routing or for load > > balancing between > > > HAs on different links. ... > > > The modification I had in mind just extends the > applicability of the > > > switch mechanism by allowing the HA to send switch messages > > to direct > > > the MN to a HA serving a different link and continue to serve as > > > secondary HA. > > > > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > Disclaimer: > The contents of this e-mail, and its attachments, if any, are > confidential and may be protected > by law against any unauthorized use. If you have received > this e-mail by mistake or have > reason to believe that you are not the intended recipient, > please notify the sender by reply > e-mail as soon as possible and delete it from your computer > system immediately thereafter. > If you are not the intended recipient, you must not copy this > e-mail or attachment or disclose > the contents to any other person. While we have made every > effort to keep our network virus free, > we take no responsibility for any computer virus which might > be transferred by way of this e-mail. > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 23 09:37:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtlqD-0004Ys-J2; Fri, 23 Jun 2006 09:36:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtlpN-0003sh-0n for mip6@ietf.org; Fri, 23 Jun 2006 09:36:05 -0400 Received: from static-ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ftler-0005FD-Ek for mip6@ietf.org; Fri, 23 Jun 2006 09:25:14 -0400 Received: (qmail 17771 invoked from network); 23 Jun 2006 13:19:40 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;a322c65271c749630f2178a89b992b0e; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by static-ip-11-194-65-202.rev.dyxnet.com with SMTP; 23 Jun 2006 13:19:40 -0000 Received: (qmail 7352 invoked from network); 23 Jun 2006 13:19:40 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;878c673c4e2f1d3b5e00c16f25ee0042; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 23 Jun 2006 13:19:40 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 21:19:40 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain;charset="utf-7" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 23 Jun 2006 21:19:37 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38019234F6@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: +AFs-Mip6+AF0- RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt Thread-Index: AcaUoMGTw2sK4nIcTRa89iWS3WtgYgAX1ETgAGU4tsAAANSUAA+AD0APD39tohAe9Cb8YAAPQA9- From: "+ACI-DENG, HUI -HCHBJ+ACI-" To: "Kilian Weniger" , "Brian Haley" X-OriginalArrivalTime: 23 Jun 2006 13:19:40.0126 (UTC) FILETIME=[AEC237E0:01C696C7] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1151068780.350-7349-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.02/0.06 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1151068780.513-17766-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.02/0.01 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: mip6@ietf.org Subject: [Mip6] RE: +AFs-Mip6+AF0- RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, Kilian, I start to understood what you mean here, You would like to do geographical different home prefix load balance, I am a little thinking about this usage in the real word. but one thing interested me is that your session is still kept in the previous home agent, is it called load balance? Secondly, how could MN notify CN about its HoA changing. I suggest that if possible you could write up your solution. Then we could figure out its applicability. Thanks -Hui +AD4- -----Original Message----- +AD4- From: Kilian Weniger +AFs-mailto:Kilian.Weniger+AEA-eu.panasonic.com+AF0- +AD4- Sent: 2006+XnQ-6+Zwg-23+ZeU- 16:04 +AD4- To: DENG, HUI -HCHBJ+ADs- Kilian Weniger+ADs- Brian Haley +AD4- Cc: mip6+AEA-ietf.org +AD4- Subject: RE: +AFs-Mip6+AF0- RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt +AD4- +AD4- +AD4- Hi Hui, +AD4- +AD4- The MN would setup Ipsec SAs using IKE with the second HA +AD4- (which is located on a different link than the first HA). The +AD4- new Ipsec Sas would be based on the new HoA (whose prefix is +AD4- not served by the first HA). The IPSec Sas with the first +AD4- (old) HA are still setup based on the old HoA. Can you +AD4- elaborate what would be the issue with that? +AD4- +AD4- -Kilian +AD4- +AD4- +AD4- -----Original Message----- +AD4- +AD4- From: +ACI-DENG, HUI -HCHBJ+ACI- +AFs-mailto:hdeng+AEA-hitachi.cn+AF0- +AD4- +AD4- Sent: Freitag, 23. Juni 2006 09:41 +AD4- +AD4- To: Kilian Weniger+ADs- Brian Haley +AD4- +AD4- Cc: mip6+AEA-ietf.org +AD4- +AD4- Subject: RE: +AFs-Mip6+AF0- RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Could you help to elaborate how IKE/IPsec SA could work in +AD4- +AD4- this scenario? +AD4- +AD4- is that session based or address based? +AD4- +AD4- +AD4- +AD4- -Hui +AD4- +AD4- +AD4- +AD4- +AD4- -----Original Message----- +AD4- +AD4- +AD4- From: Kilian Weniger +AFs-mailto:Kilian.Weniger+AEA-eu.panasonic.com+AF0- +AD4- +AD4- +AD4- Sent: 2006+XnQ-6+Zwg-23+ZeU- 15:34 +AD4- +AD4- +AD4- To: Brian Haley +AD4- +AD4- +AD4- Cc: mip6+AEA-ietf.org +AD4- +AD4- +AD4- Subject: RE: +AFs-Mip6+AF0- RE: I-D +AD4- ACTION:draft-ietf-mip6-ha-switch-00.txt +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Brian, +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- In my last mail I described scenarios that the current draft +AD4- +AD4- +AD4- does not support (see snippet below) and sketched an +AD4- +AD4- +AD4- extension to support such scenarios. What do you and the +AD4- +AD4- +AD4- authors of the draft think about this? For instance, +AD4- +AD4- +AD4- shouldn't load balancing between HAs serving different links +AD4- +AD4- +AD4- be supported? MN could obtain a new HoA from the new HA and +AD4- +AD4- +AD4- keep the old HA/HoA as secondary for existing sessions only +AD4- +AD4- +AD4- (e.g., old IPv6 HoA is moved to deprecated state, new one to +AD4- +AD4- +AD4- preferred state)? +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- - Kilian +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Scenarios +AD4- +AD4- +AD4- +AD4- I have in mind are that the network (i.e., HA) can direct +AD4- +AD4- the MN to +AD4- +AD4- +AD4- +AD4- another HA on a different link (e.g., to a more local +AD4- +AD4- HA), which is +AD4- +AD4- +AD4- +AD4- better with respect to optimized routing or for load +AD4- +AD4- +AD4- balancing between +AD4- +AD4- +AD4- +AD4- HAs on different links. ... +AD4- +AD4- +AD4- +AD4- The modification I had in mind just extends the +AD4- +AD4- applicability of the +AD4- +AD4- +AD4- +AD4- switch mechanism by allowing the HA to send switch messages +AD4- +AD4- +AD4- to direct +AD4- +AD4- +AD4- +AD4- the MN to a HA serving a different link and continue to +AD4- serve as +AD4- +AD4- +AD4- +AD4- secondary HA. +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8-+AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8- +AD4- +AD4- +AD4- Mip6 mailing list +AD4- +AD4- +AD4- Mip6+AEA-ietf.org +AD4- +AD4- +AD4- https://www1.ietf.org/mailman/listinfo/mip6 +AD4- +AD4- +AD4- +AD4- +AD4- Disclaimer: +AD4- +AD4- The contents of this e-mail, and its attachments, if any, are +AD4- +AD4- confidential and may be protected +AD4- +AD4- by law against any unauthorized use. If you have received +AD4- +AD4- this e-mail by mistake or have +AD4- +AD4- reason to believe that you are not the intended recipient, +AD4- +AD4- please notify the sender by reply +AD4- +AD4- e-mail as soon as possible and delete it from your computer +AD4- +AD4- system immediately thereafter. +AD4- +AD4- If you are not the intended recipient, you must not copy this +AD4- +AD4- e-mail or attachment or disclose +AD4- +AD4- the contents to any other person. While we have made every +AD4- +AD4- effort to keep our network virus free, +AD4- +AD4- we take no responsibility for any computer virus which might +AD4- +AD4- be transferred by way of this e-mail. +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 23 10:21:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtmXV-0006lq-K8; Fri, 23 Jun 2006 10:21:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtmXU-0006lk-OM for mip6@ietf.org; Fri, 23 Jun 2006 10:21:40 -0400 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtmXT-0000j2-9L for mip6@ietf.org; Fri, 23 Jun 2006 10:21:40 -0400 Received: from smtp2.fc.hp.com (smtp.fc.hp.com [15.11.136.114]) by atlrel9.hp.com (Postfix) with ESMTP id 8F9AF34707; Fri, 23 Jun 2006 10:21:38 -0400 (EDT) Received: from [16.116.96.215] (spaceshipone.zko.hp.com [16.116.96.215]) by smtp2.fc.hp.com (Postfix) with ESMTP id A8C441EC11; Fri, 23 Jun 2006 14:21:37 +0000 (UTC) Message-ID: <449BF8F0.8090304@hp.com> Date: Fri, 23 Jun 2006 10:21:36 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: Kilian Weniger References: <834B54D356AA8F46B9B233DD88BEAA38019234F6@hcbjdc2> In-Reply-To: <834B54D356AA8F46B9B233DD88BEAA38019234F6@hcbjdc2> Content-Type: text/plain; charset=UTF-7 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: mip6@ietf.org, "+ACI-DENG, HUI -HCHBJ+ACI-" Subject: [Mip6] Re: +AFs-Mip6+AF0- RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Kilian, This is starting to sound something like HA-HA, draft-wakikawa-mip6-nemo-haha-01.txt. The scenario you describe isn't restricted by RFC 3775, you can have multiple home addresses with multiple HAs if you like. You could then use different HoAs for talking to different CNs based on some preferences you have configured. As Hui mentioned - if you could write this up it would help us understand what you're trying to do and determine if the HA-switch draft is the right place to do it. Thanks, -Brian +ACs-ACI-DENG, HUI -HCHBJ+ACs-ACI- wrote: > Hi, Kilian, >=20 > I start to understood what you mean here, > You would like to do geographical different home prefix load balance, > I am a little thinking about this usage in the real word. >=20 > but one thing interested me is that > your session is still kept in the previous home agent, is it called loa= d balance? >=20 > Secondly, how could MN notify CN about its HoA changing. >=20 > I suggest that if possible you could write up your solution. > Then we could figure out its applicability. >=20 > Thanks >=20 > -Hui >=20 >=20 >=20 >> -----Original Message----- >> From: Kilian Weniger [mailto:Kilian.Weniger+AEA-eu.panasonic.com]=20 >> Sent: 2006+XnQ-6+Zwg-23+ZeU- 16:04 >> To: DENG, HUI -HCHBJ; Kilian Weniger; Brian Haley >> Cc: mip6+AEA-ietf.org >> Subject: RE: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt >> >> >> Hi Hui, >> >> The MN would setup Ipsec SAs using IKE with the second HA=20 >> (which is located on a different link than the first HA). The=20 >> new Ipsec Sas would be based on the new HoA (whose prefix is=20 >> not served by the first HA). The IPSec Sas with the first=20 >> (old) HA are still setup based on the old HoA. Can you=20 >> elaborate what would be the issue with that? >> >> -Kilian >> >>> -----Original Message----- >>> From: "DENG, HUI -HCHBJ" [mailto:hdeng+AEA-hitachi.cn] >>> Sent: Freitag, 23. Juni 2006 09:41 >>> To: Kilian Weniger; Brian Haley >>> Cc: mip6+AEA-ietf.org >>> Subject: RE: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt >>> >>> >>> Could you help to elaborate how IKE/IPsec SA could work in >>> this scenario? >>> is that session based or address based? >>> >>> -Hui >>> >>>> -----Original Message----- >>>> From: Kilian Weniger [mailto:Kilian.Weniger+AEA-eu.panasonic.com] >>>> Sent: 2006+XnQ-6+Zwg-23+ZeU- 15:34 >>>> To: Brian Haley >>>> Cc: mip6+AEA-ietf.org >>>> Subject: RE: [Mip6] RE: I-D=20 >> ACTION:draft-ietf-mip6-ha-switch-00.txt >>>> >>>> Brian, >>>> >>>> In my last mail I described scenarios that the current draft >>>> does not support (see snippet below) and sketched an=20 >>>> extension to support such scenarios. What do you and the=20 >>>> authors of the draft think about this? For instance,=20 >>>> shouldn't load balancing between HAs serving different links=20 >>>> be supported? MN could obtain a new HoA from the new HA and=20 >>>> keep the old HA/HoA as secondary for existing sessions only=20 >>>> (e.g., old IPv6 HoA is moved to deprecated state, new one to=20 >>>> preferred state)?=20 >>>> >>>> - Kilian >>>> >>>> >>>>> Scenarios >>>>> I have in mind are that the network (i.e., HA) can direct >>> the MN to >>>>> another HA on a different link (e.g., to a more local >>> HA), which is >>>>> better with respect to optimized routing or for load >>>> balancing between >>>>> HAs on different links. ... >>>>> The modification I had in mind just extends the >>> applicability of the >>>>> switch mechanism by allowing the HA to send switch messages >>>> to direct >>>>> the MN to a HA serving a different link and continue to=20 >> serve as=20 >>>>> secondary HA. >>>>> >>>> >>>> >>>> >>>> +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8= AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- >>>> Mip6 mailing list >>>> Mip6+AEA-ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>> >>> Disclaimer: >>> The contents of this e-mail, and its attachments, if any, are >>> confidential and may be protected >>> by law against any unauthorized use. If you have received=20 >>> this e-mail by mistake or have >>> reason to believe that you are not the intended recipient,=20 >>> please notify the sender by reply >>> e-mail as soon as possible and delete it from your computer=20 >>> system immediately thereafter. >>> If you are not the intended recipient, you must not copy this=20 >>> e-mail or attachment or disclose >>> the contents to any other person. While we have made every=20 >>> effort to keep our network virus free, >>> we take no responsibility for any computer virus which might=20 >>> be transferred by way of this e-mail. >>> >>> >> > Disclaimer: > The contents of this e-mail, and its attachments, if any, are confident= ial and may be protected > by law against any unauthorized use. If you have received this e-mail = by mistake or have > reason to believe that you are not the intended recipient, please notif= y the sender by reply > e-mail as soon as possible and delete it from your computer system imme= diately thereafter. > If you are not the intended recipient, you must not copy this e-mail or= attachment or disclose > the contents to any other person. While we have made every effort to k= eep our network virus free, > we take no responsibility for any computer virus which might be transfe= rred by way of this e-mail. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 23 11:34:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftng5-00052s-6l; Fri, 23 Jun 2006 11:34:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftng3-00052h-Tn for mip6@ietf.org; Fri, 23 Jun 2006 11:34:35 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftng2-0004rD-Ki for mip6@ietf.org; Fri, 23 Jun 2006 11:34:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home InformationDiscovery inMIPv6 Date: Fri, 23 Jun 2006 08:34:32 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home InformationDiscovery inMIPv6 Thread-Index: AcaWJ1At3e9b1E8eTceNcRUoaUj47wAQ6ahAABuse+A= From: "Vijay Devarapalli" To: "Chowdhury, Kuntal" , "Behcet Sarikaya" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: mip6@ietf.org, Heejin Jang X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org dropped the DHC WG from the cc list. =20 > Sorry, I am not getting this. Why are we dragging WiMAX and 3GPP2 > references to justify the need for basic DHCP op-codes for HoA/HL/HA > info? well, some folks were trying to justify=20 draft-jang-mip6-hiopt-00.txt by mentioning WiMAX. perhaps you should go through the entire thread. > draft-jang-mip6-hiopt-00.txt defines the DHCPv6 op-codes for=20 > HA, HoA and > HL info. it does more. it tries to also specify a DHCP based MIP6 bootstrapping protocol. > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt is the MIP6 > bootstrapping solution that leverages DHCPv6 for HA/HL bootstrapping.=20 yes. my point exactly. > There are tons of I-Ds and solutions in IETF that leverage other I-Ds. > So, what is so special here? The decision to NOT merge these I-Ds was > taken in the bootstrap DT. Why are we wasting people's time here to > revisit basic decisions? uh?? we *couldn't* reach a conclusion. check the archives. we decided to come back to this later. big concern is that there can't be two drafts that both specify how to use DHCP for MIP6 bootstrapping. my suggestion is to fold the DHCP options into the current working document and have WiMAX and 3GPP2=20 refer to this draft.=20 Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 23 12:50:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtorT-0007TK-WA; Fri, 23 Jun 2006 12:50:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtorS-0007TD-H1 for mip6@ietf.org; Fri, 23 Jun 2006 12:50:26 -0400 Received: from web60312.mail.yahoo.com ([209.73.178.135]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FtorR-0002qy-6A for mip6@ietf.org; Fri, 23 Jun 2006 12:50:26 -0400 Received: (qmail 10182 invoked by uid 60001); 23 Jun 2006 16:50:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AUY/zCrAffkWCrnuNpRT1Yj7M1cM6zE3K2DhsC2NVlgNKg4+qzVpcSky8oZYjEUtgs6cwwloSmXv3c47AVsSA0SejuLHNse4h+jqT935cFSt7MYOnLO2dhnzHEUZ5Ylewd2n9lAyl6j3zijity5BA+o+8nf5j/EtQhvJfM1VZwU= ; Message-ID: <20060623165024.10180.qmail@web60312.mail.yahoo.com> Received: from [12.129.211.52] by web60312.mail.yahoo.com via HTTP; Fri, 23 Jun 2006 09:50:24 PDT Date: Fri, 23 Jun 2006 09:50:24 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home InformationDiscovery inMIPv6 To: Vijay Devarapalli In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0393158979==" Errors-To: mip6-bounces@ietf.org --===============0393158979== Content-Type: multipart/alternative; boundary="0-647899942-1151081424=:9071" --0-647899942-1151081424=:9071 Content-Type: text/plain; charset=us-ascii ----- Original Message ---- From: Vijay Devarapalli To: "Chowdhury, Kuntal" ; Behcet Sarikaya Cc: mip6@ietf.org; Heejin Jang Sent: Friday, June 23, 2006 10:34:32 AM Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home InformationDiscovery inMIPv6 dropped the DHC WG from the cc list. > Sorry, I am not getting this. Why are we dragging WiMAX and 3GPP2 > references to justify the need for basic DHCP op-codes for HoA/HL/HA > info? well, some folks were trying to justify draft-jang-mip6-hiopt-00.txt by mentioning WiMAX. perhaps you should go through the entire thread. > draft-jang-mip6-hiopt-00.txt defines the DHCPv6 op-codes for > HA, HoA and > HL info. it does more. it tries to also specify a DHCP based MIP6 bootstrapping protocol. > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt is the MIP6 > bootstrapping solution that leverages DHCPv6 for HA/HL bootstrapping. yes. my point exactly. > There are tons of I-Ds and solutions in IETF that leverage other I-Ds. > So, what is so special here? The decision to NOT merge these I-Ds was > taken in the bootstrap DT. Why are we wasting people's time here to > revisit basic decisions? uh?? we *couldn't* reach a conclusion. check the archives. we decided to come back to this later. big concern is that there can't be two drafts that both specify how to use DHCP for MIP6 bootstrapping. my suggestion is to fold the DHCP options into the current working document and have WiMAX and 3GPP2 refer to this draft. ==> Or come up with a different solution and don't bother merging, like in HA Reliability DT. ==>Regards, ==>--behcet Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --0-647899942-1151081424=:9071 Content-Type: text/html; charset=us-ascii


----- Original Message ----
From: Vijay Devarapalli <Vijay.Devarapalli@AzaireNet.com>
To: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>; Behcet Sarikaya <sarikaya@ieee.org>
Cc: mip6@ietf.org; Heejin Jang <heejin.jang@samsung.com>
Sent: Friday, June 23, 2006 10:34:32 AM
Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home InformationDiscovery inMIPv6

dropped the DHC WG from the cc list.

> Sorry, I am not getting this. Why are we dragging WiMAX and 3GPP2
> references to justify the need for basic DHCP op-codes for HoA/HL/HA
> info?

well, some folks were trying to justify
draft-jang-mip6-hiopt-00.txt by mentioning WiMAX.
perhaps you should go through the entire thread.

> draft-jang-mip6-hiopt-00.txt defines the DHCPv6 op-codes for
> HA, HoA and
> HL info.

it does more. it tries to also specify a DHCP based
MIP6 bootstrapping protocol.

> draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt is the MIP6
> bootstrapping solution that leverages DHCPv6 for HA/HL bootstrapping.

yes. my point exactly.

> There are tons of I-Ds and solutions in IETF that leverage other I-Ds.
> So, what is so special here? The decision to NOT merge these I-Ds was
> taken in the bootstrap DT. Why are we wasting people's time here to
> revisit basic decisions?

uh?? we *couldn't* reach a conclusion. check the
archives. we decided to come back to this later.

big concern is that there can't be two drafts that
both specify how to use DHCP for MIP6 bootstrapping.
my suggestion is to fold the DHCP options into the
current working document and have WiMAX and 3GPP2
refer to this draft.
==> Or come up with a different solution and don't bother merging, like in HA Reliability DT.
==>Regards,
==>--behcet

Vijay

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6

--0-647899942-1151081424=:9071-- --===============0393158979== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0393158979==-- From mip6-bounces@ietf.org Fri Jun 23 15:50:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftrfz-0003dR-BX; Fri, 23 Jun 2006 15:50:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtrfH-0002Lt-SC; Fri, 23 Jun 2006 15:50:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtrfG-0004vR-KU; Fri, 23 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5NJo207020744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtrfG-0003BD-4n; Fri, 23 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 23 Jun 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-location-privacy-ps-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : IP Address Location Privacy and Mobile IPv6: Problem Statement Author(s) : R. Koodli Filename : draft-ietf-mip6-location-privacy-ps-02.txt Pages : 8 Date : 2006-6-23 In this document, we discuss Location Privacy as applicable to Mobile IPv6. We document the concerns arising from revealing Home Address to an on-looker and from disclosing Care of Address to a correspondent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-location-privacy-ps-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip6-location-privacy-ps-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-location-privacy-ps-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-23135733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-location-privacy-ps-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-location-privacy-ps-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-23135733.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Mon Jun 26 03:55:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fulwj-0002tM-QX; Mon, 26 Jun 2006 03:55:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fulwi-0002n6-Ha for mip6@ietf.org; Mon, 26 Jun 2006 03:55:48 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fulwh-00067T-3X for mip6@ietf.org; Mon, 26 Jun 2006 03:55:48 -0400 Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J1G000HRJBYI9@mailout3.samsung.com> for mip6@ietf.org; Mon, 26 Jun 2006 16:55:10 +0900 (KST) Received: from LocalHost (adsl-75-2-41-177.dsl.ipltin.sbcglobal.net [75.2.41.177]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0J1G004QEJBYN3@mmp1.samsung.com> for mip6@ietf.org; Mon, 26 Jun 2006 16:55:10 +0900 (KST) Date: Mon, 26 Jun 2006 16:55:10 +0900 From: Heejin Jang Subject: RE: [Mip6] [Updated] DHCP Option for Home InformationDiscovery inMIPv6 In-reply-to: To: 'Vijay Devarapalli' , "'Chowdhury, Kuntal'" , 'Behcet Sarikaya' Message-id: <002201c698f5$d916aff0$b129024b@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcaWJ1At3e9b1E8eTceNcRUoaUj47wAQ6ahAABuse+AAhprkYA== X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, Vijay What does "it does more" mean? The idea of this draft is simply "using DHCP in order to provide HA/HL/HoA" as the same way as providing other parameters such as IP addresses or DNS/NTP servers. Though the draft allows bootstrapping, it does not specify or is limited to any mechanism or procedure for bootstrapping. For e.g., the idea is also appicable in HMIPv6 map discovery. It can be used where the mobile node is required to discover the MAP (a special home agent) that is located multiple hops away from the mobile node's attachment point. If the use cases are not limited to only bootstrapping, why should the draft be merged? I hope we let the draft standalone so that operators can utililze it for various applicable use cases. Thanks for your interest. Regards, Heejin. -----Original Message----- From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com] Sent: Saturday, June 24, 2006 12:35 AM To: Chowdhury, Kuntal; Behcet Sarikaya Cc: mip6@ietf.org; Heejin Jang Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home InformationDiscovery inMIPv6 dropped the DHC WG from the cc list. > Sorry, I am not getting this. Why are we dragging WiMAX and 3GPP2 > references to justify the need for basic DHCP op-codes for HoA/HL/HA > info? well, some folks were trying to justify draft-jang-mip6-hiopt-00.txt by mentioning WiMAX. perhaps you should go through the entire thread. > draft-jang-mip6-hiopt-00.txt defines the DHCPv6 op-codes for HA, HoA > and HL info. it does more. it tries to also specify a DHCP based MIP6 bootstrapping protocol. > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt is the MIP6 > bootstrapping solution that leverages DHCPv6 for HA/HL bootstrapping. yes. my point exactly. > There are tons of I-Ds and solutions in IETF that leverage other I-Ds. > So, what is so special here? The decision to NOT merge these I-Ds was > taken in the bootstrap DT. Why are we wasting people's time here to > revisit basic decisions? uh?? we *couldn't* reach a conclusion. check the archives. we decided to come back to this later. big concern is that there can't be two drafts that both specify how to use DHCP for MIP6 bootstrapping. my suggestion is to fold the DHCP options into the current working document and have WiMAX and 3GPP2 refer to this draft. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 26 13:49:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuvD5-0005Vk-5f; Mon, 26 Jun 2006 13:49:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuvD3-0005Vf-Pu for mip6@ietf.org; Mon, 26 Jun 2006 13:49:17 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuvD1-0004ss-Co for mip6@ietf.org; Mon, 26 Jun 2006 13:49:17 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k5QHnBnu018053; Mon, 26 Jun 2006 10:49:11 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k5QHnA28018334; Mon, 26 Jun 2006 12:49:10 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A6C82865980; Mon, 26 Jun 2006 19:49:09 +0200 (CEST) Message-ID: <44A01E15.3080309@motorola.com> Date: Mon, 26 Jun 2006 19:49:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 References: <4499C82E.7020303@motorola.com> <4499D301.1080502@azairenet.com> In-Reply-To: <4499D301.1080502@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org [sorry for late reply] Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Basavaraj Patil wrote: >> >>> THURSDAY, July 13, 2006 0900-1130 Morning Session I Room 518AB >>> >>> ========================================= >>> >>> 1. Agenda review, Blue sheets and volunteers for taking notes and >>> Jabber scribe 5 Mins >>> >>> 2. WG status and I-Ds update 10 Mins >>> >>> 3. Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) >>> I-D: draft-ietf-mip6-nemo-v4traversal-01.txt >>> >>> Hesham Soliman 15 Mins >> >> >> The DS-MIPv6 draft has 7 authors on the frontpage. That was >> discussed as a potential issue with a guideline that would suggest >> only 5 authors there. > > its only a guideline. if all the people did contribute, I see nothing > wrong in including all of them. I mentioned this during NETLMM > problem statement discussion too. I don't see any reason why not following the guideline. Do you? > Among other, not following the suggestion has some practical >> consequences (AUTH48 time takes longer). >> >> I don't see why presenting this draft at IETF in its current form. >> Or maybe there are plans to update it for this? > > in general a draft should never be "presented". meeting time is for > resolving issues. I don't think issues I raised can be solved during WG meeting if they can't be solved on the mailing list. Some of the most important issues is the NAT traversal part. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 26 13:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuvEX-0007Tx-9F; Mon, 26 Jun 2006 13:50:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuvEV-0007Mh-R2 for mip6@ietf.org; Mon, 26 Jun 2006 13:50:47 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuvEU-0004vQ-G0 for mip6@ietf.org; Mon, 26 Jun 2006 13:50:47 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k5QHoenA024713; Mon, 26 Jun 2006 10:50:40 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k5QHodTD003537; Mon, 26 Jun 2006 12:50:39 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A22E8865980; Mon, 26 Jun 2006 19:50:38 +0200 (CEST) Message-ID: <44A01E6E.3070900@motorola.com> Date: Mon, 26 Jun 2006 19:50:38 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Michael Ye Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for IPv4(mip4) References: <000b01c69597$b3c880e0$c92ca40a@china.huawei.com> In-Reply-To: <000b01c69597$b3c880e0$c92ca40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mip6@ietf.org, "'Soliman, Hesham'" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Michael Ye wrote: > > > > > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Wednesday, June 21, 2006 10:33 PM > To: Tsirtsis, George > Cc: mip6@ietf.org; Soliman, Hesham > Subject: Re: [Mip6] FW: Internal WG Review: Recharter ofMobility for > IPv4(mip4) > > Tsirtsis, George wrote: >> There is no complaint. I am simply pointing out that if you use HAs >> and a Gateway (of whatever form) you have to discover, manage and >> secure two entities instead of one. > > Ok, just to say that DS-MIPv6 also has to discover its HAs, currently > DS-MIPv6 MN can't discover its HA. > > ==>Yes,DS-MIPv6 MN must discover its HA when it moves into the heterogeneous > network even in same network. I suggest re-naming HA "discovery" based on DNS to DNS-resolution of the HA name. None of the existing discovery mechanisms rely on DNS. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 26 14:01:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuvOj-0006jG-Ok; Mon, 26 Jun 2006 14:01:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuvOj-0006jB-5x for mip6@ietf.org; Mon, 26 Jun 2006 14:01:21 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuvOh-0005uw-T8 for mip6@ietf.org; Mon, 26 Jun 2006 14:01:21 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5QI1J7n025870; Mon, 26 Jun 2006 11:01:19 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k5QI1I3A012904; Mon, 26 Jun 2006 13:01:18 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 0E1AC865980; Mon, 26 Jun 2006 20:01:18 +0200 (CEST) Message-ID: <44A020ED.1020002@motorola.com> Date: Mon, 26 Jun 2006 20:01:17 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 References: <7EB20EA0938B4D42A2D82689365C9B7A04FB50@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FB50@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > >> The DS-MIPv6 draft has 7 authors on the frontpage. That was >> discussed as a potential issue with a guideline that would suggest >> only 5 authors there. Among other, not following the suggestion >> has some practical consequences (AUTH48 time takes longer). > > => What does this have to do with the agenda??? Because the suggestion was made to restrain the number of authors, and the suggestion was not considered, I don't see why spending WG meeting time in discussing all over. >> I don't see why presenting this draft at IETF in its current form. >> Or maybe there are plans to update it for this? > > => We may or may not. This has nothing to do with the technical > discussion in the draft. In what concerns my own technical remarks I don't see why discussion should take place at WG meeting, when the mailing discussion doesn't seem to advance. >>> 4. Mobility management for Dual stack mobile nodes: A Problem >>> Statement I-D: draft-ietf-mip6-dsmip-problem-02.txt >>> >>> Hesham Soliman 5 Mins >> >> AD asked for a problem statement for the MIP4-MIP6 space. >> >> However, this draft does not contain the original problem statement >> of draft-wakikawa-nemo-v4tunnel-01.txt (namely multiple >> encapsulation). Additionally, all the list discussion since last >> IETF around problem statement is not reflected in this draft. > > => Please be specific. What comments were made on this draft and not > included? One original problem statement is in the draft-wakikawa-nemo-v4tunnel-01.txt. The encapsulating tunnel problem in that draft is not reflected. That problem statement resulted in having IPv4 addresses in BU. But the entire DS-MIPv6 draft is not based on only this problem statement. Other problem statement existed and expired in draft-larsson-v6ops-mip-scenarios-01.txt >> I don't see why presenting it. Or maybe there are plans to update >> it for this? >> >> It's hard to have a meaningful discussion during the WG meeting >> when the email discussion prior to it is not taken into account. > > => Informed comments about the technical content of drafts the email > discussion will be easily reflected in the drafts. Comments about > the number of authors and confusion about what the solution does or > does not do is generally hard to reflect in the technical content of > the draft. Solutions to these comments are straightforward. Re-naming "discovery" into "DNS resolution", and putting an Editor with 6 co-authors are both straightforward resolutions. > Without being specific about what was apparently "ignored" (according > to your comment above), I really can't do anything to address your > comment. Of course not every comment made will be reflected in the > draft because it might be wrong or unsuitable. But, in any case, I > haven't seen any comments from you on the problem statement that were > simply "ignored"! I have suggested we come back to having a problem statement. The short problem should be put in terms of "continuous sessions", "permanent reachable Home Address" and "IPv4 and IPv6". I have suggested a number of times DS-MIPv6 should not deal with IPv4 continuous sessions, neither with IPv4 permanent reachable Home Addresses. > Also FYI, this is not a "presentation" of a draft, this is to discuss > the state of this draft after it was updated by comments from Pekka > S, Jari and others. Ok. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 26 14:03:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuvQo-0007Uy-Gk; Mon, 26 Jun 2006 14:03:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuvQm-0007Ut-Ro for mip6@ietf.org; Mon, 26 Jun 2006 14:03:28 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuvQl-0006A3-Gc for mip6@ietf.org; Mon, 26 Jun 2006 14:03:28 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k5QI3QmM024884; Mon, 26 Jun 2006 11:03:26 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k5QI3P7H011912; Mon, 26 Jun 2006 13:03:26 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id F18AD865980; Mon, 26 Jun 2006 20:03:24 +0200 (CEST) Message-ID: <44A0216C.8090503@motorola.com> Date: Mon, 26 Jun 2006 20:03:24 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Tom Wan Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility forIPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FB4E@NAEX14.na.qualcomm.com> <015b01c695a4$1cd87200$6e2ea40a@china.huawei.com> In-Reply-To: <015b01c695a4$1cd87200$6e2ea40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mip6@ietf.org, "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Tom Wan wrote: > Hi, Soliman: > > I think we should not consider a solution currently. > > We must answer this question firstly: should home network support > both ipv4 and ipv6 protocol? I agree we should discuss this. > I think there are three categories of scenarios: home network > supports ipv4 only home network supports ipv6 only home network > supports both ipv4 and ipv6. > > I think they all possible scenarios.The reason is that ietf should > not require the operator that all their HAs must support both ipv4 > and ipv6.It is up to the operators. > > DSmip requries that home network must support both ipv4 and ipv6. > surely,It can solve problems in scenario 3. But how about the other > two scenarios? I think we should consider all possible scenarios > firstly before we consider a unified solution. I think DS-MIPv6 should only care about IPv6 permanent home addresses and IPv6 continuous sessions (and not about IPv4 permanent home addresses, nor IPv4 continuous sessions). Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 26 14:17:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuved-0003kV-F6; Mon, 26 Jun 2006 14:17:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuvec-0003kQ-Vd for mip6@ietf.org; Mon, 26 Jun 2006 14:17:46 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuveb-0007aQ-IV for mip6@ietf.org; Mon, 26 Jun 2006 14:17:46 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k5QIHjEx014415; Mon, 26 Jun 2006 11:17:45 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k5QIHhao020192; Mon, 26 Jun 2006 13:17:43 -0500 (CDT) Message-ID: <44A024C5.1@motorola.com> Date: Mon, 26 Jun 2006 20:17:41 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Basavaraj Patil wrote: > Inline: > > > On 6/21/06 5:29 PM, "ext Alexandru Petrescu" > wrote: > >> Basavaraj Patil wrote: >>> THURSDAY, July 13, 2006 0900-1130 Morning Session I Room 518AB >>> >>> ========================================= >>> >>> 1. Agenda review, Blue sheets and volunteers for taking notes and >>> Jabber scribe 5 Mins >>> >>> 2. WG status and I-Ds update 10 Mins >>> >>> 3. Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) >>> I-D: draft-ietf-mip6-nemo-v4traversal-01.txt >>> >>> Hesham Soliman 15 Mins >> The DS-MIPv6 draft has 7 authors on the frontpage. That was >> discussed as a potential issue with a guideline that would suggest >> only 5 authors there. Among other, not following the suggestion >> has some practical consequences (AUTH48 time takes longer). > > As you noted, it is a "guideline" and NOT a rule. Raj, I agree it's a only guideline. I don't see why not following it. Do you? >> I don't see why presenting this draft at IETF in its current form. >> Or maybe there are plans to update it for this? > > The I-D in its current form is good for WG discussion. There will be > revisions before it goes to WG LC. But at this point, I see no > reason for it not being on the agenda. What is the specific concern > that you have? The concern I have is that it tries to address too many scenarios, has too many features (namely IPv4 permanent home address and IPv4 continuous sessions should be out-of-scope for DS-MIPv6). There's also the NAT Traversal part. The specific concern on it is that some NATs dynamically change the source port number even if heartbeating is going through. This may break IPv6 VoIP continuous sessions if (1) the MN is not required to send packets every 100ms even in absence of app data and (2) the HA does not store the src port number. This was raised at Dallas meeting, re-directed on the mailing list, re-discussed on the mailing list and somehow concluded that actually there's no issue with the current NAT traversal. I still believe there's a big issue with it. >>> 4. Mobility management for Dual stack mobile nodes: A Problem >>> Statement I-D: draft-ietf-mip6-dsmip-problem-02.txt >>> >>> Hesham Soliman 5 Mins >> AD asked for a problem statement for the MIP4-MIP6 space. > > This I-D has existed as a MIP6 WG I-D for a long time. This has got > nothing to do with the AD asking for a problem statement from the > work being done in MIP4. So lets not confuse the issue. I agree. It's also true that the problem statement in draft-wakikawa is at the origin of carrying IPv4 addresses in the BU - only. That problem statement talks about avoiding encapsulation. >> However, this draft does not contain the original problem statement >> of draft-wakikawa-nemo-v4tunnel-01.txt (namely multiple >> encapsulation). Additionally, all the list discussion since last >> IETF around problem statement is not reflected in this draft. >> >> I don't see why presenting it. Or maybe there are plans to update >> it for this? > > The I-D has been revised and changes will be discussed. How this work > will proceed is a matter of discussion by the WG. Will it be updated > before IETF66? No. Ok. >> It's hard to have a meaningful discussion during the WG meeting >> when the email discussion prior to it is not taken into account. > > The email discussion on the MIP6 ML was about the rechartering of > MIP4 and specifically the proposal to work on an equivalent solution > that exists in MIP6 for DS nodes for MIP4 hosts. We will not be > discussing this in the MIP6 WG. I wasn't trying to relate the MIP4 WG chartering with the MIP6 chartering. But since you mention it... if DS-MIPv6 was only trying to offer IPv6 permanent and reachable home address, and IPv6 continuous sessions (not IPv4) then the DS-MIPv4 would be easier to motivate. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 26 14:31:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuvrn-00054r-Ir; Mon, 26 Jun 2006 14:31:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuvrm-00054i-7e for mip6@ietf.org; Mon, 26 Jun 2006 14:31:22 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuvrk-0007z3-S1 for mip6@ietf.org; Mon, 26 Jun 2006 14:31:22 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5QIVIiR013701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Jun 2006 11:31:20 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5QITRte022203; Mon, 26 Jun 2006 11:31:17 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 11:31:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 Date: Mon, 26 Jun 2006 11:31:05 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A07C7EE@NAEX14.na.qualcomm.com> In-Reply-To: <44A020ED.1020002@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 Thread-Index: AcaZSpEzPFhAnI7WTcqDQgyFbP0ZgAAAv2wA From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 26 Jun 2006 18:31:06.0992 (UTC) FILETIME=[B03CEF00:01C6994E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > =3D> What does this have to do with the agenda??? >=20 > Because the suggestion was made to restrain the number of=20 > authors, and > the suggestion was not considered, I don't see why spending=20 > WG meeting > time in discussing all over. =3D> I didn't request a slot to discuss the number of authors on the draft.=20 I noted your comment before but it's not the most important issue to handle now. > > =3D> Please be specific. What comments were made on this=20 > draft and not > > included? >=20 > One original problem statement is in the > draft-wakikawa-nemo-v4tunnel-01.txt. The encapsulating=20 > tunnel problem > in that draft is not reflected. That problem statement resulted in > having IPv4 addresses in BU. But the entire DS-MIPv6 draft=20 > is not based > on only this problem statement. >=20 > Other problem statement existed and expired in > draft-larsson-v6ops-mip-scenarios-01.txt =3D> That was not a problem statement it's a scenarios document. It's interesting that you are choosing to ignore the original problem statement that the WG accepted. What specifically is your comment on the current draft? As opposed to listing other documents.=20 >=20 > Solutions to these comments are straightforward. Re-naming=20 > "discovery" > into "DNS resolution", and putting an Editor with 6=20 > co-authors are both > straightforward resolutions. =3D> We're handling issues in terms of priority. If you want to raise an issue please use the issue tracker as other people did. This way it's registered and not lost. >=20 > I have suggested we come back to having a problem statement.=20 > The short > problem should be put in terms of "continuous sessions", "permanent > reachable Home Address" and "IPv4 and IPv6". I have=20 > suggested a number > of times DS-MIPv6 should not deal with IPv4 continuous=20 > sessions, neither > with IPv4 permanent reachable Home Addresses. =3D> That's your opinion. You shouldn't expect that to be taken as = gospel. A lot of people don't agree with you about that. If you want to register it as an issue then do so on the tracker and explain the technical reasons for removing those features from the draft.=20 Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 26 15:16:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwZM-0007eI-3V; Mon, 26 Jun 2006 15:16:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwZK-0007cM-8D for mip6@ietf.org; Mon, 26 Jun 2006 15:16:22 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuwZH-0004Ok-Nt for mip6@ietf.org; Mon, 26 Jun 2006 15:16:22 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k5QJGIMI027342; Mon, 26 Jun 2006 12:16:18 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k5QJGHbu028966; Mon, 26 Jun 2006 14:16:18 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id AC421865980; Mon, 26 Jun 2006 21:16:16 +0200 (CEST) Message-ID: <44A03280.50008@motorola.com> Date: Mon, 26 Jun 2006 21:16:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 References: <7EB20EA0938B4D42A2D82689365C9B7A07C7EE@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A07C7EE@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: >>> => What does this have to do with the agenda??? >> >> Because the suggestion was made to restrain the number of authors, >> and the suggestion was not considered, I don't see why spending WG >> meeting time in discussing all over. > > => I didn't request a slot to discuss the number of authors on the > draft. I noted your comment before but it's not the most important > issue to handle now. To me it is paramount. Many authors means more difficulty in reaching editing agreement, or risk document to not reflect some authors' oppinions. >>> => Please be specific. What comments were made on this >> draft and not >>> included? >> >> One original problem statement is in the >> draft-wakikawa-nemo-v4tunnel-01.txt. The encapsulating tunnel >> problem in that draft is not reflected. That problem statement >> resulted in having IPv4 addresses in BU. But the entire DS-MIPv6 >> draft is not based on only this problem statement. >> >> Other problem statement existed and expired in >> draft-larsson-v6ops-mip-scenarios-01.txt > > => That was not a problem statement it's a scenarios document. It's > interesting that you are choosing to ignore the original problem > statement that the WG accepted. What specifically is your comment on > the current draft? As opposed to listing other documents. Efficiency (or lack thereof) can not base a problem statement. The issues: > - Mobile nodes to be both MIPv4 and MIPv6 capable. > - Mobile nodes to send two sets of signaling messages on every > handoff. > - Network Administrators to run and maintain two sets of mobility > management systems on the same network. Each of these systems > requiring their own sets of optimizations that may include > hierarchical Mobile IPv4, hierarchical Mobile IPv6 and Fast > Handoffs for Mobile IPv4, mechanisms that are currently in > development in the IETF. Small phones can easily do both mip4 and mip6. With MIP4+MIP6 and connected to a v4-access the MN only does MIP4 messaging upon handover, not MIP6 messaging. MIP4+MIP6 do not involve running HMIP4+HMIP6. The problems: > - The network operator needs to ensure that the home agent supports > both protocols or that it has two separate Home Agents supporting > the two protocols, each requiring its own management. > - Double the amount of configuration in the mobile node and the home > agent (e.g., security associations). > - Local network optimizations for handovers will also need to be > duplicated. With DS-MIPv6 the network operator must make sure all HAs run both IPv4 and IPv6, each requiring its own management. Local network optimizations have no relationship with either MIP4 or MIP6, they work independently of the global mobility management protocol. >> Solutions to these comments are straightforward. Re-naming >> "discovery" into "DNS resolution", and putting an Editor with 6 >> co-authors are both straightforward resolutions. > > => We're handling issues in terms of priority. If you want to raise > an issue please use the issue tracker as other people did. This way > it's registered and not lost. That's a good idea. It seems to be currently not reachable though (object not found) http://www1.tools.ietf.org/wg/mip6/draft-ietf-mip6-nemo-v4traversal/trac/report/1 There may be an alternative access though, if so please let me know. Otherwise I'll wait it comes up. >> I have suggested we come back to having a problem statement. The >> short problem should be put in terms of "continuous sessions", >> "permanent reachable Home Address" and "IPv4 and IPv6". I have >> suggested a number of times DS-MIPv6 should not deal with IPv4 >> continuous sessions, neither with IPv4 permanent reachable Home >> Addresses. > > => That's your opinion. You shouldn't expect that to be taken as > gospel. None of my intentions to take it as a gospel. You take it as you wish. Take it as lack of support if you wish. > A lot of people don't agree with you about that. Ok. > If you want to register it as an issue then do so on the tracker and > explain the technical reasons for removing those features from the > draft. Not sure I get more luck with a separate tool... Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 26 16:00:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxFX-0000Nu-ED; Mon, 26 Jun 2006 15:59:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxFV-0000Np-J2 for mip6@ietf.org; Mon, 26 Jun 2006 15:59:57 -0400 Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuxFU-0001lV-0q for mip6@ietf.org; Mon, 26 Jun 2006 15:59:57 -0400 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by warlock.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5QJon6E002808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 26 Jun 2006 12:50:49 -0700 (PDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5QJomUs022495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Jun 2006 12:50:48 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5QJol8I002345; Mon, 26 Jun 2006 12:50:47 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 12:50:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 Date: Mon, 26 Jun 2006 12:50:37 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A07C826@NAEX14.na.qualcomm.com> In-Reply-To: <44A03280.50008@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 Thread-Index: AcaZV3yHXM4JF4F3QpqsWsTPeHo6KQAAaIyA From: "Tsirtsis, George" To: "Alexandru Petrescu" , "Soliman, Hesham" X-OriginalArrivalTime: 26 Jun 2006 19:50:46.0969 (UTC) FILETIME=[D1538A90:01C69959] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Monday, June 26, 2006 3:16 PM > To: Soliman, Hesham > Cc: mip6@ietf.org; Basavaraj Patil > Subject: Re: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 >=20 > Soliman, Hesham wrote: > >>> =3D> What does this have to do with the agenda??? > >> > >> Because the suggestion was made to restrain the number of authors, > >> and the suggestion was not considered, I don't see why spending WG > >> meeting time in discussing all over. > > > > =3D> I didn't request a slot to discuss the number of authors on the > > draft. I noted your comment before but it's not the most important > > issue to handle now. >=20 > To me it is paramount. Many authors means more difficulty in reaching > editing agreement, or risk document to not reflect some authors' > oppinions. >=20 GT> Alex, this is a non-issue, you are inventing problems. > >>> =3D> Please be specific. What comments were made on this > >> draft and not > >>> included? > >> > >> One original problem statement is in the > >> draft-wakikawa-nemo-v4tunnel-01.txt. The encapsulating tunnel > >> problem in that draft is not reflected. That problem statement > >> resulted in having IPv4 addresses in BU. But the entire DS-MIPv6 > >> draft is not based on only this problem statement. > >> > >> Other problem statement existed and expired in > >> draft-larsson-v6ops-mip-scenarios-01.txt > > > > =3D> That was not a problem statement it's a scenarios document. = It's > > interesting that you are choosing to ignore the original problem > > statement that the WG accepted. What specifically is your comment on > > the current draft? As opposed to listing other documents. >=20 > Efficiency (or lack thereof) can not base a problem statement. The > issues: >=20 > > - Mobile nodes to be both MIPv4 and MIPv6 capable. > > - Mobile nodes to send two sets of signaling messages on every > > handoff. > > - Network Administrators to run and maintain two sets of mobility > > management systems on the same network. Each of these systems > > requiring their own sets of optimizations that may include > > hierarchical Mobile IPv4, hierarchical Mobile IPv6 and Fast > > Handoffs for Mobile IPv4, mechanisms that are currently in > > development in the IETF. >=20 > Small phones can easily do both mip4 and mip6. > With MIP4+MIP6 and connected to a v4-access the MN only does MIP4 > messaging upon handover, not MIP6 messaging. > MIP4+MIP6 do not involve running HMIP4+HMIP6. >=20 GT> It is of course possible to run MIPv4 and MIPv6. DS-MIP came up, however, because some of us did not want to do that for a variety of reasons which are explained in the problem statement (draft-ietf-mip6-dsmip-problem-02.txt) and have been accepted by the majority of the WG. I do not think going over all this again is useful.=20 > The problems: > > - The network operator needs to ensure that the home agent supports > > both protocols or that it has two separate Home Agents supporting > > the two protocols, each requiring its own management. > > - Double the amount of configuration in the mobile node and the home > > agent (e.g., security associations). > > - Local network optimizations for handovers will also need to be > > duplicated. >=20 > With DS-MIPv6 the network operator must make sure all HAs run both IPv4 > and IPv6, each requiring its own management. >=20 > Local network optimizations have no relationship with either MIP4 or > MIP6, they work independently of the global mobility management protocol. >=20 > >> Solutions to these comments are straightforward. Re-naming > >> "discovery" into "DNS resolution", and putting an Editor with 6 > >> co-authors are both straightforward resolutions. > > > > =3D> We're handling issues in terms of priority. If you want to = raise > > an issue please use the issue tracker as other people did. This way > > it's registered and not lost. >=20 > That's a good idea. It seems to be currently not reachable though > (object not found) > http://www1.tools.ietf.org/wg/mip6/draft-ietf-mip6-nemo- > v4traversal/trac/report/1 >=20 > There may be an alternative access though, if so please let me know. > Otherwise I'll wait it comes up. >=20 > >> I have suggested we come back to having a problem statement. The > >> short problem should be put in terms of "continuous sessions", > >> "permanent reachable Home Address" and "IPv4 and IPv6". I have > >> suggested a number of times DS-MIPv6 should not deal with IPv4 > >> continuous sessions, neither with IPv4 permanent reachable Home > >> Addresses. > > > > =3D> That's your opinion. You shouldn't expect that to be taken as > > gospel. >=20 > None of my intentions to take it as a gospel. You take it as you wish. > Take it as lack of support if you wish. >=20 > > A lot of people don't agree with you about that. >=20 > Ok. >=20 > > If you want to register it as an issue then do so on the tracker and > > explain the technical reasons for removing those features from the > > draft. >=20 > Not sure I get more luck with a separate tool... >=20 > Alex >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 26 16:59:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyBW-0001MZ-Bx; Mon, 26 Jun 2006 16:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyBU-0001MU-TG for mip6@ietf.org; Mon, 26 Jun 2006 16:59:52 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuyBS-0006Og-Hk for mip6@ietf.org; Mon, 26 Jun 2006 16:59:52 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 13:59:48 -0700 Message-ID: <44A04A3E.9090807@azairenet.com> Date: Mon, 26 Jun 2006 13:57:34 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 References: <7EB20EA0938B4D42A2D82689365C9B7A07C7EE@NAEX14.na.qualcomm.com> <44A03280.50008@motorola.com> In-Reply-To: <44A03280.50008@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2006 20:59:48.0484 (UTC) FILETIME=[75DC9440:01C69963] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mip6@ietf.org, "Soliman, Hesham" , Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: >>> Because the suggestion was made to restrain the number of authors, >>> and the suggestion was not considered, I don't see why spending WG >>> meeting time in discussing all over. >> >> >> => I didn't request a slot to discuss the number of authors on the >> draft. I noted your comment before but it's not the most important >> issue to handle now. > > > To me it is paramount. Many authors means more difficulty in reaching > editing agreement, or risk document to not reflect some authors' oppinions. it lists the folks who were in the design team. we have one editor (Hesham) and he edits in whatever everyone decides. so there shouldn't be an issue. > That's a good idea. It seems to be currently not reachable though > (object not found) > http://www1.tools.ietf.org/wg/mip6/draft-ietf-mip6-nemo-v4traversal/trac/report/1 the issue tracker is at http://www.mip4.org/issues/tracker/mip6/ the MIP6 WG has been using this tracker for a while. we have not yet started using the tracker at tools.ietf.org for any of the MIP6 WG documents. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 26 17:04:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyFx-0005R9-GY; Mon, 26 Jun 2006 17:04:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyFw-0005Pq-5a for mip6@ietf.org; Mon, 26 Jun 2006 17:04:28 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuyFv-0006jF-QO for mip6@ietf.org; Mon, 26 Jun 2006 17:04:28 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5QL4HU6029280; Mon, 26 Jun 2006 14:04:21 -0700 (MST) Received: from [10.129.40.85] ([10.129.40.85]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k5QL4FaC026470; Mon, 26 Jun 2006 16:04:16 -0500 (CDT) Message-ID: <44A04BCE.4030208@motorola.com> Date: Mon, 26 Jun 2006 23:04:14 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 References: <7EB20EA0938B4D42A2D82689365C9B7A07C826@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A07C826@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Tsirtsis, George wrote: > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@motorola.com] Sent: Monday, June 26, >> 2006 3:16 PM To: Soliman, Hesham Cc: mip6@ietf.org; Basavaraj Patil >> Subject: Re: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 >> >> Soliman, Hesham wrote: >>>>> => What does this have to do with the agenda??? >>>> Because the suggestion was made to restrain the number of >>>> authors, and the suggestion was not considered, I don't see why >>>> spending WG meeting time in discussing all over. >>> => I didn't request a slot to discuss the number of authors on >>> the draft. I noted your comment before but it's not the most >>> important issue to handle now. >> To me it is paramount. Many authors means more difficulty in >> reaching editing agreement, or risk document to not reflect some >> authors' oppinions. >> > > GT> Alex, this is a non-issue, you are inventing prowblems. George - I consider it a problem having 7 authors on the frontpage. >>>>> => Please be specific. What comments were made on this >>>> draft and not >>>>> included? >>>> One original problem statement is in the >>>> draft-wakikawa-nemo-v4tunnel-01.txt. The encapsulating tunnel >>>> problem in that draft is not reflected. That problem >>>> statement resulted in having IPv4 addresses in BU. But the >>>> entire DS-MIPv6 draft is not based on only this problem >>>> statement. >>>> >>>> Other problem statement existed and expired in >>>> draft-larsson-v6ops-mip-scenarios-01.txt >>> => That was not a problem statement it's a scenarios document. >>> It's interesting that you are choosing to ignore the original >>> problem statement that the WG accepted. What specifically is your >>> comment on the current draft? As opposed to listing other >>> documents. >> Efficiency (or lack thereof) can not base a problem statement. The >> issues: >> >>> - Mobile nodes to be both MIPv4 and MIPv6 capable. - Mobile nodes >>> to send two sets of signaling messages on every handoff. - >>> Network Administrators to run and maintain two sets of mobility >>> management systems on the same network. Each of these systems >>> requiring their own sets of optimizations that may include >>> hierarchical Mobile IPv4, hierarchical Mobile IPv6 and Fast >>> Handoffs for Mobile IPv4, mechanisms that are currently in >>> development in the IETF. >> Small phones can easily do both mip4 and mip6. With MIP4+MIP6 and >> connected to a v4-access the MN only does MIP4 messaging upon >> handover, not MIP6 messaging. MIP4+MIP6 do not involve running >> HMIP4+HMIP6. >> > > GT> It is of course possible to run MIPv4 and MIPv6. DS-MIP came up, > however, because some of us did not want to do that for a variety of > reasons which are explained in the problem statement > (draft-ietf-mip6-dsmip-problem-02.txt) It's not really my intention to spend a lot of time on this. I have posted remarks to the issues since miptrans. The essence of it is in my message, you seem to have missed it. Additionally, citing double SA maintenance for v4 and v6 is forgetting that MIP6 does that automatically for v6, so comes down to v4 only, as before. Additionally, citing implementation burdens for supporting MIP4+MIP6 is forgetting that MIP6 extensions _are_ implementation effort to become DS-MIPv6. > and have been accepted by the majority of the WG. majority-1. > I do not think going over all this again is useful. Same on my side. I think I'll stop... BTW, are you planning to confirm acceptation of your suggested modifs to the NEMOv4 draft (it's submitted now)? Alex > > >> The problems: >>> - The network operator needs to ensure that the home agent > supports >>> both protocols or that it has two separate Home Agents > supporting >>> the two protocols, each requiring its own management. - Double >>> the amount of configuration in the mobile node and the > home >>> agent (e.g., security associations). - Local network >>> optimizations for handovers will also need to be duplicated. >> With DS-MIPv6 the network operator must make sure all HAs run both > IPv4 >> and IPv6, each requiring its own management. >> >> Local network optimizations have no relationship with either MIP4 >> or MIP6, they work independently of the global mobility management > protocol. >>>> Solutions to these comments are straightforward. Re-naming >>>> "discovery" into "DNS resolution", and putting an Editor with 6 >>>> co-authors are both straightforward resolutions. >>> => We're handling issues in terms of priority. If you want to >>> raise an issue please use the issue tracker as other people did. >>> This way it's registered and not lost. >> That's a good idea. It seems to be currently not reachable though >> (object not found) >> http://www1.tools.ietf.org/wg/mip6/draft-ietf-mip6-nemo- >> v4traversal/trac/report/1 >> >> There may be an alternative access though, if so please let me >> know. Otherwise I'll wait it comes up. >> >>>> I have suggested we come back to having a problem statement. >>>> The short problem should be put in terms of "continuous >>>> sessions", "permanent reachable Home Address" and "IPv4 and >>>> IPv6". I have suggested a number of times DS-MIPv6 should not >>>> deal with IPv4 continuous sessions, neither with IPv4 >>>> permanent reachable Home Addresses. >>> => That's your opinion. You shouldn't expect that to be taken as >>> gospel. >> None of my intentions to take it as a gospel. You take it as you > wish. >> Take it as lack of support if you wish. >> >>> A lot of people don't agree with you about that. >> Ok. >> >>> If you want to register it as an issue then do so on the tracker >>> and explain the technical reasons for removing those features >>> from the draft. >> Not sure I get more luck with a separate tool... >> >> Alex >> >> >> _______________________________________________ Mip6 mailing list >> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 26 17:12:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyNt-0003Q8-Fq; Mon, 26 Jun 2006 17:12:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyNr-0003J8-N6 for mip6@ietf.org; Mon, 26 Jun 2006 17:12:39 -0400 Received: from av9-1-sn3.vrr.skanova.net ([81.228.9.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuyNq-0007dJ-D3 for mip6@ietf.org; Mon, 26 Jun 2006 17:12:39 -0400 Received: by av9-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 4093E381B0; Mon, 26 Jun 2006 23:12:37 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av9-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 324E4381AE for ; Mon, 26 Jun 2006 23:12:37 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 26A7F37E45 for ; Mon, 26 Jun 2006 23:12:36 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz.levkowetz.com) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FuyNm-00086x-LW for mip6@ietf.org; Mon, 26 Jun 2006 23:12:36 +0200 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: Alexandru Petrescu Date: Mon, 26 Jun 2006 21:12:34 +0000 MIME-Version: 1.0 Message-Id: <1151356354.63.0.701705253636.issue75@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-104.4 required=2.5 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.1 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Mip6] [issue75] authors on frontpage should be less than 6 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org New submission from Alexandru Petrescu : According to a guideline the number of authors on frontpage should be 5 or = less. Propose to keep an editor and list the co-authors in a different section. ---------- category: Editorial draft: draft-ietf-mip6-nemo-v4traversal messages: 250 nosy: petrescu priority: Must fix status: Text proposed title: authors on frontpage should be less than 6 _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 26 17:42:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyqX-00032k-R8; Mon, 26 Jun 2006 17:42:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyqW-00032c-N9; Mon, 26 Jun 2006 17:42:16 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuyqV-0001H5-8v; Mon, 26 Jun 2006 17:42:16 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 26 Jun 2006 14:42:14 -0700 X-IronPort-AV: i="4.06,178,1149490800"; d="scan'208"; a="301273037:sNHT36657784" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k5QLgDbp016224; Mon, 26 Jun 2006 14:42:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5QLfxJ2000491; Mon, 26 Jun 2006 14:42:08 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 14:42:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for HomeInformationDiscovery inMIPv6 Date: Mon, 26 Jun 2006 14:42:00 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52020C8E13@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] RE: [Mip6] [Updated] DHCP Option for HomeInformationDiscovery inMIPv6 Thread-Index: AcaWJ1At3e9b1E8eTceNcRUoaUj47wAQ6ahAAL8Y9OA= From: "Kent Leung ¥(kleung¥)" To: "Chowdhury, Kuntal" , "Vijay Devarapalli" , "Behcet Sarikaya" X-OriginalArrivalTime: 26 Jun 2006 21:42:02.0927 (UTC) FILETIME=[5C81E3F0:01C69969] DKIM-Signature: a=rsa-sha1; q=dns; l=3982; t=1151358133; x=1152222133; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20¥(kleung¥)=22=20 |Subject:RE=3A=20[dhcwg]=20RE=3A=20[Mip6]=20[Updated]=20DHCP=20Option=20for=20Hom eInformationDiscovery=20inMIPv6; X=v=3Dcisco.com=3B=20h=3DJYf6MBNa8mTiQH9SoxmdmxHW/20=3D; b=0a3J99ySXVUrGIAsJcpHZ4VoS0kLhNkU3hlTNwx71+UWsfFaUH8hlWrfWepioWyi4du4jztU r5l4Ln1bNNrthDLmyz+gnzGMD/vd91PFo2y1v2EMtKsfghBKgFfzv4DE; Authentication-Results: sj-dkim-5.cisco.com; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: mip6@ietf.org, Heejin Jang , dhcwg@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Kuntal and Vijay. See my posting, "Generalizing draft-jang-dhc-haopt for MIPv6 support in DHCP", back on Jan 4, 2006 on this topic. I proposed to keep the 2 drafts separate, one for defining DHCPv6 opcodes for MIPv6 parameters and a bootstrap draft that references the DHCP options needed to achieve its function. I agree there's no need to drag in references other to say that there's value for the DHCP MIPv6 options. 3GPP2/WiMAX specs can reference the DHCPv6 opcodes for MIPv6 draft/RFC, much like what MIPv6 bootstrap would have done. As for what Vijay said about the WiMAX scheme, definitely true that it doesn't conform to DHCP RFC 3315. But we should keep the issues separate. I haven't read all the emails on the thread. Just jumping in to say the following: - Keep 2 separate self contained drafts - IETF MIPv6 bootstrap draft references DHCP for MIPv6 draft - WiMAX and 3GPP2 can also reference DHCP for MIPv6 draft for their bootstrapping schemes Just some explanatory comments: - 3GPP2 conforms to DHCPv6 in its bootstrapping scheme - WiMAX does not conform to DHCPv6 when using proxy DHCP server scheme But *ALL* of the above bootstrapping schemes use the same DHCP options for MIPv6 parameters. That's what justifies an independent DHCP for MIPv6 draft, IMHO. Kent =20 > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > Sent: Thursday, June 22, 2006 7:19 PM > To: Vijay Devarapalli; Behcet Sarikaya > Cc: mip6@ietf.org; Heejin Jang; dhcwg@ietf.org > Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for=20 > HomeInformationDiscovery inMIPv6 >=20 > Sorry, I am not getting this. Why are we dragging WiMAX and=20 > 3GPP2 references to justify the need for basic DHCP op-codes=20 > for HoA/HL/HA info? >=20 > draft-jang-mip6-hiopt-00.txt defines the DHCPv6 op-codes for=20 > HA, HoA and HL info. >=20 > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt is the=20 > MIP6 bootstrapping solution that leverages DHCPv6 for HA/HL=20 > bootstrapping.=20 >=20 > There are tons of I-Ds and solutions in IETF that leverage other I-Ds. > So, what is so special here? The decision to NOT merge these=20 > I-Ds was taken in the bootstrap DT. Why are we wasting=20 > people's time here to revisit basic decisions? >=20 > -Kuntal >=20 >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Sent: Thursday, June 22, 2006 12:55 PM > > To: Behcet Sarikaya > > Cc: mip6@ietf.org; Heejin Jang; dhcwg@ietf.org > > Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home=20 > > InformationDiscovery inMIPv6 > >=20 > > Behcet Sarikaya wrote: > > > Hi Vijay, > > > The idea in the present WiMAX document is quite simple: > > > it uses EAP-PKMv2 (which is like 802.11i) authentication=20 > and during > EAP > > > transaction, they assume that AAA server determines that=20 > the MS is a > > > CMIPv6 authorized user based on the AAA profile and it=20 > will include > all > > > the so-called bootstrapping info in the Access-Accept. Then MS can > use > > > RFC 3736 to make a DHCP Information Request to DHCP Relay=20 > colocated > with > > > NAS and use draft-jang (extended now with HoA) and receive all the > info > > > to configure MIP6. > >=20 > > the DHCP Relay replies to the MN without relaying the DHCP request=20 > > from the MN to a DHCP server? this is not allowed with the current=20 > > IETF specs. > >=20 > > > In this setup can you make a case for=20 > > > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt? > >=20 > > as far as I am concerned, > > draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt > > is the document that describes how to use DHCPv6 for MIPv6=20 > > bootstrapping. as for the setup in the WiMAX NWG, it is=20 > something that=20 > > doesn't conform to the IETF DHCP specs. > >=20 > > Vijay > > >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 26 18:41:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuzlm-0003xb-PK; Mon, 26 Jun 2006 18:41:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuzll-0003wV-PE for mip6@ietf.org; Mon, 26 Jun 2006 18:41:25 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuzlj-0006vw-C2 for mip6@ietf.org; Mon, 26 Jun 2006 18:41:25 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 15:41:22 -0700 Message-ID: <44A0620F.5090408@azairenet.com> Date: Mon, 26 Jun 2006 15:39:11 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for HomeInformationDiscovery inMIPv6 References: <2979E38DD6FC6544B789C8DAD7BAFC52020C8E13@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC52020C8E13@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2006 22:41:22.0070 (UTC) FILETIME=[A5EC0360:01C69971] X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org (left out the DHC WG from the cc list). there is one issue. draft-jang just does not define the DHCP options. it goes further. abstract of draft-jang says This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home agent address, home address, and home subnet. New DHCP options are defined to carry the information from a DHCP server to the DHCP client running on the mobile node. section 4.2 further goes and ahead and specifies mobile node behavior. the draft just does not define the options. it is also incomplete because it neither describes the scope of the problem it is trying to address nor gives a complete solution. we can't have two documents that both describe how to use DHCP for MIP6 bootstrapping. Vijay Kent Leung (kleung) wrote: > Hi Kuntal and Vijay. > > See my posting, "Generalizing draft-jang-dhc-haopt for MIPv6 support in > DHCP", back on Jan 4, 2006 on this topic. I proposed to keep the 2 > drafts separate, one for defining DHCPv6 opcodes for MIPv6 parameters > and a bootstrap draft that references the DHCP options needed to achieve > its function. > > I agree there's no need to drag in references other to say that there's > value for the DHCP MIPv6 options. 3GPP2/WiMAX specs can reference the > DHCPv6 opcodes for MIPv6 draft/RFC, much like what MIPv6 bootstrap would > have done. > > As for what Vijay said about the WiMAX scheme, definitely true that it > doesn't conform to DHCP RFC 3315. But we should keep the issues > separate. I haven't read all the emails on the thread. Just jumping in > to say the following: > > - Keep 2 separate self contained drafts > - IETF MIPv6 bootstrap draft references DHCP for MIPv6 draft > - WiMAX and 3GPP2 can also reference DHCP for MIPv6 draft for their > bootstrapping schemes > > Just some explanatory comments: > - 3GPP2 conforms to DHCPv6 in its bootstrapping scheme > - WiMAX does not conform to DHCPv6 when using proxy DHCP server scheme > > But *ALL* of the above bootstrapping schemes use the same DHCP options > for MIPv6 parameters. That's what justifies an independent DHCP for > MIPv6 draft, IMHO. > > Kent > > > > >>-----Original Message----- >>From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] >>Sent: Thursday, June 22, 2006 7:19 PM >>To: Vijay Devarapalli; Behcet Sarikaya >>Cc: mip6@ietf.org; Heejin Jang; dhcwg@ietf.org >>Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for >>HomeInformationDiscovery inMIPv6 >> >>Sorry, I am not getting this. Why are we dragging WiMAX and >>3GPP2 references to justify the need for basic DHCP op-codes >>for HoA/HL/HA info? >> >>draft-jang-mip6-hiopt-00.txt defines the DHCPv6 op-codes for >>HA, HoA and HL info. >> >>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt is the >>MIP6 bootstrapping solution that leverages DHCPv6 for HA/HL >>bootstrapping. >> >>There are tons of I-Ds and solutions in IETF that leverage other I-Ds. >>So, what is so special here? The decision to NOT merge these >>I-Ds was taken in the bootstrap DT. Why are we wasting >>people's time here to revisit basic decisions? >> >>-Kuntal >> >> >> >>>-----Original Message----- >>>From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >>>Sent: Thursday, June 22, 2006 12:55 PM >>>To: Behcet Sarikaya >>>Cc: mip6@ietf.org; Heejin Jang; dhcwg@ietf.org >>>Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home >>>InformationDiscovery inMIPv6 >>> >>>Behcet Sarikaya wrote: >>> >>>>Hi Vijay, >>>>The idea in the present WiMAX document is quite simple: >>>>it uses EAP-PKMv2 (which is like 802.11i) authentication >> >>and during >>EAP >> >>>>transaction, they assume that AAA server determines that >> >>the MS is a >> >>>>CMIPv6 authorized user based on the AAA profile and it >> >>will include >>all >> >>>>the so-called bootstrapping info in the Access-Accept. Then MS can >> >>use >> >>>>RFC 3736 to make a DHCP Information Request to DHCP Relay >> >>colocated >>with >> >>>>NAS and use draft-jang (extended now with HoA) and receive all the >> >>info >> >>>>to configure MIP6. >>> >>>the DHCP Relay replies to the MN without relaying the DHCP request >>>from the MN to a DHCP server? this is not allowed with the current >>>IETF specs. >>> >>> >>>> In this setup can you make a case for >>>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt? >>> >>>as far as I am concerned, >>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt >>>is the document that describes how to use DHCPv6 for MIPv6 >>>bootstrapping. as for the setup in the WiMAX NWG, it is >> >>something that >> >>>doesn't conform to the IETF DHCP specs. >>> >>>Vijay >>> >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 26 19:02:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv06T-0006Wf-DN; Mon, 26 Jun 2006 19:02:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzuA-0004TS-6X; Mon, 26 Jun 2006 18:50:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuzuA-0007fR-4B; Mon, 26 Jun 2006 18:50:06 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fuzu6-0007nC-Je; Mon, 26 Jun 2006 18:50:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5QMo2WR010155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fuzu6-00080V-6j; Mon, 26 Jun 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 26 Jun 2006 18:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-whyauthdataoption-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Why Authentication Data suboption is needed for MIP6 Author(s) : B. Patil, G. Dommety Filename : draft-ietf-mip6-whyauthdataoption-01.txt Pages : 16 Date : 2006-6-26 Mobile IPv6 defines a set of messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec SA that is established between the MN and HA. The MIP6 working group has proposed a mechanism to secure the binding update and binding acknowledgement messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain deployment environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-whyauthdataoption-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip6-whyauthdataoption-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-whyauthdataoption-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-26173730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-whyauthdataoption-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-whyauthdataoption-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-26173730.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Mon Jun 26 19:24:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv0Rk-00018A-0V; Mon, 26 Jun 2006 19:24:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzyK-0003LZ-6G for mip6@ietf.org; Mon, 26 Jun 2006 18:54:25 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuzyG-0000T9-VP for mip6@ietf.org; Mon, 26 Jun 2006 18:54:23 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 15:53:20 -0700 Message-ID: <44A064DE.2010301@azairenet.com> Date: Mon, 26 Jun 2006 15:51:10 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Heejin Jang Subject: Re: [Mip6] [Updated] DHCP Option for Home InformationDiscovery inMIPv6 References: <002201c698f5$d916aff0$b129024b@LocalHost> In-Reply-To: <002201c698f5$d916aff0$b129024b@LocalHost> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2006 22:53:20.0902 (UTC) FILETIME=[52611260:01C69973] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Heejin Jang wrote: > Hi, Vijay > > What does "it does more" mean? see my reply to Kent. > The idea of this draft is simply "using DHCP in order to provide HA/HL/HoA" > as the same way > as providing other parameters such as IP addresses or DNS/NTP servers. > Though the draft > allows bootstrapping, it does not specify or is limited to any mechanism or > procedure for bootstrapping. this *is* the problem. we can't have two drafts that both describe how to use DHCPv6 for MIP6 bootstrapping. > For e.g., the idea is also appicable in HMIPv6 map discovery. It can be used > where the mobile node > is required to discover the MAP (a special home agent) that is located > multiple hops away from the > mobile node's attachment point. MIP6 charter does not address HMIPv6 map discovery. > If the use cases are not limited to only bootstrapping, what other use cases? are those use cases specific to Mobile IPv6? do they fit into the MIP6 WG charter? Vijay > > Thanks for your interest. > > Regards, > Heejin. > > -----Original Message----- > From: Vijay Devarapalli [mailto:Vijay.Devarapalli@AzaireNet.com] > Sent: Saturday, June 24, 2006 12:35 AM > To: Chowdhury, Kuntal; Behcet Sarikaya > Cc: mip6@ietf.org; Heejin Jang > Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home > InformationDiscovery inMIPv6 > > dropped the DHC WG from the cc list. > > >>Sorry, I am not getting this. Why are we dragging WiMAX and 3GPP2 >>references to justify the need for basic DHCP op-codes for HoA/HL/HA >>info? > > > well, some folks were trying to justify draft-jang-mip6-hiopt-00.txt by > mentioning WiMAX. > perhaps you should go through the entire thread. > > >>draft-jang-mip6-hiopt-00.txt defines the DHCPv6 op-codes for HA, HoA >>and HL info. > > > it does more. it tries to also specify a DHCP based > MIP6 bootstrapping protocol. > > >>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt is the MIP6 >>bootstrapping solution that leverages DHCPv6 for HA/HL bootstrapping. > > > yes. my point exactly. > > >>There are tons of I-Ds and solutions in IETF that leverage other I-Ds. >>So, what is so special here? The decision to NOT merge these I-Ds was >>taken in the bootstrap DT. Why are we wasting people's time here to >>revisit basic decisions? > > > uh?? we *couldn't* reach a conclusion. check the archives. we decided to > come back to this later. > > big concern is that there can't be two drafts that both specify how to use > DHCP for MIP6 bootstrapping. > my suggestion is to fold the DHCP options into the current working document > and have WiMAX and 3GPP2 refer to this draft. > > Vijay > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 26 19:40:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv0gX-0005ZJ-1c; Mon, 26 Jun 2006 19:40:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv0gW-0005W5-Br for mip6@ietf.org; Mon, 26 Jun 2006 19:40:04 -0400 Received: from web60313.mail.yahoo.com ([209.73.178.136]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fv0gV-0005V6-UD for mip6@ietf.org; Mon, 26 Jun 2006 19:40:04 -0400 Received: (qmail 92864 invoked by uid 60001); 26 Jun 2006 23:40:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=s7Pg5EPkQVSUufq+AaASt+el3/tirAghUgpM33yFqJTcD1tk3qpnThh91WC7Y/aDx9b5IlslCOF9nszMb3Ql/A8L0DTqAPLXCZBFCBS5INbHUaM/JIU0JoTdk7n6kZRKfp6O9e4gpsvqEKYqN351C24C6hSUXupZCgk3z8Ri7ws= ; Message-ID: <20060626234003.92862.qmail@web60313.mail.yahoo.com> Received: from [12.129.211.52] by web60313.mail.yahoo.com via HTTP; Mon, 26 Jun 2006 16:40:03 PDT Date: Mon, 26 Jun 2006 16:40:03 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 To: Alexandru Petrescu In-Reply-To: <44A04BCE.4030208@motorola.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0855206875==" Errors-To: mip6-bounces@ietf.org --===============0855206875== Content-Type: multipart/alternative; boundary="0-792357608-1151365203=:90637" --0-792357608-1151365203=:90637 Content-Type: text/plain; charset=us-ascii Hi Alex, FYI netlmm DT just issued their draft with 8 (yes, one more than 7) authors, while in HA reliability DT we issued the draft with one author and a list of contributors. So there are different approaches people take. I agree with Hesham in that this is not a big issue. I believe that that there are virtues of including everyone who contributed in the author list. Why not? Regards, --behcet ----- Original Message ---- From: Alexandru Petrescu To: "Tsirtsis, George" Cc: mip6@ietf.org Sent: Monday, June 26, 2006 4:04:14 PM Subject: Re: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 Tsirtsis, George wrote: > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@motorola.com] Sent: Monday, June 26, >> 2006 3:16 PM To: Soliman, Hesham Cc: mip6@ietf.org; Basavaraj Patil >> Subject: Re: [Mip6] Draft agenda for MIP6 WG meeting at IETF66 >> >> Soliman, Hesham wrote: >>>>> => What does this have to do with the agenda??? >>>> Because the suggestion was made to restrain the number of >>>> authors, and the suggestion was not considered, I don't see why >>>> spending WG meeting time in discussing all over. >>> => I didn't request a slot to discuss the number of authors on >>> the draft. I noted your comment before but it's not the most >>> important issue to handle now. >> To me it is paramount. Many authors means more difficulty in >> reaching editing agreement, or risk document to not reflect some >> authors' oppinions. >> > > GT> Alex, this is a non-issue, you are inventing prowblems. George - I consider it a problem having 7 authors on the frontpage. >>>>> => Please be specific. What comments were made on this >>>> draft and not >>>>> included? >>>> One original problem statement is in the >>>> draft-wakikawa-nemo-v4tunnel-01.txt. The encapsulating tunnel >>>> problem in that draft is not reflected. That problem >>>> statement resulted in having IPv4 addresses in BU. But the >>>> entire DS-MIPv6 draft is not based on only this problem >>>> statement. >>>> >>>> Other problem statement existed and expired in >>>> draft-larsson-v6ops-mip-scenarios-01.txt >>> => That was not a problem statement it's a scenarios document. >>> It's interesting that you are choosing to ignore the original >>> problem statement that the WG accepted. What specifically is your >>> comment on the current draft? As opposed to listing other >>> documents. >> Efficiency (or lack thereof) can not base a problem statement. The >> issues: >> >>> - Mobile nodes to be both MIPv4 and MIPv6 capable. - Mobile nodes >>> to send two sets of signaling messages on every handoff. - >>> Network Administrators to run and maintain two sets of mobility >>> management systems on the same network. Each of these systems >>> requiring their own sets of optimizations that may include >>> hierarchical Mobile IPv4, hierarchical Mobile IPv6 and Fast >>> Handoffs for Mobile IPv4, mechanisms that are currently in >>> development in the IETF. >> Small phones can easily do both mip4 and mip6. With MIP4+MIP6 and >> connected to a v4-access the MN only does MIP4 messaging upon >> handover, not MIP6 messaging. MIP4+MIP6 do not involve running >> HMIP4+HMIP6. >> > > GT> It is of course possible to run MIPv4 and MIPv6. DS-MIP came up, > however, because some of us did not want to do that for a variety of > reasons which are explained in the problem statement > (draft-ietf-mip6-dsmip-problem-02.txt) It's not really my intention to spend a lot of time on this. I have posted remarks to the issues since miptrans. The essence of it is in my message, you seem to have missed it. Additionally, citing double SA maintenance for v4 and v6 is forgetting that MIP6 does that automatically for v6, so comes down to v4 only, as before. Additionally, citing implementation burdens for supporting MIP4+MIP6 is forgetting that MIP6 extensions _are_ implementation effort to become DS-MIPv6. > and have been accepted by the majority of the WG. majority-1. > I do not think going over all this again is useful. Same on my side. I think I'll stop... BTW, are you planning to confirm acceptation of your suggested modifs to the NEMOv4 draft (it's submitted now)? Alex --0-792357608-1151365203=:90637 Content-Type: text/html; charset=us-ascii
Hi Alex,
  FYI netlmm DT just issued their draft with 8 (yes, one more than 7) authors, while in HA reliability DT we issued the draft with one author and a list of contributors. So there are different approaches people take.
  I agree with Hesham in that this is not a big issue. I believe that that there are virtues of including everyone who contributed in the author list. Why not?
  Regards,

--behcet

----- Original Message ----
From: Alexandru Petrescu <alexandru.petrescu@motorola.com>
To: "Tsirtsis, George" <tsirtsis@qualcomm.com>
Cc: mip6@ietf.org
Sent: Monday, June 26, 2006 4:04:14 PM
Subject: Re: [Mip6] Draft agenda for MIP6 WG meeting at IETF66

Tsirtsis, George wrote:
>
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:alexandru.petrescu@motorola.com] Sent: Monday, June 26,
>> 2006 3:16 PM To: Soliman, Hesham Cc: mip6@ietf.org; Basavaraj Patil
>>  Subject: Re: [Mip6] Draft agenda for MIP6 WG meeting at IETF66
>>
>> Soliman, Hesham wrote:
>>>>> => What does this have to do with the agenda???
>>>> Because the suggestion was made to restrain the number of
>>>> authors, and the suggestion was not considered, I don't see why
>>>>  spending WG meeting time in discussing all over.
>>> => I didn't request a slot to discuss the number of authors on
>>> the draft. I noted your comment before but it's not the most
>>> important issue to handle now.
>> To me it is paramount.  Many authors means more difficulty in
>> reaching editing agreement, or risk document to not reflect some
>> authors' oppinions.
>>
>
> GT> Alex, this is a non-issue, you are inventing prowblems.

George - I consider it a problem having 7 authors on the frontpage.

>>>>> => Please be specific. What comments were made on this
>>>> draft and not
>>>>> included?
>>>> One original problem statement is in the
>>>> draft-wakikawa-nemo-v4tunnel-01.txt.   The encapsulating tunnel
>>>>  problem in that draft is not reflected.  That problem
>>>> statement resulted in having IPv4 addresses in BU.  But the
>>>> entire DS-MIPv6 draft is not based on only this problem
>>>> statement.
>>>>
>>>> Other problem statement existed and expired in
>>>> draft-larsson-v6ops-mip-scenarios-01.txt
>>> => That was not a problem statement it's a scenarios document.
>>> It's interesting that you are choosing to ignore the original
>>> problem statement that the WG accepted. What specifically is your
>>>  comment on the current draft? As opposed to listing other
>>> documents.
>> Efficiency (or lack thereof) can not base a problem statement.  The
>>  issues:
>>
>>> - Mobile nodes to be both MIPv4 and MIPv6 capable. - Mobile nodes
>>>  to send two sets of signaling messages on every handoff. -
>>> Network Administrators to run and maintain two sets of mobility
>>> management systems on the same network. Each of these systems
>>> requiring their own sets of optimizations that may include
>>> hierarchical Mobile IPv4, hierarchical Mobile IPv6 and Fast
>>> Handoffs for Mobile IPv4, mechanisms that are currently in
>>> development in the IETF.
>> Small phones can easily do both mip4 and mip6. With MIP4+MIP6 and
>> connected to a v4-access the MN only does MIP4 messaging upon
>> handover, not MIP6 messaging. MIP4+MIP6 do not involve running
>> HMIP4+HMIP6.
>>
>
> GT> It is of course possible to run MIPv4 and MIPv6. DS-MIP came up,
> however, because some of us did not want to do that for a variety of
> reasons which are explained in the problem statement
> (draft-ietf-mip6-dsmip-problem-02.txt)

It's not really my intention to spend a lot of time on this.  I have
posted remarks to the issues since miptrans.  The essence of it is in my
message, you seem to have missed it.

Additionally, citing double SA maintenance for v4 and v6 is forgetting
that MIP6 does that automatically for v6, so comes down to v4 only, as
before.

Additionally, citing implementation burdens for supporting MIP4+MIP6 is
forgetting that MIP6 extensions _are_ implementation effort to become
DS-MIPv6.

> and have been accepted by the majority of the WG.

majority-1.

> I do not think going over all this again is useful.

Same on my side.  I think I'll stop...

BTW, are you planning to confirm acceptation of your suggested modifs to
the NEMOv4 draft (it's submitted now)?

Alex



--0-792357608-1151365203=:90637-- --===============0855206875== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0855206875==-- From mip6-bounces@ietf.org Tue Jun 27 04:36:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv93Z-0008Vp-0w; Tue, 27 Jun 2006 04:36:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv93Y-0008Vk-0V for mip6@ietf.org; Tue, 27 Jun 2006 04:36:24 -0400 Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv93X-0006pK-EY for mip6@ietf.org; Tue, 27 Jun 2006 04:36:23 -0400 Received: from rly14d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly14d.srv.mailcontrol.com (MailControl) with ESMTP id k5R8ZkJG011734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Jun 2006 09:36:00 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly14d.srv.mailcontrol.com (MailControl) id k5R8Za4I011236 for mip6@ietf.org; Tue, 27 Jun 2006 09:35:37 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly14d-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id k5R8ZBjh010142; Tue, 27 Jun 2006 09:35:36 +0100 (BST) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 644d_4993f3d6_05b2_11db_81ab_0030482aac25; Tue, 27 Jun 2006 09:55:22 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2006062710350501-105822 ; Tue, 27 Jun 2006 10:35:05 +0200 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: 0.575,BAYES_00: -1.665, SARE_RECV_ADDR: 0.027 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Tue, 27 Jun 2006 10:38:38 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: FW: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt Thread-Index: AcaZxHSX1geoI4pISzCN9TOe8QiBMwAAAcjA To: "DENG, HUI -HCHBJ" Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4FC56712@lan-ex-01.panasonic.de> Date: Tue, 27 Jun 2006 10:34:58 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-2022-JP" X-Scanned-By: MailControl A-07-00-10 (www.mailcontrol.com) on 10.68.1.124 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hui, > -----Original Message----- > From: "DENG, HUI -HCHBJ" [mailto:hdeng@hitachi.cn] > Sent: Freitag, 23. Juni 2006 15:20 > To: Kilian Weniger; Brian Haley > Cc: mip6@ietf.org > Subject: RE: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt > > Hi, Kilian, > > I start to understood what you mean here, > You would like to do geographical different home prefix load balance, > I am a little thinking about this usage in the real word. For example if all HAs on the link are almost overloaded or if the home link itself is almost overloaded, it would be good to support load balancing between HAs on different links. Another usage scenario would be optimized routing: another HA on a different link (e.g., a more local HA) may provide a shorter route. > > but one thing interested me is that > your session is still kept in the previous home agent, is it > called load balance? The load caused by new sessions is shifted from one HA to another, so I would call it load balancing (even though the load for existing sessions remains at the old HA for the time the sessions are active) > > Secondly, how could MN notify CN about its HoA changing. By DNS updates (see draft-ietf-mip6-bootstrapping-split-02.txt) or by some application-level signaling (e.g., SIP) > > I suggest that if possible you could write up your solution. > Then we could figure out its applicability. I probably won't have enough time in the next days. Do you need more information than provided in the mails to decide about the applicability? -Kilian > > Thanks > > -Hui > > > > > -----Original Message----- > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > Sent: 2006年6月23日 16:04 > > To: DENG, HUI -HCHBJ; Kilian Weniger; Brian Haley > > Cc: mip6@ietf.org > > Subject: RE: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt > > > > > > Hi Hui, > > > > The MN would setup Ipsec SAs using IKE with the second HA > > (which is located on a different link than the first HA). The > > new Ipsec Sas would be based on the new HoA (whose prefix is > > not served by the first HA). The IPSec Sas with the first > > (old) HA are still setup based on the old HoA. Can you > > elaborate what would be the issue with that? > > > > -Kilian > > > > > -----Original Message----- > > > From: "DENG, HUI -HCHBJ" [mailto:hdeng@hitachi.cn] > > > Sent: Freitag, 23. Juni 2006 09:41 > > > To: Kilian Weniger; Brian Haley > > > Cc: mip6@ietf.org > > > Subject: RE: [Mip6] RE: I-D > ACTION:draft-ietf-mip6-ha-switch-00.txt > > > > > > > > > Could you help to elaborate how IKE/IPsec SA could work in > > > this scenario? > > > is that session based or address based? > > > > > > -Hui > > > > > > > -----Original Message----- > > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > > > Sent: 2006年6月23日 15:34 > > > > To: Brian Haley > > > > Cc: mip6@ietf.org > > > > Subject: RE: [Mip6] RE: I-D > > ACTION:draft-ietf-mip6-ha-switch-00.txt > > > > > > > > > > > > Brian, > > > > > > > > In my last mail I described scenarios that the current draft > > > > does not support (see snippet below) and sketched an > > > > extension to support such scenarios. What do you and the > > > > authors of the draft think about this? For instance, > > > > shouldn't load balancing between HAs serving different links > > > > be supported? MN could obtain a new HoA from the new HA and > > > > keep the old HA/HoA as secondary for existing sessions only > > > > (e.g., old IPv6 HoA is moved to deprecated state, new one to > > > > preferred state)? > > > > > > > > - Kilian > > > > > > > > > > > > > Scenarios > > > > > I have in mind are that the network (i.e., HA) can direct > > > the MN to > > > > > another HA on a different link (e.g., to a more local > > > HA), which is > > > > > better with respect to optimized routing or for load > > > > balancing between > > > > > HAs on different links. ... > > > > > The modification I had in mind just extends the > > > applicability of the > > > > > switch mechanism by allowing the HA to send switch messages > > > > to direct > > > > > the MN to a HA serving a different link and continue to > > serve as > > > > > secondary HA. > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > Disclaimer: > > > The contents of this e-mail, and its attachments, if any, are > > > confidential and may be protected > > > by law against any unauthorized use. If you have received > > > this e-mail by mistake or have > > > reason to believe that you are not the intended recipient, > > > please notify the sender by reply > > > e-mail as soon as possible and delete it from your computer > > > system immediately thereafter. > > > If you are not the intended recipient, you must not copy this > > > e-mail or attachment or disclose > > > the contents to any other person. While we have made every > > > effort to keep our network virus free, > > > we take no responsibility for any computer virus which might > > > be transferred by way of this e-mail. > > > > > > > > > > > Disclaimer: > The contents of this e-mail, and its attachments, if any, are > confidential and may be protected > by law against any unauthorized use. If you have received > this e-mail by mistake or have > reason to believe that you are not the intended recipient, > please notify the sender by reply > e-mail as soon as possible and delete it from your computer > system immediately thereafter. > If you are not the intended recipient, you must not copy this > e-mail or attachment or disclose > the contents to any other person. While we have made every > effort to keep our network virus free, > we take no responsibility for any computer virus which might > be transferred by way of this e-mail. > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 27 04:40:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv97z-0000Vp-Ev; Tue, 27 Jun 2006 04:40:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv97y-0000Vk-P8 for mip6@ietf.org; Tue, 27 Jun 2006 04:40:58 -0400 Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv97y-0006w0-6V for mip6@ietf.org; Tue, 27 Jun 2006 04:40:58 -0400 Received: from rly15d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly15d.srv.mailcontrol.com (MailControl) with ESMTP id k5R8eueJ013614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Jun 2006 09:40:56 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly15d.srv.mailcontrol.com (MailControl) id k5R8ekQZ013276 for mip6@ietf.org; Tue, 27 Jun 2006 09:40:46 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly15d-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id k5R8eLDr012676; Tue, 27 Jun 2006 09:40:46 +0100 (BST) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 6394_01ed8744_05b3_11db_9bd9_0030482aac25; Tue, 27 Jun 2006 10:00:32 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2006062710401752-106254 ; Tue, 27 Jun 2006 10:40:17 +0200 X-Spam-Status: No, hits=0.0 required=6.5 tests=ALL_TRUSTED: -2.867,AWL: 0.570,BAYES_00: -1.665, SARE_RECV_ADDR: 0.027 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Tue, 27 Jun 2006 10:43:51 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt In-Reply-To: <449BF8F0.8090304@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt Thread-Index: AcaW0GuTDQOQp19pT3eZ7uQ3mmUwtQC9DDvw To: "Brian Haley" Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4FC56715@lan-ex-01.panasonic.de> Date: Tue, 27 Jun 2006 10:40:11 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-2022-JP" X-Scanned-By: MailControl A-07-00-10 (www.mailcontrol.com) on 10.68.1.125 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: mip6@ietf.org, "DENG, HUI -HCHBJ" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Brian, > -----Original Message----- > From: Brian Haley [mailto:brian.haley@hp.com] > Sent: Freitag, 23. Juni 2006 16:22 > To: Kilian Weniger > Cc: "DENG, HUI -HCHBJ"; mip6@ietf.org > Subject: Re: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt > > Kilian, > > This is starting to sound something like HA-HA, > draft-wakikawa-mip6-nemo-haha-01.txt. this draft is going much further (proxy HAs, synchronising BCs between HAs, tunneling between HAs etc.) > > The scenario you describe isn't restricted by RFC 3775, you can have > multiple home addresses with multiple HAs if you like. You could then > use different HoAs for talking to different CNs based on some > preferences you have configured. yes, using multiple HoA is possible. But the problem is that only the HAs know when they are overloaded. Consequently, some signaling (such as a switch message) is necessary to inform the MN that it should change the HA and possibly the primary HoA for load balancing reasons. > > As Hui mentioned - if you could write this up it would help us > understand what you're trying to do and determine if the > HA-switch draft > is the right place to do it. see my last mail -Kilian > > Thanks, > > -Brian > > > +ACI-DENG, HUI -HCHBJ+ACI- wrote: > > Hi, Kilian, > > > > I start to understood what you mean here, > > You would like to do geographical different home prefix > load balance, > > I am a little thinking about this usage in the real word. > > > > but one thing interested me is that > > your session is still kept in the previous home agent, is > it called load balance? > > > > Secondly, how could MN notify CN about its HoA changing. > > > > I suggest that if possible you could write up your solution. > > Then we could figure out its applicability. > > > > Thanks > > > > -Hui > > > > > > > >> -----Original Message----- > >> From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > >> Sent: 2006年6月23日 16:04 > >> To: DENG, HUI -HCHBJ; Kilian Weniger; Brian Haley > >> Cc: mip6@ietf.org > >> Subject: RE: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt > >> > >> > >> Hi Hui, > >> > >> The MN would setup Ipsec SAs using IKE with the second HA > >> (which is located on a different link than the first HA). The > >> new Ipsec Sas would be based on the new HoA (whose prefix is > >> not served by the first HA). The IPSec Sas with the first > >> (old) HA are still setup based on the old HoA. Can you > >> elaborate what would be the issue with that? > >> > >> -Kilian > >> > >>> -----Original Message----- > >>> From: "DENG, HUI -HCHBJ" [mailto:hdeng@hitachi.cn] > >>> Sent: Freitag, 23. Juni 2006 09:41 > >>> To: Kilian Weniger; Brian Haley > >>> Cc: mip6@ietf.org > >>> Subject: RE: [Mip6] RE: I-D > ACTION:draft-ietf-mip6-ha-switch-00.txt > >>> > >>> > >>> Could you help to elaborate how IKE/IPsec SA could work in > >>> this scenario? > >>> is that session based or address based? > >>> > >>> -Hui > >>> > >>>> -----Original Message----- > >>>> From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > >>>> Sent: 2006年6月23日 15:34 > >>>> To: Brian Haley > >>>> Cc: mip6@ietf.org > >>>> Subject: RE: [Mip6] RE: I-D > >> ACTION:draft-ietf-mip6-ha-switch-00.txt > >>>> > >>>> Brian, > >>>> > >>>> In my last mail I described scenarios that the current draft > >>>> does not support (see snippet below) and sketched an > >>>> extension to support such scenarios. What do you and the > >>>> authors of the draft think about this? For instance, > >>>> shouldn't load balancing between HAs serving different links > >>>> be supported? MN could obtain a new HoA from the new HA and > >>>> keep the old HA/HoA as secondary for existing sessions only > >>>> (e.g., old IPv6 HoA is moved to deprecated state, new one to > >>>> preferred state)? > >>>> > >>>> - Kilian > >>>> > >>>> > >>>>> Scenarios > >>>>> I have in mind are that the network (i.e., HA) can direct > >>> the MN to > >>>>> another HA on a different link (e.g., to a more local > >>> HA), which is > >>>>> better with respect to optimized routing or for load > >>>> balancing between > >>>>> HAs on different links. ... > >>>>> The modification I had in mind just extends the > >>> applicability of the > >>>>> switch mechanism by allowing the HA to send switch messages > >>>> to direct > >>>>> the MN to a HA serving a different link and continue to > >> serve as > >>>>> secondary HA. > >>>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Mip6 mailing list > >>>> Mip6@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/mip6 > >>>> > >>> Disclaimer: > >>> The contents of this e-mail, and its attachments, if any, are > >>> confidential and may be protected > >>> by law against any unauthorized use. If you have received > >>> this e-mail by mistake or have > >>> reason to believe that you are not the intended recipient, > >>> please notify the sender by reply > >>> e-mail as soon as possible and delete it from your computer > >>> system immediately thereafter. > >>> If you are not the intended recipient, you must not copy this > >>> e-mail or attachment or disclose > >>> the contents to any other person. While we have made every > >>> effort to keep our network virus free, > >>> we take no responsibility for any computer virus which might > >>> be transferred by way of this e-mail. > >>> > >>> > >> > > Disclaimer: > > The contents of this e-mail, and its attachments, if any, > are confidential and may be protected > > by law against any unauthorized use. If you have received > this e-mail by mistake or have > > reason to believe that you are not the intended recipient, > please notify the sender by reply > > e-mail as soon as possible and delete it from your computer > system immediately thereafter. > > If you are not the intended recipient, you must not copy > this e-mail or attachment or disclose > > the contents to any other person. While we have made every > effort to keep our network virus free, > > we take no responsibility for any computer virus which > might be transferred by way of this e-mail. > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 27 12:02:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvG16-0007VW-Ik; Tue, 27 Jun 2006 12:02:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvG15-0007UN-G5 for mip6@ietf.org; Tue, 27 Jun 2006 12:02:19 -0400 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvG14-0001lY-79 for mip6@ietf.org; Tue, 27 Jun 2006 12:02:19 -0400 Received: from smtp1.fc.hp.com (smtp1.fc.hp.com [15.15.136.127]) by atlrel7.hp.com (Postfix) with ESMTP id 77E2A35999; Tue, 27 Jun 2006 12:02:15 -0400 (EDT) Received: from [16.116.96.215] (spaceshipone.zko.hp.com [16.116.96.215]) by smtp1.fc.hp.com (Postfix) with ESMTP id BD8A927C3D; Tue, 27 Jun 2006 16:02:14 +0000 (UTC) Message-ID: <44A15685.70008@hp.com> Date: Tue, 27 Jun 2006 12:02:13 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: Kilian Weniger Subject: Re: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt References: <4D2F935F08D41A4C8866693F4F0D7C4FC56715@lan-ex-01.panasonic.de> In-Reply-To: <4D2F935F08D41A4C8866693F4F0D7C4FC56715@lan-ex-01.panasonic.de> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mip6@ietf.org, "DENG, HUI -HCHBJ" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org >> This is starting to sound something like HA-HA, >> draft-wakikawa-mip6-nemo-haha-01.txt. > > this draft is going much further (proxy HAs, synchronising BCs between HAs, tunneling between HAs etc.) Agree, but some of it does apply, that was my point. >> The scenario you describe isn't restricted by RFC 3775, you can have >> multiple home addresses with multiple HAs if you like. You could then >> use different HoAs for talking to different CNs based on some >> preferences you have configured. > > yes, using multiple HoA is possible. But the problem is that only the HAs know when they are overloaded. Consequently, some signaling (such as a switch message) is necessary to inform the MN that it should change the HA and possibly the primary HoA for load balancing reasons. The HA-switch message is just a mechanism to have a MN remove it's binding with a HA and move it elsewhere, the draft is not going to solve any load-balancing issues - that is outside the scope of the document: 6. Operational Considerations This document does not specify how an operator might use the Home Agent Switch message in its network. >> As Hui mentioned - if you could write this up it would help us >> understand what you're trying to do and determine if the >> HA-switch draft >> is the right place to do it. > > see my last mail I think what Hui and I were getting at was that you need to write a draft about load-balancing and how it might be achieved given HAs on the same (or different) links, messaging, etc. We've done that in an expired draft already :) -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 27 12:09:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvG7Y-00044h-Aw; Tue, 27 Jun 2006 12:09:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvG7X-00044c-PY for mip6@ietf.org; Tue, 27 Jun 2006 12:08:59 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvG7X-00035D-5t for mip6@ietf.org; Tue, 27 Jun 2006 12:08:59 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 27 Jun 2006 09:08:58 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5RG8wL4029881; Tue, 27 Jun 2006 09:08:58 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5RG8okq026648; Tue, 27 Jun 2006 09:08:58 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Jun 2006 09:08:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for HomeInformationDiscovery inMIPv6 Date: Tue, 27 Jun 2006 09:08:49 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52020C90B1@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] RE: [Mip6] [Updated] DHCP Option for HomeInformationDiscovery inMIPv6 Thread-Index: AcaZca/nesND/VKMTNaQZyLKbhmUjAAkfv8g From: "Kent Leung ¥(kleung¥)" To: "Vijay Devarapalli" X-OriginalArrivalTime: 27 Jun 2006 16:08:52.0598 (UTC) FILETIME=[FBC18160:01C69A03] DKIM-Signature: a=rsa-sha1; q=dns; l=5888; t=1151424538; x=1152288538; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20¥(kleung¥)=22=20 |Subject:RE=3A=20[dhcwg]=20RE=3A=20[Mip6]=20[Updated]=20DHCP=20Option=20for=20Hom eInformationDiscovery=20inMIPv6; X=v=3Dcisco.com=3B=20h=3DJYf6MBNa8mTiQH9SoxmdmxHW/20=3D; b=OqKTX+EtFLcqo131XOEp20nrhrynYzqpX2jz+T05BRsufHBvpl5u1gsrJk0HlucHekIwkJ7a 7rO1qWoBmdE1rwFlsD0orOeRcpDCJnRMelqS5st/g6+CWr2T/jMnlmHt; Authentication-Results: sj-dkim-3.cisco.com; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay. My take is still the same. Have one draft for DHCP option for MIPv6 parameters. The MIPv6 bootstrap draft should only reference this draft for DHCP options it needs. Other SDO specs can also reference this draft for their bootstrapping needs. Kent > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com]=20 > Sent: Monday, June 26, 2006 3:39 PM > To: Kent Leung (kleung) > Cc: mip6@ietf.org > Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for=20 > HomeInformationDiscovery inMIPv6 >=20 > (left out the DHC WG from the cc list). >=20 > there is one issue. >=20 > draft-jang just does not define the DHCP options. it goes further. > abstract of draft-jang says >=20 > This draft defines a DHCP-based scheme to enable dynamic=20 > discovery of > Mobile IPv6 home agent address, home address, and home=20 > subnet. New > DHCP options are defined to carry the information from a=20 > DHCP server > to the DHCP client running on the mobile node. >=20 > section 4.2 further goes and ahead and specifies mobile node=20 > behavior. the draft just does not define the options. it is=20 > also incomplete because it neither describes the scope of the=20 > problem it is trying to address nor gives a complete solution. >=20 > we can't have two documents that both describe how to use=20 > DHCP for MIP6 bootstrapping. >=20 > Vijay >=20 > Kent Leung (kleung) wrote: > > Hi Kuntal and Vijay. > >=20 > > See my posting, "Generalizing draft-jang-dhc-haopt for=20 > MIPv6 support=20 > > in DHCP", back on Jan 4, 2006 on this topic. I proposed to=20 > keep the 2=20 > > drafts separate, one for defining DHCPv6 opcodes for MIPv6=20 > parameters=20 > > and a bootstrap draft that references the DHCP options needed to=20 > > achieve its function. > >=20 > > I agree there's no need to drag in references other to say that=20 > > there's value for the DHCP MIPv6 options. 3GPP2/WiMAX specs can=20 > > reference the > > DHCPv6 opcodes for MIPv6 draft/RFC, much like what MIPv6 bootstrap=20 > > would have done. > >=20 > > As for what Vijay said about the WiMAX scheme, definitely=20 > true that it=20 > > doesn't conform to DHCP RFC 3315. But we should keep the issues=20 > > separate. I haven't read all the emails on the thread. =20 > Just jumping=20 > > in to say the following: > >=20 > > - Keep 2 separate self contained drafts > > - IETF MIPv6 bootstrap draft references DHCP for MIPv6 draft > > - WiMAX and 3GPP2 can also reference DHCP for MIPv6 draft=20 > for their=20 > > bootstrapping schemes > >=20 > > Just some explanatory comments: > > - 3GPP2 conforms to DHCPv6 in its bootstrapping scheme > > - WiMAX does not conform to DHCPv6 when using proxy DHCP server=20 > > scheme > >=20 > > But *ALL* of the above bootstrapping schemes use the same=20 > DHCP options=20 > > for MIPv6 parameters. That's what justifies an independent DHCP for > > MIPv6 draft, IMHO. > >=20 > > Kent > >=20 > > =20 > >=20 > >=20 > >>-----Original Message----- > >>From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > >>Sent: Thursday, June 22, 2006 7:19 PM > >>To: Vijay Devarapalli; Behcet Sarikaya > >>Cc: mip6@ietf.org; Heejin Jang; dhcwg@ietf.org > >>Subject: RE: [dhcwg] RE: [Mip6] [Updated] DHCP Option for=20 > >>HomeInformationDiscovery inMIPv6 > >> > >>Sorry, I am not getting this. Why are we dragging WiMAX and > >>3GPP2 references to justify the need for basic DHCP op-codes for=20 > >>HoA/HL/HA info? > >> > >>draft-jang-mip6-hiopt-00.txt defines the DHCPv6 op-codes=20 > for HA, HoA=20 > >>and HL info. > >> > >>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt is the > >>MIP6 bootstrapping solution that leverages DHCPv6 for HA/HL=20 > >>bootstrapping. > >> > >>There are tons of I-Ds and solutions in IETF that leverage=20 > other I-Ds. > >>So, what is so special here? The decision to NOT merge=20 > these I-Ds was=20 > >>taken in the bootstrap DT. Why are we wasting people's time here to=20 > >>revisit basic decisions? > >> > >>-Kuntal > >> > >> > >> > >>>-----Original Message----- > >>>From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > >>>Sent: Thursday, June 22, 2006 12:55 PM > >>>To: Behcet Sarikaya > >>>Cc: mip6@ietf.org; Heejin Jang; dhcwg@ietf.org > >>>Subject: Re: [dhcwg] RE: [Mip6] [Updated] DHCP Option for Home=20 > >>>InformationDiscovery inMIPv6 > >>> > >>>Behcet Sarikaya wrote: > >>> > >>>>Hi Vijay, > >>>>The idea in the present WiMAX document is quite simple: > >>>>it uses EAP-PKMv2 (which is like 802.11i) authentication > >> > >>and during > >>EAP > >> > >>>>transaction, they assume that AAA server determines that > >> > >>the MS is a > >> > >>>>CMIPv6 authorized user based on the AAA profile and it > >> > >>will include > >>all > >> > >>>>the so-called bootstrapping info in the Access-Accept. Then MS can > >> > >>use > >> > >>>>RFC 3736 to make a DHCP Information Request to DHCP Relay > >> > >>colocated > >>with > >> > >>>>NAS and use draft-jang (extended now with HoA) and receive all the > >> > >>info > >> > >>>>to configure MIP6. > >>> > >>>the DHCP Relay replies to the MN without relaying the DHCP request=20 > >>>from the MN to a DHCP server? this is not allowed with the current=20 > >>>IETF specs. > >>> > >>> > >>>> In this setup can you make a case for=20 > >>>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt? > >>> > >>>as far as I am concerned, > >>>draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt > >>>is the document that describes how to use DHCPv6 for MIPv6=20 > >>>bootstrapping. as for the setup in the WiMAX NWG, it is > >> > >>something that > >> > >>>doesn't conform to the IETF DHCP specs. > >>> > >>>Vijay > >>> > >> >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 27 19:12:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMj5-0006dj-GR; Tue, 27 Jun 2006 19:12:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMj4-0006de-HI for mip6@ietf.org; Tue, 27 Jun 2006 19:12:10 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvMj3-0008Tt-63 for mip6@ietf.org; Tue, 27 Jun 2006 19:12:10 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 16:12:07 -0700 Message-ID: <44A1BAC2.4060207@azairenet.com> Date: Tue, 27 Jun 2006 16:09:54 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2006 23:12:07.0673 (UTC) FILETIME=[1C666E90:01C69A3F] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Mip6] [Fwd: I-D ACTION:draft-thaler-mobility-comparison-01.txt] X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org FYI ---------- Forwarded message ---------- From: Internet-Drafts@ietf.org Date: Jun 27, 2006 12:50 PM Subject: I-D ACTION:draft-thaler-mobility-comparison-01.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Comparison of Mobility-Related Protocols Author(s) : D. Thaler Filename : draft-thaler-mobility-comparison-01.txt Pages : 0 Date : 2006-6-27 Mobile IPv6 (MIP6), the Level 3 Multihoming Shim Protocol (SHIM6), and the Host Identity Protocol (HIP) all address various aspects of mobility and multi-homing in similar ways. This document gives a brief comparison of their features. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thaler-mobility-comparison-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-thaler-mobility-comparison-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-thaler-mobility-comparison-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 28 19:05:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvj6K-0004HJ-Ss; Wed, 28 Jun 2006 19:05:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvj6E-0004Aj-D9; Wed, 28 Jun 2006 19:05:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvj6E-0004Cy-BY; Wed, 28 Jun 2006 19:05:34 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fvj5o-0001HW-Or; Wed, 28 Jun 2006 19:05:11 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5SMo2jx017058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvirC-0004nV-5H; Wed, 28 Jun 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Jun 2006 18:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-aaa-ha-goals-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Goals for AAA-HA interface Author(s) : G. Giaretta, et al. Filename : draft-ietf-mip6-aaa-ha-goals-02.txt Pages : 12 Date : 2006-6-28 In commercial deployments Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the AAA infrastructure offers also a solution component for Mobile IPv6 bootstrapping in integrated and split scenarios. This document describes various scenarios where a AAA interface for Mobile IPv6 is actually required. Additionally, it lists design goals and requirements for such an interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip6-aaa-ha-goals-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-aaa-ha-goals-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-28164609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-aaa-ha-goals-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-aaa-ha-goals-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-28164609.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Wed Jun 28 20:44:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvkdT-0003qa-RV; Wed, 28 Jun 2006 20:43:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvkdQ-0003le-7G; Wed, 28 Jun 2006 20:43:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvjbq-00072M-Cm; Wed, 28 Jun 2006 19:38:14 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fvj5s-0001HW-Sv; Wed, 28 Jun 2006 19:05:14 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5SMo2jx017054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvirC-0004nJ-2l; Wed, 28 Jun 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 28 Jun 2006 18:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-nemo-v4traversal-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) Author(s) : H. Soliman, et al. Filename : draft-ietf-mip6-nemo-v4traversal-02.txt Pages : 23 Date : 2006-6-28 The current Mobile IPv6 and NEMO specification support only IPv6. Hence, this specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the HA. This specification allows also the Mobile Node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip6-nemo-v4traversal-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-nemo-v4traversal-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-28163805.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-nemo-v4traversal-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-nemo-v4traversal-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-28163805.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Thu Jun 29 06:02:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvtLp-0001aN-8g; Thu, 29 Jun 2006 06:02:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvtLJ-0000o2-Vq for mip6@ietf.org; Thu, 29 Jun 2006 06:01:49 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvsNu-0008J0-8e for mip6@ietf.org; Thu, 29 Jun 2006 05:00:26 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvsJn-0006SO-Vk for mip6@ietf.org; Thu, 29 Jun 2006 04:56:19 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 305592FE5E for ; Thu, 29 Jun 2006 10:55:59 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FvsKz-0006MC-OZ for mip6@ietf.org; Thu, 29 Jun 2006 10:57:25 +0200 Date: Thu, 29 Jun 2006 10:57:25 +0200 From: Julien Bournelle To: mip6@ietf.org Message-ID: <20060629085725.GB24409@ipv6-3.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: -2.6 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Mip6] I-D announcement: draft-bournelle-pana-mip6-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, FYI, we have submitted an I-D which explains how PANA could used to deliver the HA information to the PaC instead of DHCPv6 in the Integrated case. The draft can be found at: http://www.ietf.org/internet-drafts/draft-bournelle-pana-mip6-01.txt Any comments welcome, Julien Bournelle _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 29 09:22:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvwTZ-0007wE-IJ; Thu, 29 Jun 2006 09:22:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvwTX-0007w9-NR for mip6@ietf.org; Thu, 29 Jun 2006 09:22:31 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvwTW-0004TH-8F for mip6@ietf.org; Thu, 29 Jun 2006 09:22:31 -0400 Received: by nf-out-0910.google.com with SMTP id c2so57878nfe for ; Thu, 29 Jun 2006 06:22:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=GUcX+YreVhIf4xgJUMGopaOfbNSkWJ6xZFiw1LZVxq4FvxICZ172vepTzUlWKjhLbimdNtbZ3Q0Ad99Sw/2VGaPgsMQe3FUzb8/RcHX7k+sUWw24CjbFS0UipcIVOG/f4kHD0y5uP6GV+SFp62Z0hs8FRWxEeA4GnPofy8T8YjA= Received: by 10.48.43.12 with SMTP id q12mr1604636nfq; Thu, 29 Jun 2006 06:22:29 -0700 (PDT) Received: by 10.49.40.17 with HTTP; Thu, 29 Jun 2006 06:22:29 -0700 (PDT) Message-ID: Date: Thu, 29 Jun 2006 14:22:29 +0100 From: "Gerardo Giaretta" To: mip6@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [Mip6] New version of draft-ietf-mip6-aaa-ha-goals-02 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, this is the new version of the AAA-HA Goals draft. Our intention is to start asap a WGLC so that DIME WG can work on the solution. Please provide your comments before the meeting so that we can use the meeting time to solve the open issues. Thx, --Gerardo > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobility for IPv6 Working Group of the IETF. > > Title : Goals for AAA-HA interface > Author(s) : G. Giaretta, et al. > Filename : draft-ietf-mip6-aaa-ha-goals-02.txt > Pages : 12 > Date : 2006-6-28 > > In commercial deployments Mobile IPv6 can be a service offered by a > Mobility Services Provider (MSP). In this case all protocol > operations may need to be explicitly authorized and traced, requiring > the interaction between Mobile IPv6 and the AAA infrastructure. > Integrating the AAA infrastructure offers also a solution component > for Mobile IPv6 bootstrapping in integrated and split scenarios. > > This document describes various scenarios where a AAA interface for > Mobile IPv6 is actually required. Additionally, it lists design > goals and requirements for such an interface. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-mip6-aaa-ha-goals-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mip6-aaa-ha-goals-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 29 21:10:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw7We-0001VS-8O; Thu, 29 Jun 2006 21:10:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw7Wc-0001VI-Q0 for mip6@ietf.org; Thu, 29 Jun 2006 21:10:26 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw7Wb-0003g0-C2 for mip6@ietf.org; Thu, 29 Jun 2006 21:10:26 -0400 Received: from wee.isi.edu (wee.isi.edu [128.9.168.112]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5U19sp05255 for ; Thu, 29 Jun 2006 18:09:54 -0700 (PDT) From: Wei Ye To: mip6@ietf.org Content-Type: text/plain; charset=UTF-8 Date: Thu, 29 Jun 2006 18:09:53 -0700 Message-Id: <1151629793.10346.37.camel@wee.isi.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: weiye@isi.edu Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by boreas.isi.edu id k5U19sp05255 X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Subject: [Mip6] Deadline extension: ACM Workshop on Underwater Networks (WUWNet 2006) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Submission deadline has been extended to July 7, 2006. Our Apologies if you have received multiple copies of the CFP. Volkan Rodoplu and Wei Ye WUWNet 2006 Publicity Co-Chairs ----------------------------------------------------- The First ACM International Workshop on UnderWater Networks (WUWNet 2006) http://wuwnet.engr.uconn.edu/ In conjunction with ACM MobiCom 2006 September 25, 2006 Los Angeles, California, USA Sponsored by ACM SIGMOBILE Technical Co-Sponsorship: IEEE Oceanographic Engineering Society Financial Support Pending From: MIT SeaGrant, Boeing, DARPA, NSF ----------------------------------------------------- Important Dates *************** Submission deadline: July 7, 2006 Acceptance notification: July 28, 2006 Camera-ready version: August 11, 2006 Workshop date: September 25, 2006 Overview & Scope **************** The oceans cover 71% of the earth's surface and represent one of the least explored frontiers, yet the oceans are integral to climate regulation, nutrient production, oil retrieval and transportation. As such, there is significant interest in monitoring aquatic environments for scientific, environmental, commercial, safety, and military reasons. While there is a need for highly precise, real-time, fine grained spatio-temporal sampling of the ocean environment, current methods such as remote telemetry and sequential local sensing cannot satisfy current needs, let alone future needs. The notion of an underwater network is relatively new due to the lack of maturity of underwater acoustic communication. However, networks are necessary in order to achieve the monitoring goals noted above. The physical challenges of acoustic underwater communication require us to completely re-think how a network should be designed and deployed in this environment. Challenges to be overcome by underwater acoustic modem and network designers include: severely limited range-dependent bandwidth and attenuation, extensive time-varying multipath propagation, and low speed of sound propagation in water resulting in long propagation delays. Moreover, a unique feature of underwater networks is that the environment is constantly mobile, naturally causing the node passive mobility. All the above distinct features of underwater networks yield new challenges for every level of the network protocol suite. The goal of the proposed workshop is to bring together researchers and practioners in areas relevant to underwater networks. Thus, many layers of the "stack" from the physical layer to the application layer will be represented. The objective is to serve as a forum for presenting state of the art research, exchanging ideas and experiences, and facilitating interaction and collaboration. The workshop will span one day, including presentations of technical papers, tutorial/survey papers, a panel session and a poster/demo session. Submissions for regular technical papers and poster/demo extended abstracts should describe original research, not published or currently under review for other workshops, conferences, or journals. Topics of interest include, but are not limited to: - Network architecture design - Efficient acoustic communications - Cooperative underwater communications - Medium access control - Routing and forwarding - Reliable data transfer - Security and robustness - Power management - Data storage and management - Localization and synchronization - Data fusion, dissemination, tracking - Network modeling and simulations - Capacity analysis - New techniques for aquatic applications - New applications for underwater networks Submission Guidelines ********************* All paper submissions will be handled electronically. Papers must be in PDF format, no longer than 8 pages for regular papers (10 pages for tutorial/survey papers and 4 pages for poster/demo papers), and must follow ACM single-space, double-column format, 10 pt. Submitted papers will be judged based on their quality and novelty through a rigorous review process. Over-length papers will be automatically rejected. Detailed instructions for paper submission are posted on the workshop website. Organizing Committee ******************** General Co-chairs: Jun-Hong Cui (University of Connecticut) Urbashi Mitra (University of Southern California) Technical Program Co-chairs: Kevin Fall (Intel Research, Berkeley) Milica Stojanovic (MIT/WHOI) Publicity Co-chairs: Volkan Rodoplu (University of California, Santa Barbara) Wei Ye (USC/ISI) Treasurer: Shengli Zhou (University of Connecticut) Publications Chair: Xiuzhen Cheng (George Washington University) Technical Program Committee *************************** Ian Akyildiz (Georgia Institute of Technology) Lee Freitag (Woods Hole Oceanographic Institution) Mario Gerla (University of California, Los Angeles) Jo=C3=A3o Pedro Gomes (Instituto Superior T=C3=A9cnico, Portugal) John Heidemann (USC/ISI) Ronald A. Iltis (University of California, Santa Barbara) Jim Kurose (University of Massachusetts, Amherst) Mehul Motani (National University of Singapore) Joseph A. Rice (Naval Postgraduate School) Daniela Rus (Massachusetts Institute of Technology) Mani Srivastava (University of California, Los Angeles) Yongguang Zhang (Microsoft Research Asia, China) Michele Zorzi (Universita'di Ferrara, Italy) _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 30 05:09:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwEzl-0002nr-Sg; Fri, 30 Jun 2006 05:09:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwEzk-0002nm-2x for mip6@ietf.org; Fri, 30 Jun 2006 05:09:00 -0400 Received: from av8-2-sn3.vrr.skanova.net ([81.228.9.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwEzi-0001Tp-Ov for mip6@ietf.org; Fri, 30 Jun 2006 05:09:00 -0400 Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 3138D38161; Fri, 30 Jun 2006 11:08:58 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 223C938025 for ; Fri, 30 Jun 2006 11:08:58 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id CA6AF37E48 for ; Fri, 30 Jun 2006 11:08:57 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz.levkowetz.com) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FwEzV-0008QQ-7Q for mip6@ietf.org; Fri, 30 Jun 2006 11:08:56 +0200 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: Pascal Thubert Date: Fri, 30 Jun 2006 09:08:45 +0000 MIME-Version: 1.0 Message-Id: <1151658525.17.0.000349996542607.issue76@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-104.4 required=2.5 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.1 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Mip6] [issue76] altCoA should not be used when traversing IPv4 NAT X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org New submission from Pascal Thubert : The draft implicitly reuses altCoA as specified in RFC 3775. As a result, in an IPv4 NAT traversal situation, the altCoA option will be present with the mapped address containing the IPv4 address on the MN side = of the NAT. And the HA will use that address as opposed to the source of the packet to respond, as mandated by MIP6. We need to make sure that the HA answers to the IPv4 address that is found = as source of the BU regardless of the altCoA option.=20 It might be better to completely omit the option in an IPv4 traversal situa= tion. ---------- category: Technical draft: draft-ietf-mip6-nemo-v4traversal messages: 253 nosy: pthubert priority: Should fix status: Pending title: altCoA should not be used when traversing IPv4 NAT _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6