From charles.perkins@earthlink.net Mon Aug 1 11:28:33 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5137411E808E for ; Mon, 1 Aug 2011 11:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mrdtck7ThK+d for ; Mon, 1 Aug 2011 11:28:32 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id E820511E8077 for ; Mon, 1 Aug 2011 11:28:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=jNx/QXMrcY7CyoeB3M6T/9CDpk+dPWc7FL+3C13vZmxHNUbYgY6TcuQI42nStQyM; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.56]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1QnxEC-0002xU-JD; Mon, 01 Aug 2011 14:28:36 -0400 Message-ID: <4E36F052.8050107@earthlink.net> Date: Mon, 01 Aug 2011 11:28:34 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8609718d7801d63eb5904e6fea6a2e5bcb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: dino@cisco.com Subject: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 18:28:33 -0000 Hello folks, At IETF 81, LISP for mobile devices was presented. While I am not yet convinced about the specific solution presented, I started to look at LISP as a possible component of an overall DMM solution. LISP has a website: http://www.lisp4.net For people who are unfamiliar, this issue of IPJ has a tutorial article about LISP: http://www.lisp4.net/docs/ipj_11-1.pdf The LISP draft for mobile nodes is accessible here: http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/ Comments? I think that LISP should be added to the comparison matrix in my draft with Dapeng Liu. Would that be helpful? Regards, Charlie P. From sjkoh@knu.ac.kr Mon Aug 1 16:50:24 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B045E8017 for ; Mon, 1 Aug 2011 16:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hicbq4xKiWNV for ; Mon, 1 Aug 2011 16:50:23 -0700 (PDT) Received: from spam2.knu.ac.kr (spam2.knu.ac.kr [155.230.10.253]) by ietfa.amsl.com (Postfix) with ESMTP id 61EA85E8015 for ; Mon, 1 Aug 2011 16:50:21 -0700 (PDT) Received: from unknown (HELO knu.ac.kr) (155.230.11.8) by 155.230.10.253 with SMTP; 2 Aug 2011 08:46:18 +0900 X-Original-SENDERIP: 155.230.11.8 X-Original-MAILFROM: sjkoh@knu.ac.kr x-beehive-trace: sjkoh@knu.ac.kr mext@ietf.org 155.230.105.149 Received: from knu.ac.kr by ietf.org with ESMTP (knu.ac.kr) for mext@ietf.org; Tue, 2 Aug 2011 08:50:17 +0900 (KST) x-beehive-kind: normal x-beehive-modified: received kind Message-ID: <77C2DE20B9834174B0856B541F903036@knucpl> From: "Seok-Joo Koh" To: "Charles E. Perkins" , "mext" References: <4E36F052.8050107@earthlink.net> Date: Tue, 2 Aug 2011 08:50:18 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: dino@cisco.com Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 23:50:24 -0000 Dear Charles, I think the LISP can also be considered as a promising candidate in the design of DMM solutions. Several works are being progressed to use or extend the LISP for mobility support, which inlcude LISP-MN draft and many research papers. Actually, I am also considering how to extend the LISP scheme in the DMM perspective. LISP is a network-based ID-LOC separation scheme and thus it may give some advantages for effective mobility support. On the other hand, it is noted that the current version of LISP and LISP-MN may need to be more enhanced in terms of scalability in the mobile environment. For example, one concern of LISP is that the LISP EIDs may not be aggregated anymore in the mobile networks, since each mobile node will have its own distinctive EIDs that do not conform the concerned mobile domain. This may decrease the scaling benefits of original LISP. We may need to design a new enhanced EID structure to be used for mobile environment. Nontheless, it is worthwhile to consider LISP as a promisng candidate in the disign of DMM, I think. By the way, as I already said in this IETF DMM ad hoc meeting, the urgent action item of DMM is to make one or more introductory I-Ds with WG consensus, which may include the problem statements and requirements for DMM, use cases/scenarios, and comparison matrix, etc. Regards, ************************* Seok-Joo Koh http://protocol.knu.ac.kr/ ************************* ----- Original Message ----- From: "Charles E. Perkins" To: "mext" Cc: Sent: Tuesday, August 02, 2011 3:28 AM Subject: [MEXT] LISP as a solution for some part of the DMM requirement > > Hello folks, > > At IETF 81, LISP for mobile devices was presented. > While I am not yet convinced about the specific > solution presented, I started to look at LISP as > a possible component of an overall DMM solution. > > LISP has a website: > http://www.lisp4.net > > For people who are unfamiliar, this issue of IPJ > has a tutorial article about LISP: > http://www.lisp4.net/docs/ipj_11-1.pdf > > The LISP draft for mobile nodes is accessible here: > http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/ > > Comments? I think that LISP should be added to the > comparison matrix in my draft with Dapeng Liu. > Would that be helpful? > > Regards, > Charlie P. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From sgundave@cisco.com Mon Aug 1 20:13:11 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C2821F8C79 for ; Mon, 1 Aug 2011 20:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.164 X-Spam-Level: X-Spam-Status: No, score=-3.164 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEO3hhUMVE0X for ; Mon, 1 Aug 2011 20:13:06 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1BF21F8B3C for ; Mon, 1 Aug 2011 20:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=3860; q=dns/txt; s=iport; t=1312254793; x=1313464393; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=gifAlodua7bTjGngFHmjItd8MVPEcD61uZxhiePKpCY=; b=L0/YYfbyxYliwPyJz9/ozMdEYCXRDX0927B5BoV9DbYbFSpeCbo/kqBR MkWHue8VQAZF29E0+J3mhMizt9g8VZB2GfG5M/hJJcriDyvsdbewMYYqh ZSVFuw2+cH4c0OQOa1/WzCF4npgfQfcZgPhUpzS9krEp1x5+Aj5hkOtBK c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHVqN06rRDoI/2dsb2JhbABCDqdSd4FAAQEBAQIBEgEnAgE8BQ0BCIEdAQEEAQ0FGweHSqFuAZ8WhkIEh1qLIYUQix1X X-IronPort-AV: E=Sophos;i="4.67,304,1309737600"; d="scan'208";a="8648204" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-3.cisco.com with ESMTP; 02 Aug 2011 03:13:09 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p723D9GH032752; Tue, 2 Aug 2011 03:13:09 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Aug 2011 20:13:09 -0700 Received: from 10.32.246.212 ([10.32.246.212]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 2 Aug 2011 03:13:08 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 01 Aug 2011 20:13:04 -0700 From: Sri Gundavelli To: Seok-Joo Koh , "Charles E. Perkins" , mext Message-ID: Thread-Topic: [MEXT] LISP as a solution for some part of the DMM requirement Thread-Index: AcxQwhfLnuKfCPPY3k6t02z05yDwwQ== In-Reply-To: <77C2DE20B9834174B0856B541F903036@knucpl> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Aug 2011 03:13:09.0216 (UTC) FILETIME=[1AE78600:01CC50C2] Cc: dino@cisco.com Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 03:13:11 -0000 Hi Charlie, I agree, we have to look at other approaches and bring any value added features to MIPv6/PMIPv6 protocols that its missing today. But, I've to say, I'm still trying to understand the DMM problem statement and what DMM should translate to: - Is it about optimized routing path ? This is very subjective and the requirement may vary based on the use-case. Very much depends on the placement of the anchor point. No solution on the table can ever solve this, unless we assume the target site where the CN is located, or the ISP above is providing some new location functions. This new location function, sure, can be a proxy home agent at the global internet level too, for the argument sake, providing direct path to the access network where the MN is currently attached. We also have talked some time back on the Global HAHA, as an approach of session re-anchoring. - Is it about moving from a centralized one box model to more distributed zillion box model ? This sounds very promising on the paper. But, as we discussed during the DMM BOF, rolling out a zillion pizza box type box anchors sounds very cool. Sure, but we bring back ten-fold complexity in the form of building distributed charging, Legal Intercept, DPI, Inline services, hotlining, high-availability ...etc etc, which are now part of that one central anchor box. It is to be noted, we have not seen a true distributed service deployed in the internet today, other than DNS. But, I agree, if this about building a true internet, who the heck cares about all of these functions, in the true spirit. Either way, I assumed any of the new solution will be bound by the following parameters: - The signaling protocol will continue to be based on MIPv6/PMIPv6 signaling semantics. - We will not introduce a new client, what is now MIP client struggling to make it to every variants of operating systems. - Any client-based solution will be an extension on top of DSMIP. Any network-based solution will be an extension to PMIPv6 I hope we can discuss the solution approaches in the next meeting and bring new extension to MIPv6/PMIPv6 protocols. Regards Sri On 8/1/11 4:50 PM, "Seok-Joo Koh" wrote: > Dear Charles, > > I think the LISP can also be considered as a promising candidate > in the design of DMM solutions. Several works are being progressed > to use or extend the LISP for mobility support, which inlcude LISP-MN draft > and many research papers. Actually, I am also considering how to extend > the LISP scheme in the DMM perspective. > > LISP is a network-based ID-LOC separation scheme and thus it may give some > advantages for effective mobility support. On the other hand, it is noted that > the current version of LISP and LISP-MN may need to be more enhanced > in terms of scalability in the mobile environment. For example, one concern of > LISP > is that the LISP EIDs may not be aggregated anymore in the mobile networks, > since > each mobile node will have its own distinctive EIDs that do not conform the > concerned mobile domain. > This may decrease the scaling benefits of original LISP. > We may need to design a new enhanced EID structure to be used for mobile > environment. > Nontheless, it is worthwhile to consider LISP as a promisng candidate in the > disign of DMM, I think. > > By the way, as I already said in this IETF DMM ad hoc meeting, the urgent > action item of DMM is > to make one or more introductory I-Ds with WG consensus, which may include > the problem statements and requirements for DMM, use cases/scenarios, and > comparison matrix, etc. > > Regards, > > ************************* > Seok-Joo Koh > http://protocol.knu.ac.kr/ > ************************* > From sgundave@cisco.com Mon Aug 1 20:22:54 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667E021F8B4F for ; Mon, 1 Aug 2011 20:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.142 X-Spam-Level: X-Spam-Status: No, score=-3.142 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DcdFFRSPBBq for ; Mon, 1 Aug 2011 20:22:45 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5365921F84CE for ; Mon, 1 Aug 2011 20:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=5389; q=dns/txt; s=iport; t=1312255365; x=1313464965; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=LKuPOHnWg8RMfSVUGrZBnsWqyn4WAQQY2vbGGCRQpRI=; b=hAZxC54q7uG68Ch+ypGXJ3bwSeASqfK8vuMEAZvMtpQCgoYkUnjJTjex /HgfKEPkbZIBsm1p90u4eJvqagowxrSSOUpgREYSQTKEukERpRLU3JgGk Rw3+jIoVgSt9Zpgu0AMPCodD8lv6t2tdTCyvO138tzHOCTLLU3tZM+Dzv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFJsN06rRDoH/2dsb2JhbAA4Cg6nUneBQAEBAQECARIBJwIBPAUNAQgYgQUBAQQBDQUbB4dKoWkBnxaDJIMeBIdaiyGFEIsdVw X-IronPort-AV: E=Sophos;i="4.67,304,1309737600"; d="scan'208";a="8648522" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-6.cisco.com with ESMTP; 02 Aug 2011 03:22:44 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p723MiGn011159; Tue, 2 Aug 2011 03:22:44 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Aug 2011 20:22:44 -0700 Received: from 10.32.246.212 ([10.32.246.212]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Tue, 2 Aug 2011 03:22:42 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 01 Aug 2011 20:22:38 -0700 From: Sri Gundavelli To: Seok-Joo Koh , "Charles E. Perkins" , mext Message-ID: Thread-Topic: [MEXT] LISP as a solution for some part of the DMM requirement Thread-Index: AcxQwhfLnuKfCPPY3k6t02z05yDwwQAAVYhP In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Aug 2011 03:22:44.0374 (UTC) FILETIME=[71B9AB60:01CC50C3] Cc: dino@cisco.com Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 03:22:54 -0000 With respect to the solutions, there are multiple approaches that are on the table. To me, to achieve a flat distributed model, we need: - the ability to select a mobility anchor closer to the access network where the mobile node is attached. 3GPP Rel-10 has done quite a few enhancements on the aspects of gateway selection. Using the parameters eNB, APN, RNC-ID, BSC-ID, ...etc - the ability to re-anchor a session, or create a new session on a new anchor closer to the new attachment point - the ability to allow the mobile node to identify the assigned IP address properties, distinguish between an address assigned in the previous access network, from an address assigned in the current access network, so it can continue to use the new address for new sessions and phase out the older address/mobility session on the previous anchor over a period of time. In other words, enhancing the SAS rules with mobility awareness will give the needed session re-anchoring capabilities This approach gives me the gateway selection closer to the access network where the mobile node is attached and the needed optimized routing path. So, I'm trying to understand what are the expectation from the DMM efforts, beyond this. Sri On 8/1/11 8:13 PM, "Sri Gundavelli" wrote: > Hi Charlie, > > I agree, we have to look at other approaches and bring any value added > features to MIPv6/PMIPv6 protocols that its missing today. But, I've to say, > I'm still trying to understand the DMM problem statement and what DMM should > translate to: > > - Is it about optimized routing path ? This is very subjective and the > requirement may vary based on the use-case. Very much depends on the placement > of the anchor point. No solution on the table can ever solve this, unless we > assume the target site where the CN is located, or the ISP above is providing > some new location functions. This new location function, sure, can be a proxy > home agent at the global internet level too, for the argument sake, providing > direct path to the access network where the MN is currently attached. We also > have talked some time back on the Global HAHA, as an approach of session > re-anchoring. > > - Is it about moving from a centralized one box model to more distributed > zillion box model ? This sounds very promising on the paper. But, as we > discussed during the DMM BOF, rolling out a zillion pizza box type box anchors > sounds very cool. Sure, but we bring back ten-fold complexity in the form of > building distributed charging, Legal Intercept, DPI, Inline services, > hotlining, high-availability ...etc etc, which are now part of that one > central anchor box. It is to be noted, we have not seen a true distributed > service deployed in the internet today, other than DNS. But, I agree, if this > about building a true internet, who the heck cares about all of these > functions, in the true spirit. > > Either way, I assumed any of the new solution will be bound by the following > parameters: > > - The signaling protocol will continue to be based on MIPv6/PMIPv6 signaling > semantics. > > - We will not introduce a new client, what is now MIP client struggling to > make it to every variants of operating systems. > > - Any client-based solution will be an extension on top of DSMIP. Any > network-based solution will be an extension to PMIPv6 > > > > I hope we can discuss the solution approaches in the next meeting and bring > new extension to MIPv6/PMIPv6 protocols. > > > > > Regards > Sri > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/1/11 4:50 PM, "Seok-Joo Koh" wrote: > >> Dear Charles, >> >> I think the LISP can also be considered as a promising candidate >> in the design of DMM solutions. Several works are being progressed >> to use or extend the LISP for mobility support, which inlcude LISP-MN draft >> and many research papers. Actually, I am also considering how to extend >> the LISP scheme in the DMM perspective. >> >> LISP is a network-based ID-LOC separation scheme and thus it may give some >> advantages for effective mobility support. On the other hand, it is noted >> that >> the current version of LISP and LISP-MN may need to be more enhanced >> in terms of scalability in the mobile environment. For example, one concern >> of >> LISP >> is that the LISP EIDs may not be aggregated anymore in the mobile networks, >> since >> each mobile node will have its own distinctive EIDs that do not conform the >> concerned mobile domain. >> This may decrease the scaling benefits of original LISP. >> We may need to design a new enhanced EID structure to be used for mobile >> environment. >> Nontheless, it is worthwhile to consider LISP as a promisng candidate in the >> disign of DMM, I think. >> >> By the way, as I already said in this IETF DMM ad hoc meeting, the urgent >> action item of DMM is >> to make one or more introductory I-Ds with WG consensus, which may include >> the problem statements and requirements for DMM, use cases/scenarios, and >> comparison matrix, etc. >> >> Regards, >> >> ************************* >> Seok-Joo Koh >> http://protocol.knu.ac.kr/ >> ************************* >> From charles.perkins@earthlink.net Mon Aug 1 22:05:03 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2EB21F8D84 for ; Mon, 1 Aug 2011 22:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4qf1GbJbsZ0 for ; Mon, 1 Aug 2011 22:05:02 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8353321F8D83 for ; Mon, 1 Aug 2011 22:05:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=O3puBECLxpV2i1ZaGR6u2PY4+QIDCFu2sr1TPGy2FzuSfP921oUx1Kjhg7rEdqCk; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Forwarded-Message-Id:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.239]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Qo7AC-00080y-60 for mext@ietf.org; Tue, 02 Aug 2011 01:05:08 -0400 Message-ID: <4E378581.1010001@earthlink.net> Date: Mon, 01 Aug 2011 22:05:05 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mext References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8615ab722e2a731c86c700186d9f70a401350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Subject: [MEXT] Reply from Dino [Re: LISP as a solution for some part of the DMM requirement] X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 05:05:04 -0000 Hello folks, Dino has replied to Seok-Joo Koh's message, but he is not on the [mext] mailing list, so I am forwarding his reply. Regards, Charlie P. -------- Original Message -------- Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement Date: Mon, 1 Aug 2011 19:01:50 -0700 From: Dino Farinacci To: Seok-Joo Koh CC: Charles E. Perkins , mext > Dear Charles, > > I think the LISP can also be considered as a promising candidate > in the design of DMM solutions. Several works are being progressed > to use or extend the LISP for mobility support, which inlcude LISP-MN draft > and many research papers. Actually, I am also considering how to extend > the LISP scheme in the DMM perspective. > > LISP is a network-based ID-LOC separation scheme and thus it may give some > advantages for effective mobility support. On the other hand, it is noted that > the current version of LISP and LISP-MN may need to be more enhanced > in terms of scalability in the mobile environment. For example, one concern of LISP > is that the LISP EIDs may not be aggregated anymore in the mobile networks, since > each mobile node will have its own distinctive EIDs that do not conform the concerned mobile domain. > This may decrease the scaling benefits of original LISP. > We may need to design a new enhanced EID structure to be used for mobile environment. > Nontheless, it is worthwhile to consider LISP as a promisng candidate in the disign of DMM, I think. LISP-MN EIDs do aggregate no matter where the EID roams. The reason is because the registering map-server the LISP-MN registers to keeps the aggregate. It is the control-plane anchor point. The mapping database does not need to store more-specifics anywhere else but the 2 (or 4) map-servers the LISP-MN registers to. The mapping database topology is based-on/arranged on address allocation hierarchy so aggregation is optimized. > By the way, as I already said in this IETF DMM ad hoc meeting, the urgent action item of DMM is > to make one or more introductory I-Ds with WG consensus, which may include > the problem statements and requirements for DMM, use cases/scenarios, and comparison matrix, etc. > > Regards, > > ************************* > Seok-Joo Koh > http://protocol.knu.ac.kr/ > ************************* > > ----- Original Message ----- From: "Charles E. Perkins" > To: "mext" > Cc: > Sent: Tuesday, August 02, 2011 3:28 AM > Subject: [MEXT] LISP as a solution for some part of the DMM requirement > > >> >> Hello folks, >> >> At IETF 81, LISP for mobile devices was presented. >> While I am not yet convinced about the specific >> solution presented, I started to look at LISP as >> a possible component of an overall DMM solution. >> >> LISP has a website: >> http://www.lisp4.net >> >> For people who are unfamiliar, this issue of IPJ >> has a tutorial article about LISP: >> http://www.lisp4.net/docs/ipj_11-1.pdf >> >> The LISP draft for mobile nodes is accessible here: >> http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/ >> >> Comments? I think that LISP should be added to the >> comparison matrix in my draft with Dapeng Liu. >> Would that be helpful? >> >> Regards, >> Charlie P. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > From alexandru.petrescu@gmail.com Tue Aug 2 04:28:04 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E968921F8877 for ; Tue, 2 Aug 2011 04:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PF7Td1c2y5Yb for ; Tue, 2 Aug 2011 04:28:04 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id A6A6721F8B54 for ; Tue, 2 Aug 2011 04:28:03 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p72BS9L5029408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Aug 2011 13:28:09 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p72BS9oM025629; Tue, 2 Aug 2011 13:28:09 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010183.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p72BS9bM014116; Tue, 2 Aug 2011 13:28:09 +0200 Message-ID: <4E37DF49.3050204@gmail.com> Date: Tue, 02 Aug 2011 13:28:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mext@ietf.org References: <4E36F052.8050107@earthlink.net> In-Reply-To: <4E36F052.8050107@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 11:28:05 -0000 Le 01/08/2011 20:28, Charles E. Perkins a écrit : > > Hello folks, > > At IETF 81, LISP for mobile devices was presented. In Mobopts? Alex > While I am not yet convinced about the specific > solution presented, I started to look at LISP as > a possible component of an overall DMM solution. > > LISP has a website: > http://www.lisp4.net > > For people who are unfamiliar, this issue of IPJ > has a tutorial article about LISP: > http://www.lisp4.net/docs/ipj_11-1.pdf > > The LISP draft for mobile nodes is accessible here: > http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/ > > Comments? I think that LISP should be added to the > comparison matrix in my draft with Dapeng Liu. > Would that be helpful? > > Regards, > Charlie P. > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From alexandru.petrescu@gmail.com Tue Aug 2 04:28:54 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB9C21F8ED5 for ; Tue, 2 Aug 2011 04:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mc3wBPNGRBnS for ; Tue, 2 Aug 2011 04:28:53 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 33E8E21F8ED4 for ; Tue, 2 Aug 2011 04:28:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p72BT09W001585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Aug 2011 13:29:00 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p72BT0OG025845; Tue, 2 Aug 2011 13:29:00 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010183.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p72BSx63014313; Tue, 2 Aug 2011 13:29:00 +0200 Message-ID: <4E37DF7B.4060404@gmail.com> Date: Tue, 02 Aug 2011 13:28:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mext@ietf.org References: <4E36F052.8050107@earthlink.net> <77C2DE20B9834174B0856B541F903036@knucpl> In-Reply-To: <77C2DE20B9834174B0856B541F903036@knucpl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 11:28:54 -0000 Le 02/08/2011 01:50, Seok-Joo Koh a écrit : > Dear Charles, > > I think the LISP can also be considered as a promising candidate > in the design of DMM solutions. Several works are being progressed > to use or extend the LISP for mobility support, which inlcude LISP-MN draft > and many research papers. Actually, I am also considering how to extend > the LISP scheme in the DMM perspective. > > LISP is a network-based ID-LOC separation scheme and thus it may give some > advantages for effective mobility support. On the other hand, it is > noted that > the current version of LISP and LISP-MN may need to be more enhanced > in terms of scalability in the mobile environment. For example, one > concern of LISP > is that the LISP EIDs may not be aggregated anymore in the mobile > networks, since > each mobile node will have its own distinctive EIDs that do not conform > the concerned mobile domain. > This may decrease the scaling benefits of original LISP. > We may need to design a new enhanced EID structure to be used for mobile > environment. > Nontheless, it is worthwhile to consider LISP as a promisng candidate in > the disign of DMM, I think. > > By the way, as I already said in this IETF DMM ad hoc meeting, Sorry, which IETF DMM ad hoc meeting? Alex > the > urgent action item of DMM is > to make one or more introductory I-Ds with WG consensus, which may include > the problem statements and requirements for DMM, use cases/scenarios, > and comparison matrix, etc. > > Regards, > > ************************* > Seok-Joo Koh > http://protocol.knu.ac.kr/ > ************************* > > ----- Original Message ----- From: "Charles E. Perkins" > > To: "mext" > Cc: > Sent: Tuesday, August 02, 2011 3:28 AM > Subject: [MEXT] LISP as a solution for some part of the DMM requirement > > >> >> Hello folks, >> >> At IETF 81, LISP for mobile devices was presented. >> While I am not yet convinced about the specific >> solution presented, I started to look at LISP as >> a possible component of an overall DMM solution. >> >> LISP has a website: >> http://www.lisp4.net >> >> For people who are unfamiliar, this issue of IPJ >> has a tutorial article about LISP: >> http://www.lisp4.net/docs/ipj_11-1.pdf >> >> The LISP draft for mobile nodes is accessible here: >> http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/ >> >> Comments? I think that LISP should be added to the >> comparison matrix in my draft with Dapeng Liu. >> Would that be helpful? >> >> Regards, >> Charlie P. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From alexandru.petrescu@gmail.com Tue Aug 2 04:29:37 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7EE21F8EDB for ; Tue, 2 Aug 2011 04:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uknk3jqOhol9 for ; Tue, 2 Aug 2011 04:29:36 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 00C6C21F8ED5 for ; Tue, 2 Aug 2011 04:29:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p72BTgk0000983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Aug 2011 13:29:42 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p72BTg6o025992; Tue, 2 Aug 2011 13:29:42 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010183.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p72BTgAW014527; Tue, 2 Aug 2011 13:29:42 +0200 Message-ID: <4E37DFA6.7080306@gmail.com> Date: Tue, 02 Aug 2011 13:29:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 11:29:37 -0000 Le 02/08/2011 05:13, Sri Gundavelli a écrit : > Hi Charlie, > > I agree, we have to look at other approaches and bring any value added > features to MIPv6/PMIPv6 protocols that its missing today. But, I've to say, > I'm still trying to understand the DMM problem statement and what DMM should > translate to: > > - Is it about optimized routing path ? This is very subjective and the > requirement may vary based on the use-case. Very much depends on the > placement of the anchor point. No solution on the table can ever solve this, > unless we assume the target site where the CN is located, or the ISP above > is providing some new location functions. This new location function, sure, > can be a proxy home agent at the global internet level too, for the argument > sake, providing direct path to the access network where the MN is currently > attached. We also have talked some time back on the Global HAHA, as an > approach of session re-anchoring. > > - Is it about moving from a centralized one box model to more distributed > zillion box model ? This sounds very promising on the paper. But, as we > discussed during the DMM BOF, rolling out a zillion pizza box type box > anchors sounds very cool. Sure, but we bring back ten-fold complexity in the > form of building distributed charging, Legal Intercept, DPI, Inline > services, hotlining, high-availability ...etc etc, which are now part of > that one central anchor box. It is to be noted, we have not seen a true > distributed service deployed in the internet today, other than DNS. But, I > agree, if this about building a true internet, who the heck cares about all > of these functions, in the true spirit. > > Either way, I assumed any of the new solution will be bound by the following > parameters: > > - The signaling protocol will continue to be based on MIPv6/PMIPv6 signaling > semantics. > > - We will not introduce a new client, what is now MIP client struggling to > make it to every variants of operating systems. > > - Any client-based solution will be an extension on top of DSMIP. Any > network-based solution will be an extension to PMIPv6 > > > > I hope we can discuss the solution approaches in the next meeting Which meeting? Alex and bring > new extension to MIPv6/PMIPv6 protocols. > > > > > Regards > Sri > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8/1/11 4:50 PM, "Seok-Joo Koh" wrote: > >> Dear Charles, >> >> I think the LISP can also be considered as a promising candidate >> in the design of DMM solutions. Several works are being progressed >> to use or extend the LISP for mobility support, which inlcude LISP-MN draft >> and many research papers. Actually, I am also considering how to extend >> the LISP scheme in the DMM perspective. >> >> LISP is a network-based ID-LOC separation scheme and thus it may give some >> advantages for effective mobility support. On the other hand, it is noted that >> the current version of LISP and LISP-MN may need to be more enhanced >> in terms of scalability in the mobile environment. For example, one concern of >> LISP >> is that the LISP EIDs may not be aggregated anymore in the mobile networks, >> since >> each mobile node will have its own distinctive EIDs that do not conform the >> concerned mobile domain. >> This may decrease the scaling benefits of original LISP. >> We may need to design a new enhanced EID structure to be used for mobile >> environment. >> Nontheless, it is worthwhile to consider LISP as a promisng candidate in the >> disign of DMM, I think. >> >> By the way, as I already said in this IETF DMM ad hoc meeting, the urgent >> action item of DMM is >> to make one or more introductory I-Ds with WG consensus, which may include >> the problem statements and requirements for DMM, use cases/scenarios, and >> comparison matrix, etc. >> >> Regards, >> >> ************************* >> Seok-Joo Koh >> http://protocol.knu.ac.kr/ >> ************************* >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From alexandru.petrescu@gmail.com Tue Aug 2 04:42:18 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCEA21F8EAC for ; Tue, 2 Aug 2011 04:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JWrPLBKsWak for ; Tue, 2 Aug 2011 04:42:18 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id A905521F8EA0 for ; Tue, 2 Aug 2011 04:42:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p72BgPMR005902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Aug 2011 13:42:25 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p72BgPOl029242; Tue, 2 Aug 2011 13:42:25 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010183.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p72BgPCP018900; Tue, 2 Aug 2011 13:42:25 +0200 Message-ID: <4E37E2A1.2030705@gmail.com> Date: Tue, 02 Aug 2011 13:42:25 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mext Content-Type: multipart/mixed; boundary="------------030702030206090407050502" Subject: [MEXT] my handwritten minutes about the "not MEXT" meeting IETF81 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 11:42:18 -0000 This is a multi-part message in MIME format. --------------030702030206090407050502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit This is unofficial, and is my sentiment about this meeting, which, as all sentiments, may be not right. MEXT Discussion Group met on July 27th, 2011, in room 303ABC of Hilton, in Québec, Canada, during the IETF 81 meeting, as announced in the attached email. Approximately 21-27 people were in the room, varying in time. It was led by Charles Perkins and Raj Patil. There was projector and slides. CP humurously named this the "not MEXT WG" meeting, laughs. CP invited to post to MEXT email list (and no longer use the DMM email list dmm@ietf.org) and he gave reasonable argument for that. Requirements discussion happened. Sri on Source Address Selection and Policy Table DHCP. Antony Chan on problem statement for dynamic mobility mgmt. Raj Patil on reasons for DMM: not backhauling, latency, inefficient routing, scalability and cost. Dapeng Liu (spelling?) of ZTE saying DMM based on PMIP is different than LR PMIP in that order of LMA and MAG. Carlos on PMIP-DMM will present in Mobopts RG. Pete McCann on lawful interception. CP on IETF Protocols for 4th generation wireless. Mobile IP in 4G Networks. GTP for HA. WLAN as a "trusted network". EAP running HA instead of AAA, because HA-VPN inefficient. SIPTO. LIPTA (local IP Access). Discussion. CP said maybe slides will he upload send ref. End of minutes. Alex --------------030702030206090407050502 Content-Type: message/rfc822; name="Message joint" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Message joint" Received: from muguet2.intra.cea.fr (132.166.192.7) by EXCAH-A3.intra.cea.fr (132.166.88.77) with Microsoft SMTP Server id 14.1.270.1; Tue, 26 Jul 2011 22:16:54 +0200 Received: from epeire2.extra.cea.fr (epeire2.extra.cea.fr [132.167.198.32]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-in-1.1) with ESMTP id p6QKGso9021410 for ; Tue, 26 Jul 2011 22:16:54 +0200 Received: from sainfoin.extra.cea.fr (sainfoin.extra.cea.fr [132.166.172.103]) by epeire2.extra.cea.fr (8.14.4/8.14.4) with ESMTP id p6QKGr4a008344 for ; Tue, 26 Jul 2011 22:16:53 +0200 (envelope-from alexandru.petrescu+caf_=alexandru.petrescu=incognitus.eu@gmail.com) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-in-3.0) with ESMTP id p6QKGmBU011494 for ; Tue, 26 Jul 2011 22:16:53 +0200 X-Originating-IP: 10.0.21.134 Received: from spool.mail.gandi.net (mspool3-d.mgt.gandi.net [10.0.21.134]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 8A296172070; Tue, 26 Jul 2011 22:16:48 +0200 (CEST) Received: from mfilter4-d.gandi.net (mfilter4-d.gandi.net [217.70.178.134]) by spool.mail.gandi.net (Postfix) with ESMTP id 85829116069; Tue, 26 Jul 2011 22:16:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter4-d.gandi.net Received: from spool.mail.gandi.net ([10.0.21.134]) by mfilter4-d.gandi.net (mfilter4-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 8d52J4tY+5eX; Tue, 26 Jul 2011 22:16:47 +0200 (CEST) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by spool.mail.gandi.net (Postfix) with ESMTP id EC33F11607F for ; Tue, 26 Jul 2011 22:16:46 +0200 (CEST) Received: by gxk28 with SMTP id 28so918393gxk.27 for ; Tue, 26 Jul 2011 13:16:46 -0700 (PDT) Received: by 10.146.157.7 with SMTP id f7mr5562366yae.24.1311711406168; Tue, 26 Jul 2011 13:16:46 -0700 (PDT) X-Forwarded-To: alexandru.petrescu@incognitus.eu X-Forwarded-For: alexandru.petrescu@gmail.com alexandru.petrescu@incognitus.eu Delivered-To: alexandru.petrescu@gmail.com Received: by 10.146.167.3 with SMTP id p3cs139512yae; Tue, 26 Jul 2011 13:16:45 -0700 (PDT) Received: by 10.142.136.18 with SMTP id j18mr3798310wfd.284.1311711404829; Tue, 26 Jul 2011 13:16:44 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by mx.google.com with ESMTP id m6si2716834wfh.6.2011.07.26.13.16.42; Tue, 26 Jul 2011 13:16:43 -0700 (PDT) Received-SPF: pass (google.com: domain of dmm-bounces@ietf.org designates 64.170.98.30 as permitted sender) client-ip=64.170.98.30; Authentication-Results: mx.google.com; spf=pass (google.com: domain of dmm-bounces@ietf.org designates 64.170.98.30 as permitted sender) smtp.mail=dmm-bounces@ietf.org; dkim=pass (test mode) header.i=@ietf.org Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA80821F863A; Tue, 26 Jul 2011 13:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1311711401; bh=P3uUu8sh0UtgDS53tqg6g3cC/PNmmou7f3jGXq769dg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=RiR2uaWBbNniojlDAJFPhPZRR+FuuTR9/VVvpaUaB0oIlHwmPB/2+54IdZ5fjz26l 4RlKBqV+HYlDOftMx1JjdMsrteKuDmAnqZW/8stvQXYLdDSTnRh/F+tiSuDRzHTNCb +9cRu+XDR4if04H63Jdr9DxDrWkjnpP+7vrAs0oo= X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D27811E8099 for ; Tue, 26 Jul 2011 13:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOHrehSP7YhX for ; Tue, 26 Jul 2011 13:16:39 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 574C311E80A0 for ; Tue, 26 Jul 2011 13:16:39 -0700 (PDT) Received: by gwb20 with SMTP id 20so673299gwb.31 for ; Tue, 26 Jul 2011 13:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yK5SksfK89YEWYYR2H8qedGvooyU1CrlFesRu5NKhOo=; b=d0Jq+5uaemBVH/CEurxAKODNx1dw71VKWd73UzSKGd3XGsgDc5T60H/m4//zvaN/KM 9BFs5WThce7SZkhSOK7aw+I7163FkrYu3HdMLU0j/uAVjb1SFmn5zjJRSD3iGqPx8Rps TF+65LbbaiSIiUCFC2SP5n5DE5GTrsPI3T9S4= Received: by 10.231.117.93 with SMTP id p29mr5927078ibq.179.1311711398770; Tue, 26 Jul 2011 13:16:38 -0700 (PDT) Received: by 10.231.113.145 with HTTP; Tue, 26 Jul 2011 13:16:37 -0700 (PDT) In-Reply-To: <4E2ED841.50604@earthlink.net> References: <4E2ED841.50604@earthlink.net> Date: Wed, 27 Jul 2011 04:16:37 +0800 Message-ID: From: liu dapeng To: dmm Subject: [dmm] Fwd: [MEXT] [mext] discussion group Wednesday morning 9:00-11:30am, room 303AB X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: Errors-To: dmm-bounces@ietf.org X-CEA-Source: externe X-CEA-Spam: 10% X-CEA-Spam-Report: The following antispam rules were triggered by this message: Rule Score Description TO_IN_SUBJECT 0.500 To address is found in the subject line BODYTEXTP_SIZE_3000_LESS 0.000 Body size of the text/plain part is less than 3k BODY_SIZE_1000_1099 0.000 Message body size is 1000 to 1099 bytes BODY_SIZE_2000_LESS 0.000 Message body size is less than 2000 bytes. BODY_SIZE_5000_LESS 0.000 Message body size is less than 5000 bytes. BODY_SIZE_7000_LESS 0.000 Message body size is less than 5000 bytes. WEBMAIL_SOURCE 0.000 message appears to come from a webmail service WEBMAIL_XOIP 0.000 Contains a header line seen in webmail systems WEBMAIL_X_IP_HDR 0.000 Conntains a known webmail X-IP header X-CEA-Spam-Hits: TO_IN_SUBJECT 0.5, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_1099 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, WEBMAIL_SOURCE 0, WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0, __ANY_URI 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __DATE_TZ_HK 0, __FRAUD_WEBMAIL 0, __FRAUD_WEBMAIL_FROM 0, __FROM_GMAIL 0, __HAS_LIST_HEADER 0, __HAS_LIST_HELP 0, __HAS_LIST_SUBSCRIBE 0, __HAS_LIST_UNSUBSCRIBE 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_HTTP_RECEIVED 0, __PHISH_SPEAR_STRUCTURE_1 0, __PHISH_SPEAR_STRUCTURE_2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NS , __X_FORWARDED_FOR_GMAIL 0 Return-Path: alexandru.petrescu+caf_=alexandru.petrescu=incognitus.eu@gmail.com X-MS-Exchange-Organization-AuthSource: EXCAH-A3.intra.cea.fr X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-TM-AS-Product-Ver: SMEX-10.0.0.4152-6.500.1024-18284.007 X-TM-AS-Result: No--12.134600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-MS-Exchange-Organization-AVStamp-Mailbox: SMEXawoY;831100;0;This mail has been scanned by Trend Micro ScanMail for Microsoft Exchange; X-MS-Exchange-Organization-SCL: 0 MIME-Version: 1.0 FYI ---------- Forwarded message ---------- From: "Charles E. Perkins" Date: Tue, 26 Jul 2011 08:07:45 -0700 Subject: [MEXT] [mext] discussion group Wednesday morning 9:00-11:30am, room 303AB To: mext Hello folks, Basavaraj Patil and I have arranged a room to discuss topics of interest for MEXT, with emphasis on DMM. The meeting will take place Wednesday in room 303AB from 9:00-11:30am,. Here is a tentative agenda: 1. Discussion of DMM I-Ds and topic (60 mins) 2. Enhancements to (DS)MIP6 to meet deployment and 4G+ architecture needs (60 mins) 3. Anything else that people have in mind. Regards, Charlie P. _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext -- ------ Best Regards, Dapeng Liu _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --------------030702030206090407050502-- From rkuntz@us.toyota-itc.com Tue Aug 2 14:08:58 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2828021F84E0 for ; Tue, 2 Aug 2011 14:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSrWDDZsBWGs for ; Tue, 2 Aug 2011 14:08:56 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aob106.obsmtp.com [74.125.149.76]) by ietfa.amsl.com (Postfix) with SMTP id 9DD9F21F850B for ; Tue, 2 Aug 2011 14:08:55 -0700 (PDT) Received: from mail-yi0-f43.google.com ([209.85.218.43]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTjhncZgl4NLS1gmBb5wk81T0tfkPFx+z@postini.com; Tue, 02 Aug 2011 14:09:06 PDT Received: by mail-yi0-f43.google.com with SMTP id 12so126311yib.30 for ; Tue, 02 Aug 2011 14:09:05 -0700 (PDT) Received: by 10.68.56.5 with SMTP id w5mr1906659pbp.199.1312319344680; Tue, 02 Aug 2011 14:09:04 -0700 (PDT) Received: from hong-lt.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id o6sm215313pbj.34.2011.08.02.14.09.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Aug 2011 14:09:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Romain KUNTZ X-Priority: 3 In-Reply-To: <77C2DE20B9834174B0856B541F903036@knucpl> Date: Tue, 2 Aug 2011 14:09:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8F4C283D-BBE7-473E-8FCD-6B1CBDE8BE4C@us.toyota-itc.com> References: <4E36F052.8050107@earthlink.net> <77C2DE20B9834174B0856B541F903036@knucpl> To: Seok-Joo Koh X-Mailer: Apple Mail (2.1244.3) Cc: dino@cisco.com, mext Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:08:58 -0000 Hello, I fail to see how LISP would fall in the MEXT charter item, which = concentrates on MIPv6-based DMM solution ('Operational considerations = for distributed use of Mobile IPv6'). If LISP is foreseen as a potential = solution for distributed mobility management, that should probably be = discussed in the Network WG, where LISP and LISP MN are discussed. Regards, Romain On Aug 1, 2011, at 16:50, Seok-Joo Koh wrote: > Dear Charles, >=20 > I think the LISP can also be considered as a promising candidate > in the design of DMM solutions. Several works are being progressed > to use or extend the LISP for mobility support, which inlcude LISP-MN = draft > and many research papers. Actually, I am also considering how to = extend > the LISP scheme in the DMM perspective. >=20 > LISP is a network-based ID-LOC separation scheme and thus it may give = some > advantages for effective mobility support. On the other hand, it is = noted that > the current version of LISP and LISP-MN may need to be more enhanced > in terms of scalability in the mobile environment. For example, one = concern of LISP > is that the LISP EIDs may not be aggregated anymore in the mobile = networks, since > each mobile node will have its own distinctive EIDs that do not = conform the concerned mobile domain. > This may decrease the scaling benefits of original LISP. > We may need to design a new enhanced EID structure to be used for = mobile environment. > Nontheless, it is worthwhile to consider LISP as a promisng candidate = in the disign of DMM, I think. >=20 > By the way, as I already said in this IETF DMM ad hoc meeting, the = urgent action item of DMM is > to make one or more introductory I-Ds with WG consensus, which may = include > the problem statements and requirements for DMM, use cases/scenarios, = and comparison matrix, etc. >=20 > Regards, >=20 > ************************* > Seok-Joo Koh > http://protocol.knu.ac.kr/ > ************************* >=20 > ----- Original Message ----- From: "Charles E. Perkins" = > To: "mext" > Cc: > Sent: Tuesday, August 02, 2011 3:28 AM > Subject: [MEXT] LISP as a solution for some part of the DMM = requirement >=20 >=20 >>=20 >> Hello folks, >>=20 >> At IETF 81, LISP for mobile devices was presented. >> While I am not yet convinced about the specific >> solution presented, I started to look at LISP as >> a possible component of an overall DMM solution. >>=20 >> LISP has a website: >> http://www.lisp4.net >>=20 >> For people who are unfamiliar, this issue of IPJ >> has a tutorial article about LISP: >> http://www.lisp4.net/docs/ipj_11-1.pdf >>=20 >> The LISP draft for mobile nodes is accessible here: >> http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/ >>=20 >> Comments? I think that LISP should be added to the >> comparison matrix in my draft with Dapeng Liu. >> Would that be helpful? >>=20 >> Regards, >> Charlie P. >>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From Basavaraj.Patil@nokia.com Tue Aug 2 14:15:35 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C55211E80A9 for ; Tue, 2 Aug 2011 14:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73w9jNO5-oQE for ; Tue, 2 Aug 2011 14:15:34 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADAF11E808F for ; Tue, 2 Aug 2011 14:15:34 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p72LFcM9014939; Wed, 3 Aug 2011 00:15:38 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Aug 2011 00:15:33 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 2 Aug 2011 23:15:33 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.61]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.002; Tue, 2 Aug 2011 23:15:33 +0200 From: To: , Thread-Topic: [MEXT] LISP as a solution for some part of the DMM requirement Thread-Index: AQHMUHjflPAjusyMQk2URcjHRVvy/ZUIqsa6gAFDjoD//63+AA== Date: Tue, 2 Aug 2011 21:15:32 +0000 Message-ID: In-Reply-To: <8F4C283D-BBE7-473E-8FCD-6B1CBDE8BE4C@us.toyota-itc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [172.19.59.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <5A5714354D8EF94688D982A0FD3E88FB@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Aug 2011 21:15:33.0839 (UTC) FILETIME=[50EA8DF0:01CC5159] X-Nokia-AV: Clean Cc: dino@cisco.com, mext@ietf.org Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:15:35 -0000 I agree with Romain's comment. The scope of DMM within the context of the MEXT WG is to reuse Mobile IPv6 protocols, extensions and elements to address the concerns of the base Mobile IP model.=20 Mobility using LISP may be a good solution in itself. I have no idea or opinion about such a solution at the present time. I believe that we can address the DMM requirements with a few extensions to MIP6 signaling and guidelines for deployment. Expanding the scope of DMM beyond the base MIP6 protocol would be taking us down a path with no visible end. -Basavaraj On 8/2/11 4:09 PM, "ext Romain KUNTZ" wrote: >Hello, > >I fail to see how LISP would fall in the MEXT charter item, which >concentrates on MIPv6-based DMM solution ('Operational considerations for >distributed use of Mobile IPv6'). If LISP is foreseen as a potential >solution for distributed mobility management, that should probably be >discussed in the Network WG, where LISP and LISP MN are discussed. > >Regards, >Romain > >On Aug 1, 2011, at 16:50, Seok-Joo Koh wrote: > >> Dear Charles, >>=20 >> I think the LISP can also be considered as a promising candidate >> in the design of DMM solutions. Several works are being progressed >> to use or extend the LISP for mobility support, which inlcude LISP-MN >>draft >> and many research papers. Actually, I am also considering how to extend >> the LISP scheme in the DMM perspective. >>=20 >> LISP is a network-based ID-LOC separation scheme and thus it may give >>some >> advantages for effective mobility support. On the other hand, it is >>noted that >> the current version of LISP and LISP-MN may need to be more enhanced >> in terms of scalability in the mobile environment. For example, one >>concern of LISP >> is that the LISP EIDs may not be aggregated anymore in the mobile >>networks, since >> each mobile node will have its own distinctive EIDs that do not conform >>the concerned mobile domain. >> This may decrease the scaling benefits of original LISP. >> We may need to design a new enhanced EID structure to be used for >>mobile environment. >> Nontheless, it is worthwhile to consider LISP as a promisng candidate >>in the disign of DMM, I think. >>=20 >> By the way, as I already said in this IETF DMM ad hoc meeting, the >>urgent action item of DMM is >> to make one or more introductory I-Ds with WG consensus, which may >>include >> the problem statements and requirements for DMM, use cases/scenarios, >>and comparison matrix, etc. >>=20 >> Regards, >>=20 >> ************************* >> Seok-Joo Koh >> http://protocol.knu.ac.kr/ >> ************************* >>=20 >> ----- Original Message ----- From: "Charles E. Perkins" >> >> To: "mext" >> Cc: >> Sent: Tuesday, August 02, 2011 3:28 AM >> Subject: [MEXT] LISP as a solution for some part of the DMM requirement >>=20 >>=20 >>>=20 >>> Hello folks, >>>=20 >>> At IETF 81, LISP for mobile devices was presented. >>> While I am not yet convinced about the specific >>> solution presented, I started to look at LISP as >>> a possible component of an overall DMM solution. >>>=20 >>> LISP has a website: >>> http://www.lisp4.net >>>=20 >>> For people who are unfamiliar, this issue of IPJ >>> has a tutorial article about LISP: >>> http://www.lisp4.net/docs/ipj_11-1.pdf >>>=20 >>> The LISP draft for mobile nodes is accessible here: >>> http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/ >>>=20 >>> Comments? I think that LISP should be added to the >>> comparison matrix in my draft with Dapeng Liu. >>> Would that be helpful? >>>=20 >>> Regards, >>> Charlie P. >>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>=20 >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext From charles.perkins@earthlink.net Tue Aug 2 14:41:35 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB48F11E80C7 for ; Tue, 2 Aug 2011 14:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9bkA3+2VcDB for ; Tue, 2 Aug 2011 14:41:34 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id D470F11E808F for ; Tue, 2 Aug 2011 14:41:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=mji7vcEEgKEEyQ3995s3O9QQqio4E4+Qdyg0TfDO6O1h2Zlvt6fsfQit2sJGT6SZ; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.56]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1QoMiZ-0003Jy-6v; Tue, 02 Aug 2011 17:41:39 -0400 Message-ID: <4E386F10.6080101@earthlink.net> Date: Tue, 02 Aug 2011 14:41:36 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86e3fd2febb6acf1c9246c6b7a0f9f5b4d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: dino@cisco.com, mext@ietf.org Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:41:35 -0000 Hello folks, I agree that LISP work should not be done in the [mext] working group. However, if the LISP design shows how to make a good solution for distributed anchoring, it is pertinent to our work insofar as it provides a model for the [mext] solution. In that case, if we are fortunate, it would be easier to devise an appropriate solution by using the LISP distributed anchoring as a guide. Please note that I do not yet claim that LISP does what is needed -- only that we ought to take a look. Regards, Charlie P. On 8/2/2011 2:15 PM, Basavaraj.Patil@nokia.com wrote: > > I agree with Romain's comment. > The scope of DMM within the context of the MEXT WG is to reuse Mobile IPv6 > protocols, extensions and elements to address the concerns of the base > Mobile IP model. > > Mobility using LISP may be a good solution in itself. I have no idea or > opinion about such a solution at the present time. > > I believe that we can address the DMM requirements with a few extensions > to MIP6 signaling and guidelines for deployment. Expanding the scope of > DMM beyond the base MIP6 protocol would be taking us down a path with no > visible end. > > -Basavaraj > > On 8/2/11 4:09 PM, "ext Romain KUNTZ" wrote: > >> Hello, >> >> I fail to see how LISP would fall in the MEXT charter item, which >> concentrates on MIPv6-based DMM solution ('Operational considerations for >> distributed use of Mobile IPv6'). If LISP is foreseen as a potential >> solution for distributed mobility management, that should probably be >> discussed in the Network WG, where LISP and LISP MN are discussed. >> >> Regards, >> Romain >> >> On Aug 1, 2011, at 16:50, Seok-Joo Koh wrote: >> >>> Dear Charles, >>> >>> I think the LISP can also be considered as a promising candidate >>> in the design of DMM solutions. Several works are being progressed >>> to use or extend the LISP for mobility support, which inlcude LISP-MN >>> draft >>> and many research papers. Actually, I am also considering how to extend >>> the LISP scheme in the DMM perspective. >>> >>> LISP is a network-based ID-LOC separation scheme and thus it may give >>> some >>> advantages for effective mobility support. On the other hand, it is >>> noted that >>> the current version of LISP and LISP-MN may need to be more enhanced >>> in terms of scalability in the mobile environment. For example, one >>> concern of LISP >>> is that the LISP EIDs may not be aggregated anymore in the mobile >>> networks, since >>> each mobile node will have its own distinctive EIDs that do not conform >>> the concerned mobile domain. >>> This may decrease the scaling benefits of original LISP. >>> We may need to design a new enhanced EID structure to be used for >>> mobile environment. >>> Nontheless, it is worthwhile to consider LISP as a promisng candidate >>> in the disign of DMM, I think. >>> >>> By the way, as I already said in this IETF DMM ad hoc meeting, the >>> urgent action item of DMM is >>> to make one or more introductory I-Ds with WG consensus, which may >>> include >>> the problem statements and requirements for DMM, use cases/scenarios, >>> and comparison matrix, etc. >>> >>> Regards, >>> >>> ************************* >>> Seok-Joo Koh >>> http://protocol.knu.ac.kr/ >>> ************************* >>> >>> ----- Original Message ----- From: "Charles E. Perkins" >>> >>> To: "mext" >>> Cc: >>> Sent: Tuesday, August 02, 2011 3:28 AM >>> Subject: [MEXT] LISP as a solution for some part of the DMM requirement >>> >>> >>>> >>>> Hello folks, >>>> >>>> At IETF 81, LISP for mobile devices was presented. >>>> While I am not yet convinced about the specific >>>> solution presented, I started to look at LISP as >>>> a possible component of an overall DMM solution. >>>> >>>> LISP has a website: >>>> http://www.lisp4.net >>>> >>>> For people who are unfamiliar, this issue of IPJ >>>> has a tutorial article about LISP: >>>> http://www.lisp4.net/docs/ipj_11-1.pdf >>>> >>>> The LISP draft for mobile nodes is accessible here: >>>> http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/ >>>> >>>> Comments? I think that LISP should be added to the >>>> comparison matrix in my draft with Dapeng Liu. >>>> Would that be helpful? >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From Fred.L.Templin@boeing.com Tue Aug 2 14:50:31 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3801411E80CE for ; Tue, 2 Aug 2011 14:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, J_BACKHAIR_22=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y139OCbFct1t for ; Tue, 2 Aug 2011 14:50:29 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id AE28B11E80CB for ; Tue, 2 Aug 2011 14:50:29 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p72LoZHU006196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 Aug 2011 14:50:35 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p72LoYSl004312; Tue, 2 Aug 2011 14:50:34 -0700 (PDT) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p72Lnpq6002452 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 2 Aug 2011 14:50:34 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Tue, 2 Aug 2011 14:50:07 -0700 From: "Templin, Fred L" To: "Charles E. Perkins" , "Basavaraj.Patil@nokia.com" Date: Tue, 2 Aug 2011 14:50:04 -0700 Thread-Topic: [MEXT] LISP as a solution for some part of the DMM requirement Thread-Index: AcxRXP05k4wavJz9R/60T9j0ny9USAAAEzpg Message-ID: References: <4E386F10.6080101@earthlink.net> In-Reply-To: <4E386F10.6080101@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dino@cisco.com" , "mext@ietf.org" Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:50:31 -0000 IRON also provides an alternate approach to mobility management. I'll have to look at what is meant by distributed anchoring, but IRON essentially allows MNs to access a topologically-close HA and move to a new nearby HA if they move far away from the former one. The MN<->HA relationship is managed similar to how a MOBIKE client corresponds with a MOBIKE security gateway. Thanks - Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On=20 > Behalf Of Charles E. Perkins > Sent: Tuesday, August 02, 2011 2:42 PM > To: Basavaraj.Patil@nokia.com > Cc: dino@cisco.com; mext@ietf.org > Subject: Re: [MEXT] LISP as a solution for some part of the=20 > DMM requirement >=20 >=20 > Hello folks, >=20 > I agree that LISP work should not be done in the [mext] > working group. >=20 > However, if the LISP design shows how to make a good > solution for distributed anchoring, it is pertinent to > our work insofar as it provides a model for the [mext] > solution. In that case, if we are fortunate, it would > be easier to devise an appropriate solution by using > the LISP distributed anchoring as a guide. >=20 > Please note that I do not yet claim that LISP does > what is needed -- only that we ought to take a look. >=20 > Regards, > Charlie P. >=20 >=20 > On 8/2/2011 2:15 PM, Basavaraj.Patil@nokia.com wrote: > > > > I agree with Romain's comment. > > The scope of DMM within the context of the MEXT WG is to=20 > reuse Mobile IPv6 > > protocols, extensions and elements to address the concerns=20 > of the base > > Mobile IP model. > > > > Mobility using LISP may be a good solution in itself. I=20 > have no idea or > > opinion about such a solution at the present time. > > > > I believe that we can address the DMM requirements with a=20 > few extensions > > to MIP6 signaling and guidelines for deployment. Expanding=20 > the scope of > > DMM beyond the base MIP6 protocol would be taking us down a=20 > path with no > > visible end. > > > > -Basavaraj > > > > On 8/2/11 4:09 PM, "ext Romain=20 > KUNTZ" wrote: > > > >> Hello, > >> > >> I fail to see how LISP would fall in the MEXT charter item, which > >> concentrates on MIPv6-based DMM solution ('Operational=20 > considerations for > >> distributed use of Mobile IPv6'). If LISP is foreseen as a=20 > potential > >> solution for distributed mobility management, that should=20 > probably be > >> discussed in the Network WG, where LISP and LISP MN are discussed. > >> > >> Regards, > >> Romain > >> > >> On Aug 1, 2011, at 16:50, Seok-Joo Koh wrote: > >> > >>> Dear Charles, > >>> > >>> I think the LISP can also be considered as a promising candidate > >>> in the design of DMM solutions. Several works are being progressed > >>> to use or extend the LISP for mobility support, which=20 > inlcude LISP-MN > >>> draft > >>> and many research papers. Actually, I am also considering=20 > how to extend > >>> the LISP scheme in the DMM perspective. > >>> > >>> LISP is a network-based ID-LOC separation scheme and thus=20 > it may give > >>> some > >>> advantages for effective mobility support. On the other=20 > hand, it is > >>> noted that > >>> the current version of LISP and LISP-MN may need to be=20 > more enhanced > >>> in terms of scalability in the mobile environment. For=20 > example, one > >>> concern of LISP > >>> is that the LISP EIDs may not be aggregated anymore in the mobile > >>> networks, since > >>> each mobile node will have its own distinctive EIDs that=20 > do not conform > >>> the concerned mobile domain. > >>> This may decrease the scaling benefits of original LISP. > >>> We may need to design a new enhanced EID structure to be used for > >>> mobile environment. > >>> Nontheless, it is worthwhile to consider LISP as a=20 > promisng candidate > >>> in the disign of DMM, I think. > >>> > >>> By the way, as I already said in this IETF DMM ad hoc meeting, the > >>> urgent action item of DMM is > >>> to make one or more introductory I-Ds with WG consensus, which may > >>> include > >>> the problem statements and requirements for DMM, use=20 > cases/scenarios, > >>> and comparison matrix, etc. > >>> > >>> Regards, > >>> > >>> ************************* > >>> Seok-Joo Koh > >>> http://protocol.knu.ac.kr/ > >>> ************************* > >>> > >>> ----- Original Message ----- From: "Charles E. Perkins" > >>> > >>> To: "mext" > >>> Cc: > >>> Sent: Tuesday, August 02, 2011 3:28 AM > >>> Subject: [MEXT] LISP as a solution for some part of the=20 > DMM requirement > >>> > >>> > >>>> > >>>> Hello folks, > >>>> > >>>> At IETF 81, LISP for mobile devices was presented. > >>>> While I am not yet convinced about the specific > >>>> solution presented, I started to look at LISP as > >>>> a possible component of an overall DMM solution. > >>>> > >>>> LISP has a website: > >>>> http://www.lisp4.net > >>>> > >>>> For people who are unfamiliar, this issue of IPJ > >>>> has a tutorial article about LISP: > >>>> http://www.lisp4.net/docs/ipj_11-1.pdf > >>>> > >>>> The LISP draft for mobile nodes is accessible here: > >>>> http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/ > >>>> > >>>> Comments? I think that LISP should be added to the > >>>> comparison matrix in my draft with Dapeng Liu. > >>>> Would that be helpful? > >>>> > >>>> Regards, > >>>> Charlie P. > >>>> > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >> > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext > > > > _______________________________________________ > > MEXT mailing list > > MEXT@ietf.org > > https://www.ietf.org/mailman/listinfo/mext > > >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > = From Basavaraj.Patil@nokia.com Tue Aug 2 14:59:09 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABAE5E800D for ; Tue, 2 Aug 2011 14:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQ+fXlhPc78h for ; Tue, 2 Aug 2011 14:59:08 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id DA1EE5E8005 for ; Tue, 2 Aug 2011 14:59:07 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p72LxDPK020933; Wed, 3 Aug 2011 00:59:15 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Aug 2011 00:59:08 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 2 Aug 2011 23:59:07 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.61]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0323.002; Tue, 2 Aug 2011 23:58:58 +0200 From: To: Thread-Topic: [MEXT] LISP as a solution for some part of the DMM requirement Thread-Index: AQHMUHjflPAjusyMQk2URcjHRVvy/ZUIqsa6gAFDjoD//63+AIAAWx0A//+xBYA= Date: Tue, 2 Aug 2011 21:58:58 +0000 Message-ID: In-Reply-To: <4E386F10.6080101@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [172.19.59.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <7BB578AAE3364641B4D3E0EBE7C69E17@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Aug 2011 21:59:08.0418 (UTC) FILETIME=[6753A620:01CC515F] X-Nokia-AV: Clean Cc: dino@cisco.com, mext@ietf.org Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:59:09 -0000 Hi Charlie, On 8/2/11 4:41 PM, "ext Charles E. Perkins" wrote: > >Hello folks, > >I agree that LISP work should not be done in the [mext] >working group. > >However, if the LISP design shows how to make a good >solution for distributed anchoring, it is pertinent to >our work insofar as it provides a model for the [mext] >solution. In that case, if we are fortunate, it would >be easier to devise an appropriate solution by using >the LISP distributed anchoring as a guide. If the LISP design helps in alleviating the concerns that we have identified as some of the key issues in I-D draft-patil-mext-dmm-approaches-01.txt (Sec 3), then maybe yes. If we have to incorporate LISP based mobility as a solution for DMM, then we have an issue, because at the present time it can be perceived that the problems could be solved within the framework of MIP6 signaling and network elements. -Basavaraj > >Please note that I do not yet claim that LISP does >what is needed -- only that we ought to take a look. > >Regards, >Charlie P. > > >On 8/2/2011 2:15 PM, Basavaraj.Patil@nokia.com wrote: >> >> I agree with Romain's comment. >> The scope of DMM within the context of the MEXT WG is to reuse Mobile >>IPv6 >> protocols, extensions and elements to address the concerns of the base >> Mobile IP model. >> >> Mobility using LISP may be a good solution in itself. I have no idea or >> opinion about such a solution at the present time. >> >> I believe that we can address the DMM requirements with a few extensions >> to MIP6 signaling and guidelines for deployment. Expanding the scope of >> DMM beyond the base MIP6 protocol would be taking us down a path with no >> visible end. >> >> -Basavaraj >> >> On 8/2/11 4:09 PM, "ext Romain KUNTZ" wrote: >> >>> Hello, >>> >>> I fail to see how LISP would fall in the MEXT charter item, which >>> concentrates on MIPv6-based DMM solution ('Operational considerations >>>for >>> distributed use of Mobile IPv6'). If LISP is foreseen as a potential >>> solution for distributed mobility management, that should probably be >>> discussed in the Network WG, where LISP and LISP MN are discussed. >>> >>> Regards, >>> Romain >>> >>> On Aug 1, 2011, at 16:50, Seok-Joo Koh wrote: >>> >>>> Dear Charles, >>>> >>>> I think the LISP can also be considered as a promising candidate >>>> in the design of DMM solutions. Several works are being progressed >>>> to use or extend the LISP for mobility support, which inlcude LISP-MN >>>> draft >>>> and many research papers. Actually, I am also considering how to >>>>extend >>>> the LISP scheme in the DMM perspective. >>>> >>>> LISP is a network-based ID-LOC separation scheme and thus it may give >>>> some >>>> advantages for effective mobility support. On the other hand, it is >>>> noted that >>>> the current version of LISP and LISP-MN may need to be more enhanced >>>> in terms of scalability in the mobile environment. For example, one >>>> concern of LISP >>>> is that the LISP EIDs may not be aggregated anymore in the mobile >>>> networks, since >>>> each mobile node will have its own distinctive EIDs that do not >>>>conform >>>> the concerned mobile domain. >>>> This may decrease the scaling benefits of original LISP. >>>> We may need to design a new enhanced EID structure to be used for >>>> mobile environment. >>>> Nontheless, it is worthwhile to consider LISP as a promisng candidate >>>> in the disign of DMM, I think. >>>> >>>> By the way, as I already said in this IETF DMM ad hoc meeting, the >>>> urgent action item of DMM is >>>> to make one or more introductory I-Ds with WG consensus, which may >>>> include >>>> the problem statements and requirements for DMM, use cases/scenarios, >>>> and comparison matrix, etc. >>>> >>>> Regards, >>>> >>>> ************************* >>>> Seok-Joo Koh >>>> http://protocol.knu.ac.kr/ >>>> ************************* >>>> >>>> ----- Original Message ----- From: "Charles E. Perkins" >>>> >>>> To: "mext" >>>> Cc: >>>> Sent: Tuesday, August 02, 2011 3:28 AM >>>> Subject: [MEXT] LISP as a solution for some part of the DMM >>>>requirement >>>> >>>> >>>>> >>>>> Hello folks, >>>>> >>>>> At IETF 81, LISP for mobile devices was presented. >>>>> While I am not yet convinced about the specific >>>>> solution presented, I started to look at LISP as >>>>> a possible component of an overall DMM solution. >>>>> >>>>> LISP has a website: >>>>> http://www.lisp4.net >>>>> >>>>> For people who are unfamiliar, this issue of IPJ >>>>> has a tutorial article about LISP: >>>>> http://www.lisp4.net/docs/ipj_11-1.pdf >>>>> >>>>> The LISP draft for mobile nodes is accessible here: >>>>> http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/ >>>>> >>>>> Comments? I think that LISP should be added to the >>>>> comparison matrix in my draft with Dapeng Liu. >>>>> Would that be helpful? >>>>> >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > From sjkoh@knu.ac.kr Tue Aug 2 16:29:25 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647AA11E8103 for ; Tue, 2 Aug 2011 16:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWPc-EbpK767 for ; Tue, 2 Aug 2011 16:29:24 -0700 (PDT) Received: from spam2.knu.ac.kr (spam2.knu.ac.kr [155.230.10.253]) by ietfa.amsl.com (Postfix) with ESMTP id A61F911E80FE for ; Tue, 2 Aug 2011 16:29:21 -0700 (PDT) Received: from unknown (HELO knu.ac.kr) (155.230.11.8) by 155.230.10.253 with SMTP; 3 Aug 2011 08:25:13 +0900 X-Original-SENDERIP: 155.230.11.8 X-Original-MAILFROM: sjkoh@knu.ac.kr x-beehive-trace: sjkoh@knu.ac.kr mext@ietf.org 155.230.105.149 Received: from knu.ac.kr by ietf.org with ESMTP (knu.ac.kr) for mext@ietf.org; Wed, 3 Aug 2011 08:29:23 +0900 (KST) x-beehive-kind: normal x-beehive-modified: received kind Message-ID: From: "Seok-Joo Koh" To: , References: Date: Wed, 3 Aug 2011 08:29:27 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: dino@cisco.com, mext@ietf.org Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 23:29:25 -0000 Hello there, To my understanding, this thread of discussion was intended to review LISP so as to collect a lot of useful information in the perspective of DMM requirements, NOT to make specific schemes, such as MIP-based, PMIP-based, or LISP-based DMM solutions. It seems that the issues on DMM requirements are under the scope of MEXT WG, as described in the WG charter. However, it is still unclear to me which WG is appropriate to develop specific solutions for DMM: MIP-based DMM -> MEXT WG ? PMIP-based DMM -> NETEXT WG ? LISP-based DMM -> LISP WG ? or all the issues shall fall into the MOPOPT RG ?? ************************* Seok-Joo Koh http://protocol.knu.ac.kr/ ************************* ----- Original Message ----- From: To: Cc: ; Sent: Wednesday, August 03, 2011 6:58 AM Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement > > Hi Charlie, > > On 8/2/11 4:41 PM, "ext Charles E. Perkins" > wrote: > >> >>Hello folks, >> >>I agree that LISP work should not be done in the [mext] >>working group. >> >>However, if the LISP design shows how to make a good >>solution for distributed anchoring, it is pertinent to >>our work insofar as it provides a model for the [mext] >>solution. In that case, if we are fortunate, it would >>be easier to devise an appropriate solution by using >>the LISP distributed anchoring as a guide. > > If the LISP design helps in alleviating the concerns that we have > identified as some of the key issues in I-D > draft-patil-mext-dmm-approaches-01.txt (Sec 3), then maybe yes. If we have > to incorporate LISP based mobility as a solution for DMM, then we have an > issue, because at the present time it can be perceived that the problems > could be solved within the framework of MIP6 signaling and network > elements. > > -Basavaraj > > >> >>Please note that I do not yet claim that LISP does >>what is needed -- only that we ought to take a look. >> >>Regards, >>Charlie P. >> >> >>On 8/2/2011 2:15 PM, Basavaraj.Patil@nokia.com wrote: >>> >>> I agree with Romain's comment. >>> The scope of DMM within the context of the MEXT WG is to reuse Mobile >>>IPv6 >>> protocols, extensions and elements to address the concerns of the base >>> Mobile IP model. >>> >>> Mobility using LISP may be a good solution in itself. I have no idea or >>> opinion about such a solution at the present time. >>> >>> I believe that we can address the DMM requirements with a few extensions >>> to MIP6 signaling and guidelines for deployment. Expanding the scope of >>> DMM beyond the base MIP6 protocol would be taking us down a path with no >>> visible end. >>> >>> -Basavaraj >>> >>> On 8/2/11 4:09 PM, "ext Romain KUNTZ" wrote: >>> >>>> Hello, >>>> >>>> I fail to see how LISP would fall in the MEXT charter item, which >>>> concentrates on MIPv6-based DMM solution ('Operational considerations >>>>for >>>> distributed use of Mobile IPv6'). If LISP is foreseen as a potential >>>> solution for distributed mobility management, that should probably be >>>> discussed in the Network WG, where LISP and LISP MN are discussed. >>>> >>>> Regards, >>>> Romain >>>> >>>> On Aug 1, 2011, at 16:50, Seok-Joo Koh wrote: >>>> >>>>> Dear Charles, >>>>> >>>>> I think the LISP can also be considered as a promising candidate >>>>> in the design of DMM solutions. Several works are being progressed >>>>> to use or extend the LISP for mobility support, which inlcude LISP-MN >>>>> draft >>>>> and many research papers. Actually, I am also considering how to >>>>>extend >>>>> the LISP scheme in the DMM perspective. >>>>> >>>>> LISP is a network-based ID-LOC separation scheme and thus it may give >>>>> some >>>>> advantages for effective mobility support. On the other hand, it is >>>>> noted that >>>>> the current version of LISP and LISP-MN may need to be more enhanced >>>>> in terms of scalability in the mobile environment. For example, one >>>>> concern of LISP >>>>> is that the LISP EIDs may not be aggregated anymore in the mobile >>>>> networks, since >>>>> each mobile node will have its own distinctive EIDs that do not >>>>>conform >>>>> the concerned mobile domain. >>>>> This may decrease the scaling benefits of original LISP. >>>>> We may need to design a new enhanced EID structure to be used for >>>>> mobile environment. >>>>> Nontheless, it is worthwhile to consider LISP as a promisng candidate >>>>> in the disign of DMM, I think. >>>>> >>>>> By the way, as I already said in this IETF DMM ad hoc meeting, the >>>>> urgent action item of DMM is >>>>> to make one or more introductory I-Ds with WG consensus, which may >>>>> include >>>>> the problem statements and requirements for DMM, use cases/scenarios, >>>>> and comparison matrix, etc. >>>>> >>>>> Regards, >>>>> >>>>> ************************* >>>>> Seok-Joo Koh >>>>> http://protocol.knu.ac.kr/ >>>>> ************************* >>>>> >>>>> ----- Original Message ----- From: "Charles E. Perkins" >>>>> >>>>> To: "mext" >>>>> Cc: >>>>> Sent: Tuesday, August 02, 2011 3:28 AM >>>>> Subject: [MEXT] LISP as a solution for some part of the DMM >>>>>requirement >>>>> >>>>> >>>>>> >>>>>> Hello folks, >>>>>> >>>>>> At IETF 81, LISP for mobile devices was presented. >>>>>> While I am not yet convinced about the specific >>>>>> solution presented, I started to look at LISP as >>>>>> a possible component of an overall DMM solution. >>>>>> >>>>>> LISP has a website: >>>>>> http://www.lisp4.net >>>>>> >>>>>> For people who are unfamiliar, this issue of IPJ >>>>>> has a tutorial article about LISP: >>>>>> http://www.lisp4.net/docs/ipj_11-1.pdf >>>>>> >>>>>> The LISP draft for mobile nodes is accessible here: >>>>>> http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/ >>>>>> >>>>>> Comments? I think that LISP should be added to the >>>>>> comparison matrix in my draft with Dapeng Liu. >>>>>> Would that be helpful? >>>>>> >>>>>> Regards, >>>>>> Charlie P. >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From sgundave@cisco.com Tue Aug 2 17:22:33 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0611711E80F2 for ; Tue, 2 Aug 2011 17:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.122 X-Spam-Level: X-Spam-Status: No, score=-3.122 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRyZFc5S8++B for ; Tue, 2 Aug 2011 17:22:31 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AE4B711E80F0 for ; Tue, 2 Aug 2011 17:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=8925; q=dns/txt; s=iport; t=1312330962; x=1313540562; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=lUm7QcrCW+V44cM6Ou7HNEQ4gXaYBljrL4zuqRwIgfA=; b=XC218XuJhBDm5+tvgJ005z5TmbfbePsn+SQBlFJ+QfMfaY5CGQWdKyNS Log+7lcTUwe4jVHJTOz+T4vF3ZJ8BERnYDzwQxf5IJhMa3Y4fDxvJOc/i hfSG+OThEnpXqxZPDx9VOsALnev9L3qIPbWij0QssVoOvLhy8K2lciOXc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusAAAeUOE6rRDoH/2dsb2JhbAA3Cg6Xdo9Wd4FAAQEBAQEBAQEBAQ8BFBMCATELBQcGAQgRBAEBAVUoCAEBBAENBRsHh0oEoAgBnlGDJIMeBIdaiyGFEIsdVw X-IronPort-AV: E=Sophos;i="4.67,307,1309737600"; d="scan'208";a="9016858" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-1.cisco.com with ESMTP; 03 Aug 2011 00:22:38 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p730McZp025731; Wed, 3 Aug 2011 00:22:38 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Aug 2011 17:22:38 -0700 Received: from 10.32.246.212 ([10.32.246.212]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Wed, 3 Aug 2011 00:22:37 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 02 Aug 2011 17:22:35 -0700 From: Sri Gundavelli To: Seok-Joo Koh , , Message-ID: Thread-Topic: [MEXT] LISP as a solution for some part of the DMM requirement Thread-Index: AcxRc3E/uupKgbU9LUmZsG4tlE5APg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Aug 2011 00:22:38.0176 (UTC) FILETIME=[73247600:01CC5173] Cc: dino@cisco.com, mext@ietf.org Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 00:22:33 -0000 > However, it is still unclear to me which WG is appropriate to develop specific > solutions for DMM: > MIP-based DMM -> MEXT WG ? > PMIP-based DMM -> NETEXT WG ? There is no reason to define a PMIP-only or a CMIP-only solution, unless the extension makes sense only to one of the mobility models. Many of the protocol options/extensions are relevant to both the approaches. Looking at revocation work [RFC-5846], it was done in MEXT WG, but the options were specified for both the client-based and network-based variants of MIPv6 protocol. We need to ensure, we don't take MIPv6 and PMIPv6 in two different directions. LMA serving network-based mobility domain is a feature extension on home agent, its the same code base, same function to most part will be supporting client-based mobile nodes and IP hosts in a PMIPv6 domain. They are not two different systems, but a common anchor point supporting two different mobility approaches, over a common protocol semantics. In any case, as Raj/Romain and others pointed out, we need to look at the problem statement and identify the needed extensions. At this point, I'm not going with the assumption that, we need to redesign the protocol, boil the ocean, or come back with a radically new approach, but rather identify the needed incremental extensions to fix some of the gaps. Sri On 8/2/11 4:29 PM, "Seok-Joo Koh" wrote: > Hello there, > > To my understanding, this thread of discussion was intended to review LISP > so as to collect a lot of useful information in the perspective of DMM > requirements, > NOT to make specific schemes, such as MIP-based, PMIP-based, or LISP-based DMM > solutions. > > It seems that the issues on DMM requirements are under the scope of MEXT WG, > as described in the WG > charter. > However, it is still unclear to me which WG is appropriate to develop specific > solutions for DMM: > MIP-based DMM -> MEXT WG ? > PMIP-based DMM -> NETEXT WG ? > LISP-based DMM -> LISP WG ? > or > all the issues shall fall into the MOPOPT RG ?? > > ************************* > Seok-Joo Koh > http://protocol.knu.ac.kr/ > ************************* > > ----- Original Message ----- > From: > To: > Cc: ; > Sent: Wednesday, August 03, 2011 6:58 AM > Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement > > >> >> Hi Charlie, >> >> On 8/2/11 4:41 PM, "ext Charles E. Perkins" >> wrote: >> >>> >>> Hello folks, >>> >>> I agree that LISP work should not be done in the [mext] >>> working group. >>> >>> However, if the LISP design shows how to make a good >>> solution for distributed anchoring, it is pertinent to >>> our work insofar as it provides a model for the [mext] >>> solution. In that case, if we are fortunate, it would >>> be easier to devise an appropriate solution by using >>> the LISP distributed anchoring as a guide. >> >> If the LISP design helps in alleviating the concerns that we have >> identified as some of the key issues in I-D >> draft-patil-mext-dmm-approaches-01.txt (Sec 3), then maybe yes. If we have >> to incorporate LISP based mobility as a solution for DMM, then we have an >> issue, because at the present time it can be perceived that the problems >> could be solved within the framework of MIP6 signaling and network >> elements. >> >> -Basavaraj >> >> >>> >>> Please note that I do not yet claim that LISP does >>> what is needed -- only that we ought to take a look. >>> >>> Regards, >>> Charlie P. >>> >>> >>> On 8/2/2011 2:15 PM, Basavaraj.Patil@nokia.com wrote: >>>> >>>> I agree with Romain's comment. >>>> The scope of DMM within the context of the MEXT WG is to reuse Mobile >>>> IPv6 >>>> protocols, extensions and elements to address the concerns of the base >>>> Mobile IP model. >>>> >>>> Mobility using LISP may be a good solution in itself. I have no idea or >>>> opinion about such a solution at the present time. >>>> >>>> I believe that we can address the DMM requirements with a few extensions >>>> to MIP6 signaling and guidelines for deployment. Expanding the scope of >>>> DMM beyond the base MIP6 protocol would be taking us down a path with no >>>> visible end. >>>> >>>> -Basavaraj >>>> >>>> On 8/2/11 4:09 PM, "ext Romain KUNTZ" wrote: >>>> >>>>> Hello, >>>>> >>>>> I fail to see how LISP would fall in the MEXT charter item, which >>>>> concentrates on MIPv6-based DMM solution ('Operational considerations >>>>> for >>>>> distributed use of Mobile IPv6'). If LISP is foreseen as a potential >>>>> solution for distributed mobility management, that should probably be >>>>> discussed in the Network WG, where LISP and LISP MN are discussed. >>>>> >>>>> Regards, >>>>> Romain >>>>> >>>>> On Aug 1, 2011, at 16:50, Seok-Joo Koh wrote: >>>>> >>>>>> Dear Charles, >>>>>> >>>>>> I think the LISP can also be considered as a promising candidate >>>>>> in the design of DMM solutions. Several works are being progressed >>>>>> to use or extend the LISP for mobility support, which inlcude LISP-MN >>>>>> draft >>>>>> and many research papers. Actually, I am also considering how to >>>>>> extend >>>>>> the LISP scheme in the DMM perspective. >>>>>> >>>>>> LISP is a network-based ID-LOC separation scheme and thus it may give >>>>>> some >>>>>> advantages for effective mobility support. On the other hand, it is >>>>>> noted that >>>>>> the current version of LISP and LISP-MN may need to be more enhanced >>>>>> in terms of scalability in the mobile environment. For example, one >>>>>> concern of LISP >>>>>> is that the LISP EIDs may not be aggregated anymore in the mobile >>>>>> networks, since >>>>>> each mobile node will have its own distinctive EIDs that do not >>>>>> conform >>>>>> the concerned mobile domain. >>>>>> This may decrease the scaling benefits of original LISP. >>>>>> We may need to design a new enhanced EID structure to be used for >>>>>> mobile environment. >>>>>> Nontheless, it is worthwhile to consider LISP as a promisng candidate >>>>>> in the disign of DMM, I think. >>>>>> >>>>>> By the way, as I already said in this IETF DMM ad hoc meeting, the >>>>>> urgent action item of DMM is >>>>>> to make one or more introductory I-Ds with WG consensus, which may >>>>>> include >>>>>> the problem statements and requirements for DMM, use cases/scenarios, >>>>>> and comparison matrix, etc. >>>>>> >>>>>> Regards, >>>>>> >>>>>> ************************* >>>>>> Seok-Joo Koh >>>>>> http://protocol.knu.ac.kr/ >>>>>> ************************* >>>>>> >>>>>> ----- Original Message ----- From: "Charles E. Perkins" >>>>>> >>>>>> To: "mext" >>>>>> Cc: >>>>>> Sent: Tuesday, August 02, 2011 3:28 AM >>>>>> Subject: [MEXT] LISP as a solution for some part of the DMM >>>>>> requirement >>>>>> >>>>>> >>>>>>> >>>>>>> Hello folks, >>>>>>> >>>>>>> At IETF 81, LISP for mobile devices was presented. >>>>>>> While I am not yet convinced about the specific >>>>>>> solution presented, I started to look at LISP as >>>>>>> a possible component of an overall DMM solution. >>>>>>> >>>>>>> LISP has a website: >>>>>>> http://www.lisp4.net >>>>>>> >>>>>>> For people who are unfamiliar, this issue of IPJ >>>>>>> has a tutorial article about LISP: >>>>>>> http://www.lisp4.net/docs/ipj_11-1.pdf >>>>>>> >>>>>>> The LISP draft for mobile nodes is accessible here: >>>>>>> http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/ >>>>>>> >>>>>>> Comments? I think that LISP should be added to the >>>>>>> comparison matrix in my draft with Dapeng Liu. >>>>>>> Would that be helpful? >>>>>>> >>>>>>> Regards, >>>>>>> Charlie P. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From Dirk.von-Hugo@telekom.de Wed Aug 3 03:40:56 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7973721F8B70 for ; Wed, 3 Aug 2011 03:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3E48HuL5L8q for ; Wed, 3 Aug 2011 03:40:55 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 17AFE21F8B6F for ; Wed, 3 Aug 2011 03:40:54 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 03 Aug 2011 12:40:49 +0200 Received: from HE113472.emea1.cds.t-internal.com (10.134.93.130) by HE110889.emea1.cds.t-internal.com (10.134.92.130) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 3 Aug 2011 12:40:45 +0200 Received: from HE113484.emea1.cds.t-internal.com ([169.254.4.241]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 3 Aug 2011 12:40:45 +0200 From: To: , Date: Wed, 3 Aug 2011 12:40:44 +0200 Thread-Topic: [MEXT] my handwritten minutes about the "not MEXT" meeting IETF81 Thread-Index: AcxRCUllxXUoOE6ASuSCbqQ9blUx/wAv71DQ Message-ID: <05C81A773E48DD49B181B04BA21A342A263EFE4BE4@HE113484.emea1.cds.t-internal.com> References: <4E37E2A1.2030705@gmail.com> In-Reply-To: <4E37E2A1.2030705@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [MEXT] my handwritten minutes about the "not MEXT" meeting IETF81 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 10:40:56 -0000 Hi Alex, Thanks for sharing your notes - I just may add mine here for information (e= ven more unofficial ones ;-)): Discussions between Hendrik, Raj, Charlie on reason for missing deployment = of host-based mobility and low ML traffic (decommission DMM!) - session continuity (pot. w/o HoA continuity) vs. MIP mobility with consta= nt HoA - multiple HAs for different sessions?(Marco and Raj) Alex proposes to derive DMM requirements from relaxed MIP requirements Charlie: solution space too large for exhaustive analysis Raj: practical limit to existing boundaries - no new solution Jouni: No solution for all possible deployment cases minimum baseline for dployment? take into account effort required on host? 1. Discussion of DMM I-Ds and topic (60 mins) Sri: Motivation local breakout vs. home tunneling mobility chaining (EPC&WLAN for off-load) goals: can we evolve the source address selection for mobility awareness? Prefix coloring (address properties) application configuration protocol extensions (e.g. PIO in RA, or new DHCPv6 option) IPv6 host policy table on address selection (some apps need no mobility sup= port!) Charlie: mobility vs. other app specific (QoS) requirements - connection manager functionality (aka. socket stuff) Juan Carlos on similar work in MIF WG Alex on 6MAN WG items Anthony presents impressive wish list ("desirables" rather than requirement= s) RO in flat topology? Raj slide on reasons for DMM: - backhauling all traffic to central GW - latency considerations - inefficient routing (to a distant HA) and signalling overhead - scalability and cost ZTE presentation MN and CN on different MAGs Raj: difference to LR? Charlie: both on same domain - if not, traffic will go through LMA general discussion: Pete: keep in mind centralized accounting/charging (not to talk about billi= ng!) at GGSN - how to solve in distributed architecture? 2. Enhancements to (DS)MIP6 to meet deployment and 4G+ architecture needs (= 60 mins) charlie: motivation (no 3GPP consideration of IETF - GTP!) possible solution elements: enabling easier evolution towards IETF solution - PMIP with GTP extensions? - EAP-AKA enabled HA? - SFF-based HOs for heterogeneous networks HA can help based on existing MSA with UE Raj: criteria for IETF superiority? Proved?? Charlies other slides... discussion on GTP (Alex) Pete: LTE is moving target - consider LTE what it will be in some years ... Raj and Sri: 3GPP as closed system - not to try to enter, but focus on WLAN Charlie: Always been told "it is too late" no it's not Raj: flow mobility will be covered in Netext Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] Im Auftrag von Al= exandru Petrescu Gesendet: Dienstag, 2. August 2011 13:42 An: mext Betreff: [MEXT] my handwritten minutes about the "not MEXT" meeting IETF81 This is unofficial, and is my sentiment about this meeting, which, as all sentiments, may be not right. MEXT Discussion Group met on July 27th, 2011, in room 303ABC of Hilton, in Qu=E9bec, Canada, during the IETF 81 meeting, as announced in the attached email. Approximately 21-27 people were in the room, varying in time. It was led by Charles Perkins and Raj Patil. There was projector and slides. CP humurously named this the "not MEXT WG" meeting, laughs. CP invited to post to MEXT email list (and no longer use the DMM email list dmm@ietf.org) and he gave reasonable argument for that. Requirements discussion happened. Sri on Source Address Selection and Policy Table DHCP. Antony Chan on problem statement for dynamic mobility mgmt. Raj Patil on reasons for DMM: not backhauling, latency, inefficient routing, scalability and cost. Dapeng Liu (spelling?) of ZTE saying DMM based on PMIP is different than LR PMIP in that order of LMA and MAG. Carlos on PMIP-DMM will present in Mobopts RG. Pete McCann on lawful interception. CP on IETF Protocols for 4th generation wireless. Mobile IP in 4G Networks. GTP for HA. WLAN as a "trusted network". EAP running HA instead of AAA, because HA-VPN inefficient. SIPTO. LIPTA (local IP Access). Discussion. CP said maybe slides will he upload send ref. End of minutes. Alex From charles.perkins@earthlink.net Wed Aug 3 10:25:09 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5510C21F8AAC for ; Wed, 3 Aug 2011 10:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i91+8KUnekUr for ; Wed, 3 Aug 2011 10:25:08 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id BD87421F8A96 for ; Wed, 3 Aug 2011 10:25:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=KBblUwLjruEcoH66E8CU/gdi15yyIIm59+qPLsWQ/Dx9bbj/PIvJgZ4aBs2XiBUu; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.56]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1QofC1-0002ue-Rq for mext@ietf.org; Wed, 03 Aug 2011 13:25:17 -0400 Message-ID: <4E39847B.7080803@earthlink.net> Date: Wed, 03 Aug 2011 10:25:15 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86bf200e887ff5f86af7161735c81b3d1c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Subject: [MEXT] draft-perkins-mext-hatunaddr-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 17:25:09 -0000 Hello folks, I have revised and resubmitted my earlier draft proposing a split between the control and data plane addresses of the home agent. For some reason, the Internet Draft submission process seems to have hung when I made the formal submission, and I don't know when I will get the verification email. In the meantime, here is a URL: http://www.psg.com/~charliep/txt/ietf81/draft-perkins-mext-hatunaddr-01.txt I also added text for the same idea with Mobile IPv4. Regards, Charlie P. From charliep@computer.org Wed Aug 3 12:20:07 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE6E21F8A4B for ; Wed, 3 Aug 2011 12:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-fyTBSU5thK for ; Wed, 3 Aug 2011 12:20:07 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id B732F21F8538 for ; Wed, 3 Aug 2011 12:20:06 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.96.56]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1QogzJ-0000ed-3G for mext@ietf.org; Wed, 03 Aug 2011 15:20:17 -0400 Message-ID: <4E399F6E.8090508@computer.org> Date: Wed, 03 Aug 2011 12:20:14 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mext References: <20110803185832.21283.61262.idtracker@ietfa.amsl.com> In-Reply-To: <20110803185832.21283.61262.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110803185832.21283.61262.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad864b475bca209d1cb78b59150c3248bfb0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Subject: [MEXT] Fwd: New Version Notification for draft-perkins-mext-hatunaddr-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 19:20:07 -0000 Hello folks, My draft has now made it through the submission process. Please excuse the repeat notification... Comments will be appreciated. Regards, Charlie P. -------- Original Message -------- Subject: New Version Notification for draft-perkins-mext-hatunaddr-01.txt Date: Wed, 03 Aug 2011 11:58:32 -0700 From: To: CC: A new version of I-D, draft-perkins-mext-hatunaddr-01.txt has been successfully submitted by Charles Perkins and posted to the IETF repository. Filename: draft-perkins-mext-hatunaddr Revision: 01 Title: Alternate Tunnel Source Address for Home Agent Creation date: 2011-08-03 WG ID: Individual Submission Number of pages: 10 Abstract: Widely deployed mobility management systems for wireless communications have isolated the path for forwarding data from the control plane signaling for mobility management. To realize this requirement with Mobile IP requires that the control functions of the home agent be addressable at a different IP address than the source IP address of the tunnel between the home agent and mobile node. Similar considerations hold for mobility anchors implementing Hierarchical Mobile IP or PMIP. The IETF Secretariat From julien.ietf@gmail.com Thu Aug 4 09:03:20 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B3B21F8BAB for ; Thu, 4 Aug 2011 09:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASHcnGscgtuf for ; Thu, 4 Aug 2011 09:03:19 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7281221F856C for ; Thu, 4 Aug 2011 09:03:19 -0700 (PDT) Received: by wwe5 with SMTP id 5so1391913wwe.13 for ; Thu, 04 Aug 2011 09:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Rpvd3i3f/sZtb4CpbxR52oQttTN9CyZcfzC0QJNTAB4=; b=ZFgXDj//ArQdPJW1Simo1Td+0nrbA28OjSSASBmXNtrPHQumv8sUhL0tSXjfRQ+VDb W+RJZBUYfY8sjpDOlNe3OM3kirPo6XrlIpnzuJagcxIupQs1lD8cMnCsBdz8U0TSzNtO 4WiMtMYykA7mRou26H7SgN3/toldPAAJnvfrg= MIME-Version: 1.0 Received: by 10.227.177.133 with SMTP id bi5mr895502wbb.39.1312473813629; Thu, 04 Aug 2011 09:03:33 -0700 (PDT) Received: by 10.227.152.13 with HTTP; Thu, 4 Aug 2011 09:03:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Aug 2011 09:03:33 -0700 Message-ID: From: Julien Laganier To: Seok-Joo Koh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org, dino@cisco.com, Basavaraj.Patil@nokia.com Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:03:21 -0000 Seok-Joo, At this point it is not clear that new mechanisms are needed thus the question on where should solution work be undertaken seems a bit premature. For now I' d advise people interested in the DMM work to focus on what are their requirements and then see how the MIPv6 protocol suite can be applied to fulfill those. --julien On Tue, Aug 2, 2011 at 4:29 PM, Seok-Joo Koh wrote: > Hello there, > > To my understanding, this thread of discussion was intended to review LIS= P > so as to collect a lot of useful information in the perspective of DMM > requirements, > NOT to make specific schemes, such as MIP-based, PMIP-based, or LISP-base= d > DMM solutions. > > It seems that the issues on DMM requirements are under the scope of MEXT = WG, > as described in the WG charter. > However, it is still unclear to me which WG is appropriate to develop > specific solutions for DMM: > MIP-based DMM -> MEXT WG ? > PMIP-based DMM -> NETEXT WG ? > LISP-based DMM -> LISP WG ? > or > all the issues shall fall into the MOPOPT RG ?? > > ************************* > Seok-Joo Koh > http://protocol.knu.ac.kr/ > ************************* > > ----- Original Message ----- From: > To: > Cc: ; > Sent: Wednesday, August 03, 2011 6:58 AM > Subject: Re: [MEXT] LISP as a solution for some part of the DMM requireme= nt > > >> >> Hi Charlie, >> >> On 8/2/11 4:41 PM, "ext Charles E. Perkins" >> wrote: >> >>> >>> Hello folks, >>> >>> I agree that LISP work should not be done in the [mext] >>> working group. >>> >>> However, if the LISP design shows how to make a good >>> solution for distributed anchoring, it is pertinent to >>> our work insofar as it provides a model for the [mext] >>> solution. =A0In that case, if we are fortunate, it would >>> be easier to devise an appropriate solution by using >>> the LISP distributed anchoring as a guide. >> >> If the LISP design helps in alleviating the concerns that we have >> identified as some of the key issues in I-D >> draft-patil-mext-dmm-approaches-01.txt (Sec 3), then maybe yes. If we ha= ve >> to incorporate LISP based mobility as a solution for DMM, then we have a= n >> issue, because at the present time it can be perceived that the problems >> could be solved within the framework of MIP6 signaling and network >> elements. >> >> -Basavaraj >> >> >>> >>> Please note that I do not yet claim that LISP does >>> what is needed -- only that we ought to take a look. >>> >>> Regards, >>> Charlie P. >>> >>> >>> On 8/2/2011 2:15 PM, Basavaraj.Patil@nokia.com wrote: >>>> >>>> I agree with Romain's comment. >>>> The scope of DMM within the context of the MEXT WG is to reuse Mobile >>>> IPv6 >>>> protocols, extensions and elements to address the concerns of the base >>>> Mobile IP model. >>>> >>>> Mobility using LISP may be a good solution in itself. I have no idea o= r >>>> opinion about such a solution at the present time. >>>> >>>> I believe that we can address the DMM requirements with a few extensio= ns >>>> to MIP6 signaling and guidelines for deployment. Expanding the scope o= f >>>> DMM beyond the base MIP6 protocol would be taking us down a path with = no >>>> visible end. >>>> >>>> -Basavaraj >>>> >>>> On 8/2/11 4:09 PM, "ext Romain KUNTZ" =A0wro= te: >>>> >>>>> Hello, >>>>> >>>>> I fail to see how LISP would fall in the MEXT charter item, which >>>>> concentrates on MIPv6-based DMM solution ('Operational considerations >>>>> for >>>>> distributed use of Mobile IPv6'). If LISP is foreseen as a potential >>>>> solution for distributed mobility management, that should probably be >>>>> discussed in the Network WG, where LISP and LISP MN are discussed. >>>>> >>>>> Regards, >>>>> Romain >>>>> >>>>> On Aug 1, 2011, at 16:50, Seok-Joo Koh wrote: >>>>> >>>>>> Dear Charles, >>>>>> >>>>>> I think the LISP can also be considered as a promising candidate >>>>>> in the design of DMM solutions. Several works are being progressed >>>>>> to use or extend the LISP for mobility support, which inlcude LISP-M= N >>>>>> draft >>>>>> and many research papers. Actually, I am also considering how to >>>>>> extend >>>>>> the LISP scheme in the DMM perspective. >>>>>> >>>>>> LISP is a network-based ID-LOC separation scheme and thus it may giv= e >>>>>> some >>>>>> advantages for effective mobility support. On the other hand, it is >>>>>> noted that >>>>>> the current version of LISP and LISP-MN may need to be more enhanced >>>>>> in terms of scalability in the mobile environment. For example, one >>>>>> concern of LISP >>>>>> is that the LISP EIDs may not be aggregated anymore in the mobile >>>>>> networks, since >>>>>> each mobile node will have its own distinctive EIDs that do not >>>>>> conform >>>>>> the concerned mobile domain. >>>>>> This may decrease the scaling benefits of original LISP. >>>>>> We may need to design a new enhanced EID structure to be used for >>>>>> mobile environment. >>>>>> Nontheless, it is worthwhile to consider LISP as a promisng candidat= e >>>>>> in the disign of DMM, I think. >>>>>> >>>>>> By the way, as I already said in this IETF DMM ad hoc meeting, the >>>>>> urgent action item of DMM is >>>>>> to make one or more introductory I-Ds with WG consensus, which may >>>>>> include >>>>>> the problem statements and requirements for DMM, use cases/scenarios= , >>>>>> and comparison matrix, etc. >>>>>> >>>>>> Regards, >>>>>> >>>>>> ************************* >>>>>> Seok-Joo Koh >>>>>> http://protocol.knu.ac.kr/ >>>>>> ************************* >>>>>> >>>>>> ----- Original Message ----- From: "Charles E. Perkins" >>>>>> >>>>>> To: "mext" >>>>>> Cc: >>>>>> Sent: Tuesday, August 02, 2011 3:28 AM >>>>>> Subject: [MEXT] LISP as a solution for some part of the DMM >>>>>> requirement >>>>>> >>>>>> >>>>>>> >>>>>>> Hello folks, >>>>>>> >>>>>>> At IETF 81, LISP for mobile devices was presented. >>>>>>> While I am not yet convinced about the specific >>>>>>> solution presented, I started to look at LISP as >>>>>>> a possible component of an overall DMM solution. >>>>>>> >>>>>>> LISP has a website: >>>>>>> http://www.lisp4.net >>>>>>> >>>>>>> For people who are unfamiliar, this issue of IPJ >>>>>>> has a tutorial article about LISP: >>>>>>> http://www.lisp4.net/docs/ipj_11-1.pdf >>>>>>> >>>>>>> The LISP draft for mobile nodes is accessible here: >>>>>>> http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/ >>>>>>> >>>>>>> Comments? =A0I think that LISP should be added to the >>>>>>> comparison matrix in my draft with Dapeng Liu. >>>>>>> Would that be helpful? >>>>>>> >>>>>>> Regards, >>>>>>> Charlie P. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From rkuntz@us.toyota-itc.com Thu Aug 4 11:38:53 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1518A11E80A6 for ; Thu, 4 Aug 2011 11:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpMVMlh7D9wE for ; Thu, 4 Aug 2011 11:38:52 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with SMTP id 5CAE311E808C for ; Thu, 4 Aug 2011 11:38:51 -0700 (PDT) Received: from mail-pz0-f49.google.com ([209.85.210.49]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTjrnSctdZymoEAxsSGp7Qm465kLnvhk5@postini.com; Thu, 04 Aug 2011 11:39:08 PDT Received: by mail-pz0-f49.google.com with SMTP id 6so1241703pzk.22 for ; Thu, 04 Aug 2011 11:39:05 -0700 (PDT) Received: by 10.143.20.28 with SMTP id x28mr1100677wfi.349.1312483145337; Thu, 04 Aug 2011 11:39:05 -0700 (PDT) Received: from hong-lt.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id m7sm2488983pbk.54.2011.08.04.11.39.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Aug 2011 11:39:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Romain KUNTZ In-Reply-To: <4E399F6E.8090508@computer.org> Date: Thu, 4 Aug 2011 11:39:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <75B8624B-6C94-4B7F-9487-DCF0E06B5256@us.toyota-itc.com> References: <20110803185832.21283.61262.idtracker@ietfa.amsl.com> <4E399F6E.8090508@computer.org> To: charliep@computer.org X-Mailer: Apple Mail (2.1244.3) Cc: mext Subject: Re: [MEXT] New Version Notification for draft-perkins-mext-hatunaddr-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 18:38:53 -0000 Hello Charlie, If the MN has to tunnel data to a different HA than the one to which it = sends the BU, then it also needs an IPsec SA with that HA. How would the = MN create such SA as it does not know in advance what HA it may use for = tunneling? My guess is that the MN is supposed to trust the address = received in the option and create the SA upon reception of the option. = Similarly, all of the HA tunneling box would also need to be configured = with the corresponding SA. Some considerations about that may be needed = in the draft. Regards, romain =20 On Aug 3, 2011, at 12:20, Charles E. Perkins wrote: >=20 > Hello folks, >=20 > My draft has now made it through the submission process. > Please excuse the repeat notification... >=20 > Comments will be appreciated. >=20 > Regards, > Charlie P. >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for = draft-perkins-mext-hatunaddr-01.txt > Date: Wed, 03 Aug 2011 11:58:32 -0700 > From: > To: > CC: >=20 > A new version of I-D, draft-perkins-mext-hatunaddr-01.txt has been = successfully submitted by Charles Perkins and posted to the IETF = repository. >=20 > Filename: draft-perkins-mext-hatunaddr > Revision: 01 > Title: Alternate Tunnel Source Address for Home Agent > Creation date: 2011-08-03 > WG ID: Individual Submission > Number of pages: 10 >=20 > Abstract: > Widely deployed mobility management systems for wireless > communications have isolated the path for forwarding data from the > control plane signaling for mobility management. To realize this > requirement with Mobile IP requires that the control functions of = the > home agent be addressable at a different IP address than the source > IP address of the tunnel between the home agent and mobile node. > Similar considerations hold for mobility anchors implementing > Hierarchical Mobile IP or PMIP. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From charles.perkins@earthlink.net Thu Aug 4 13:51:55 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0A021F867F for ; Thu, 4 Aug 2011 13:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzzDBXol7EVB for ; Thu, 4 Aug 2011 13:51:54 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4260A21F8678 for ; Thu, 4 Aug 2011 13:51:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=X0oWMClW1aAcE5TLUbOS3pr6/XI9sv2Myw8owLH6LylZ8VpU/HD91N2770TrjUbw; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.56]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Qp4tl-0003cj-Gn for mext@ietf.org; Thu, 04 Aug 2011 16:52:09 -0400 Message-ID: <4E3B0677.8050705@earthlink.net> Date: Thu, 04 Aug 2011 13:52:07 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86f82972c8ee93e53a4cc36877e980fe90350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Subject: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 20:51:55 -0000 Hello folks, Sorry if this is considered to be imperfectly relevant, but I'm curious whether or not handovers in the future would be typically make-before-break. Or [even "worse"], in terms of radio interfaces, whether typically wireless devices in the future will keep multiple radios powered on all the time. This might well have an impact on assumptions about dmm. It was claimed that, for instance, iPad and iPhone usually have both interfaces active. I know that when I'm using my iPad I do not keep both radios turned on, but I do not claim to be a typical user, and anyway I do not have an iPhone. Comments will be appreciated! Regards, Charlie P. From Basavaraj.Patil@nokia.com Thu Aug 4 14:21:57 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4FC921F8879 for ; Thu, 4 Aug 2011 14:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.682 X-Spam-Level: X-Spam-Status: No, score=-102.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyNChLkvDZas for ; Thu, 4 Aug 2011 14:21:57 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id C1C7521F8877 for ; Thu, 4 Aug 2011 14:21:56 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p74LM5Sd030032; Fri, 5 Aug 2011 00:22:06 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Aug 2011 00:22:05 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 4 Aug 2011 23:22:04 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.61]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0323.002; Thu, 4 Aug 2011 23:22:02 +0200 From: To: , Thread-Topic: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance Thread-Index: AQHMUuyMHmpdQRSJykeD7X8pFNgavw== Date: Thu, 4 Aug 2011 21:22:01 +0000 Message-ID: In-Reply-To: <4E3B0677.8050705@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [173.74.219.186] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <290FE8FC3DC71044AFC45D9F6A80E97C@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Aug 2011 21:22:05.0384 (UTC) FILETIME=[8F1F1480:01CC52EC] X-Nokia-AV: Clean Subject: Re: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 21:21:57 -0000 Hi Charlie, I guess you are referring to handovers across different access types (wifi<->3G) etc. Whether you can accomplish a make-before-break handover in such scenarios depends on the device in many cases. So there is no black-or-white answer to your question at the present time. Will devices keep multiple radios powered on simultaneously in the future? It depends. Battery technology still lags the advances of radio, processors and displays on devices. And hence it generally boils down to optimizing battery in handheld devices which implies that you would not want to always keep multiple radios switched "On" all the time. You could if you were willing to carry around a battery backpack all the time :) Or keep your device plugged into a power source or charge it every few hours... Algorithms will/may help a device to turn on/off various radios to enable better handover performance. And multiple radios could be simultaneously operational for brief periods of time to enable the make-before-break handover scenarios. DMM design should not be overly concerned about the make-before-break handovers IMO. DMM is focused on optimizing the latency, reducing backhaul traffic etc. I don=B9t believe DMM is a way to enable handovers with better performance. It would be a benefit if performance of even the break-before-make handover scenario improves as a result of DMM. W.r.t devices a couple of examples: 1. On my Nokia N900 (Maemo), I can operate both the wifi and 3G radios simultaneously (requires an update to the software that ships on the device). Normal operation however is either wifi or 3G. 2. On my N8 (S^3), I can have cellular data (PDP context) and wifi connectivity running in parallel all the time. But there is no good reason to do that. And hence the setting is to have either 3G or Wifi data connectivity.=20 -Basavaraj On 8/4/11 3:52 PM, "ext Charles E. Perkins" wrote: > >Hello folks, > >Sorry if this is considered to be imperfectly relevant, >but I'm curious whether or not handovers in the future >would be typically make-before-break. Or [even "worse"], >in terms of radio interfaces, whether typically wireless >devices in the future will keep multiple radios powered >on all the time. > >This might well have an impact on assumptions about >dmm. It was claimed that, for instance, iPad and iPhone >usually have both interfaces active. I know that when >I'm using my iPad I do not keep both radios turned on, >but I do not claim to be a typical user, and anyway I >do not have an iPhone. > >Comments will be appreciated! > >Regards, >Charlie P. > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext From stu.card@critical.com Thu Aug 4 15:40:56 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF13711E8080 for ; Thu, 4 Aug 2011 15:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ni3G9EwnVLYn for ; Thu, 4 Aug 2011 15:40:55 -0700 (PDT) Received: from mail.critical.com (mail.critical.com [64.246.137.41]) by ietfa.amsl.com (Postfix) with ESMTP id 923BC11E807C for ; Thu, 4 Aug 2011 15:40:55 -0700 (PDT) Received: by mail.critical.com (Postfix, from userid 99) id 965A319311; Thu, 4 Aug 2011 18:41:08 -0400 (EDT) Received: from [192.168.10.102] (unknown [64.246.137.24]) by mail.critical.com (Postfix) with ESMTP id 8BE7949B5; Thu, 4 Aug 2011 18:41:04 -0400 (EDT) Message-ID: <4E3B1FFC.8050106@critical.com> Date: Thu, 04 Aug 2011 18:41:00 -0400 From: "Stuart W. Card" Organization: Critical Technologies Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b2pre Thunderbird/3.0 MIME-Version: 1.0 To: mext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=ADB078BE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mary.chruscicki@agilexllc.com, patricia.baskinger@agilexllc.com Subject: Re: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 22:40:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/4/2011 5:22 PM, Basavaraj.Patil@nokia.com wrote: > ... > I guess you are referring to handovers across different access types... Could be either -- some systems have multiple interfaces of the same type that can be active simultaneously. For instance I have worked on airborne platforms with multiple VHF/UHF line-of-sight radios each connecting to a different basestation concurrently; depending upon where the aircraft was in its orbit, it would have good links to some but not all of the basestations; we load balanced dynamically across all links that were up at any moment, keeping MIP registrations active on links that were down only briefly by backing off the registration timeouts (but not routing any traffic over them while they were down). > Will devices keep multiple radios powered on simultaneously in the future? > It depends. > Battery technology still lags the advances of radio, processors and > displays on devices. And hence it generally boils down to optimizing > battery in handheld devices which implies that you would not want to > always keep multiple radios switched "On" all the time... There's nominally "on" and there's really "on". IMHO you can expect to see newer radios that aggressively manage battery energy consumption through scheduling and wake-up tricks, so that a radio can be nominally "on" in the sense that if any traffic is destined for that node, it will go really "on" and receive that traffic, then go quiescent again. Whether this happens on a session by session or packet by packet basis is just another engineering trade-off that can go either way depending upon the particulars of the design case. > On 8/4/11 3:52 PM, "ext Charles E. Perkins" > wrote: > >> ... I'm curious whether or not handovers in the future >> would be typically make-before-break. Or [even "worse"], >> in terms of radio interfaces, whether typically wireless >> devices in the future will keep multiple radios powered >> on all the time... Check out how many Android smartphones operate today. I'm not sure, but it looks to me like they continue to use their cellular connections for certain network management functions even when they are using WiFi for user bulk data transfers. Also consider the use of smartphones as WiFi hotspots, together with WiFi mesh networking: there are all kinds of corner cases involving NEMO, MANET, etc., some of which may become prevalent. The Internet of Things will complicate this further. A while back when I was actively participating in the on-line discussions regarding NEMO, it was decided that the complex cases involving multi-homing and nesting would be left out of scope, because they were a lot harder than the basic scenarios that presumably would be a lot more common initially, and we needed to make progress on support for those basic scenarios. Here's a scenario I presented then (avoiding HA, MR, etc. nomenclature and details to avoid nitpicking): NEMO#1 aboard aircraft#1 connects to basestation#1 NEMO#2 aboard aircraft#2 connects to NEMO#1 initially (nesting) NEMO#2 aboard aircraft#2 connects to basestation#2 later (multihoming) NEMO#1 aboard aircraft#1 loses its connection to basestation#1 Do we really want to cause all open connections from nodes in NEMO#1 to break? When they could be re-routed via NEMO#2 (nesting, reversed from its initial heirarchy)? If I were running NEMO#2, I sure would want to make a route via basestation#2 before I broke my route via NEMO#1... and if I were running NEMO#1, and had some way of learning that NEMO#2 had achieved another path to the backbone, I sure would want to make a route via NEMO#2 as soon as I could, just in case I might later break (lose) my route via basestation#1. Addressing this handover/multihoming/nesting scenario is probably out of scope for DMM. However, it would not seem to me very prudent to design DMM such that it can't handle at least make-before-break, and preferably the more general case of "multiple radios powered on all the time". (Just the $0.02 of a guy who was heavily involved in some of the earliest experiments with MIP, NEMO, multi-homing and nesting on aircraft, but who has not been active since this WG became MEXT.) - -- Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc. * Creativity * Diversity * Expertise * Flexibility * Integrity * Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501 315-793-0248 x141 FAX -9710 www.critical.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk47H/wACgkQS7PQ0a2weL6jPACfQYwRIH7jSt2HQesBC2gISXtI qOwAoMWoWjmtJpOs8C8T0jPLX7daoVX4 =2c8h -----END PGP SIGNATURE----- From charles.perkins@earthlink.net Thu Aug 4 15:47:38 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2B821F8556 for ; Thu, 4 Aug 2011 15:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVa38qhYJ6Ec for ; Thu, 4 Aug 2011 15:47:38 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDBF21F8546 for ; Thu, 4 Aug 2011 15:47:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gMDB9RTPP9TVDXyzKtIZy1/CJyVqEVuiJXbGbAuTR37rMoXRKtL7WIpuIGWdEnJK; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.56]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Qp6hj-00074o-LA for mext@ietf.org; Thu, 04 Aug 2011 18:47:51 -0400 Message-ID: <4E3B2194.9030309@earthlink.net> Date: Thu, 04 Aug 2011 15:47:48 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86b4d4d3b1c61d8850b3789d94bd508267350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Subject: [MEXT] Minutes and presentations from the "alt-mext" discussion group at IETF 81 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 22:47:38 -0000 Hello folks, We had a lively discussion at an ad-hoc meeting for people interesting in discussion DMM and other [mext]-related topics at the IETF. I have collected together the materials at the following website: http://www.psg.com/~charliep/txt/ietf81/alt_mext/ Here are some minutes, collected from Alex and Dirk [thanks!]. One important procedural detail from the meeting bears repetition. It was stated that the reason we did not have a scheduled meeting of the [mext] WG at IETF 81, was because there was not much discussion on the mailing list. Some of the discussion had instead gone to the old DMM mailing list. I recommended that we shut down the DMM mailing list, because anything related to DMM ought to be discussed on the main [mext] mailing list now that DMM is on our charter. No one objected to my recommendation. Is there anyone on the [mext] mailing list who would object if the DMM mailing list were to be shut down? For all other comments, please direct discussion to this mailing list. Regards, Charlie P. From charles.perkins@earthlink.net Thu Aug 4 15:56:11 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A0521F85CA for ; Thu, 4 Aug 2011 15:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDN7NcqU-Yhp for ; Thu, 4 Aug 2011 15:56:10 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 533B121F85C7 for ; Thu, 4 Aug 2011 15:56:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=WZH187DCuNIgtuZre6e4l40b60F2DSPMSgBw7GoJ96hkfG0lEPyFBnlpJL/bsKoI; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.56]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Qp6q1-000850-EL for mext@ietf.org; Thu, 04 Aug 2011 18:56:25 -0400 Message-ID: <4E3B2396.8000007@earthlink.net> Date: Thu, 04 Aug 2011 15:56:22 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mext References: <4E3B2194.9030309@earthlink.net> In-Reply-To: <4E3B2194.9030309@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86ab69a22512f7b4f5e3901aeff921c3b7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Subject: Re: [MEXT] Minutes and presentations from the "alt-mext" discussion group at IETF 81 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 22:56:11 -0000 Hello again folks, On 8/4/2011 3:47 PM, Charles E. Perkins wrote: > Here are some minutes, collected from Alex and Dirk > [thanks!]. Please excuse -- I forgot to include the minutes in my previous message... ================================================================== Agenda: alt_mext-Minutes.txt - Purpose of meeting (vs. scheduled WG meetings) - Need to increase participation on mailing list = Should decommission [dmm] mailing list - Discussion of DMM I-Ds and topic (60 mins) - Enhancements to (DS)MIP6 to meet deployment and 4G+ architecture needs (60 mins) - Anything else that people have in mind. Presenters [including filename on http://www.psg.com/~charliep/txt/ietf81/alt_mext/] Charles Perkins: Agenda Agenda-Mext_Discussion.pptx Sri Gundavelli: Source Address Selection Evolving-The-SAS-Rules-for-Mobility-Awareness-2.pdf Anthony Chan: problem statement for dynamic mobility mgmt. distributed-mobility-should.ppt Luo Wen: PMIP Based DMM Approach-Song PMIP Based DMM Approach-Song.pptx Basavaraj Patil: Reasons for DMM (backhaul, etc.) DMM_Approaches_with_MIP6_IETF80.pdf Charles Perkins: Mobile IP for 4G wireless MIPv4_for_4G.pptx == Minutes from Alexandru Petrescu === MEXT Discussion Group met on July 27th, 2011, in room 303ABC of Hilton, in Québec, Canada, during the IETF 81 meeting, as announced in the attached email. Approximately 21-27 people were in the room, varying in time. It was led by Charles Perkins and Raj Patil. There was projector and slides. CP humurously named this the "not MEXT WG" meeting, laughs. CP invited to post to MEXT email list (and no longer use the DMM email list dmm@ietf.org) and he gave reasonable argument for that. Requirements discussion happened. Sri on Source Address Selection and Policy Table DHCP. Antony Chan on problem statement for dynamic mobility mgmt. Raj Patil on reasons for DMM: not backhauling, latency, inefficient routing, scalability and cost. Dapeng Liu (spelling?) of ZTE saying DMM based on PMIP is different than LR PMIP in that order of LMA and MAG. Carlos on PMIP-DMM will present in Mobopts RG. Pete McCann on lawful interception. CP on IETF Protocols for 4th generation wireless. Mobile IP in 4G Networks. GTP for HA. WLAN as a "trusted network". EAP running HA instead of AAA, because HA-VPN inefficient. SIPTO. LIPTA (local IP Access). Discussion. CP said maybe slides will he upload send ref. End of minutes. Alex ======= Minutes from Dirk von Hugo ====== Discussions between Hendrik, Raj, Charlie on reason for missing deployment of host-based mobility and low ML traffic (decommission DMM!) - session continuity (pot. w/o HoA continuity) vs. MIP mobility with constant HoA - multiple HAs for different sessions?(Marco and Raj) Alex proposes to derive DMM requirements from relaxed MIP requirements Charlie: solution space too large for exhaustive analysis Raj: practical limit to existing boundaries - no new solution Jouni: No solution for all possible deployment cases minimum baseline for deployment? take into account effort required on host? 1. Discussion of DMM I-Ds and topic (60 mins) Sri: Motivation local breakout vs. home tunneling mobility chaining (EPC&WLAN for off-load) goals: can we evolve the source address selection for mobility awareness? Prefix coloring (address properties) application configuration protocol extensions (e.g. PIO in RA, or new DHCPv6 option) IPv6 host policy table on address selection (some apps need no mobility support!) Charlie: mobility vs. other app specific (QoS) requirements - connection manager functionality (aka. socket stuff) Juan Carlos on similar work in MIF WG Alex on 6MAN WG items Anthony presents impressive wish list ("desirables" rather than requirements) RO in flat topology? Raj slide on reasons for DMM: - backhauling all traffic to central GW - latency considerations - inefficient routing (to a distant HA) and signalling overhead - scalability and cost ZTE presentation MN and CN on different MAGs Raj: difference to LR? Charlie: both on same domain - if not, traffic will go through LMA general discussion: Pete: keep in mind centralized accounting/charging (not to talk about billing!) at GGSN - how to solve in distributed architecture? 2. Enhancements to (DS)MIP6 to meet deployment and 4G+ architecture needs (60 mins) charlie: motivation (no 3GPP consideration of IETF - GTP!) possible solution elements: enabling easier evolution towards IETF solution - PMIP with GTP extensions? - EAP-AKA enabled HA? - SFF-based HOs for heterogeneous networks HA can help based on existing MSA with UE Raj: criteria for IETF superiority? Proved?? Charlies other slides... discussion on GTP (Alex) Pete: LTE is moving target - consider LTE what it will be in some years ... Raj and Sri: 3GPP as closed system - not to try to enter, but focus on WLAN Charlie: Always been told "it is too late" no it's not Raj: flow mobility will be covered in Netext ========================================================================== Regards, Charlie P. From julien.ietf@gmail.com Thu Aug 4 19:10:36 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F16321F8512 for ; Thu, 4 Aug 2011 19:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vl3x6675en-A for ; Thu, 4 Aug 2011 19:10:36 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7CF621F8511 for ; Thu, 4 Aug 2011 19:10:35 -0700 (PDT) Received: by wyg8 with SMTP id 8so935342wyg.31 for ; Thu, 04 Aug 2011 19:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gkAz1wvQqc022j2Sl8AXS7ERKdAD/3MG5Qllb/tOlxY=; b=sJ1Ok/TW5wDSS2/jb2HFj3NZaX3DywauB7CEIx81p+1vOAiMVTwaPBo76Y3mIOzB6/ f+0hyMDxtDGkicjuQhhpCkZ02lEbfZhCRH5kqiT10EVnnx0jHHJgzgkBS+gygBECMwOU LztxCpYRoiZ+j0j35Tpop41MLnmiANSrKukyw= MIME-Version: 1.0 Received: by 10.227.38.164 with SMTP id b36mr1386794wbe.54.1312510251414; Thu, 04 Aug 2011 19:10:51 -0700 (PDT) Received: by 10.227.152.13 with HTTP; Thu, 4 Aug 2011 19:10:51 -0700 (PDT) In-Reply-To: <4E3B2194.9030309@earthlink.net> References: <4E3B2194.9030309@earthlink.net> Date: Thu, 4 Aug 2011 19:10:51 -0700 Message-ID: From: Julien Laganier To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: mext Subject: Re: [MEXT] Minutes and presentations from the "alt-mext" discussion group at IETF 81 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 02:10:36 -0000 On Thu, Aug 4, 2011 at 3:47 PM, Charles E. Perkins wrote: > > [...] > > One important procedural detail from the meeting bears > repetition. > > It was stated that the reason we did not have a scheduled > meeting of the [mext] WG at IETF 81, was because there was > not much discussion on the mailing list. Thanks for highlighting this, Charlie. In the future I'd like to focus face-to-face meeting time to 1) resolution of issues that have failed resolution on the mailing list, and 2) presentation of new issues that might be of interest to the WG, e.g., while the WG is in a re-chartering phase. I believe this is in the spirit of RFC 2418 that states that "most of the work of an IETF working group will be conducted on the mailing list." --julien From hesham@elevatemobile.com Thu Aug 4 19:25:03 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A804E11E809B for ; Thu, 4 Aug 2011 19:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKRODeIvhMBe for ; Thu, 4 Aug 2011 19:25:03 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id F1AAA11E807C for ; Thu, 4 Aug 2011 19:25:02 -0700 (PDT) Received: from [203.219.211.243] (helo=[192.168.0.11]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1QpA5k-0005eE-C6; Fri, 05 Aug 2011 12:24:52 +1000 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Fri, 05 Aug 2011 12:24:49 +1000 From: Hesham Soliman To: "Charles E. Perkins" , mext Message-ID: Thread-Topic: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance In-Reply-To: <4E3B0677.8050705@earthlink.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 02:25:03 -0000 Hi Charlie, I don't think anyone can answer that question with enough certainty that allows their answer to become a reliable assumption. If history is anything to go by, it doesn't look likely, but who knows. Cheers, Hesham -----Original Message----- From: "Charles E. Perkins" Organization: Wichorus Inc. Date: Thu, 04 Aug 2011 13:52:07 -0700 To: mext Subject: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance > >Hello folks, > >Sorry if this is considered to be imperfectly relevant, >but I'm curious whether or not handovers in the future >would be typically make-before-break. Or [even "worse"], >in terms of radio interfaces, whether typically wireless >devices in the future will keep multiple radios powered >on all the time. > >This might well have an impact on assumptions about >dmm. It was claimed that, for instance, iPad and iPhone >usually have both interfaces active. I know that when >I'm using my iPad I do not keep both radios turned on, >but I do not claim to be a typical user, and anyway I >do not have an iPhone. > >Comments will be appreciated! > >Regards, >Charlie P. > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext From sgundave@cisco.com Thu Aug 4 19:53:31 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9534821F8678 for ; Thu, 4 Aug 2011 19:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.103 X-Spam-Level: X-Spam-Status: No, score=-3.103 tagged_above=-999 required=5 tests=[AWL=-0.504, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+VjlVsEOLBh for ; Thu, 4 Aug 2011 19:53:30 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B7A5621F866A for ; Thu, 4 Aug 2011 19:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1183; q=dns/txt; s=iport; t=1312512827; x=1313722427; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=oCkNfzS37NkXfBP9ZcJnPo+ML9JF9ork2JTIzaKSKF4=; b=h7IJVS7CbBUULNCnuMIygIkKt/fz9scPLTEFka49FhVqSI5Jz0xO1ju7 jVeMcRcGDmXsLnh7FnJXzh+1gibN7tmk3hBFDoRaHALxJXcCRi1K+gVGC M4a//rC4xDVZu2JbUv9pYI5IK6i1VW0KYygaVOI4LFASzrSAETYujELjb 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADhaO06rRDoJ/2dsb2JhbABDp253gUABAQEBAgESAScCAUENAQiBHQIEATSHSqIvAZ5ghkIEh1qLIYUQi3Q X-IronPort-AV: E=Sophos;i="4.67,320,1309737600"; d="scan'208";a="9876340" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-3.cisco.com with ESMTP; 05 Aug 2011 02:53:44 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p752riBG011433; Fri, 5 Aug 2011 02:53:44 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 19:53:44 -0700 Received: from 10.32.246.212 ([10.32.246.212]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Fri, 5 Aug 2011 02:53:43 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 04 Aug 2011 19:53:38 -0700 From: Sri Gundavelli To: , , Message-ID: Thread-Topic: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance Thread-Index: AQHMUuyMHmpdQRSJykeD7X8pFNgav5UNj+b4 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Aug 2011 02:53:44.0561 (UTC) FILETIME=[E3F48610:01CC531A] Subject: Re: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 02:53:31 -0000 > Will devices keep multiple radios powered on simultaneously in the future? > It depends. > Battery technology still lags the advances of radio, processors and > displays on devices. And hence it generally boils down to optimizing > battery in handheld devices which implies that you would not want to > always keep multiple radios switched "On" all the time. You could if you > were willing to carry around a battery backpack all the time :) After all the standardization around MCoA/IFOM, building all the hype/coolness around driving one flow on path and another the other path, its sad to note that we simply don't have the devices/or the battery technology that can keep multiple radios up at the same time for a reasonable length of time (except few exceptions). Most devices/operator configuration still try to keep only one radio active at a time, so they can claim better battery serving time. So, we are not there yet, but from what I believe with LTE radios, the power requirement is only going up. Hopefully, there will be a major breakthrough in the battery technology that will allow all the radios to be up for a day with a recharge ... Sri From hesham@elevatemobile.com Thu Aug 4 20:32:30 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B9011E80B4 for ; Thu, 4 Aug 2011 20:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrPxd+aB8BhD for ; Thu, 4 Aug 2011 20:32:30 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id E3CB211E809B for ; Thu, 4 Aug 2011 20:32:29 -0700 (PDT) Received: from [203.219.211.243] (helo=[192.168.0.11]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1QpB8W-0008DA-WE; Fri, 05 Aug 2011 13:31:49 +1000 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Fri, 05 Aug 2011 13:31:44 +1000 From: Hesham Soliman To: Sri Gundavelli , , , Message-ID: Thread-Topic: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 03:32:30 -0000 From: Sri Gundavelli >>Will devices keep multiple radios powered on simultaneously in the >>future? >> It depends. >> Battery technology still lags the advances of radio, processors and >> displays on devices. And hence it generally boils down to optimizing >> battery in handheld devices which implies that you would not want to >> always keep multiple radios switched "On" all the time. You could if you >> were willing to carry around a battery backpack all the time :) > > >After all the standardization around MCoA/IFOM, building all the >hype/coolness around driving one flow on path and another the other path, >its sad to note that we simply don't have the devices/or the battery >technology that can keep multiple radios up at the same time for a >reasonable length of time (except few exceptions). => This is not about MCoA or flow mobility. Of course we have the ability to have multiple interfaces up and many of us use it everyday. I assumed Charlie's question was not about this trivial case, which we all know exists, but rather about a single technology doing make before break handovers. I know of only one radio technology that did that in real deployments (OFDM). Hesham >Most devices/operator >configuration still try to keep only one radio active at a time, so they >can >claim better battery serving time. So, we are not there yet, but from >what I >believe with LTE radios, the power requirement is only going up. >Hopefully, >there will be a major breakthrough in the battery technology that will >allow >all the radios to be up for a day with a recharge ... > > >Sri > > > > > > > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext From sgundave@cisco.com Thu Aug 4 21:24:26 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4453311E80C4 for ; Thu, 4 Aug 2011 21:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.086 X-Spam-Level: X-Spam-Status: No, score=-3.086 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVNqJm+-WsAz for ; Thu, 4 Aug 2011 21:24:25 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id AD9EA11E8073 for ; Thu, 4 Aug 2011 21:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1507; q=dns/txt; s=iport; t=1312518281; x=1313727881; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=HKsrWDq6iX/3YOHvCmpUNUWCpjxeBW6DmlpQ9X8ce+s=; b=FkORW5mIoIoN1tfm5GRhKdtXMORQNgHlHgCm8JPxOJaE4fH3NSMNAOXl s6oBJmqE8eIFW6HxijlHxKHcPO8fnXIogPtYMDVDxlt6+gY6NfeqGzMfc dXH5YBDqkroaR9zQnxqwjNqayhgzUaNttCOTgjMsyyl3nJ32iisdzvGAI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAI5vO06rRDoI/2dsb2JhbABDp293gUABAQEBAxIBJwIBMR0BCIEdAQEEARIZCaosAZ5mhkYEh1uLJIURi3Y X-IronPort-AV: E=Sophos;i="4.67,320,1309737600"; d="scan'208";a="9899414" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-7.cisco.com with ESMTP; 05 Aug 2011 04:24:40 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p754OeHZ025953; Fri, 5 Aug 2011 04:24:40 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 21:24:40 -0700 Received: from 10.32.246.212 ([10.32.246.212]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Fri, 5 Aug 2011 04:24:39 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 04 Aug 2011 21:24:39 -0700 From: Sri Gundavelli To: Hesham Soliman , , , Message-ID: Thread-Topic: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance Thread-Index: AcxTJ5cNBbFZPpZ6I0OHtk4LjtJNyw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Aug 2011 04:24:40.0412 (UTC) FILETIME=[97E551C0:01CC5327] Subject: Re: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 04:24:26 -0000 On 8/4/11 8:31 PM, "Hesham Soliman" wrote: > > >> >> After all the standardization around MCoA/IFOM, building all the >> hype/coolness around driving one flow on path and another the other path, >> its sad to note that we simply don't have the devices/or the battery >> technology that can keep multiple radios up at the same time for a >> reasonable length of time (except few exceptions). > > > => This is not about MCoA or flow mobility. Of course we have the ability > to have multiple interfaces up and many of us use it everyday. I assumed > Charlie's question was not about this trivial case, which we all know > exists, but rather about a single technology doing make before break > handovers. I know of only one radio technology that did that in real > deployments (OFDM). > > Hesham Yes, we slightly digressed from Charlie's original point. But, on keeping multiple radios up, the point that Raj touched on, sure, we can keep all the radios up, but with the charger wired on, in practical terms. All I know is, if I keep my WLAN interface up on my Droid X, I need a much sooner recharge. I also know, most terminals are configured to USE only one radio up for whatever reasons. But, I Ack, there may be some terminals which may be using both the interfaces, ignoring their SAS awareness ..etc... Any case, glad to hear your comments/disagreements. We need some life into these all dead IETF mailing lists :) ... Sri From hesham@elevatemobile.com Thu Aug 4 22:11:54 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0940721F877B for ; Thu, 4 Aug 2011 22:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XomKdFzlu-e9 for ; Thu, 4 Aug 2011 22:11:53 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5009921F8779 for ; Thu, 4 Aug 2011 22:11:52 -0700 (PDT) Received: from [203.219.211.243] (helo=[192.168.0.11]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1QpChH-0005UX-9r; Fri, 05 Aug 2011 15:11:47 +1000 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Fri, 05 Aug 2011 15:11:42 +1000 From: Hesham Soliman To: Sri Gundavelli , , , Message-ID: Thread-Topic: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 05:11:54 -0000 >> >> >> >>> >>> After all the standardization around MCoA/IFOM, building all the >>> hype/coolness around driving one flow on path and another the other >>>path, >>> its sad to note that we simply don't have the devices/or the battery >>> technology that can keep multiple radios up at the same time for a >>> reasonable length of time (except few exceptions). >> >> >> => This is not about MCoA or flow mobility. Of course we have the >>ability >> to have multiple interfaces up and many of us use it everyday. I assumed >> Charlie's question was not about this trivial case, which we all know >> exists, but rather about a single technology doing make before break >> handovers. I know of only one radio technology that did that in real >> deployments (OFDM). >> >> Hesham > >Yes, we slightly digressed from Charlie's original point. But, on keeping >multiple radios up, the point that Raj touched on, sure, we can keep all >the >radios up, but with the charger wired on, in practical terms. All I know >is, >if I keep my WLAN interface up on my Droid X, I need a much sooner >recharge. >I also know, most terminals are configured to USE only one radio up for >whatever reasons. => Yes they use one radio because they don't have sophisticated enough src address selection mechanisms (probably because the current services don't need it) to split the traffic. They make the calls on 3G not WLAN :) so think about when VoIP is really deployed over 3G (LTE), they will have to distinguish between those two interfaces and split traffic. On the battery issue, yes of course but a few years ago those smart phones needed to be charged every few hours, now they improved. My laptop battery lasts 5-6 hours, which is an improvement. So these things change over time. >But, I Ack, there may be some terminals which may be using >both the interfaces, ignoring their SAS awareness ..etc... > >Any case, glad to hear your comments/disagreements. We need some life into >these all dead IETF mailing lists :) ... => :). Happy to contribute. Hesham > > > > >Sri > From sjkoh@knu.ac.kr Thu Aug 4 23:15:40 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66115E8006 for ; Thu, 4 Aug 2011 23:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+xSLSguXm5x for ; Thu, 4 Aug 2011 23:15:39 -0700 (PDT) Received: from spam2.knu.ac.kr (spam2.knu.ac.kr [155.230.10.253]) by ietfa.amsl.com (Postfix) with ESMTP id E866D5E8005 for ; Thu, 4 Aug 2011 23:15:35 -0700 (PDT) Received: from unknown (HELO knu.ac.kr) (155.230.11.8) by 155.230.10.253 with SMTP; 5 Aug 2011 15:11:03 +0900 X-Original-SENDERIP: 155.230.11.8 X-Original-MAILFROM: sjkoh@knu.ac.kr x-beehive-trace: sjkoh@knu.ac.kr mext@ietf.org 155.230.105.149 Received: from knu.ac.kr by ietf.org with ESMTP (knu.ac.kr) for mext@ietf.org; Fri, 5 Aug 2011 15:15:45 +0900 (KST) x-beehive-kind: normal x-beehive-modified: received kind Message-ID: From: "Seok-Joo Koh" To: "Julien Laganier" References: Date: Fri, 5 Aug 2011 15:15:50 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: Basavaraj.Patil@nokia.com, dino@cisco.com, mext@ietf.org Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 06:15:40 -0000 Julien, Your comment is completely agreed. I believe the first step of DMM shall be to make a couple of WG documents on problem statements and requirements, together with applicability to the current MIP protocol suite. Our energy needs to be focused on those issues. Thanks, Seok-Joo Koh ----- Original Message ----- From: "Julien Laganier" To: "Seok-Joo Koh" Cc: ; ; Sent: Friday, August 05, 2011 1:03 AM Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement Seok-Joo, At this point it is not clear that new mechanisms are needed thus the question on where should solution work be undertaken seems a bit premature. For now I' d advise people interested in the DMM work to focus on what are their requirements and then see how the MIPv6 protocol suite can be applied to fulfill those. --julien On Tue, Aug 2, 2011 at 4:29 PM, Seok-Joo Koh wrote: > Hello there, > > To my understanding, this thread of discussion was intended to review LISP > so as to collect a lot of useful information in the perspective of DMM > requirements, > NOT to make specific schemes, such as MIP-based, PMIP-based, or LISP-based > DMM solutions. > > It seems that the issues on DMM requirements are under the scope of MEXT WG, > as described in the WG charter. > However, it is still unclear to me which WG is appropriate to develop > specific solutions for DMM: > MIP-based DMM -> MEXT WG ? > PMIP-based DMM -> NETEXT WG ? > LISP-based DMM -> LISP WG ? > or > all the issues shall fall into the MOPOPT RG ?? > > ************************* > Seok-Joo Koh > http://protocol.knu.ac.kr/ > ************************* > > ----- Original Message ----- From: > To: > Cc: ; > Sent: Wednesday, August 03, 2011 6:58 AM > Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement > > >> >> Hi Charlie, >> >> On 8/2/11 4:41 PM, "ext Charles E. Perkins" >> wrote: >> >>> >>> Hello folks, >>> >>> I agree that LISP work should not be done in the [mext] >>> working group. >>> >>> However, if the LISP design shows how to make a good >>> solution for distributed anchoring, it is pertinent to >>> our work insofar as it provides a model for the [mext] >>> solution. In that case, if we are fortunate, it would >>> be easier to devise an appropriate solution by using >>> the LISP distributed anchoring as a guide. >> >> If the LISP design helps in alleviating the concerns that we have >> identified as some of the key issues in I-D >> draft-patil-mext-dmm-approaches-01.txt (Sec 3), then maybe yes. If we have >> to incorporate LISP based mobility as a solution for DMM, then we have an >> issue, because at the present time it can be perceived that the problems >> could be solved within the framework of MIP6 signaling and network >> elements. >> >> -Basavaraj >> >> >>> >>> Please note that I do not yet claim that LISP does >>> what is needed -- only that we ought to take a look. >>> >>> Regards, >>> Charlie P. >>> >>> >>> On 8/2/2011 2:15 PM, Basavaraj.Patil@nokia.com wrote: >>>> >>>> I agree with Romain's comment. >>>> The scope of DMM within the context of the MEXT WG is to reuse Mobile >>>> IPv6 >>>> protocols, extensions and elements to address the concerns of the base >>>> Mobile IP model. >>>> >>>> Mobility using LISP may be a good solution in itself. I have no idea or >>>> opinion about such a solution at the present time. >>>> >>>> I believe that we can address the DMM requirements with a few extensions >>>> to MIP6 signaling and guidelines for deployment. Expanding the scope of >>>> DMM beyond the base MIP6 protocol would be taking us down a path with no >>>> visible end. >>>> >>>> -Basavaraj >>>> >>>> On 8/2/11 4:09 PM, "ext Romain KUNTZ" wrote: >>>> >>>>> Hello, >>>>> >>>>> I fail to see how LISP would fall in the MEXT charter item, which >>>>> concentrates on MIPv6-based DMM solution ('Operational considerations >>>>> for >>>>> distributed use of Mobile IPv6'). If LISP is foreseen as a potential >>>>> solution for distributed mobility management, that should probably be >>>>> discussed in the Network WG, where LISP and LISP MN are discussed. >>>>> >>>>> Regards, >>>>> Romain >>>>> >>>>> On Aug 1, 2011, at 16:50, Seok-Joo Koh wrote: >>>>> >>>>>> Dear Charles, >>>>>> >>>>>> I think the LISP can also be considered as a promising candidate >>>>>> in the design of DMM solutions. Several works are being progressed >>>>>> to use or extend the LISP for mobility support, which inlcude LISP-MN >>>>>> draft >>>>>> and many research papers. Actually, I am also considering how to >>>>>> extend >>>>>> the LISP scheme in the DMM perspective. >>>>>> >>>>>> LISP is a network-based ID-LOC separation scheme and thus it may give >>>>>> some >>>>>> advantages for effective mobility support. On the other hand, it is >>>>>> noted that >>>>>> the current version of LISP and LISP-MN may need to be more enhanced >>>>>> in terms of scalability in the mobile environment. For example, one >>>>>> concern of LISP >>>>>> is that the LISP EIDs may not be aggregated anymore in the mobile >>>>>> networks, since >>>>>> each mobile node will have its own distinctive EIDs that do not >>>>>> conform >>>>>> the concerned mobile domain. >>>>>> This may decrease the scaling benefits of original LISP. >>>>>> We may need to design a new enhanced EID structure to be used for >>>>>> mobile environment. >>>>>> Nontheless, it is worthwhile to consider LISP as a promisng candidate >>>>>> in the disign of DMM, I think. >>>>>> >>>>>> By the way, as I already said in this IETF DMM ad hoc meeting, the >>>>>> urgent action item of DMM is >>>>>> to make one or more introductory I-Ds with WG consensus, which may >>>>>> include >>>>>> the problem statements and requirements for DMM, use cases/scenarios, >>>>>> and comparison matrix, etc. >>>>>> >>>>>> Regards, >>>>>> >>>>>> ************************* >>>>>> Seok-Joo Koh >>>>>> http://protocol.knu.ac.kr/ >>>>>> ************************* >>>>>> >>>>>> ----- Original Message ----- From: "Charles E. Perkins" >>>>>> >>>>>> To: "mext" >>>>>> Cc: >>>>>> Sent: Tuesday, August 02, 2011 3:28 AM >>>>>> Subject: [MEXT] LISP as a solution for some part of the DMM >>>>>> requirement >>>>>> >>>>>> >>>>>>> >>>>>>> Hello folks, >>>>>>> >>>>>>> At IETF 81, LISP for mobile devices was presented. >>>>>>> While I am not yet convinced about the specific >>>>>>> solution presented, I started to look at LISP as >>>>>>> a possible component of an overall DMM solution. >>>>>>> >>>>>>> LISP has a website: >>>>>>> http://www.lisp4.net >>>>>>> >>>>>>> For people who are unfamiliar, this issue of IPJ >>>>>>> has a tutorial article about LISP: >>>>>>> http://www.lisp4.net/docs/ipj_11-1.pdf >>>>>>> >>>>>>> The LISP draft for mobile nodes is accessible here: >>>>>>> http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/ >>>>>>> >>>>>>> Comments? I think that LISP should be added to the >>>>>>> comparison matrix in my draft with Dapeng Liu. >>>>>>> Would that be helpful? >>>>>>> >>>>>>> Regards, >>>>>>> Charlie P. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MEXT mailing list >>>>>>> MEXT@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext From charles.perkins@earthlink.net Fri Aug 5 00:21:02 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D166311E8085 for ; Fri, 5 Aug 2011 00:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0sXjwBZUhyB for ; Fri, 5 Aug 2011 00:20:58 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 95D1311E8073 for ; Fri, 5 Aug 2011 00:20:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=l2uz/FoVuzKlk+rYh5Mbj0MPUcaSlxx8F33837GbphdXohe0ruUPxNwjxCJfxpY1; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.239]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1QpEiV-0006Fy-Tn; Fri, 05 Aug 2011 03:21:12 -0400 Message-ID: <4E3B99E4.2050603@earthlink.net> Date: Fri, 05 Aug 2011 00:21:08 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8640e5903243eec6babcc4801e105dd702350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: mext@ietf.org Subject: Re: [MEXT] [dmm?] Surprising assertion about make-before-break ... X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 07:21:03 -0000 Hello Hesham, Long time no see... To your point: On 8/4/2011 10:11 PM, Hesham Soliman wrote: > On the battery issue, yes of course but a few years ago those smart phones > needed to be charged every few hours, now they improved. My laptop battery > lasts 5-6 hours, which is an improvement. So these things change over > time. Assume, just for a moment, there were a handover method requiring only a single radio interface to be powered up at any one time, that had roughly equal performance as handover algorithms which relied on multiple radio interfaces being powered up. In that case, I think it would be considerably preferable to make use of the single-radio algorithm. Excellent performance with single-radio devices is quite possible, and we would practically already be there except for politics or, (less likely but plausible) simply a matter of inertia. Certainly possible for good VoIP, almost certainly for interactive video on 4G networks <--> WLAN. We were showing smooth VoIP handovers almost ten years ago with 802.11b, and with SFF-based preregistration in 4G networks we could do far better than that now (I recently submitted a draft about this). How to get it standardized in LTE seems to be a puzzle of monumental proportions. Perhaps if the end users realized how much better their service could be, and started demanding it, things would progress. In the meantime, they'll get slow, battery-wasting handovers to WLAN that do not even preserve IP addresses, much less offer session continuity. And the operators will have to purchase unbelievably complicated equipment to even enable that level of service. I'd like to see the IETF start offering solutions that have an easier evolutionary path towards deployment. http://www.psg.com/~charliep/txt/ietf81/alt_mext/MIPv6_for_4G.pptx [note I renamed that file, there was a typo in the previous name] Regards, Charlie P. From hesham@elevatemobile.com Fri Aug 5 03:16:44 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A7721F8ACE for ; Fri, 5 Aug 2011 03:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqFiI7Tu8qUv for ; Fri, 5 Aug 2011 03:16:40 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id AE40421F89B8 for ; Fri, 5 Aug 2011 03:16:36 -0700 (PDT) Received: from [203.219.211.243] (helo=[192.168.0.11]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1QpHRk-0006lE-DR; Fri, 05 Aug 2011 20:16:04 +1000 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Fri, 05 Aug 2011 20:16:00 +1000 From: Hesham Soliman To: "Charles E. Perkins" Message-ID: Thread-Topic: [MEXT] [dmm?] Surprising assertion about make-before-break ... In-Reply-To: <4E3B99E4.2050603@earthlink.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: mext@ietf.org Subject: Re: [MEXT] [dmm?] Surprising assertion about make-before-break ... X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 10:16:44 -0000 Hi Charlie, > >Hello Hesham, > >Long time no see... => Likewise! >To your point: > >On 8/4/2011 10:11 PM, Hesham Soliman wrote: > >> On the battery issue, yes of course but a few years ago those smart >>phones >> needed to be charged every few hours, now they improved. My laptop >>battery >> lasts 5-6 hours, which is an improvement. So these things change over >> time. > >Assume, just for a moment, there were a handover method requiring >only a single radio interface to be powered up at any one time, that >had roughly equal performance as handover algorithms which relied on >multiple radio interfaces being powered up. > >In that case, I think it would be considerably preferable to >make use of the single-radio algorithm. => Sure. I think we got two topics wrapped up in the same thread, I was referring to multiple radio interfaces using different technologies. But I agree with you that you can get good performance without make before break handover. > >Excellent performance with single-radio devices is quite possible, >and we would practically already be there except for politics or, >(less likely but plausible) simply a matter of inertia. Certainly >possible for good VoIP, almost certainly for interactive video on >4G networks <--> WLAN. We were showing smooth VoIP handovers >almost ten years ago with 802.11b, and with SFF-based preregistration >in 4G networks we could do far better than that now (I recently >submitted a draft about this). => Absolutely, I've done similar experiments on WLAN and still do in fact and I agree. And did the same with 3G and you're right, it's all politics that's stopping this. Luckily for me I'm not in the middle of these politics anymore :) > >How to get it standardized in LTE seems to be a puzzle of monumental >proportions. Perhaps if the end users realized how much better >their service could be, and started demanding it, things would >progress. In the meantime, they'll get slow, battery-wasting >handovers to WLAN that do not even preserve IP addresses, much >less offer session continuity. And the operators will have to >purchase unbelievably complicated equipment to even enable that >level of service. => Forget about average users demanding proper IP networks, some operators tried that and failed. Unfortunately the "getting it into LTE" part is not fun. The fun part is making it work and the rest is...well you know. But it might be worth giving LTE a unified IETF solution for mobility instead of re-dressing GTP in IP (PMIP) and then getting it rejected anyway. I didn't like that approach, but that was a long time ago. > >I'd like to see the IETF start offering solutions that >have an easier evolutionary path towards deployment. >http://www.psg.com/~charliep/txt/ietf81/alt_mext/MIPv6_for_4G.pptx => Nice plug :), but I don't see the relation to the single Vs multiple radio discussion. Hesham > >[note I renamed that file, there was a typo in the previous name] > >Regards, >Charlie P. From Marco.Liebsch@neclab.eu Mon Aug 8 05:10:35 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4697821F8ACA for ; Mon, 8 Aug 2011 05:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7g1wYKRLu2D for ; Mon, 8 Aug 2011 05:10:33 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9B97F21F8782 for ; Mon, 8 Aug 2011 05:10:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 354A528000213; Mon, 8 Aug 2011 14:09:26 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HccJ7KmXPjcH; Mon, 8 Aug 2011 14:09:26 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 17389280001AA; Mon, 8 Aug 2011 14:09:06 +0200 (CEST) Received: from [10.1.6.32] (10.1.6.32) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 8 Aug 2011 14:09:06 +0200 Message-ID: <4E3FD1E1.9020204@neclab.eu> Date: Mon, 8 Aug 2011 14:09:05 +0200 From: Marco Liebsch User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Charles E. Perkins" References: <4E386F10.6080101@earthlink.net> In-Reply-To: <4E386F10.6080101@earthlink.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.32] Cc: mext@ietf.org, dino@cisco.com, Basavaraj.Patil@nokia.com Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 12:10:35 -0000 I agree on that point and a good solution for DMM may require a look beyond Mobile IP protocols and their extensions. As discussed with some of you at IETF81, I think a solution which supports DMM above anchor level should be at least on the table for discussion. LISP is one candidate that could support IP address continuity after anchor re-location (handover between two anchors). The issue to solve is at an appropriate mapping base and to push an update of the MN's locator state at the ITR(s) to allow session continuity. Maybe beyond MEXT scope, but reasonale enough for being included to the discussion. marco Am 02.08.2011 23:41, schrieb Charles E. Perkins: > > Hello folks, > > I agree that LISP work should not be done in the [mext] > working group. > > However, if the LISP design shows how to make a good > solution for distributed anchoring, it is pertinent to > our work insofar as it provides a model for the [mext] > solution. In that case, if we are fortunate, it would > be easier to devise an appropriate solution by using > the LISP distributed anchoring as a guide. > > Please note that I do not yet claim that LISP does > what is needed -- only that we ought to take a look. > > Regards, > Charlie P. > > > On 8/2/2011 2:15 PM, Basavaraj.Patil@nokia.com wrote: >> >> I agree with Romain's comment. >> The scope of DMM within the context of the MEXT WG is to reuse Mobile >> IPv6 >> protocols, extensions and elements to address the concerns of the base >> Mobile IP model. >> >> Mobility using LISP may be a good solution in itself. I have no idea or >> opinion about such a solution at the present time. >> >> I believe that we can address the DMM requirements with a few extensions >> to MIP6 signaling and guidelines for deployment. Expanding the scope of >> DMM beyond the base MIP6 protocol would be taking us down a path with no >> visible end. >> >> -Basavaraj >> >> On 8/2/11 4:09 PM, "ext Romain KUNTZ" wrote: >> >>> Hello, >>> >>> I fail to see how LISP would fall in the MEXT charter item, which >>> concentrates on MIPv6-based DMM solution ('Operational >>> considerations for >>> distributed use of Mobile IPv6'). If LISP is foreseen as a potential >>> solution for distributed mobility management, that should probably be >>> discussed in the Network WG, where LISP and LISP MN are discussed. >>> >>> Regards, >>> Romain >>> >>> On Aug 1, 2011, at 16:50, Seok-Joo Koh wrote: >>> >>>> Dear Charles, >>>> >>>> I think the LISP can also be considered as a promising candidate >>>> in the design of DMM solutions. Several works are being progressed >>>> to use or extend the LISP for mobility support, which inlcude LISP-MN >>>> draft >>>> and many research papers. Actually, I am also considering how to >>>> extend >>>> the LISP scheme in the DMM perspective. >>>> >>>> LISP is a network-based ID-LOC separation scheme and thus it may give >>>> some >>>> advantages for effective mobility support. On the other hand, it is >>>> noted that >>>> the current version of LISP and LISP-MN may need to be more enhanced >>>> in terms of scalability in the mobile environment. For example, one >>>> concern of LISP >>>> is that the LISP EIDs may not be aggregated anymore in the mobile >>>> networks, since >>>> each mobile node will have its own distinctive EIDs that do not >>>> conform >>>> the concerned mobile domain. >>>> This may decrease the scaling benefits of original LISP. >>>> We may need to design a new enhanced EID structure to be used for >>>> mobile environment. >>>> Nontheless, it is worthwhile to consider LISP as a promisng candidate >>>> in the disign of DMM, I think. >>>> >>>> By the way, as I already said in this IETF DMM ad hoc meeting, the >>>> urgent action item of DMM is >>>> to make one or more introductory I-Ds with WG consensus, which may >>>> include >>>> the problem statements and requirements for DMM, use cases/scenarios, >>>> and comparison matrix, etc. >>>> >>>> Regards, >>>> >>>> ************************* >>>> Seok-Joo Koh >>>> http://protocol.knu.ac.kr/ >>>> ************************* >>>> >>>> ----- Original Message ----- From: "Charles E. Perkins" >>>> >>>> To: "mext" >>>> Cc: >>>> Sent: Tuesday, August 02, 2011 3:28 AM >>>> Subject: [MEXT] LISP as a solution for some part of the DMM >>>> requirement >>>> >>>> >>>>> >>>>> Hello folks, >>>>> >>>>> At IETF 81, LISP for mobile devices was presented. >>>>> While I am not yet convinced about the specific >>>>> solution presented, I started to look at LISP as >>>>> a possible component of an overall DMM solution. >>>>> >>>>> LISP has a website: >>>>> http://www.lisp4.net >>>>> >>>>> For people who are unfamiliar, this issue of IPJ >>>>> has a tutorial article about LISP: >>>>> http://www.lisp4.net/docs/ipj_11-1.pdf >>>>> >>>>> The LISP draft for mobile nodes is accessible here: >>>>> http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/ >>>>> >>>>> Comments? I think that LISP should be added to the >>>>> comparison matrix in my draft with Dapeng Liu. >>>>> Would that be helpful? >>>>> >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From Marco.Liebsch@neclab.eu Mon Aug 8 05:10:51 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8DB21F8AF4 for ; Mon, 8 Aug 2011 05:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOO1ts7GTmgL for ; Mon, 8 Aug 2011 05:10:50 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 85EE621F8AF3 for ; Mon, 8 Aug 2011 05:10:50 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 3C9C6280002FE; Mon, 8 Aug 2011 14:09:46 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-7SvbkQbk1c; Mon, 8 Aug 2011 14:09:46 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 214E4280001AA; Mon, 8 Aug 2011 14:09:26 +0200 (CEST) Received: from [10.1.6.32] (10.1.6.32) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 8 Aug 2011 14:09:15 +0200 Message-ID: <4E3FD1EA.6040306@neclab.eu> Date: Mon, 8 Aug 2011 14:09:14 +0200 From: Marco Liebsch User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Charles E. Perkins" References: <4E386F10.6080101@earthlink.net> In-Reply-To: <4E386F10.6080101@earthlink.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.6.32] Cc: mext@ietf.org, dino@cisco.com, Basavaraj.Patil@nokia.com Subject: Re: [MEXT] LISP as a solution for some part of the DMM requirement X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 12:10:51 -0000 I agree on that point and a good solution for DMM may require a look beyond Mobile IP protocols and their extensions. As discussed with some of you at IETF81, I think a solution which supports DMM above anchor level should be at least on the table for discussion. LISP is one candidate that could support IP address continuity after anchor re-location (handover between two anchors). The issue to solve is at an appropriate mapping base and to push an update of the MN's locator state at the ITR(s) to allow session continuity. Maybe beyond MEXT scope, but reasonale enough for being included to the discussion. marco Am 02.08.2011 23:41, schrieb Charles E. Perkins: > > Hello folks, > > I agree that LISP work should not be done in the [mext] > working group. > > However, if the LISP design shows how to make a good > solution for distributed anchoring, it is pertinent to > our work insofar as it provides a model for the [mext] > solution. In that case, if we are fortunate, it would > be easier to devise an appropriate solution by using > the LISP distributed anchoring as a guide. > > Please note that I do not yet claim that LISP does > what is needed -- only that we ought to take a look. > > Regards, > Charlie P. > > > On 8/2/2011 2:15 PM, Basavaraj.Patil@nokia.com wrote: >> >> I agree with Romain's comment. >> The scope of DMM within the context of the MEXT WG is to reuse Mobile >> IPv6 >> protocols, extensions and elements to address the concerns of the base >> Mobile IP model. >> >> Mobility using LISP may be a good solution in itself. I have no idea or >> opinion about such a solution at the present time. >> >> I believe that we can address the DMM requirements with a few extensions >> to MIP6 signaling and guidelines for deployment. Expanding the scope of >> DMM beyond the base MIP6 protocol would be taking us down a path with no >> visible end. >> >> -Basavaraj >> >> On 8/2/11 4:09 PM, "ext Romain KUNTZ" wrote: >> >>> Hello, >>> >>> I fail to see how LISP would fall in the MEXT charter item, which >>> concentrates on MIPv6-based DMM solution ('Operational >>> considerations for >>> distributed use of Mobile IPv6'). If LISP is foreseen as a potential >>> solution for distributed mobility management, that should probably be >>> discussed in the Network WG, where LISP and LISP MN are discussed. >>> >>> Regards, >>> Romain >>> >>> On Aug 1, 2011, at 16:50, Seok-Joo Koh wrote: >>> >>>> Dear Charles, >>>> >>>> I think the LISP can also be considered as a promising candidate >>>> in the design of DMM solutions. Several works are being progressed >>>> to use or extend the LISP for mobility support, which inlcude LISP-MN >>>> draft >>>> and many research papers. Actually, I am also considering how to >>>> extend >>>> the LISP scheme in the DMM perspective. >>>> >>>> LISP is a network-based ID-LOC separation scheme and thus it may give >>>> some >>>> advantages for effective mobility support. On the other hand, it is >>>> noted that >>>> the current version of LISP and LISP-MN may need to be more enhanced >>>> in terms of scalability in the mobile environment. For example, one >>>> concern of LISP >>>> is that the LISP EIDs may not be aggregated anymore in the mobile >>>> networks, since >>>> each mobile node will have its own distinctive EIDs that do not >>>> conform >>>> the concerned mobile domain. >>>> This may decrease the scaling benefits of original LISP. >>>> We may need to design a new enhanced EID structure to be used for >>>> mobile environment. >>>> Nontheless, it is worthwhile to consider LISP as a promisng candidate >>>> in the disign of DMM, I think. >>>> >>>> By the way, as I already said in this IETF DMM ad hoc meeting, the >>>> urgent action item of DMM is >>>> to make one or more introductory I-Ds with WG consensus, which may >>>> include >>>> the problem statements and requirements for DMM, use cases/scenarios, >>>> and comparison matrix, etc. >>>> >>>> Regards, >>>> >>>> ************************* >>>> Seok-Joo Koh >>>> http://protocol.knu.ac.kr/ >>>> ************************* >>>> >>>> ----- Original Message ----- From: "Charles E. Perkins" >>>> >>>> To: "mext" >>>> Cc: >>>> Sent: Tuesday, August 02, 2011 3:28 AM >>>> Subject: [MEXT] LISP as a solution for some part of the DMM >>>> requirement >>>> >>>> >>>>> >>>>> Hello folks, >>>>> >>>>> At IETF 81, LISP for mobile devices was presented. >>>>> While I am not yet convinced about the specific >>>>> solution presented, I started to look at LISP as >>>>> a possible component of an overall DMM solution. >>>>> >>>>> LISP has a website: >>>>> http://www.lisp4.net >>>>> >>>>> For people who are unfamiliar, this issue of IPJ >>>>> has a tutorial article about LISP: >>>>> http://www.lisp4.net/docs/ipj_11-1.pdf >>>>> >>>>> The LISP draft for mobile nodes is accessible here: >>>>> http://datatracker.ietf.org/doc/draft-meyer-lisp-mn/ >>>>> >>>>> Comments? I think that LISP should be added to the >>>>> comparison matrix in my draft with Dapeng Liu. >>>>> Would that be helpful? >>>>> >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From ryuji.wakikawa@gmail.com Mon Aug 8 12:36:50 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E92711E8088 for ; Mon, 8 Aug 2011 12:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EID2PMlQmQ1s for ; Mon, 8 Aug 2011 12:36:49 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id BA85911E8086 for ; Mon, 8 Aug 2011 12:36:49 -0700 (PDT) Received: by pzk33 with SMTP id 33so2066790pzk.18 for ; Mon, 08 Aug 2011 12:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=GAE6SEhX4JbfkB2hmQBrqaYWnnBWZ0PDnNdLv33+IZM=; b=hwVaOJwp9iQVC4bwMISyJ2N2LgqsffLWoTuaKGsOGswdFKdUxX/k2q9KGZMalfLmOq bKqCJ7mteBKL7sgzdARK4NZJDA1eUuuUwm8dO/zbKgSclL0d6YF7QEb3PoskQEDa3lYJ yYXSCwgGbkxOExtM+GwOJ2+bfAkylEYBEcDPk= Received: by 10.142.242.2 with SMTP id p2mr6336431wfh.325.1312832235953; Mon, 08 Aug 2011 12:37:15 -0700 (PDT) Received: from [192.168.110.126] ([206.132.173.18]) by mx.google.com with ESMTPS id m3sm4034309pbm.44.2011.08.08.12.37.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Aug 2011 12:37:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ryuji Wakikawa In-Reply-To: <4E1D4DEC.2060103@it.uc3m.es> Date: Mon, 8 Aug 2011 12:37:13 -0700 Content-Transfer-Encoding: 7bit Message-Id: <6A111AA0-CFB3-4011-A68E-B7857AEFCFAE@gmail.com> References: <4E1D4DEC.2060103@it.uc3m.es> To: marcelo bagnulo braun X-Mailer: Apple Mail (2.1084) Cc: mext Subject: Re: [MEXT] WGLC for draft-ietf-mip6-hareliability-09 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 19:36:50 -0000 Hi Marcelo and all Thanks a lot for all who provided comments. WGLC was passed. What is the chairs' call here? next step? thanks ryuji On 2011/07/13, at 0:49, marcelo bagnulo braun wrote: > This note issues the WGLC for draft-ietf-mip6-hareliability-09. > > Please send your comments before the 1st of august. > > You can find the draft at: > http://tools.ietf.org/html/draft-ietf-mip6-hareliability-09 > > Regards, marcelo > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From behcetsarikaya@yahoo.com Thu Aug 11 09:25:01 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663FC21F8C1D for ; Thu, 11 Aug 2011 09:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.618 X-Spam-Level: X-Spam-Status: No, score=-0.618 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id On38JC7JZ+JF for ; Thu, 11 Aug 2011 09:25:00 -0700 (PDT) Received: from nm18-vm0.bullet.mail.sp2.yahoo.com (nm18-vm0.bullet.mail.sp2.yahoo.com [98.139.91.214]) by ietfa.amsl.com (Postfix) with SMTP id 8AB9421F8B49 for ; Thu, 11 Aug 2011 09:25:00 -0700 (PDT) Received: from [98.139.91.62] by nm18.bullet.mail.sp2.yahoo.com with NNFMP; 11 Aug 2011 16:25:32 -0000 Received: from [98.139.91.11] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 11 Aug 2011 16:25:32 -0000 Received: from [127.0.0.1] by omp1011.mail.sp2.yahoo.com with NNFMP; 11 Aug 2011 16:25:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 528302.15255.bm@omp1011.mail.sp2.yahoo.com Received: (qmail 23665 invoked by uid 60001); 11 Aug 2011 16:25:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313079932; bh=ltieU0F0whjxT94RQ3sT+EOSNXqK8hx2lZRtJaZqQzc=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KDLlpTkKaWzfrGdiut9lpDvnE+MB9UeIiTSVa3mE/YLMhrT6yQ7T+ZtQ41pTikmzAf77a2QIy3jlOaG6LEmwnylrRBE4gj+VZppUBxl14UMf8cWxRgCm+F/sfJhXEGjzidA0jzAX8iDuGrPEMHNDSalya5fgnOMD9WNfI8KCUQk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cYq6e6SqfKScD1k6aozSc9i1bptcYV2h2jtjzvjNOu/06dOcXEfqLysJF0HocXOk2fPdjCHFvJoNBJmUNVdn5ZtPoUL95l1kWGHcfB+c69gsaJj4bXG28swN84RNDQUNkxoGJm2p5LiIrSavfj7EIAd0Ge/Ukwhtgv7t3DVU70E=; X-YMail-OSG: c8Y03hsVM1mgvz3Y9aL_EhIqJOlKBY3BMwIJ2d1g8MK1Y2e 1CgQQz7gSLEr6EA.kovv4TNr_oD7yN.LGzdRICRyoM4FO_HJ5L3nny3q8aMp ZJIbx3bc10BSc6LWi8N3iTCqpBhND7jib72_5uOPbhIvoi48gfCRUIhawjVP 8htpmlesw4BgApBfb8rhzRwvYukV_dBpGsNPVOojIUhW.r2SGGYes9UB.Q1N Qflrk3xHOlHCLOESisB2PNnH8lVhv3m.nLeqZKiAGfQ3QXuP7zxfMFatdL0T XBILwqucSjFaODkyBfgcCbrzIO1K8cXDDo3Y9BR5Au07rLoEYg7WE7hZ3h0X LPStIdCgX2j6OGJWAzFpywzzJZNQEOSTABXTisnV5scp_EHBtmLAjFja_PXg p9Re3uz2c.8OTmHoxshv7XLfNjaO9tvvDm0RqBUKvejVF5YTylhib3CjpImd g8q4kCFbXBFaiB6pwgrso07ssKXirmxAtbe5egkx.e0ocRyeZd8K6fyKPFgz Jx4yOTZz6Iqnr6KoBHTMQZqsub0LOK1Z34O_NIoB23Ekbyj1Nyl1sf1HD7sy Sk7_Y9hasBdIe Received: from [50.58.7.243] by web111414.mail.gq1.yahoo.com via HTTP; Thu, 11 Aug 2011 09:25:31 PDT X-Mailer: YahooMailWebService/0.8.113.313619 References: <4E39847B.7080803@earthlink.net> Message-ID: <1313079931.10204.YahooMailNeo@web111414.mail.gq1.yahoo.com> Date: Thu, 11 Aug 2011 09:25:31 -0700 (PDT) From: Behcet Sarikaya To: "Charles E. Perkins" , mext In-Reply-To: <4E39847B.7080803@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MEXT] draft-perkins-mext-hatunaddr-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 16:25:01 -0000 Hi Charlie,=0A=A0 I took a look at this draft.=0ARegarding control plane da= ta plane separation, what is the difference between =0A=0AAlternate Home Ag= ent Tunnel Address=0Athat you defined and =0A=0A=0AAlternate Care-of Addres= s=0A=0A=0Adefined in RFC 6275?=0A=0AI remember there was some discussion in= the past by Vijay, et al. for a similar use? Maybe you remember the detail= s and you can shed some light into this?=0A=0ARegards,=0A=0ABehcet=0A> =0A>= Hello folks,=0A> =0A> I have revised and resubmitted my earlier draft prop= osing=0A> a split between the control and data plane addresses of=0A> the h= ome agent.=A0 For some reason, the Internet Draft=0A> submission process se= ems to have hung when I made the=0A> formal submission, and I don't know wh= en I will get the=0A> verification email.=A0 In the meantime, here is a URL= :=0A> =0A> http://www.psg.com/~charliep/txt/ietf81/draft-perkins-mext-hatun= addr-01.txt=0A> =0A> I also added text for the same idea with Mobile IPv4.= =0A> =0A> Regards,=0A> Charlie P.=0A> =0A> ________________________________= _______________=0A> MEXT mailing list=0A> MEXT@ietf.org=0A> https://www.iet= f.org/mailman/listinfo/mext=0A> From rkuntz@us.toyota-itc.com Thu Aug 11 16:38:58 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C340521F8B3F for ; Thu, 11 Aug 2011 16:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TA7KWjso1HTw for ; Thu, 11 Aug 2011 16:38:58 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with SMTP id 1414921F8876 for ; Thu, 11 Aug 2011 16:38:58 -0700 (PDT) Received: from mail-iy0-f173.google.com ([209.85.210.173]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKTkRoLflRRGl+6DPc1HDD51A5wRFEhUbR@postini.com; Thu, 11 Aug 2011 16:39:33 PDT Received: by mail-iy0-f173.google.com with SMTP id 2so403556iyk.32 for ; Thu, 11 Aug 2011 16:39:25 -0700 (PDT) Received: by 10.43.134.69 with SMTP id ib5mr190455icc.284.1313105964377; Thu, 11 Aug 2011 16:39:24 -0700 (PDT) Received: from hong-lt.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id f14sm3811620icm.3.2011.08.11.16.39.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Aug 2011 16:39:23 -0700 (PDT) From: Romain KUNTZ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Aug 2011 16:39:22 -0700 References: <20110811233410.28827.79170.idtracker@ietfa.amsl.com> To: mext Message-Id: Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [MEXT] Fwd: New Version Notification for draft-kuntz-dmm-summary-01.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 23:38:58 -0000 Hello, We have updated our DMM solution summary draft. It is available here: http://tools.ietf.org/html/draft-kuntz-dmm-summary-01 We have restrained the scope to Mobile IPv6-based solutions. = PMIPv6-based solutions have been moved to Appendix.=20 Thank you, Romain Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-kuntz-dmm-summary-01.txt > Date: August 11, 2011 16:34:10 PDT > To: rkuntz@us.toyota-itc.com >=20 > Filename: draft-kuntz-dmm-summary > Revision: 01 > Title: A Summary of Distributed Mobility Management > Creation date: 2011-08-11 > WG ID: Individual Submission > Number of pages: 23 >=20 > Abstract: > As stated in the MEXT charter, the working group will "work on > operational considerations on setting up Mobile IPv6 networks so = that > traffic is distributed in an optimal way". This topic, = referred to > as Distributed Mobility Management (DMM), has motivated the > submission of multiple problem statement and solution drafts. This > document aims at summarizing the current status of the DMM effort, > mainly focusing on Mobile IPv6-based solutions, in order to initiate > more discussions within the working group. >=20 >=20 >=20 >=20 > The IETF Secretariat From behcetsarikaya@yahoo.com Fri Aug 12 14:53:56 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90B221F873D for ; Fri, 12 Aug 2011 14:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSuzL3-a7OEy for ; Fri, 12 Aug 2011 14:53:56 -0700 (PDT) Received: from nm19.bullet.mail.ne1.yahoo.com (nm19.bullet.mail.ne1.yahoo.com [98.138.90.82]) by ietfa.amsl.com (Postfix) with SMTP id EAF6521F873A for ; Fri, 12 Aug 2011 14:53:55 -0700 (PDT) Received: from [98.138.90.48] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 12 Aug 2011 21:54:27 -0000 Received: from [98.138.89.199] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 12 Aug 2011 21:54:27 -0000 Received: from [127.0.0.1] by omp1057.mail.ne1.yahoo.com with NNFMP; 12 Aug 2011 21:54:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 792650.16541.bm@omp1057.mail.ne1.yahoo.com Received: (qmail 64704 invoked by uid 60001); 12 Aug 2011 21:54:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313186067; bh=3gaF3NfJ6v1URCDgUVw9knMchR5lA3k+3cahM0ejx7U=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=icHvkh1b9rJTdjsRj8eMQzbjO48HOd/t7kepWvE1iVl/x7x+AemOaxwOCsJ9bqgKAaMf4XJLk2TApSiF1VA+e69zeEI5zb0H2/aPLbl36bpjbJ0qeKD7vfBm1QMq2CX3tsLFfk6RjlVQZDSBMx0v3ERt8ETwcr4Qfw4EbQCLDpI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ok32QlDh6v5Llczb4r1HodmvZvQ7Rj+2DPG+lR+EErqAng2e18X+87OmbMZWssPRM3qHO0Xdpn/TTMb/j3CxkxHR+IvaBtxQ0XvaOC1RCW/6tl2nenz99UPXgZ6KMcmF8IcVM9Pn3p6vIH9L21pZy1PO7fQPaTqBKAK87zewqKA=; X-YMail-OSG: cpO87O4VM1m.Y5dzLQrBc06rtQ44r9UdtoTrKEW2JHXGugz Av_gLASmeDt7h613324bfpT6yfdDvdGt1z6OkQ5KqTLhq_V23hJ1NJ2qaYN4 2lxTROwm9gVPXG8W2iuCPJC91WX6idohhfRnTh8OLxd7j6y1qCUhVB7VYS4S pCQdVjgxfHdwKUGnY8Envr3AHMmgDGaCfuPIacR5JAJY9kAXKZG.zGssZl6Y NiSKBE4U4ZLgBeXE_gs.AzacBcXD8cdlrrGmLoI57mIdcQD1hYjV9TmbPduB LrKLYqgrCFCDUicmEcOawiTLGBJmbr1XtL.LaqZarOC6cML1h0Bu3nlfPpS9 fZ9TMFroTCHsNo4z67r3min1Hhhx.fHy0wG3Te0mNjBKUoohX0C3wfbenjex 0cxud72An_PflPPg1dxDzoiG0nTqU1QRmeKcMu2wFeJrK_5OPLnUutd_KvXX jnYoz7usAPrx4jOyPVDixCgIfwMw1Fo5EirW_6d64fnouMs2hY3n2RHE_CeK 0QR2nt91UwMnKtshgsYtuCqYVKw-- Received: from [50.58.7.243] by web111413.mail.gq1.yahoo.com via HTTP; Fri, 12 Aug 2011 14:54:27 PDT X-Mailer: YahooMailWebService/0.8.113.313619 References: <5ABC57DC-9BF5-4626-B51F-DD50222BA5CB@us.toyota-itc.com> <1311438985.9673.YahooMailRC@web111416.mail.gq1.yahoo.com> Message-ID: <1313186067.61346.YahooMailNeo@web111413.mail.gq1.yahoo.com> Date: Fri, 12 Aug 2011 14:54:27 -0700 (PDT) From: Behcet Sarikaya To: Romain KUNTZ , Behcet Sarikaya In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mext@ietf.org" Subject: Re: [MEXT] Some questions on draft-sarikaya-mext-multicastdmm X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 21:53:56 -0000 Hi Romain,=0A=0ASorry for my late reply.=0A=0A=0A=0A> Hello Behcet, =0A> = =0A> Comments inline:=0A> =0A> On Jul 23, 2011, at 9:36, Behcet Sarikaya wr= ote:=0A>>> I'm currently updating draft-kuntz-dmm-summary and was=A0 consi= dering =0A> including =0A>>> draft-sarikaya-mext-multicastdmm. However I h= ave a few=A0 questions about =0A> your =0A>>> draft.=0A>>> =0A>>> To me i= t seems that your proposal is not a=A0 DMM solution by itself but =0A> is b= uilt =0A>>> upon draft-kassi-mobileip-dmi. Am I right?=A0 Is the exact mot= ivation of =0A> your =0A>>> proposal to support multicast on the mobile no= de=A0 when DMI is used?=0A>>> =0A>> =0A>> My draft is intended to be a can= didate for Mext WG charter item on dmm and =0A> it is =0A>> inline with th= e discussions we had in the last Mext session on dmm, I =0A> don't =0A>> r= emember where, was it Beijing, IETF 79?=0A>> .=0A>> If you are saying tha= t=A0 cellular network application is emphasized, yes, I =0A> think =0A>> t= hat cellular networks are of course the place where we should look for =0A>= > deployment possibilities.=0A> =0A> I'm not sure what made you think I wa= s talking about cellular network =0A> application? That was not my intent. = =0A> I was stating that if we remove the multicast part, the underlying DMM= solution =0A> exposed in your draft seems to be very similar to DMI (draft= -kassi-mobileip-dmi) =0A> and was wondering if there were any differences t= hat I failed to see.=0A> =0A>> I think multicast support is important and = so far no other draft talks =0A> about =0A>> multicast. That's why multica= st is covered in my draft.=0A> =0A> Ok.=0A> =0A>>> About the solution itse= lf:=0A>>> =0A>>> * Section 3: =0A>>> =0A>>> =A0 "MN starts to receive the = packets over HA-MN link from=0A>>> =A0 =A0 CN and MN starts to send packets= with a destination option =0A> containing=0A>>> =A0 =A0 the previous Care-= of Address as MN's Home Address (HoA) to the =0A> CN."=0A>>> =0A>>> I'm=A0= not sure why you are doing this? This sounds like route =0A> optimization = to=A0 =0A>>> me.=0A>>> =0A>> =0A>> Why not? This is the behaviour MN shou= ld have because HA keeps changing, =0A> right?=0A> =0A> In section 5 you ar= e stating "This protocol removes the need for route =0A> optimization.=A0 C= orrespondent nodes do not need to maintain a binding cache of =0A> bindings= for other=A0 nodes.", so this does not sound coherent with the MN =0A> beh= avior exposed above. =0A> =0A=0ARFC 6275 says destination option is used in= a packet=0A sent by a mobile node while away from home, to inform the re= cipient=0A of the mobile node's home address.=0ASo we need it. I will cla= rify no route optimization statement, which means that there is no need =0A= =0A=A01 Home Test Init=0A=0A 2 Care-of Test Init=0A=0A 3 Home T= est=0A=0A 4 Care-of Test=0Amessage exchanges.=0A=0ARegards,=0A=0ABehc= et=0A From behcetsarikaya@yahoo.com Fri Aug 12 15:04:49 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B934B5E8005 for ; Fri, 12 Aug 2011 15:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9nxpsd9-kST for ; Fri, 12 Aug 2011 15:04:49 -0700 (PDT) Received: from nm23.bullet.mail.sp2.yahoo.com (nm23.bullet.mail.sp2.yahoo.com [98.139.91.93]) by ietfa.amsl.com (Postfix) with SMTP id 3F8D65E8002 for ; Fri, 12 Aug 2011 15:04:48 -0700 (PDT) Received: from [98.139.91.67] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 12 Aug 2011 22:05:26 -0000 Received: from [98.139.91.11] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 12 Aug 2011 22:05:26 -0000 Received: from [127.0.0.1] by omp1011.mail.sp2.yahoo.com with NNFMP; 12 Aug 2011 22:05:26 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 627746.94609.bm@omp1011.mail.sp2.yahoo.com Received: (qmail 37702 invoked by uid 60001); 12 Aug 2011 22:05:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313186726; bh=DNC2thXGtoQunUWSGOHbEdoy96fgWI36yhBSTMbWLaY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zs8AUIrMsrQJxzVei5QDNIiAlB/CR0zSNJBPURCH0qn9KktqAkr2Aa/T4XtpzMF7pDFUGIoBqXQY1UPOlpr+Hl6Munyyd4I/nWMDUDh6OJGm2bTPE+S4U5DFpvWlV9UPzf1wyEdpbX8zVYug/X5UiBvblzTaFdbombARcuCZfes= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lp49n4pl6Yb3NSu8CYqPtWHBpkHdviT5R4Njc6SoyZjHQMwi0W9FOJWWypkMTpbAb6/EaFdLyoPhSOKxPD0A9gjcbntVc5dQmnivcv6CKFSgao8Y1E/pAdgX++pYgn19EagcD/qGrJTVmGRsDVM4FDcaXjquZkspJZrGbN3RWFs=; X-YMail-OSG: rGD_jHMVM1kwAvs3_Uew.8Ga2FTfcsdm7jvPB7rGl.GTwSX hFFA3jzML4pGmyrMG1R4qlQ4yqZgE..kUluiQIjSknPjACtDwXG7_v3v8ZHy UIDN9s46dG1rEmOqgUvqsoKZ4YLbqAN6cLtbjNOHE2S13wpM4myu4bFmsRGL ZuKWcX1Ieia_zoUrjwXOFOnHBNHXZY9RNxNsWFtxBKZN.UlIwz6ISfTdbYnM OqsAwI4U4Q22FK1Z5rcrBveBY4DFR53d_Gr4VeCplaubVQZzUZKbyfsrdZmJ knVQeH3LpYOQUtCjCy9jascHB3eXGiCSDiz5rpSENrSI2iqoFL0p0WrqgvMU 8kS00moDQDQ0sD0V8olIQxkSXj8u5vmbqr1iiVYvBdQUk0EmQtK.gyheG_3v EedRdSU4R9n0lunpSLbvt76QJ22L4gDtfl6KEmfyn.EPFouZgjV0BfcsYCDn EKjqwfi4QmSyMKI1kdc7vFyRm3OoUMjBPjUwJsAZbGKCO1Iqy8Grccjj_L6d CZOKNeMiJ1L72YjAfP.LMgr8kXw-- Received: from [50.58.7.243] by web111402.mail.gq1.yahoo.com via HTTP; Fri, 12 Aug 2011 15:05:25 PDT X-Mailer: YahooMailWebService/0.8.113.313619 References: <5ABC57DC-9BF5-4626-B51F-DD50222BA5CB@us.toyota-itc.com> <1311438985.9673.YahooMailRC@web111416.mail.gq1.yahoo.com> Message-ID: <1313186725.90692.YahooMailNeo@web111402.mail.gq1.yahoo.com> Date: Fri, 12 Aug 2011 15:05:25 -0700 (PDT) From: Behcet Sarikaya To: Romain KUNTZ In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mext@ietf.org" Subject: Re: [MEXT] Some questions on draft-sarikaya-mext-multicastdmm X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 22:04:49 -0000 Hi Romain,=0ASorry for my late reply.=0A=0A=0A=0A=0A> Hello Behcet, =0A> = =0A> Comments inline:=0A> =0A> On Jul 23, 2011, at 9:36, Behcet Sarikaya wr= ote:=0A>>> I'm currently updating draft-kuntz-dmm-summary and was=A0 consi= dering =0A> including =0A>>> draft-sarikaya-mext-multicastdmm. However I h= ave a few=A0 questions about =0A> your =0A>>> draft.=0A>>> =0A>>> To me i= t seems that your proposal is not a=A0 DMM solution by itself but =0A> is b= uilt =0A>>> upon draft-kassi-mobileip-dmi. Am I right?=A0 Is the exact mot= ivation of =0A> your =0A>>> proposal to support multicast on the mobile no= de=A0 when DMI is used?=0A>>> =0A>> =0A>> My draft is intended to be a can= didate for Mext WG charter item on dmm and =0A> it is =0A>> inline with th= e discussions we had in the last Mext session on dmm, I =0A> don't =0A>> r= emember where, was it Beijing, IETF 79?=0A>> .=0A>> If you are saying tha= t=A0 cellular network application is emphasized, yes, I =0A> think =0A>> t= hat cellular networks are of course the place where we should look for =0A>= > deployment possibilities.=0A> =0A> I'm not sure what made you think I wa= s talking about cellular network =0A> application? That was not my intent. = =0A> I was stating that if we remove the multicast part, the underlying DMM= solution =0A> exposed in your draft seems to be very similar to DMI (draft= -kassi-mobileip-dmi) =0A> and was wondering if there were any differences t= hat I failed to see.=0A> =0A>> I think multicast support is important and = so far no other draft talks =0A> about =0A>> multicast. That's why multica= st is covered in my draft.=0A> =0A> Ok.=0A> =0A>>> About the solution itse= lf:=0A>>> =0A>>> * Section 3: =0A>>> =0A>>> =A0 "MN starts to receive the = packets over HA-MN link from=0A>>> =A0 =A0 CN and MN starts to send packets= with a destination option =0A> containing=0A>>> =A0 =A0 the previous Care-= of Address as MN's Home Address (HoA) to the =0A> CN."=0A>>> =0A>>> I'm=A0= not sure why you are doing this? This sounds like route =0A> optimization = to=A0 =0A>>> me.=0A>>> =0A>> =0A>> Why not? This is the behaviour MN shou= ld have because HA keeps changing, =0A> right?=0A> =0A> In section 5 you ar= e stating "This protocol removes the need for route =0A> optimization.=A0 C= orrespondent nodes do not need to maintain a binding cache of =0A> bindings= for other=A0 nodes.", so this does not sound coherent with the MN =0A> beh= avior exposed above. =0A> =0A=0A=0ARFC 6275 says destination option is used= in a packet=0A=A0 sent by a mobile node while away from home, to inform t= he recipient=0A=A0 of the mobile node's home address.=0ASo we need it. I w= ill clarify no route optimization statement, which means that there is no n= eed =0A=0A=A01 Home Test Init=0A=0A=A0 =A0 =A0 2=A0 Care-of Test Init=0A=0A= =A0 =A0 =A0 3=A0 Home Test=0A=0A=A0 =A0 =A0 4=A0 Care-of Test=0Amessage exc= hanges.=0A=0ARegards,=0A=0ABehcet From behcetsarikaya@yahoo.com Fri Aug 12 15:15:11 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1041911E8094 for ; Fri, 12 Aug 2011 15:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[AWL=-1.719, BAYES_50=0.001, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASMiO7+vUk2f for ; Fri, 12 Aug 2011 15:15:06 -0700 (PDT) Received: from nm16-vm0.bullet.mail.sp2.yahoo.com (nm16-vm0.bullet.mail.sp2.yahoo.com [98.139.91.210]) by ietfa.amsl.com (Postfix) with SMTP id DDB5C11E8088 for ; Fri, 12 Aug 2011 15:15:05 -0700 (PDT) Received: from [98.139.91.68] by nm16.bullet.mail.sp2.yahoo.com with NNFMP; 12 Aug 2011 22:15:43 -0000 Received: from [98.139.91.11] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 12 Aug 2011 22:15:43 -0000 Received: from [127.0.0.1] by omp1011.mail.sp2.yahoo.com with NNFMP; 12 Aug 2011 22:15:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 471305.85133.bm@omp1011.mail.sp2.yahoo.com Received: (qmail 1621 invoked by uid 60001); 12 Aug 2011 22:15:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313187342; bh=Ak1PIqYU4s7R3ZigBUyeZkWQvcYjc2ImCxUoOCkl/2s=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=PsX2MTHSaH22OSsfEGFnMzHYn9J6U3QW7OnqS5WqQ3zcsBwbTXbajkwvuXu6B7JukHa9IvEz8IPsBU9Hu0AohmbGdXD7POb61GoxuviXCG839Y0eR6m/sLSKuQgt7Db3sKNYQhyJ66EhozmhO5cOz70K9nJDkNzJOdyOzhIX5p0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=gKi0QXMyluhIK1EBPtAPLlI53h00Mq+ci3sLrXHH/sxF53+zKSs7YLuf6EBPn5RHYP12me95Y/JekwMnBmhL7FmnDUTpfpEcwEQXOZQVpu/Gn36tjvfYM1ZiYS1yLaaf63jugF83jNU1K7LeoQ72jaHueoRbqgOVZ+MedWwhcrM=; X-YMail-OSG: DI8MhUIVM1mTmprTe.NUcJulPDd7hyY3lDPdaCIaQ4Dk9qh sI3VUnWUbGESv_I8u2gvoM0Ts1O3vxhbv6zCY5JMhELlKKDKPqdj97wf3NvZ u3ruvc5VaS28bQWgF8NHCe43PqW31Ba75evy1lkK9Gvcra9vwbxFMVaSXL7Q EHhKOW03kABOzWLGd9KLsrGWX7Po41xfifkbzmqcwwFeII.ibIQq3gWU8sq4 _Ku2rM_NH_oUCqWKJ5gn6aWjdmEHJlPcX2MNZF.4KSBQTsKUfLyhevDUfNl5 EXylHvQvTjKvCQuc0vcF_GilcUtgYFnYobCIhnvqePfnZp2nQogWnPK71GSN NEuZcnxRjbx8zET_cmKQLj3zrQWIjm4TifnSaI55EhAyhUxvNQ3A7EcoGdJH YoeBmUUPiMFFSFzkOnc1eTxAfIzCiBgNQSi5u_ISvdT_TAN2gAX5TwWs0h7x uCp.Dc0kk8sPvQaqaC1LPiabj8LHf.uCKohFVhJBK.1pCa2I7.8RzvE.w__o wByhHA0FZaexra1fICM0T8n1PzeuLyeAbLK6O5NApeDp6cw-- Received: from [50.58.7.243] by web111414.mail.gq1.yahoo.com via HTTP; Fri, 12 Aug 2011 15:15:42 PDT X-Mailer: YahooMailWebService/0.8.113.313619 Message-ID: <1313187342.89796.YahooMailNeo@web111414.mail.gq1.yahoo.com> Date: Fri, 12 Aug 2011 15:15:42 -0700 (PDT) From: Behcet Sarikaya To: "mext@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [MEXT] New version for draft-sarikaya-mext-multicastdmm X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 22:15:11 -0000 http://www.ietf.org/id/draft-sarikaya-mext-multicastdmm-01.txt From rkuntz@us.toyota-itc.com Fri Aug 12 17:28:02 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2664421F863A for ; Fri, 12 Aug 2011 17:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PatAPrFT3r+3 for ; Fri, 12 Aug 2011 17:28:01 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with SMTP id E5CDF21F861A for ; Fri, 12 Aug 2011 17:28:00 -0700 (PDT) Received: from mail-yx0-f182.google.com ([209.85.213.182]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKTkXFMwpa/vHr/5Oon9Qi3GKwFwLPA5A/@postini.com; Fri, 12 Aug 2011 17:28:39 PDT Received: by mail-yx0-f182.google.com with SMTP id 31so2935481yxl.41 for ; Fri, 12 Aug 2011 17:28:35 -0700 (PDT) Received: by 10.150.159.1 with SMTP id h1mr2692890ybe.233.1313195315563; Fri, 12 Aug 2011 17:28:35 -0700 (PDT) Received: from [192.168.18.145] (adsl-99-49-9-53.dsl.pltn13.sbcglobal.net [99.49.9.53]) by mx.google.com with ESMTPS id p1sm109694yba.17.2011.08.12.17.28.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Aug 2011 17:28:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Romain KUNTZ In-Reply-To: <1313186725.90692.YahooMailNeo@web111402.mail.gq1.yahoo.com> Date: Fri, 12 Aug 2011 17:28:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <94FEB967-CECD-440A-81DE-7D29C7F77251@us.toyota-itc.com> References: <5ABC57DC-9BF5-4626-B51F-DD50222BA5CB@us.toyota-itc.com> <1311438985.9673.YahooMailRC@web111416.mail.gq1.yahoo.com> <1313186725.90692.YahooMailNeo@web111402.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1244.3) Cc: "mext@ietf.org" Subject: Re: [MEXT] Some questions on draft-sarikaya-mext-multicastdmm X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 00:28:02 -0000 Hello Behcet, On Aug 12, 2011, at 15:05, Behcet Sarikaya wrote: >> In section 5 you are stating "This protocol removes the need for = route=20 >> optimization. Correspondent nodes do not need to maintain a binding = cache of=20 >> bindings for other nodes.", so this does not sound coherent with the = MN=20 >> behavior exposed above.=20 >>=20 >=20 >=20 > RFC 6275 says destination option is used in a packet > sent by a mobile node while away from home, to inform the recipient > of the mobile node's home address. > So we need it. I will clarify no route optimization statement, which = means that there is no need=20 >=20 > 1 Home Test Init >=20 > 2 Care-of Test Init >=20 > 3 Home Test >=20 > 4 Care-of Test > message exchanges. If I remember correctly, RFC6275 requires the CN to have a binding cache = entry to process destination options from the MN, which requires the = return routability procedure.=20 romain= From behcetsarikaya@yahoo.com Mon Aug 15 08:10:42 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04E421F8C40 for ; Mon, 15 Aug 2011 08:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.563 X-Spam-Level: X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[AWL=-0.564, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UldcG5XYKAZ for ; Mon, 15 Aug 2011 08:10:41 -0700 (PDT) Received: from nm25.bullet.mail.sp2.yahoo.com (nm25.bullet.mail.sp2.yahoo.com [98.139.91.95]) by ietfa.amsl.com (Postfix) with SMTP id A31F121F8C42 for ; Mon, 15 Aug 2011 08:10:41 -0700 (PDT) Received: from [98.139.91.65] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 15 Aug 2011 15:11:18 -0000 Received: from [98.139.91.50] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 15 Aug 2011 15:11:18 -0000 Received: from [127.0.0.1] by omp1050.mail.sp2.yahoo.com with NNFMP; 15 Aug 2011 15:11:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 24485.33293.bm@omp1050.mail.sp2.yahoo.com Received: (qmail 40437 invoked by uid 60001); 15 Aug 2011 15:11:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313421077; bh=jm3BoCKoLooDIsRsa6CohggzD16Y6nNVZS85WF9pwOM=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=P+addFkeMtryy1uqAS/k3TEWCYe4I10mt5FhfB9IrQraE9EPIt4fg7nXrJFX9yXSFGWvmEnuYEjNHGLCotTOZ8pBHyoZqz735UBRGAtEIommI5PtULLD5u/Vgdjfvv5Q0uRMiOoblmCgmMzqK1N6eOa70/GTCSzYyVXjtTmLjAI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=B66pXwAcqJ7qTAIb+QesAugu/hQfpMz0aUQnfhzqNOfEVaeTGKJIWwKOl0AUUnyJJp1UCDTpaMQ/drVjkiwOUbaJ3P0/tanS2CjQf/BriMHruMgGFks/Y1BtABZX0y+BbfX9mvIRCtlZRqocVoVRYgJlNQOgg6aynhlkARTX9pI=; X-YMail-OSG: .vv9FlgVM1lgR9D0n4r853_xCJI2c0bQSevW4gaHWXy0Ni4 o_oJlHpttPLax8IwaMHxrCSCpqxbwVzWo.CsrzT5E8INJD9FTSrxlO9.awQ9 0KnqtquW1foPgNPYfQszTlAvhItXeG0Xb7MpPktBvilzXbfBBjOSYfnF8bLs t7Php_9rLGjFvig2G3Ne8cX5gglTG2r.8v7U1S6PEcxvgDBp2NP3IQMyo5un p9X2XLOQDV5jejxK_9zA0fDRAQ9qJ4bvdgG3M6dBkV8h3EOTBc77CXwkzU3p qszH3nqdhuT8.Em3vd5Lb7h8_fxIogY4fC_jsx05eqF_D9YI5JNs30y84CWj R0GG25zXetvdIik4OFf8tKYaWJK_e7LGI8HBfzlL_OZ8pO.pzjhFOwxcC7LQ nBTsgVss96v4r7IHGES4QLS8.WCJvODwhKmGZIzCRRlpr8HYk.YwDM.xH79f U44sWhmmVxR8pE9UGkYKvPOfYDrwXiXAWA5EKWqTdZcSiJFST99Z7H5doCVJ JyxNyql4YMkJC9mTzTfhXXAmkNjyHm.fRWyKM2UWU8NpEYsc- Received: from [50.58.7.243] by web111401.mail.gq1.yahoo.com via HTTP; Mon, 15 Aug 2011 08:11:17 PDT X-Mailer: YahooMailWebService/0.8.113.313619 References: <5ABC57DC-9BF5-4626-B51F-DD50222BA5CB@us.toyota-itc.com> <1311438985.9673.YahooMailRC@web111416.mail.gq1.yahoo.com> <1313186725.90692.YahooMailNeo@web111402.mail.gq1.yahoo.com> <94FEB967-CECD-440A-81DE-7D29C7F77251@us.toyota-itc.com> Message-ID: <1313421077.34816.YahooMailNeo@web111401.mail.gq1.yahoo.com> Date: Mon, 15 Aug 2011 08:11:17 -0700 (PDT) From: Behcet Sarikaya To: Romain KUNTZ In-Reply-To: <94FEB967-CECD-440A-81DE-7D29C7F77251@us.toyota-itc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mext@ietf.org" Subject: Re: [MEXT] Some questions on draft-sarikaya-mext-multicastdmm X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 15:10:42 -0000 Hi Romain,=0A=0A=0A> Hello Behcet,=0A> =0A> On Aug 12, 2011, at 15:05, Behc= et Sarikaya wrote:=0A>>> In section 5 you are stating "This protocol remov= es the need for =0A> route =0A>>> optimization.=A0 Correspondent nodes do = not need to maintain a binding =0A> cache of =0A>>> bindings for other=A0 = nodes.", so this does not sound coherent with =0A> the MN =0A>>> behavior = exposed above. =0A>>> =0A>> =0A>> =0A>> RFC 6275 says destination option i= s used in a packet=0A>> =A0 =A0 sent by a mobile node while away from home,= to inform the recipient=0A>> =A0 =A0 of the mobile node's home address.=0A= >> So we need it. I will clarify no route optimization statement, which me= ans =0A> that there is no need =0A>> =0A>> =A0 1 Home Test Init=0A>> =0A>> = =A0 =A0 =A0 2=A0 Care-of Test Init=0A>> =0A>> =A0 =A0 =A0 3=A0 Home Test= =0A>> =0A>> =A0 =A0 =A0 4=A0 Care-of Test=0A>> message exchanges.=0A> =0A= > If I remember correctly, RFC6275 requires the CN to have a binding cache = entry =0A> to process destination options from the MN, which requires the r= eturn =0A> routability procedure. =0A> =0A=0AAs it says in RFC 6275 the des= tination option is needed to inform the recipient=0Aof the mobile node's ho= me address=0A=0A=0AThis is the functionality that is needed for dmm. There = is no need for return routability procedure.=0AThat means dmm can not work = with an unmodified CN, which is the most important impact.=0A=0ARegards,=0A= =0ABehcet From rkuntz@us.toyota-itc.com Mon Aug 15 18:17:05 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8691A21F863E for ; Mon, 15 Aug 2011 18:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYQhoXUI5+up for ; Mon, 15 Aug 2011 18:17:05 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with SMTP id 21E0921F8CFE for ; Mon, 15 Aug 2011 18:16:57 -0700 (PDT) Received: from mail-yx0-f174.google.com ([209.85.213.174]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTknFL6orKYzkVunTfEhtTb1KwQbEEFUo@postini.com; Mon, 15 Aug 2011 18:17:45 PDT Received: by mail-yx0-f174.google.com with SMTP id 19so3478269yxj.19 for ; Mon, 15 Aug 2011 18:17:35 -0700 (PDT) Received: by 10.101.84.12 with SMTP id m12mr4497626anl.62.1313457454865; Mon, 15 Aug 2011 18:17:34 -0700 (PDT) Received: from hong-lt.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id b5sm2311591anm.47.2011.08.15.18.17.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 15 Aug 2011 18:17:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Romain KUNTZ In-Reply-To: <1313421077.34816.YahooMailNeo@web111401.mail.gq1.yahoo.com> Date: Mon, 15 Aug 2011 18:17:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5ABC57DC-9BF5-4626-B51F-DD50222BA5CB@us.toyota-itc.com> <1311438985.9673.YahooMailRC@web111416.mail.gq1.yahoo.com> <1313186725.90692.YahooMailNeo@web111402.mail.gq1.yahoo.com> <94FEB967-CECD-440A-81DE-7D29C7F77251@us.toyota-itc.com> <1313421077.34816.YahooMailNeo@web111401.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1244.3) Cc: "mext@ietf.org" Subject: Re: [MEXT] Some questions on draft-sarikaya-mext-multicastdmm X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 01:17:05 -0000 Hi Behcet,=20 On Aug 15, 2011, at 8:11, Behcet Sarikaya wrote: >>> RFC 6275 says destination option is used in a packet >>> sent by a mobile node while away from home, to inform the = recipient >>> of the mobile node's home address. >>> So we need it. I will clarify no route optimization statement, which = means that there is no need=20 >>>=20 >>> 1 Home Test Init >>>=20 >>> 2 Care-of Test Init >>>=20 >>> 3 Home Test >>>=20 >>> 4 Care-of Test >>> message exchanges. >>=20 >> If I remember correctly, RFC6275 requires the CN to have a binding = cache entry=20 >> to process destination options from the MN, which requires the return=20= >> routability procedure.=20 >>=20 >=20 > As it says in RFC 6275 the destination option is needed to inform the = recipient > of the mobile node's home address >=20 >=20 > This is the functionality that is needed for dmm. There is no need for = return routability procedure. > That means dmm can not work with an unmodified CN, which is the most = important impact. I'm not sure you get my point: it is a security breach to use the = destination option with a CN without having a proper binding = registration & return routability procedure. Regards, Romain= From behcetsarikaya@yahoo.com Wed Aug 17 11:52:31 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB8721F859F for ; Wed, 17 Aug 2011 11:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwWxEfjyHK0P for ; Wed, 17 Aug 2011 11:52:30 -0700 (PDT) Received: from nm11-vm0.bullet.mail.sp2.yahoo.com (nm11-vm0.bullet.mail.sp2.yahoo.com [98.139.91.240]) by ietfa.amsl.com (Postfix) with SMTP id B1ABA21F854E for ; Wed, 17 Aug 2011 11:52:30 -0700 (PDT) Received: from [98.139.91.68] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 17 Aug 2011 18:53:17 -0000 Received: from [98.139.91.14] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 17 Aug 2011 18:53:17 -0000 Received: from [127.0.0.1] by omp1014.mail.sp2.yahoo.com with NNFMP; 17 Aug 2011 18:53:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 517538.16378.bm@omp1014.mail.sp2.yahoo.com Received: (qmail 72413 invoked by uid 60001); 17 Aug 2011 18:53:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313607197; bh=33Sy+JYcKP9ZWdBOYLqr3KqUqdOpBcBYQhQp6Uiqol8=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pPgfDraEL5jzsXYvjGQPC3heahxyDZqvWKpCkdcXVdbS7e5U1H4n5ty39VBbJJ8lAeKnCvWfaOFs3DSaAkuZ+9bEexd8EWVTfKD5h4V5bWVikzqQcTli50J7vHwfZHuv47qGkhThYzpLGDc1R3A7yfA18eKuGxnc5k3v5/Ho+iM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=uUn2GicOcwb8NLAE8OJZ4c0IKvN4r+tjD6pD0pCpCOBsWGu7nxPNZYM797L4IBv1VzIcDS+QA4X3/ABLLyLHvKL4JzYfc3TiFxsCecygGs2RGGm+NgJHddyNH0zCiCWUEM9USN6Fbn80uMg5LFktlhN4RrH4/zGJUKW5HNXOHIs=; X-YMail-OSG: NsLlNYAVM1kERixb0SRy.eAXzZ2w4_5lA1WQo7oHJTKNCZi dvjchE2H31YhD5HAIva__hLI9ISRnJIzmayovWMPHcHlvOQ.r29V2OtrsUl7 Rv0WtCf01sfYRRGcMEDyBDk2yYEbkTFRuIlP4U7qdXKnT_FuRUyyn6pDyD0x qmjQXeJuhETC6fboO.dnb2yEWuSXH.wqDmoEsKFZ5LCp2AfGRFsYtxfn0YzF ZREF9EyUeAUpL4yQTzO_E4P0pdU_pJshJr6K8IHqNNIydEPLFxM.f3Wker9c RBb00DawSI3F6hnsz3ytjir_w6VTNJ0aWRJboZ8zOTTSaRaaOeUNNGpowTiO qYdb__uW1l.Ab87S9tJRrfrv.yQ8h_HDe9ekpG4H9E0VvQRsXLwIQf29c.rn KCCYOE1cEyAlGYumlweWIprOfOqqtnf0PLQtH5YrptXSHWc_zSMHV_ZEZ3qq Q9na9LlhHiEUwV7bj4jBFyHFeUSeFXyzegWtaR3VTdGwoiviMX5jSuFPFtpu TcX1gfceb.omRQ5uRJ9brhjV.5FusUsuVtaldUuShmST2WZOlxaFLbm06LPC 98lxsGSHgC6NeBGgL1dwxCYKNwjI- Received: from [50.58.7.243] by web111412.mail.gq1.yahoo.com via HTTP; Wed, 17 Aug 2011 11:53:16 PDT X-Mailer: YahooMailWebService/0.8.113.313619 References: <5ABC57DC-9BF5-4626-B51F-DD50222BA5CB@us.toyota-itc.com> <1311438985.9673.YahooMailRC@web111416.mail.gq1.yahoo.com> <1313186725.90692.YahooMailNeo@web111402.mail.gq1.yahoo.com> <94FEB967-CECD-440A-81DE-7D29C7F77251@us.toyota-itc.com> <1313421077.34816.YahooMailNeo@web111401.mail.gq1.yahoo.com> Message-ID: <1313607196.45178.YahooMailNeo@web111412.mail.gq1.yahoo.com> Date: Wed, 17 Aug 2011 11:53:16 -0700 (PDT) From: Behcet Sarikaya To: "mext@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [MEXT] Some questions on draft-sarikaya-mext-multicastdmm X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 18:52:31 -0000 Hi Romain, all,=0A=0A=0A> Hi Behcet, =0A> =0A> On Aug 15, 2011, at 8:11, Be= hcet Sarikaya wrote:=0A>>>>=A0 RFC 6275 says destination option is used in = a packet=0A>>>> =A0 =A0=A0 sent by a mobile node while away from home, to i= nform the =0A> recipient=0A>>>> =A0 =A0=A0 of the mobile node's home addres= s.=0A>>>>=A0 So we need it. I will clarify no route optimization statement,= =0A> which means that there is no need =0A>>>> =0A>>>> =A0=A0 1 Home Test = Init=0A>>>> =0A>>>> =A0 =A0 =A0 =A0 2=A0 Care-of Test Init=0A>>>> =0A>>>> = =A0 =A0 =A0 =A0 3=A0 Home Test=0A>>>> =0A>>>> =A0 =A0 =A0 =A0 4=A0 Care-of = Test=0A>>>>=A0 message exchanges.=0A>>> =0A>>>=A0 If I remember correctly, = RFC6275 requires the CN to have a binding =0A> cache entry =0A>>>=A0 to pro= cess destination options from the MN, which requires the return =0A>>>=A0 r= outability procedure. =0A>>> =0A>> =0A>>=A0 As it says in RFC 6275 the dest= ination option is needed to inform the =0A> recipient=0A>>=A0 of the mobile= node's home address=0A>> =0A>> =0A>>=A0 This is the functionality that is = needed for dmm. There is no need for =0A> return routability procedure.=0A>= >=A0 That means dmm can not work with an unmodified CN, which is the most = =0A> important impact.=0A> =0A> I'm not sure you get my point: it is a secu= rity breach to use the =0A> destination option with a CN without having a p= roper binding registration & =0A> return routability procedure.=0A> =0A=0A= =0AYes, you are right.=0ASorry=0A for my misunderstanding, I was mislead by= Sec. 6.3 in RFC 6275 which =0Adid not clearly state that home address dest= ination option is only =0Arequired for route optimized packets.=0A=0Adraft-= sarikaya-mext-multicastdmm-03.txt=0A=0Aclarifies it, I hope.=0A=0ARegards,= =0A=0ABehcet=0A From charliep@computer.org Wed Aug 24 12:05:26 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A17321F8BA7 for ; Wed, 24 Aug 2011 12:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLPyRivJQVou for ; Wed, 24 Aug 2011 12:05:25 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 7F88421F8B9B for ; Wed, 24 Aug 2011 12:05:25 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.96.89]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1QwImY-0008PP-AM for mext@ietf.org; Wed, 24 Aug 2011 15:06:34 -0400 Message-ID: <4E554BAA.9080409@computer.org> Date: Wed, 24 Aug 2011 12:06:18 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: mext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86caac4dccf7e3e446c16127e913e9449c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Subject: [MEXT] Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 19:05:26 -0000 Hello folks, It's now 2011. Mobile IP was standardized late in 1996, after work had already been started nearly ten years before. Over two decades! -- and regardless of lip service to fixed/mobile convergence we still don't have seamless mobility in user devices across heterogeneous media, and standards organizations (notably 3GPP) are not properly taking advantage of what Mobile IP can do. The losers are the end-users, which means all of us. There are many reasons for this, but one of the main reasons has to do with authentication at the access network. EAP in various forms is being utilized for this purpose, and Mobile IP is not, even though there has never been any reported failure of the RFC 5944 or RFC 4285 or RFC 6275 (to my knowledge). Moreover, unless there is something wrong with the cryptography that also has not been reported, these authentication methods enable _mutual_ authentication between the network and the client, not just client authentication. In order for Mobile IP to enable the real promise of high performance heterogeneous networking, we have to do some more work. I would like to initiate some more discussion about this. DMM is interesting in its own right, but it's not at all the whole story. Moreover, with proper design, it is likely the supposed burden of signaling to the home agent can be substantially reduced. As one simple example, if handovers are accomplished locally between trusted access agents (routers, 802.11 access controllers, ...) then the actual timing of tunnel redirection from the home agent becomes much less critical. This is also intricately intertwined with authentication. If the Home Agent were recognized as a robust security appliance, then it could naturally sit on the network boundary as an IP-addressable device. Mobile IP authentication could become the primary means of validating user access, instead of an afterthought to enable IP-address preservation after all the heavy lifting has been done a lower levels. I would like to propose that in this working group we should go about making this happen. It seems to be important, and undeniably aligned with our working group responsibilities. Regards, Charlie P. From alper.yegin@yegin.org Thu Aug 25 01:47:52 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BCE21F8AF2 for ; Thu, 25 Aug 2011 01:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wewNWbTkT0UJ for ; Thu, 25 Aug 2011 01:47:52 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3C721F8AF0 for ; Thu, 25 Aug 2011 01:47:52 -0700 (PDT) Received: from [172.20.10.3] ([46.154.95.149]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MA7tp-1R7oHN0aZV-00Baki; Thu, 25 Aug 2011 04:49:03 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_03A3F744-1A26-4D9E-BD7E-2E98DB9378C2" From: Alper Yegin In-Reply-To: <4E554BAA.9080409@computer.org> Date: Thu, 25 Aug 2011 11:48:58 +0300 Message-Id: <82040B86-84C1-4CDD-B739-AC4D91865744@yegin.org> References: <4E554BAA.9080409@computer.org> To: charliep@computer.org X-Mailer: Apple Mail (2.1244.3) X-Provags-ID: V02:K0:WKZFZk/owQDd3LjwwGbm9oDU8+APDOBQURd0ZaK/XcP K2O9AXLdHSdaVLVVYV7mnUiCfj1woqm87La3xz4Ng3uwGzQrnj jTNygr+5f/8tkCtojV+LfS51DASiA9ejLDlWdKa5OrdRc4Q1hr LxDg+21VQFX5fnhs2GntUvWMYpgefFXtjLqhua1fg9lcwX64y9 H/ur0P8WlwcZbQknH6THs/PQ0GpYqQpL0+EWeYf2nQ= Cc: mext Subject: Re: [MEXT] Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 08:47:52 -0000 --Apple-Mail=_03A3F744-1A26-4D9E-BD7E-2E98DB9378C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Charlie, On Aug 24, 2011, at 10:06 PM, Charles E. Perkins wrote: > If the Home Agent were recognized as a robust security > appliance, then it could naturally sit on the network > boundary as an IP-addressable device. Mobile IP > authentication could become the primary means of > validating user access, instead of an afterthought > to enable IP-address preservation after all the heavy > lifting has been done a lower levels. Do you mean using Mobile IP protocol for (local area) network access = authentication? Or, something else? Alper --Apple-Mail=_03A3F744-1A26-4D9E-BD7E-2E98DB9378C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Charlie,

On Aug 24, 2011, at 10:06 PM, Charles E. = Perkins wrote:

If the Home = Agent were recognized as a robust security
appliance, then it could = naturally sit on the network
boundary as an IP-addressable device. =  Mobile IP
authentication could become the primary means = of
validating user access, instead of an afterthought
to enable = IP-address preservation after all the heavy
lifting has been done a = lower levels.

Do you mean using = Mobile IP protocol for (local area) network access authentication? Or, = something = else?

Alper


= --Apple-Mail=_03A3F744-1A26-4D9E-BD7E-2E98DB9378C2-- From charliep@computer.org Thu Aug 25 09:27:07 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C1F21F86AF for ; Thu, 25 Aug 2011 09:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuNviWLJP+wd for ; Thu, 25 Aug 2011 09:27:06 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 197FD21F852E for ; Thu, 25 Aug 2011 09:27:06 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.96.89]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Qwcmv-000237-Dx; Thu, 25 Aug 2011 12:28:17 -0400 Message-ID: <4E56781E.60904@computer.org> Date: Thu, 25 Aug 2011 09:28:14 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Alper Yegin References: <4E554BAA.9080409@computer.org> <82040B86-84C1-4CDD-B739-AC4D91865744@yegin.org> In-Reply-To: <82040B86-84C1-4CDD-B739-AC4D91865744@yegin.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8695c57ea4dfa317a4b19f31265620d5fe350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: mext Subject: Re: [MEXT] Well-known problem with authentication/etc. in wirelessnetworks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 16:27:07 -0000 Hello Alper, Here is a diagram that might help. AS == Authentication server (AAA server) AR == AAA relay EA == EAP authenticator UE == User Equipment == mobile node == access terminal == ... Then, UE --- EA --- AS is a schematic diagram for 802.1x We can have AAA relays: UE --- EA --- AR --- AS I can't think of any reason not to allow HA as AR in this protocol exchange. And then as part of the protocol operation the home agent should be very simply able to update its binding cache. But this is just one example, using 802.1x. Of course others are possible and important in various circumstances. Why aren't we there in all of those circumstances? In the above diagram, we might also design EAP signaling for mutual authentication in a single round trip. Why not? If EAP is the magic incantation that makes operators comfortable, why not use it? Regards, Charlie P. On 8/25/2011 1:48 AM, Alper Yegin wrote: > Hi Charlie, > > On Aug 24, 2011, at 10:06 PM, Charles E. Perkins wrote: > >> If the Home Agent were recognized as a robust security >> appliance, then it could naturally sit on the network >> boundary as an IP-addressable device. Mobile IP >> authentication could become the primary means of >> validating user access, instead of an afterthought >> to enable IP-address preservation after all the heavy >> lifting has been done a lower levels. > > Do you mean using Mobile IP protocol for (local area) network access > authentication? Or, something else? > > Alper > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From julien.ietf@gmail.com Thu Aug 25 10:43:33 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D862C21F8C22 for ; Thu, 25 Aug 2011 10:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.407 X-Spam-Level: X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZyH2sOzOi4A for ; Thu, 25 Aug 2011 10:43:33 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 043B821F8C1E for ; Thu, 25 Aug 2011 10:43:32 -0700 (PDT) Received: by wyg8 with SMTP id 8so2132760wyg.31 for ; Thu, 25 Aug 2011 10:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZJiGD7p9XVGN0/jcjBbzi9DiAv7wWmLodePIy6G2SPU=; b=bOizQtugFz7qXP8slOq7zN2fUxo9v3fAKzSs5CSysM6jH3l4438X9P2v1a+UOYSGl0 F/CfWDvwZWMN096kUUQTvhtokkH9YezIf4XQ7zgv+X2jhT0br7kVZ4Ee8LGnkjOUmax0 TUfzzJ66buVkKShy3Y1enBEL4FOBWJdvMlhOk= MIME-Version: 1.0 Received: by 10.227.28.4 with SMTP id k4mr44340wbc.21.1314294286335; Thu, 25 Aug 2011 10:44:46 -0700 (PDT) Received: by 10.227.141.79 with HTTP; Thu, 25 Aug 2011 10:44:46 -0700 (PDT) In-Reply-To: <4E554BAA.9080409@computer.org> References: <4E554BAA.9080409@computer.org> Date: Thu, 25 Aug 2011 10:44:46 -0700 Message-ID: From: Julien Laganier To: charliep@computer.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 17:43:34 -0000 Charlie, I am not sure I understand what is missing in MIPv6; a MN and an HA can already mutually authenticate using EAP, and this is incidentally what 3GPP leverages on, together with the EAP-AKA method. What is missing? --julien On Wed, Aug 24, 2011 at 12:06 PM, Charles E. Perkins wrote: > > Hello folks, > > It's now 2011. =A0Mobile IP was standardized late in > 1996, after work had already been started nearly > ten years before. =A0Over two decades! -- and regardless > of lip service to fixed/mobile convergence we still > don't have seamless mobility in user devices across > heterogeneous media, and standards organizations > (notably 3GPP) are not properly taking advantage of > what Mobile IP can do. The losers are the end-users, > which means all of us. > > There are many reasons for this, but one of the > main reasons has to do with authentication at the > access network. =A0EAP in various forms is being > utilized for this purpose, and Mobile IP is not, > even though there has never been any reported > failure of the RFC 5944 or RFC 4285 or RFC 6275 > (to my knowledge). =A0Moreover, unless there is > something wrong with the cryptography that also > has not been reported, these authentication methods > enable _mutual_ authentication between the network > and the client, not just client authentication. > > In order for Mobile IP to enable the real promise > of high performance heterogeneous networking, we > have to do some more work. =A0I would like to initiate > some more discussion about this. =A0DMM is interesting > in its own right, but it's not at all the whole > story. =A0Moreover, with proper design, it is likely > the supposed burden of signaling to the home agent > can be substantially reduced. =A0As one simple example, > if handovers are accomplished locally between trusted > access agents (routers, 802.11 access controllers, ...) > then the actual timing of tunnel redirection from the > home agent becomes much less critical. =A0This is also > intricately intertwined with authentication. > > If the Home Agent were recognized as a robust security > appliance, then it could naturally sit on the network > boundary as an IP-addressable device. =A0Mobile IP > authentication could become the primary means of > validating user access, instead of an afterthought > to enable IP-address preservation after all the heavy > lifting has been done a lower levels. > > I would like to propose that in this working group we > should go about making this happen. =A0It seems to be > important, and undeniably aligned with our working > group responsibilities. > > Regards, > Charlie P. > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From mccap@petoni.org Thu Aug 25 11:39:21 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5176621F8C0A for ; Thu, 25 Aug 2011 11:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmsCyg6wzQ8Q for ; Thu, 25 Aug 2011 11:39:20 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41AAD21F8C09 for ; Thu, 25 Aug 2011 11:39:20 -0700 (PDT) Received: by fxe6 with SMTP id 6so2183983fxe.31 for ; Thu, 25 Aug 2011 11:40:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petoni.org; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4ebLuV0Po1hW92WN54bqpZMIaz65PbTmckC9suFprGQ=; b=eG1wcpwuLnkBSNTTccadcDTZK19qLk88hCjy+zRCW6yYMyL+R/zKDa7RA+KBOobJ/g JbWtEcWYKcCIAReDFEK0avTIrHX9z1+FfJYAKCy0PHqQRTg0klSo4YWVODpIc6cy3aNV SQBXKBwVADdTLmUf99nGpurxFGZE63trapKxA= MIME-Version: 1.0 Received: by 10.223.91.147 with SMTP id n19mr128576fam.53.1314297633486; Thu, 25 Aug 2011 11:40:33 -0700 (PDT) Received: by 10.223.144.143 with HTTP; Thu, 25 Aug 2011 11:40:33 -0700 (PDT) X-Originating-IP: [4.28.5.163] In-Reply-To: References: <4E554BAA.9080409@computer.org> Date: Thu, 25 Aug 2011 14:40:33 -0400 Message-ID: From: Pete McCann To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: charliep@computer.org, mext Subject: Re: [MEXT] Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 18:39:21 -0000 Hi, Julien, Are you talking about EAP inside IKEv2? That presupposes that the MN is already attached to the network somewhere and has an IP address (i.e., it has already passed access authentication). It may be interesting to look at whether access authentication and mobility management can be combined. For example, we could put Mobile IP (or some variant of it) inside an EAP exchange used for access authentication. Charlie, are you proposing something like this? -Pete On Thu, Aug 25, 2011 at 1:44 PM, Julien Laganier wr= ote: > Charlie, > > I am not sure I understand what is missing in MIPv6; a MN and an HA > can already mutually authenticate using EAP, and this is incidentally > what 3GPP leverages on, together with the EAP-AKA method. What is > missing? > > --julien > > On Wed, Aug 24, 2011 at 12:06 PM, Charles E. Perkins > wrote: >> >> Hello folks, >> >> It's now 2011. =A0Mobile IP was standardized late in >> 1996, after work had already been started nearly >> ten years before. =A0Over two decades! -- and regardless >> of lip service to fixed/mobile convergence we still >> don't have seamless mobility in user devices across >> heterogeneous media, and standards organizations >> (notably 3GPP) are not properly taking advantage of >> what Mobile IP can do. The losers are the end-users, >> which means all of us. >> >> There are many reasons for this, but one of the >> main reasons has to do with authentication at the >> access network. =A0EAP in various forms is being >> utilized for this purpose, and Mobile IP is not, >> even though there has never been any reported >> failure of the RFC 5944 or RFC 4285 or RFC 6275 >> (to my knowledge). =A0Moreover, unless there is >> something wrong with the cryptography that also >> has not been reported, these authentication methods >> enable _mutual_ authentication between the network >> and the client, not just client authentication. >> >> In order for Mobile IP to enable the real promise >> of high performance heterogeneous networking, we >> have to do some more work. =A0I would like to initiate >> some more discussion about this. =A0DMM is interesting >> in its own right, but it's not at all the whole >> story. =A0Moreover, with proper design, it is likely >> the supposed burden of signaling to the home agent >> can be substantially reduced. =A0As one simple example, >> if handovers are accomplished locally between trusted >> access agents (routers, 802.11 access controllers, ...) >> then the actual timing of tunnel redirection from the >> home agent becomes much less critical. =A0This is also >> intricately intertwined with authentication. >> >> If the Home Agent were recognized as a robust security >> appliance, then it could naturally sit on the network >> boundary as an IP-addressable device. =A0Mobile IP >> authentication could become the primary means of >> validating user access, instead of an afterthought >> to enable IP-address preservation after all the heavy >> lifting has been done a lower levels. >> >> I would like to propose that in this working group we >> should go about making this happen. =A0It seems to be >> important, and undeniably aligned with our working >> group responsibilities. >> >> Regards, >> Charlie P. >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From charliep@computer.org Thu Aug 25 12:18:35 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B2221F8BA2 for ; Thu, 25 Aug 2011 12:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8tien1Ecov4 for ; Thu, 25 Aug 2011 12:18:35 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 079C321F8B98 for ; Thu, 25 Aug 2011 12:18:35 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.96.89]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1QwfSu-00026l-Fl; Thu, 25 Aug 2011 15:19:48 -0400 Message-ID: <4E56A052.1000604@computer.org> Date: Thu, 25 Aug 2011 12:19:46 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Pete McCann References: <4E554BAA.9080409@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86548192237726173f06ee375395b3594c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: mext Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 19:18:35 -0000 Hello Pete, Yes, putting Mobile IP inside of EAP would be one approach. It would have some interesting advantages. Other approaches might be more properly done in [netext] -- or perhaps have already been looked; I could have possibly missed some of the relevant discussion there. Regards, Charlie P. On 8/25/2011 11:40 AM, Pete McCann wrote: > Hi, Julien, > > Are you talking about EAP inside IKEv2? That presupposes that the MN > is already attached to the network somewhere and has an IP address (i.e., > it has already passed access authentication). > > It may be interesting to look at whether access authentication and mobility > management can be combined. For example, we could put Mobile IP (or > some variant of it) inside an EAP exchange used for access authentication. > Charlie, are you proposing something like this? > > -Pete > > On Thu, Aug 25, 2011 at 1:44 PM, Julien Laganier wrote: >> Charlie, >> >> I am not sure I understand what is missing in MIPv6; a MN and an HA >> can already mutually authenticate using EAP, and this is incidentally >> what 3GPP leverages on, together with the EAP-AKA method. What is >> missing? >> >> --julien >> >> On Wed, Aug 24, 2011 at 12:06 PM, Charles E. Perkins >> wrote: >>> >>> Hello folks, >>> >>> It's now 2011. Mobile IP was standardized late in >>> 1996, after work had already been started nearly >>> ten years before. Over two decades! -- and regardless >>> of lip service to fixed/mobile convergence we still >>> don't have seamless mobility in user devices across >>> heterogeneous media, and standards organizations >>> (notably 3GPP) are not properly taking advantage of >>> what Mobile IP can do. The losers are the end-users, >>> which means all of us. >>> >>> There are many reasons for this, but one of the >>> main reasons has to do with authentication at the >>> access network. EAP in various forms is being >>> utilized for this purpose, and Mobile IP is not, >>> even though there has never been any reported >>> failure of the RFC 5944 or RFC 4285 or RFC 6275 >>> (to my knowledge). Moreover, unless there is >>> something wrong with the cryptography that also >>> has not been reported, these authentication methods >>> enable _mutual_ authentication between the network >>> and the client, not just client authentication. >>> >>> In order for Mobile IP to enable the real promise >>> of high performance heterogeneous networking, we >>> have to do some more work. I would like to initiate >>> some more discussion about this. DMM is interesting >>> in its own right, but it's not at all the whole >>> story. Moreover, with proper design, it is likely >>> the supposed burden of signaling to the home agent >>> can be substantially reduced. As one simple example, >>> if handovers are accomplished locally between trusted >>> access agents (routers, 802.11 access controllers, ...) >>> then the actual timing of tunnel redirection from the >>> home agent becomes much less critical. This is also >>> intricately intertwined with authentication. >>> >>> If the Home Agent were recognized as a robust security >>> appliance, then it could naturally sit on the network >>> boundary as an IP-addressable device. Mobile IP >>> authentication could become the primary means of >>> validating user access, instead of an afterthought >>> to enable IP-address preservation after all the heavy >>> lifting has been done a lower levels. >>> >>> I would like to propose that in this working group we >>> should go about making this happen. It seems to be >>> important, and undeniably aligned with our working >>> group responsibilities. >>> >>> Regards, >>> Charlie P. >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > From alper.yegin@yegin.org Thu Aug 25 12:49:02 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA59021F8C46 for ; Thu, 25 Aug 2011 12:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOnU9cy69CdU for ; Thu, 25 Aug 2011 12:49:02 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id F182721F8C39 for ; Thu, 25 Aug 2011 12:49:01 -0700 (PDT) Received: from [172.20.10.3] ([46.155.26.100]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MX1My-1QiQIq28tI-00W5nX; Thu, 25 Aug 2011 15:50:10 -0400 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <4E56A052.1000604@computer.org> Date: Thu, 25 Aug 2011 22:50:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2DE7A02D-05DA-4C99-AE17-1EB809A4E20C@yegin.org> References: <4E554BAA.9080409@computer.org> <4E56A052.1000604@computer.org> To: charliep@computer.org X-Mailer: Apple Mail (2.1244.3) X-Provags-ID: V02:K0:EeRuJCSya+ZjVC4wRY9/TIH9lHIbbx+9XiTjIGVqnI4 Mb4cCPAXd4L5TfMwoMwCAAdZUBPKbAIYzgaWtY/WDQH82OyKQ3 4DTu4FyIuhPZAkgbW3HxrqErt55wb2vZNMqHshAbc0bMRVN4zK I+sjfQ0yc0PDO6RKxo8rb6nCTiJj65+i4Oj8GoZOYyKezXJWuQ ypHdCjg3B04R0HaUm6SQX5rN2uzmNiFa7+T4g/jDro= Cc: Pete McCann , mext Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 19:49:02 -0000 Charlie, Lot of possibilities exist. EAP over Mobile IP, Mobile IP over EAP, etc. = We can also blend in other protocols as well. But I'm not clear on the problem statement. What are we trying to = achieve, can we narrow that down? Thanks. Alper On Aug 25, 2011, at 10:19 PM, Charles E. Perkins wrote: > Hello Pete, >=20 > Yes, putting Mobile IP inside of EAP would be one approach. > It would have some interesting advantages. Other approaches > might be more properly done in [netext] -- or perhaps have > already been looked; I could have possibly missed some of > the relevant discussion there. >=20 > Regards, > Charlie P. >=20 >=20 >=20 > On 8/25/2011 11:40 AM, Pete McCann wrote: >> Hi, Julien, >>=20 >> Are you talking about EAP inside IKEv2? That presupposes that the MN >> is already attached to the network somewhere and has an IP address = (i.e., >> it has already passed access authentication). >>=20 >> It may be interesting to look at whether access authentication and = mobility >> management can be combined. For example, we could put Mobile IP (or >> some variant of it) inside an EAP exchange used for access = authentication. >> Charlie, are you proposing something like this? >>=20 >> -Pete >>=20 >> On Thu, Aug 25, 2011 at 1:44 PM, Julien = Laganier wrote: >>> Charlie, >>>=20 >>> I am not sure I understand what is missing in MIPv6; a MN and an HA >>> can already mutually authenticate using EAP, and this is = incidentally >>> what 3GPP leverages on, together with the EAP-AKA method. What is >>> missing? >>>=20 >>> --julien >>>=20 >>> On Wed, Aug 24, 2011 at 12:06 PM, Charles E. Perkins >>> wrote: >>>>=20 >>>> Hello folks, >>>>=20 >>>> It's now 2011. Mobile IP was standardized late in >>>> 1996, after work had already been started nearly >>>> ten years before. Over two decades! -- and regardless >>>> of lip service to fixed/mobile convergence we still >>>> don't have seamless mobility in user devices across >>>> heterogeneous media, and standards organizations >>>> (notably 3GPP) are not properly taking advantage of >>>> what Mobile IP can do. The losers are the end-users, >>>> which means all of us. >>>>=20 >>>> There are many reasons for this, but one of the >>>> main reasons has to do with authentication at the >>>> access network. EAP in various forms is being >>>> utilized for this purpose, and Mobile IP is not, >>>> even though there has never been any reported >>>> failure of the RFC 5944 or RFC 4285 or RFC 6275 >>>> (to my knowledge). Moreover, unless there is >>>> something wrong with the cryptography that also >>>> has not been reported, these authentication methods >>>> enable _mutual_ authentication between the network >>>> and the client, not just client authentication. >>>>=20 >>>> In order for Mobile IP to enable the real promise >>>> of high performance heterogeneous networking, we >>>> have to do some more work. I would like to initiate >>>> some more discussion about this. DMM is interesting >>>> in its own right, but it's not at all the whole >>>> story. Moreover, with proper design, it is likely >>>> the supposed burden of signaling to the home agent >>>> can be substantially reduced. As one simple example, >>>> if handovers are accomplished locally between trusted >>>> access agents (routers, 802.11 access controllers, ...) >>>> then the actual timing of tunnel redirection from the >>>> home agent becomes much less critical. This is also >>>> intricately intertwined with authentication. >>>>=20 >>>> If the Home Agent were recognized as a robust security >>>> appliance, then it could naturally sit on the network >>>> boundary as an IP-addressable device. Mobile IP >>>> authentication could become the primary means of >>>> validating user access, instead of an afterthought >>>> to enable IP-address preservation after all the heavy >>>> lifting has been done a lower levels. >>>>=20 >>>> I would like to propose that in this working group we >>>> should go about making this happen. It seems to be >>>> important, and undeniably aligned with our working >>>> group responsibilities. >>>>=20 >>>> Regards, >>>> Charlie P. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>>=20 >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>>=20 >>=20 >=20 > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From mccap@petoni.org Thu Aug 25 12:54:59 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C9B21F8B79 for ; Thu, 25 Aug 2011 12:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DvdItEbCYbG for ; Thu, 25 Aug 2011 12:54:58 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2287021F8C50 for ; Thu, 25 Aug 2011 12:54:57 -0700 (PDT) Received: by fxe6 with SMTP id 6so2235716fxe.31 for ; Thu, 25 Aug 2011 12:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petoni.org; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LZ78KwZ9uozE6SmrUnY/DPkYwVwD76hLRdgr0uRQYsM=; b=Ag5Rod2/2pfAx9bRY671f93IIyk3Mg7RCWEhFgNvbOtkrph2Y3pZ3T1hGrhfJr97DE bGluZjfFqn6HdqqerHTUIswembu/ycJqo4BcBNxU8oEZXWGsM7n/IDDhWHq4d1jK4rWP QAuGLcMDlemJl4Fgtm8m9eLMF66kVXHLvddOk= MIME-Version: 1.0 Received: by 10.223.35.210 with SMTP id q18mr179384fad.148.1314302083701; Thu, 25 Aug 2011 12:54:43 -0700 (PDT) Received: by 10.223.144.143 with HTTP; Thu, 25 Aug 2011 12:54:43 -0700 (PDT) X-Originating-IP: [4.28.5.163] In-Reply-To: <4E56A052.1000604@computer.org> References: <4E554BAA.9080409@computer.org> <4E56A052.1000604@computer.org> Date: Thu, 25 Aug 2011 15:54:43 -0400 Message-ID: From: Pete McCann To: charliep@computer.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 19:54:59 -0000 Hi, Charlie, The problem seems to be we have the following three steps that have to be carried out in order: 1) access authentication 2) address assignment 3) mobility management (3) depends on (2) because you can't bind your home address to a care-of address until you have a care-of address. (2) depends on (1) because operators don't like to give out resources until they know they will get paid. It's possible to combine all these things into one protocol (perhaps PANA could have been that vehicle, if certain decisions had not been made) but the IETF seems to like breaking problems down into layered solutions. -Pete On Thu, Aug 25, 2011 at 3:19 PM, Charles E. Perkins wrote: > Hello Pete, > > Yes, putting Mobile IP inside of EAP would be one approach. > It would have some interesting advantages. =A0Other approaches > might be more properly done in [netext] -- or perhaps have > already been looked; I could have possibly missed some of > the relevant discussion there. > > Regards, > Charlie P. > > > > On 8/25/2011 11:40 AM, Pete McCann wrote: >> >> Hi, Julien, >> >> Are you talking about EAP inside IKEv2? =A0That presupposes that the MN >> is already attached to the network somewhere and has an IP address (i.e.= , >> it has already passed access authentication). >> >> It may be interesting to look at whether access authentication and >> mobility >> management can be combined. =A0For example, we could put Mobile IP (or >> some variant of it) inside an EAP exchange used for access authenticatio= n. >> Charlie, are you proposing something like this? >> >> -Pete >> >> On Thu, Aug 25, 2011 at 1:44 PM, Julien Laganier >> =A0wrote: >>> >>> Charlie, >>> >>> I am not sure I understand what is missing in MIPv6; a MN and an HA >>> can already mutually authenticate using EAP, and this is incidentally >>> what 3GPP leverages on, together with the EAP-AKA method. What is >>> missing? >>> >>> --julien >>> >>> On Wed, Aug 24, 2011 at 12:06 PM, Charles E. Perkins >>> =A0wrote: >>>> >>>> Hello folks, >>>> >>>> It's now 2011. =A0Mobile IP was standardized late in >>>> 1996, after work had already been started nearly >>>> ten years before. =A0Over two decades! -- and regardless >>>> of lip service to fixed/mobile convergence we still >>>> don't have seamless mobility in user devices across >>>> heterogeneous media, and standards organizations >>>> (notably 3GPP) are not properly taking advantage of >>>> what Mobile IP can do. The losers are the end-users, >>>> which means all of us. >>>> >>>> There are many reasons for this, but one of the >>>> main reasons has to do with authentication at the >>>> access network. =A0EAP in various forms is being >>>> utilized for this purpose, and Mobile IP is not, >>>> even though there has never been any reported >>>> failure of the RFC 5944 or RFC 4285 or RFC 6275 >>>> (to my knowledge). =A0Moreover, unless there is >>>> something wrong with the cryptography that also >>>> has not been reported, these authentication methods >>>> enable _mutual_ authentication between the network >>>> and the client, not just client authentication. >>>> >>>> In order for Mobile IP to enable the real promise >>>> of high performance heterogeneous networking, we >>>> have to do some more work. =A0I would like to initiate >>>> some more discussion about this. =A0DMM is interesting >>>> in its own right, but it's not at all the whole >>>> story. =A0Moreover, with proper design, it is likely >>>> the supposed burden of signaling to the home agent >>>> can be substantially reduced. =A0As one simple example, >>>> if handovers are accomplished locally between trusted >>>> access agents (routers, 802.11 access controllers, ...) >>>> then the actual timing of tunnel redirection from the >>>> home agent becomes much less critical. =A0This is also >>>> intricately intertwined with authentication. >>>> >>>> If the Home Agent were recognized as a robust security >>>> appliance, then it could naturally sit on the network >>>> boundary as an IP-addressable device. =A0Mobile IP >>>> authentication could become the primary means of >>>> validating user access, instead of an afterthought >>>> to enable IP-address preservation after all the heavy >>>> lifting has been done a lower levels. >>>> >>>> I would like to propose that in this working group we >>>> should go about making this happen. =A0It seems to be >>>> important, and undeniably aligned with our working >>>> group responsibilities. >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> > > From Basavaraj.Patil@nokia.com Thu Aug 25 13:04:41 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EA021F8C75 for ; Thu, 25 Aug 2011 13:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.636 X-Spam-Level: X-Spam-Status: No, score=-102.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi2K3ZIJeT9Q for ; Thu, 25 Aug 2011 13:04:40 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 52D7421F8C37 for ; Thu, 25 Aug 2011 13:04:40 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7PK5ih3015367; Thu, 25 Aug 2011 23:05:44 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Aug 2011 23:05:39 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 25 Aug 2011 22:05:39 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0323.007; Thu, 25 Aug 2011 22:05:39 +0200 From: To: , Thread-Topic: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks Thread-Index: AQHMY1wFXQKtm0ixAkGph0+eSVzEr5Ut2WuA//+vPIA= Date: Thu, 25 Aug 2011 20:05:38 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [172.19.59.133] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0E87267F493C724A817FD6813B3ACC57@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Aug 2011 20:05:39.0803 (UTC) FILETIME=[5C93B2B0:01CC6362] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 20:04:41 -0000 That=B9s a good summarization Pete. But we do multiple authentications today. We do access authentication (1) and then we have to authenticate with the HA yet again in (3). That could be optimized. -Raj On 8/25/11 2:54 PM, "ext Pete McCann" wrote: >Hi, Charlie, > >The problem seems to be we have the following three steps that have >to be carried out in order: > >1) access authentication >2) address assignment >3) mobility management > >(3) depends on (2) because you can't bind your home address to a >care-of address until you have a care-of address. (2) depends on (1) >because operators don't like to give out resources until they know they >will get paid. > >It's possible to combine all these things into one protocol (perhaps PANA >could have been that vehicle, if certain decisions had not been made) but >the IETF seems to like breaking problems down into layered solutions. > >-Pete > >On Thu, Aug 25, 2011 at 3:19 PM, Charles E. Perkins > wrote: >> Hello Pete, >> >> Yes, putting Mobile IP inside of EAP would be one approach. >> It would have some interesting advantages. Other approaches >> might be more properly done in [netext] -- or perhaps have >> already been looked; I could have possibly missed some of >> the relevant discussion there. >> >> Regards, >> Charlie P. >> >> >> >> On 8/25/2011 11:40 AM, Pete McCann wrote: >>> >>> Hi, Julien, >>> >>> Are you talking about EAP inside IKEv2? That presupposes that the MN >>> is already attached to the network somewhere and has an IP address >>>(i.e., >>> it has already passed access authentication). >>> >>> It may be interesting to look at whether access authentication and >>> mobility >>> management can be combined. For example, we could put Mobile IP (or >>> some variant of it) inside an EAP exchange used for access >>>authentication. >>> Charlie, are you proposing something like this? >>> >>> -Pete >>> >>> On Thu, Aug 25, 2011 at 1:44 PM, Julien Laganier >>> wrote: >>>> >>>> Charlie, >>>> >>>> I am not sure I understand what is missing in MIPv6; a MN and an HA >>>> can already mutually authenticate using EAP, and this is incidentally >>>> what 3GPP leverages on, together with the EAP-AKA method. What is >>>> missing? >>>> >>>> --julien >>>> >>>> On Wed, Aug 24, 2011 at 12:06 PM, Charles E. Perkins >>>> wrote: >>>>> >>>>> Hello folks, >>>>> >>>>> It's now 2011. Mobile IP was standardized late in >>>>> 1996, after work had already been started nearly >>>>> ten years before. Over two decades! -- and regardless >>>>> of lip service to fixed/mobile convergence we still >>>>> don't have seamless mobility in user devices across >>>>> heterogeneous media, and standards organizations >>>>> (notably 3GPP) are not properly taking advantage of >>>>> what Mobile IP can do. The losers are the end-users, >>>>> which means all of us. >>>>> >>>>> There are many reasons for this, but one of the >>>>> main reasons has to do with authentication at the >>>>> access network. EAP in various forms is being >>>>> utilized for this purpose, and Mobile IP is not, >>>>> even though there has never been any reported >>>>> failure of the RFC 5944 or RFC 4285 or RFC 6275 >>>>> (to my knowledge). Moreover, unless there is >>>>> something wrong with the cryptography that also >>>>> has not been reported, these authentication methods >>>>> enable _mutual_ authentication between the network >>>>> and the client, not just client authentication. >>>>> >>>>> In order for Mobile IP to enable the real promise >>>>> of high performance heterogeneous networking, we >>>>> have to do some more work. I would like to initiate >>>>> some more discussion about this. DMM is interesting >>>>> in its own right, but it's not at all the whole >>>>> story. Moreover, with proper design, it is likely >>>>> the supposed burden of signaling to the home agent >>>>> can be substantially reduced. As one simple example, >>>>> if handovers are accomplished locally between trusted >>>>> access agents (routers, 802.11 access controllers, ...) >>>>> then the actual timing of tunnel redirection from the >>>>> home agent becomes much less critical. This is also >>>>> intricately intertwined with authentication. >>>>> >>>>> If the Home Agent were recognized as a robust security >>>>> appliance, then it could naturally sit on the network >>>>> boundary as an IP-addressable device. Mobile IP >>>>> authentication could become the primary means of >>>>> validating user access, instead of an afterthought >>>>> to enable IP-address preservation after all the heavy >>>>> lifting has been done a lower levels. >>>>> >>>>> I would like to propose that in this working group we >>>>> should go about making this happen. It seems to be >>>>> important, and undeniably aligned with our working >>>>> group responsibilities. >>>>> >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> >> >> >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext From mccap@petoni.org Thu Aug 25 13:14:32 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C7F21F8828 for ; Thu, 25 Aug 2011 13:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EV8eANcUyylR for ; Thu, 25 Aug 2011 13:14:30 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 63ACE21F8804 for ; Thu, 25 Aug 2011 13:14:26 -0700 (PDT) Received: by fxe6 with SMTP id 6so2248025fxe.31 for ; Thu, 25 Aug 2011 13:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petoni.org; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=R7XIJEDgyELrAdiSt+JYhhuBJbzhL5N58gVfjg9kDeU=; b=T/eA1pOOx7QT1vgf2Z0uEcYsvGUsG0eMPeh+0MquH95R/MmEMv1vcytVxYrH4Y1ZXm d4GDb77t9fZvoMztJ7OeAQVSOE7a52+kzvjFSoeZitH4ctSXVQCSlEyw+j5I78qKbaQZ v1Bn5KpUbIGmy/O/LWXZ3zuEBDmOz2XjV+6as= MIME-Version: 1.0 Received: by 10.223.91.147 with SMTP id n19mr260018fam.53.1314303339020; Thu, 25 Aug 2011 13:15:39 -0700 (PDT) Received: by 10.223.144.143 with HTTP; Thu, 25 Aug 2011 13:15:38 -0700 (PDT) X-Originating-IP: [4.28.5.163] In-Reply-To: References: Date: Thu, 25 Aug 2011 16:15:38 -0400 Message-ID: From: Pete McCann To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 20:14:32 -0000 On Thu, Aug 25, 2011 at 4:05 PM, wrote: > > That=B9s a good summarization Pete. > But we do multiple authentications today. > We do access authentication (1) and then we have to authenticate with the > HA yet again in (3). > That could be optimized. Indeed. It should be possible to borrow some keying material from (1) to create an SA with an HA. And you wouldn't necessarily use that SA until you moved away from the initial point of attachment. -Pete From charliep@computer.org Thu Aug 25 13:22:38 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BDA21F8B79 for ; Thu, 25 Aug 2011 13:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtWOSo+pc8e9 for ; Thu, 25 Aug 2011 13:22:37 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 173A621F8B76 for ; Thu, 25 Aug 2011 13:22:37 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.96.89]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1QwgSq-0005n4-B0; Thu, 25 Aug 2011 16:23:48 -0400 Message-ID: <4E56AF52.3070306@computer.org> Date: Thu, 25 Aug 2011 13:23:46 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Pete McCann , Alper Yegin References: <4E554BAA.9080409@computer.org><4E56A052.1000604@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86ecb476500cdd476d5055a9ae9a07b1a4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: mext Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 20:22:38 -0000 Hello Pete, Your analysis of operator concerns is quite correct, it seems to me, but on the other hand maybe the IETF would be able to alleviate operator concerns once they are properly understood. And, if operators could be assured that they would suffer no harm by following some revised IETF protocol steps, there would be a good chance for progress. Address assignment is perhaps the stickiest case. Here are some observations: - The UE doesn't necessarily have to know its care-of address until after handover is complete (and, according to [netext], not even then) - The access network does not have to complete the assignment of the care-of address until it has verified the authentication - As mentioned before, the home agent is a viable candidate for AAA relay, actually appearing as the AAA server to the access network - An IPv6 address can't really be considered a valuable resource if it isn't routable, and so even if UE knew its IPv6 care-of address, it would not get any benefit until authentication completes. If there is any disagreement about these points, I would be surprised, but every day brings new surprises. I am proposing that we should try to make a higher-performance handover specification that is less complicated than, say, S101/S102/S103. Almost anything the IETF could possibly do would be less complicated than those, and I fully expect much easier to configure, administer, and operate. So, the problem statement could be: Enable Mobile IP to provide high-performance mobility management that is better able to be deployed in modern wireless access networks that already utilize alternate access authentication protocols. Determine the suitability of network-based versus client-based variations of the candidate solutions. Regards, Charlie P. On 8/25/2011 12:54 PM, Pete McCann wrote: > Hi, Charlie, > > The problem seems to be we have the following three steps that have > to be carried out in order: > > 1) access authentication > 2) address assignment > 3) mobility management > > (3) depends on (2) because you can't bind your home address to a > care-of address until you have a care-of address. (2) depends on (1) > because operators don't like to give out resources until they know they > will get paid. > > It's possible to combine all these things into one protocol (perhaps PANA > could have been that vehicle, if certain decisions had not been made) but > the IETF seems to like breaking problems down into layered solutions. > > -Pete > > On Thu, Aug 25, 2011 at 3:19 PM, Charles E. Perkins > wrote: >> Hello Pete, >> >> Yes, putting Mobile IP inside of EAP would be one approach. >> It would have some interesting advantages. Other approaches >> might be more properly done in [netext] -- or perhaps have >> already been looked; I could have possibly missed some of >> the relevant discussion there. >> >> Regards, >> Charlie P. >> >> >> >> On 8/25/2011 11:40 AM, Pete McCann wrote: >>> >>> Hi, Julien, >>> >>> Are you talking about EAP inside IKEv2? That presupposes that the MN >>> is already attached to the network somewhere and has an IP address (i.e., >>> it has already passed access authentication). >>> >>> It may be interesting to look at whether access authentication and >>> mobility >>> management can be combined. For example, we could put Mobile IP (or >>> some variant of it) inside an EAP exchange used for access authentication. >>> Charlie, are you proposing something like this? >>> >>> -Pete >>> >>> On Thu, Aug 25, 2011 at 1:44 PM, Julien Laganier >>> wrote: >>>> >>>> Charlie, >>>> >>>> I am not sure I understand what is missing in MIPv6; a MN and an HA >>>> can already mutually authenticate using EAP, and this is incidentally >>>> what 3GPP leverages on, together with the EAP-AKA method. What is >>>> missing? >>>> >>>> --julien >>>> >>>> On Wed, Aug 24, 2011 at 12:06 PM, Charles E. Perkins >>>> wrote: >>>>> >>>>> Hello folks, >>>>> >>>>> It's now 2011. Mobile IP was standardized late in >>>>> 1996, after work had already been started nearly >>>>> ten years before. Over two decades! -- and regardless >>>>> of lip service to fixed/mobile convergence we still >>>>> don't have seamless mobility in user devices across >>>>> heterogeneous media, and standards organizations >>>>> (notably 3GPP) are not properly taking advantage of >>>>> what Mobile IP can do. The losers are the end-users, >>>>> which means all of us. >>>>> >>>>> There are many reasons for this, but one of the >>>>> main reasons has to do with authentication at the >>>>> access network. EAP in various forms is being >>>>> utilized for this purpose, and Mobile IP is not, >>>>> even though there has never been any reported >>>>> failure of the RFC 5944 or RFC 4285 or RFC 6275 >>>>> (to my knowledge). Moreover, unless there is >>>>> something wrong with the cryptography that also >>>>> has not been reported, these authentication methods >>>>> enable _mutual_ authentication between the network >>>>> and the client, not just client authentication. >>>>> >>>>> In order for Mobile IP to enable the real promise >>>>> of high performance heterogeneous networking, we >>>>> have to do some more work. I would like to initiate >>>>> some more discussion about this. DMM is interesting >>>>> in its own right, but it's not at all the whole >>>>> story. Moreover, with proper design, it is likely >>>>> the supposed burden of signaling to the home agent >>>>> can be substantially reduced. As one simple example, >>>>> if handovers are accomplished locally between trusted >>>>> access agents (routers, 802.11 access controllers, ...) >>>>> then the actual timing of tunnel redirection from the >>>>> home agent becomes much less critical. This is also >>>>> intricately intertwined with authentication. >>>>> >>>>> If the Home Agent were recognized as a robust security >>>>> appliance, then it could naturally sit on the network >>>>> boundary as an IP-addressable device. Mobile IP >>>>> authentication could become the primary means of >>>>> validating user access, instead of an afterthought >>>>> to enable IP-address preservation after all the heavy >>>>> lifting has been done a lower levels. >>>>> >>>>> I would like to propose that in this working group we >>>>> should go about making this happen. It seems to be >>>>> important, and undeniably aligned with our working >>>>> group responsibilities. >>>>> >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> >> >> > From jong-hyouk.lee@inria.fr Thu Aug 25 13:22:45 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9C621F8B85 for ; Thu, 25 Aug 2011 13:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.148 X-Spam-Level: X-Spam-Status: No, score=-9.148 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45OgyoJXyxuT for ; Thu, 25 Aug 2011 13:22:44 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9518E21F8B79 for ; Thu, 25 Aug 2011 13:22:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,282,1312149600"; d="scan'208";a="106648999" Received: from mail-vx0-f172.google.com ([209.85.220.172]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 25 Aug 2011 22:23:55 +0200 Received: by vxi29 with SMTP id 29so2524294vxi.31 for ; Thu, 25 Aug 2011 13:23:54 -0700 (PDT) Received: by 10.52.26.97 with SMTP id k1mr227872vdg.523.1314303834440; Thu, 25 Aug 2011 13:23:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.101.134 with HTTP; Thu, 25 Aug 2011 13:23:33 -0700 (PDT) In-Reply-To: References: From: Jong-Hyouk Lee Date: Thu, 25 Aug 2011 22:23:33 +0200 Message-ID: To: Basavaraj.Patil@nokia.com Content-Type: multipart/alternative; boundary=20cf307f33ec2dc3ec04ab5a3505 Cc: charliep@computer.org, mccap@petoni.org, mext@ietf.org Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 20:22:45 -0000 --20cf307f33ec2dc3ec04ab5a3505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable authentication for access network and authentication for binding update are different. On Thu, Aug 25, 2011 at 10:05 PM, wrote: > > That=C2=B9s a good summarization Pete. > But we do multiple authentications today. > We do access authentication (1) and then we have to authenticate with the > HA yet again in (3). > That could be optimized. > > -Raj > > > On 8/25/11 2:54 PM, "ext Pete McCann" wrote: > > >Hi, Charlie, > > > >The problem seems to be we have the following three steps that have > >to be carried out in order: > > > >1) access authentication > >2) address assignment > >3) mobility management > > > >(3) depends on (2) because you can't bind your home address to a > >care-of address until you have a care-of address. (2) depends on (1) > >because operators don't like to give out resources until they know they > >will get paid. > > > >It's possible to combine all these things into one protocol (perhaps PAN= A > >could have been that vehicle, if certain decisions had not been made) bu= t > >the IETF seems to like breaking problems down into layered solutions. > > > >-Pete > > > >On Thu, Aug 25, 2011 at 3:19 PM, Charles E. Perkins > > wrote: > >> Hello Pete, > >> > >> Yes, putting Mobile IP inside of EAP would be one approach. > >> It would have some interesting advantages. Other approaches > >> might be more properly done in [netext] -- or perhaps have > >> already been looked; I could have possibly missed some of > >> the relevant discussion there. > >> > >> Regards, > >> Charlie P. > >> > >> > >> > >> On 8/25/2011 11:40 AM, Pete McCann wrote: > >>> > >>> Hi, Julien, > >>> > >>> Are you talking about EAP inside IKEv2? That presupposes that the MN > >>> is already attached to the network somewhere and has an IP address > >>>(i.e., > >>> it has already passed access authentication). > >>> > >>> It may be interesting to look at whether access authentication and > >>> mobility > >>> management can be combined. For example, we could put Mobile IP (or > >>> some variant of it) inside an EAP exchange used for access > >>>authentication. > >>> Charlie, are you proposing something like this? > >>> > >>> -Pete > >>> > >>> On Thu, Aug 25, 2011 at 1:44 PM, Julien Laganier > > >>> wrote: > >>>> > >>>> Charlie, > >>>> > >>>> I am not sure I understand what is missing in MIPv6; a MN and an HA > >>>> can already mutually authenticate using EAP, and this is incidentall= y > >>>> what 3GPP leverages on, together with the EAP-AKA method. What is > >>>> missing? > >>>> > >>>> --julien > >>>> > >>>> On Wed, Aug 24, 2011 at 12:06 PM, Charles E. Perkins > >>>> wrote: > >>>>> > >>>>> Hello folks, > >>>>> > >>>>> It's now 2011. Mobile IP was standardized late in > >>>>> 1996, after work had already been started nearly > >>>>> ten years before. Over two decades! -- and regardless > >>>>> of lip service to fixed/mobile convergence we still > >>>>> don't have seamless mobility in user devices across > >>>>> heterogeneous media, and standards organizations > >>>>> (notably 3GPP) are not properly taking advantage of > >>>>> what Mobile IP can do. The losers are the end-users, > >>>>> which means all of us. > >>>>> > >>>>> There are many reasons for this, but one of the > >>>>> main reasons has to do with authentication at the > >>>>> access network. EAP in various forms is being > >>>>> utilized for this purpose, and Mobile IP is not, > >>>>> even though there has never been any reported > >>>>> failure of the RFC 5944 or RFC 4285 or RFC 6275 > >>>>> (to my knowledge). Moreover, unless there is > >>>>> something wrong with the cryptography that also > >>>>> has not been reported, these authentication methods > >>>>> enable _mutual_ authentication between the network > >>>>> and the client, not just client authentication. > >>>>> > >>>>> In order for Mobile IP to enable the real promise > >>>>> of high performance heterogeneous networking, we > >>>>> have to do some more work. I would like to initiate > >>>>> some more discussion about this. DMM is interesting > >>>>> in its own right, but it's not at all the whole > >>>>> story. Moreover, with proper design, it is likely > >>>>> the supposed burden of signaling to the home agent > >>>>> can be substantially reduced. As one simple example, > >>>>> if handovers are accomplished locally between trusted > >>>>> access agents (routers, 802.11 access controllers, ...) > >>>>> then the actual timing of tunnel redirection from the > >>>>> home agent becomes much less critical. This is also > >>>>> intricately intertwined with authentication. > >>>>> > >>>>> If the Home Agent were recognized as a robust security > >>>>> appliance, then it could naturally sit on the network > >>>>> boundary as an IP-addressable device. Mobile IP > >>>>> authentication could become the primary means of > >>>>> validating user access, instead of an afterthought > >>>>> to enable IP-address preservation after all the heavy > >>>>> lifting has been done a lower levels. > >>>>> > >>>>> I would like to propose that in this working group we > >>>>> should go about making this happen. It seems to be > >>>>> important, and undeniably aligned with our working > >>>>> group responsibilities. > >>>>> > >>>>> Regards, > >>>>> Charlie P. > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> MEXT mailing list > >>>>> MEXT@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mext > >>>>> > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >>>> > >>> > >> > >> > >_______________________________________________ > >MEXT mailing list > >MEXT@ietf.org > >https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > --=20 IMARA Team, INRIA, France. Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random. #email: hurryon (at) gmail (dot) com || jong-hyouk.lee (at) inria (dot) fr #webpage: https://sites.google.com/site/hurryon/ --20cf307f33ec2dc3ec04ab5a3505 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable authentication for access network and authentication for binding update are= different.

On Thu, Aug 25, 2011 at 10:05= PM, <Ba= savaraj.Patil@nokia.com> wrote:

That=C2=B9s a good summarization Pete.
But we do multiple authentications today.
We do access authentication (1) and then we have to authenticate with the HA yet again in (3).
That could be optimized.

-Raj


On 8/25/11 2:54 PM, "ext Pete McCann" <mccap@petoni.org> wrote:

>Hi, Charlie,
>
>The problem seems to be we have the following three steps that have
>to be carried out in order:
>
>1) access authentication
>2) address assignment
>3) mobility management
>
>(3) depends on (2) because you can't bind your home address to a >care-of address until you have a care-of address. =C2=A0(2) depends on = (1)
>because operators don't like to give out resources until they know = they
>will get paid.
>
>It's possible to combine all these things into one protocol (perhap= s PANA
>could have been that vehicle, if certain decisions had not been made) b= ut
>the IETF seems to like breaking problems down into layered solutions. >
>-Pete
>
>On Thu, Aug 25, 2011 at 3:19 PM, Charles E. Perkins
><charliep@computer.org&= gt; wrote:
>> Hello Pete,
>>
>> Yes, putting Mobile IP inside of EAP would be one approach.
>> It would have some interesting advantages. =C2=A0Other approaches<= br> >> might be more properly done in [netext] -- or perhaps have
>> already been looked; I could have possibly missed some of
>> the relevant discussion there.
>>
>> Regards,
>> Charlie P.
>>
>>
>>
>> On 8/25/2011 11:40 AM, Pete McCann wrote:
>>>
>>> Hi, Julien,
>>>
>>> Are you talking about EAP inside IKEv2? =C2=A0That presupposes= that the MN
>>> is already attached to the network somewhere and has an IP add= ress
>>>(i.e.,
>>> it has already passed access authentication).
>>>
>>> It may be interesting to look at whether access authentication= and
>>> mobility
>>> management can be combined. =C2=A0For example, we could put Mo= bile IP (or
>>> some variant of it) inside an EAP exchange used for access
>>>authentication.
>>> Charlie, are you proposing something like this?
>>>
>>> -Pete
>>>
>>> On Thu, Aug 25, 2011 at 1:44 PM, Julien Laganier<julien.ietf@gmail.com>
>>> =C2=A0wrote:
>>>>
>>>> Charlie,
>>>>
>>>> I am not sure I understand what is missing in MIPv6; a MN = and an HA
>>>> can already mutually authenticate using EAP, and this is i= ncidentally
>>>> what 3GPP leverages on, together with the EAP-AKA method. = What is
>>>> missing?
>>>>
>>>> --julien
>>>>
>>>> On Wed, Aug 24, 2011 at 12:06 PM, Charles E. Perkins
>>>> <charliep@comp= uter.org> =C2=A0wrote:
>>>>>
>>>>> Hello folks,
>>>>>
>>>>> It's now 2011. =C2=A0Mobile IP was standardized la= te in
>>>>> 1996, after work had already been started nearly
>>>>> ten years before. =C2=A0Over two decades! -- and regar= dless
>>>>> of lip service to fixed/mobile convergence we still >>>>> don't have seamless mobility in user devices acros= s
>>>>> heterogeneous media, and standards organizations
>>>>> (notably 3GPP) are not properly taking advantage of >>>>> what Mobile IP can do. The losers are the end-users, >>>>> which means all of us.
>>>>>
>>>>> There are many reasons for this, but one of the
>>>>> main reasons has to do with authentication at the
>>>>> access network. =C2=A0EAP in various forms is being >>>>> utilized for this purpose, and Mobile IP is not,
>>>>> even though there has never been any reported
>>>>> failure of the RFC 5944 or RFC 4285 or RFC 6275
>>>>> (to my knowledge). =C2=A0Moreover, unless there is
>>>>> something wrong with the cryptography that also
>>>>> has not been reported, these authentication methods >>>>> enable _mutual_ authentication between the network
>>>>> and the client, not just client authentication.
>>>>>
>>>>> In order for Mobile IP to enable the real promise
>>>>> of high performance heterogeneous networking, we
>>>>> have to do some more work. =C2=A0I would like to initi= ate
>>>>> some more discussion about this. =C2=A0DMM is interest= ing
>>>>> in its own right, but it's not at all the whole >>>>> story. =C2=A0Moreover, with proper design, it is likel= y
>>>>> the supposed burden of signaling to the home agent
>>>>> can be substantially reduced. =C2=A0As one simple exam= ple,
>>>>> if handovers are accomplished locally between trusted<= br> >>>>> access agents (routers, 802.11 access controllers, ...= )
>>>>> then the actual timing of tunnel redirection from the<= br> >>>>> home agent becomes much less critical. =C2=A0This is a= lso
>>>>> intricately intertwined with authentication.
>>>>>
>>>>> If the Home Agent were recognized as a robust security=
>>>>> appliance, then it could naturally sit on the network<= br> >>>>> boundary as an IP-addressable device. =C2=A0Mobile IP<= br> >>>>> authentication could become the primary means of
>>>>> validating user access, instead of an afterthought
>>>>> to enable IP-address preservation after all the heavy<= br> >>>>> lifting has been done a lower levels.
>>>>>
>>>>> I would like to propose that in this working group we<= br> >>>>> should go about making this happen. =C2=A0It seems to = be
>>>>> important, and undeniably aligned with our working
>>>>> group responsibilities.
>>>>>
>>>>> Regards,
>>>>> Charlie P.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> MEXT mailing list
>>>>> MEXT@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>
>>>> _______________________________________________
>>>> MEXT mailing list
>>>> MEXT@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>
>>>
>>
>>
>_______________________________________________
>MEXT mailing list
>MEXT@ietf.org
>https://www.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
MEXT@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mext



--
= IMARA Team, INRIA, France.
Jong-Hyouk Lee, living somewhere between /de= v/null and /dev/random.

#email: hurryon (at) gmail (dot) com || jong= -hyouk.lee (at) inria (dot) fr
#webpage: https://sites.google.com/site/hurryon/
--20cf307f33ec2dc3ec04ab5a3505-- From Basavaraj.Patil@nokia.com Thu Aug 25 13:23:52 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BFB21F8B91 for ; Thu, 25 Aug 2011 13:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.258 X-Spam-Level: X-Spam-Status: No, score=-102.258 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhUaJMb5cvpF for ; Thu, 25 Aug 2011 13:23:52 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2EA21F8B98 for ; Thu, 25 Aug 2011 13:23:52 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7PKP1wf002139; Thu, 25 Aug 2011 23:25:03 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Aug 2011 23:25:01 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 25 Aug 2011 22:25:00 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0323.007; Thu, 25 Aug 2011 22:25:00 +0200 From: To: Thread-Topic: [MEXT] Re: Well-known problem with authentication/etc. in wireless networks Thread-Index: AQHMY2UPlm/DFKHyiU6WsMTtllzSHQ== Date: Thu, 25 Aug 2011 20:24:59 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [172.19.59.133] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 25 Aug 2011 20:25:01.0011 (UTC) FILETIME=[10B5FA30:01CC6365] X-Nokia-AV: Clean Cc: charliep@computer.org, mext@ietf.org Subject: Re: [MEXT] Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 20:23:53 -0000 DQpPbiA4LzI1LzExIDM6MTUgUE0sICJleHQgUGV0ZSBNY0Nhbm4iIDxtY2NhcEBwZXRvbmkub3Jn PiB3cm90ZToNCg0KPk9uIFRodSwgQXVnIDI1LCAyMDExIGF0IDQ6MDUgUE0sICA8QmFzYXZhcmFq LlBhdGlsQG5va2lhLmNvbT4gd3JvdGU6DQo+Pg0KPj4gVGhhdKn2cyBhIGdvb2Qgc3VtbWFyaXph dGlvbiBQZXRlLg0KPj4gQnV0IHdlIGRvIG11bHRpcGxlIGF1dGhlbnRpY2F0aW9ucyB0b2RheS4N Cj4+IFdlIGRvIGFjY2VzcyBhdXRoZW50aWNhdGlvbiAoMSkgYW5kIHRoZW4gd2UgaGF2ZSB0byBh dXRoZW50aWNhdGUgd2l0aA0KPj50aGUNCj4+IEhBIHlldCBhZ2FpbiBpbiAoMykuDQo+PiBUaGF0 IGNvdWxkIGJlIG9wdGltaXplZC4NCj4NCj5JbmRlZWQuICBJdCBzaG91bGQgYmUgcG9zc2libGUg dG8gYm9ycm93IHNvbWUga2V5aW5nIG1hdGVyaWFsIGZyb20gKDEpDQo+dG8gY3JlYXRlIGFuIFNB IHdpdGggYW4gSEEuICBBbmQgeW91IHdvdWxkbid0IG5lY2Vzc2FyaWx5IHVzZSB0aGF0IFNBDQo+ dW50aWwgeW91IG1vdmVkIGF3YXkgZnJvbSB0aGUgaW5pdGlhbCBwb2ludCBvZiBhdHRhY2htZW50 Lg0KPg0KPi1QZXRlDQoNCkkgZG9uoa90IGtub3cgQ2hhcmxpZSdzIHRob3VnaHRzIHJlZ2FyZGlu ZyBFQVAuDQpCdXQgaWYgRUFQIGlzIHVzZWQgaW4gYWNjZXNzIGF1dGhlbnRpY2F0aW9uLCB0aGVu IGl0IGNvdWxkIHBvdGVudGlhbGx5DQpwcm92aWRlIGtleWluZyBhbmQgYm9vdHN0cmFwcGluZyBt YXRlcmlhbCB0byB0aGUgTU4gZHVyaW5nIHRoZSBhY2Nlc3MNCmF1dGhlbnRpY2F0aW9uIHBoYXNl LiBUaGUgU0Egd2l0aCB0aGUgYXNzaWduZWQgSEEgaXMgdGhlbiBzZXR1cCB1c2luZyB0aGF0DQpr ZXlpbmcgbWF0ZXJpYWwuDQoNCi1SYWoNCg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+TUVYVCBtYWlsaW5nIGxpc3QNCj5NRVhUQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tZXh0DQoNCg== From Basavaraj.Patil@nokia.com Thu Aug 25 13:28:54 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7249821F8B91 for ; Thu, 25 Aug 2011 13:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.745 X-Spam-Level: X-Spam-Status: No, score=-101.745 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QBkZ7wEWbxx for ; Thu, 25 Aug 2011 13:28:53 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF3021F8B1D for ; Thu, 25 Aug 2011 13:28:53 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7PKTxmA021316; Thu, 25 Aug 2011 23:30:02 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Aug 2011 23:29:54 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 25 Aug 2011 22:29:54 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0323.007; Thu, 25 Aug 2011 22:29:42 +0200 From: To: Thread-Topic: [MEXT] Re: Well-known problem with authentication/etc. in wireless networks Thread-Index: AQHMY2W45hW7KiJOCEGei652kiXmbQ== Date: Thu, 25 Aug 2011 20:29:41 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [172.19.59.133] Content-Type: multipart/alternative; boundary="_000_CA7C1A7DF9ECbasavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Aug 2011 20:29:54.0399 (UTC) FILETIME=[BF956EF0:01CC6365] X-Nokia-AV: Clean Cc: charliep@computer.org, mccap@petoni.org, mext@ietf.org Subject: Re: [MEXT] Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 20:28:54 -0000 --_000_CA7C1A7DF9ECbasavarajpatilnokiacom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 DQpBIEJVIGlzIHByb2Nlc3NlZCBieSBhbiBIQSBpZiB0aGVyZSBpcyBhIHZhbGlkIFNBIGJldHdl ZW4gdGhlIE1OIGFuZCBIQS4gU28gdGhlIHBvaW50IGlzIGlmIHRoZSBTQSBjYW4gYmUgZXN0YWJs aXNoZWQgKHVzaW5nIG1hdGVyaWFsIGZyb20gdGhlIGFjY2VzcyBhdXRoKSB3aXRob3V0IGhhdmlu ZyB0byBkbyBhbm90aGVyIGF1dGhlbnRpY2F0aW9uIGluIElLRXYyLg0KDQpGcm9tOiBleHQgSm9u Zy1IeW91ayBMZWUgPGpvbmctaHlvdWsubGVlQGlucmlhLmZyPG1haWx0bzpqb25nLWh5b3VrLmxl ZUBpbnJpYS5mcj4+DQpEYXRlOiBUaHUsIDI1IEF1ZyAyMDExIDIyOjIzOjMzICswMjAwDQpUbzog QmFzYXZhcmFqIFBhdGlsIDxiYXNhdmFyYWoucGF0aWxAbm9raWEuY29tPG1haWx0bzpiYXNhdmFy YWoucGF0aWxAbm9raWEuY29tPj4NCkNjOiA8bWNjYXBAcGV0b25pLm9yZzxtYWlsdG86bWNjYXBA cGV0b25pLm9yZz4+LCBDaGFybGVzIFBlcmtpbnMgPGNoYXJsaWVwQGNvbXB1dGVyLm9yZzxtYWls dG86Y2hhcmxpZXBAY29tcHV0ZXIub3JnPj4sICJtZXh0QGlldGYub3JnPG1haWx0bzptZXh0QGll dGYub3JnPiIgPG1leHRAaWV0Zi5vcmc8bWFpbHRvOm1leHRAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UmU6IFtNRVhUXSBbISEgU1BBTV0gUmU6IFdlbGwta25vd24gcHJvYmxlbSB3aXRoIGF1dGhlbnRp Y2F0aW9uL2V0Yy4gaW4gd2lyZWxlc3MgbmV0d29ya3MNCg0KYXV0aGVudGljYXRpb24gZm9yIGFj Y2VzcyBuZXR3b3JrIGFuZCBhdXRoZW50aWNhdGlvbiBmb3IgYmluZGluZyB1cGRhdGUgYXJlIGRp ZmZlcmVudC4NCg0KT24gVGh1LCBBdWcgMjUsIDIwMTEgYXQgMTA6MDUgUE0sIDxCYXNhdmFyYWou UGF0aWxAbm9raWEuY29tPG1haWx0bzpCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tPj4gd3JvdGU6 DQoNClRoYXSp9nMgYSBnb29kIHN1bW1hcml6YXRpb24gUGV0ZS4NCkJ1dCB3ZSBkbyBtdWx0aXBs ZSBhdXRoZW50aWNhdGlvbnMgdG9kYXkuDQpXZSBkbyBhY2Nlc3MgYXV0aGVudGljYXRpb24gKDEp IGFuZCB0aGVuIHdlIGhhdmUgdG8gYXV0aGVudGljYXRlIHdpdGggdGhlDQpIQSB5ZXQgYWdhaW4g aW4gKDMpLg0KVGhhdCBjb3VsZCBiZSBvcHRpbWl6ZWQuDQoNCi1SYWoNCg0KDQpPbiA4LzI1LzEx IDI6NTQgUE0sICJleHQgUGV0ZSBNY0Nhbm4iIDxtY2NhcEBwZXRvbmkub3JnPG1haWx0bzptY2Nh cEBwZXRvbmkub3JnPj4gd3JvdGU6DQoNCj5IaSwgQ2hhcmxpZSwNCj4NCj5UaGUgcHJvYmxlbSBz ZWVtcyB0byBiZSB3ZSBoYXZlIHRoZSBmb2xsb3dpbmcgdGhyZWUgc3RlcHMgdGhhdCBoYXZlDQo+ dG8gYmUgY2FycmllZCBvdXQgaW4gb3JkZXI6DQo+DQo+MSkgYWNjZXNzIGF1dGhlbnRpY2F0aW9u DQo+MikgYWRkcmVzcyBhc3NpZ25tZW50DQo+MykgbW9iaWxpdHkgbWFuYWdlbWVudA0KPg0KPigz KSBkZXBlbmRzIG9uICgyKSBiZWNhdXNlIHlvdSBjYW4ndCBiaW5kIHlvdXIgaG9tZSBhZGRyZXNz IHRvIGENCj5jYXJlLW9mIGFkZHJlc3MgdW50aWwgeW91IGhhdmUgYSBjYXJlLW9mIGFkZHJlc3Mu ICAoMikgZGVwZW5kcyBvbiAoMSkNCj5iZWNhdXNlIG9wZXJhdG9ycyBkb24ndCBsaWtlIHRvIGdp dmUgb3V0IHJlc291cmNlcyB1bnRpbCB0aGV5IGtub3cgdGhleQ0KPndpbGwgZ2V0IHBhaWQuDQo+ DQo+SXQncyBwb3NzaWJsZSB0byBjb21iaW5lIGFsbCB0aGVzZSB0aGluZ3MgaW50byBvbmUgcHJv dG9jb2wgKHBlcmhhcHMgUEFOQQ0KPmNvdWxkIGhhdmUgYmVlbiB0aGF0IHZlaGljbGUsIGlmIGNl cnRhaW4gZGVjaXNpb25zIGhhZCBub3QgYmVlbiBtYWRlKSBidXQNCj50aGUgSUVURiBzZWVtcyB0 byBsaWtlIGJyZWFraW5nIHByb2JsZW1zIGRvd24gaW50byBsYXllcmVkIHNvbHV0aW9ucy4NCj4N Cj4tUGV0ZQ0KPg0KPk9uIFRodSwgQXVnIDI1LCAyMDExIGF0IDM6MTkgUE0sIENoYXJsZXMgRS4g UGVya2lucw0KPjxjaGFybGllcEBjb21wdXRlci5vcmc8bWFpbHRvOmNoYXJsaWVwQGNvbXB1dGVy Lm9yZz4+IHdyb3RlOg0KPj4gSGVsbG8gUGV0ZSwNCj4+DQo+PiBZZXMsIHB1dHRpbmcgTW9iaWxl IElQIGluc2lkZSBvZiBFQVAgd291bGQgYmUgb25lIGFwcHJvYWNoLg0KPj4gSXQgd291bGQgaGF2 ZSBzb21lIGludGVyZXN0aW5nIGFkdmFudGFnZXMuICBPdGhlciBhcHByb2FjaGVzDQo+PiBtaWdo dCBiZSBtb3JlIHByb3Blcmx5IGRvbmUgaW4gW25ldGV4dF0gLS0gb3IgcGVyaGFwcyBoYXZlDQo+ PiBhbHJlYWR5IGJlZW4gbG9va2VkOyBJIGNvdWxkIGhhdmUgcG9zc2libHkgbWlzc2VkIHNvbWUg b2YNCj4+IHRoZSByZWxldmFudCBkaXNjdXNzaW9uIHRoZXJlLg0KPj4NCj4+IFJlZ2FyZHMsDQo+ PiBDaGFybGllIFAuDQo+Pg0KPj4NCj4+DQo+PiBPbiA4LzI1LzIwMTEgMTE6NDAgQU0sIFBldGUg TWNDYW5uIHdyb3RlOg0KPj4+DQo+Pj4gSGksIEp1bGllbiwNCj4+Pg0KPj4+IEFyZSB5b3UgdGFs a2luZyBhYm91dCBFQVAgaW5zaWRlIElLRXYyPyAgVGhhdCBwcmVzdXBwb3NlcyB0aGF0IHRoZSBN Tg0KPj4+IGlzIGFscmVhZHkgYXR0YWNoZWQgdG8gdGhlIG5ldHdvcmsgc29tZXdoZXJlIGFuZCBo YXMgYW4gSVAgYWRkcmVzcw0KPj4+KGkuZS4sDQo+Pj4gaXQgaGFzIGFscmVhZHkgcGFzc2VkIGFj Y2VzcyBhdXRoZW50aWNhdGlvbikuDQo+Pj4NCj4+PiBJdCBtYXkgYmUgaW50ZXJlc3RpbmcgdG8g bG9vayBhdCB3aGV0aGVyIGFjY2VzcyBhdXRoZW50aWNhdGlvbiBhbmQNCj4+PiBtb2JpbGl0eQ0K Pj4+IG1hbmFnZW1lbnQgY2FuIGJlIGNvbWJpbmVkLiAgRm9yIGV4YW1wbGUsIHdlIGNvdWxkIHB1 dCBNb2JpbGUgSVAgKG9yDQo+Pj4gc29tZSB2YXJpYW50IG9mIGl0KSBpbnNpZGUgYW4gRUFQIGV4 Y2hhbmdlIHVzZWQgZm9yIGFjY2Vzcw0KPj4+YXV0aGVudGljYXRpb24uDQo+Pj4gQ2hhcmxpZSwg YXJlIHlvdSBwcm9wb3Npbmcgc29tZXRoaW5nIGxpa2UgdGhpcz8NCj4+Pg0KPj4+IC1QZXRlDQo+ Pj4NCj4+PiBPbiBUaHUsIEF1ZyAyNSwgMjAxMSBhdCAxOjQ0IFBNLCBKdWxpZW4gTGFnYW5pZXI8 anVsaWVuLmlldGZAZ21haWwuY29tPG1haWx0bzpqdWxpZW4uaWV0ZkBnbWFpbC5jb20+Pg0KPj4+ ICB3cm90ZToNCj4+Pj4NCj4+Pj4gQ2hhcmxpZSwNCj4+Pj4NCj4+Pj4gSSBhbSBub3Qgc3VyZSBJ IHVuZGVyc3RhbmQgd2hhdCBpcyBtaXNzaW5nIGluIE1JUHY2OyBhIE1OIGFuZCBhbiBIQQ0KPj4+ PiBjYW4gYWxyZWFkeSBtdXR1YWxseSBhdXRoZW50aWNhdGUgdXNpbmcgRUFQLCBhbmQgdGhpcyBp cyBpbmNpZGVudGFsbHkNCj4+Pj4gd2hhdCAzR1BQIGxldmVyYWdlcyBvbiwgdG9nZXRoZXIgd2l0 aCB0aGUgRUFQLUFLQSBtZXRob2QuIFdoYXQgaXMNCj4+Pj4gbWlzc2luZz8NCj4+Pj4NCj4+Pj4g LS1qdWxpZW4NCj4+Pj4NCj4+Pj4gT24gV2VkLCBBdWcgMjQsIDIwMTEgYXQgMTI6MDYgUE0sIENo YXJsZXMgRS4gUGVya2lucw0KPj4+PiA8Y2hhcmxpZXBAY29tcHV0ZXIub3JnPG1haWx0bzpjaGFy bGllcEBjb21wdXRlci5vcmc+PiAgd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4gSGVsbG8gZm9sa3MsDQo+ Pj4+Pg0KPj4+Pj4gSXQncyBub3cgMjAxMS4gIE1vYmlsZSBJUCB3YXMgc3RhbmRhcmRpemVkIGxh dGUgaW4NCj4+Pj4+IDE5OTYsIGFmdGVyIHdvcmsgaGFkIGFscmVhZHkgYmVlbiBzdGFydGVkIG5l YXJseQ0KPj4+Pj4gdGVuIHllYXJzIGJlZm9yZS4gIE92ZXIgdHdvIGRlY2FkZXMhIC0tIGFuZCBy ZWdhcmRsZXNzDQo+Pj4+PiBvZiBsaXAgc2VydmljZSB0byBmaXhlZC9tb2JpbGUgY29udmVyZ2Vu Y2Ugd2Ugc3RpbGwNCj4+Pj4+IGRvbid0IGhhdmUgc2VhbWxlc3MgbW9iaWxpdHkgaW4gdXNlciBk ZXZpY2VzIGFjcm9zcw0KPj4+Pj4gaGV0ZXJvZ2VuZW91cyBtZWRpYSwgYW5kIHN0YW5kYXJkcyBv cmdhbml6YXRpb25zDQo+Pj4+PiAobm90YWJseSAzR1BQKSBhcmUgbm90IHByb3Blcmx5IHRha2lu ZyBhZHZhbnRhZ2Ugb2YNCj4+Pj4+IHdoYXQgTW9iaWxlIElQIGNhbiBkby4gVGhlIGxvc2VycyBh cmUgdGhlIGVuZC11c2VycywNCj4+Pj4+IHdoaWNoIG1lYW5zIGFsbCBvZiB1cy4NCj4+Pj4+DQo+ Pj4+PiBUaGVyZSBhcmUgbWFueSByZWFzb25zIGZvciB0aGlzLCBidXQgb25lIG9mIHRoZQ0KPj4+ Pj4gbWFpbiByZWFzb25zIGhhcyB0byBkbyB3aXRoIGF1dGhlbnRpY2F0aW9uIGF0IHRoZQ0KPj4+ Pj4gYWNjZXNzIG5ldHdvcmsuICBFQVAgaW4gdmFyaW91cyBmb3JtcyBpcyBiZWluZw0KPj4+Pj4g dXRpbGl6ZWQgZm9yIHRoaXMgcHVycG9zZSwgYW5kIE1vYmlsZSBJUCBpcyBub3QsDQo+Pj4+PiBl dmVuIHRob3VnaCB0aGVyZSBoYXMgbmV2ZXIgYmVlbiBhbnkgcmVwb3J0ZWQNCj4+Pj4+IGZhaWx1 cmUgb2YgdGhlIFJGQyA1OTQ0IG9yIFJGQyA0Mjg1IG9yIFJGQyA2Mjc1DQo+Pj4+PiAodG8gbXkg a25vd2xlZGdlKS4gIE1vcmVvdmVyLCB1bmxlc3MgdGhlcmUgaXMNCj4+Pj4+IHNvbWV0aGluZyB3 cm9uZyB3aXRoIHRoZSBjcnlwdG9ncmFwaHkgdGhhdCBhbHNvDQo+Pj4+PiBoYXMgbm90IGJlZW4g cmVwb3J0ZWQsIHRoZXNlIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMNCj4+Pj4+IGVuYWJsZSBfbXV0 dWFsXyBhdXRoZW50aWNhdGlvbiBiZXR3ZWVuIHRoZSBuZXR3b3JrDQo+Pj4+PiBhbmQgdGhlIGNs aWVudCwgbm90IGp1c3QgY2xpZW50IGF1dGhlbnRpY2F0aW9uLg0KPj4+Pj4NCj4+Pj4+IEluIG9y ZGVyIGZvciBNb2JpbGUgSVAgdG8gZW5hYmxlIHRoZSByZWFsIHByb21pc2UNCj4+Pj4+IG9mIGhp Z2ggcGVyZm9ybWFuY2UgaGV0ZXJvZ2VuZW91cyBuZXR3b3JraW5nLCB3ZQ0KPj4+Pj4gaGF2ZSB0 byBkbyBzb21lIG1vcmUgd29yay4gIEkgd291bGQgbGlrZSB0byBpbml0aWF0ZQ0KPj4+Pj4gc29t ZSBtb3JlIGRpc2N1c3Npb24gYWJvdXQgdGhpcy4gIERNTSBpcyBpbnRlcmVzdGluZw0KPj4+Pj4g aW4gaXRzIG93biByaWdodCwgYnV0IGl0J3Mgbm90IGF0IGFsbCB0aGUgd2hvbGUNCj4+Pj4+IHN0 b3J5LiAgTW9yZW92ZXIsIHdpdGggcHJvcGVyIGRlc2lnbiwgaXQgaXMgbGlrZWx5DQo+Pj4+PiB0 aGUgc3VwcG9zZWQgYnVyZGVuIG9mIHNpZ25hbGluZyB0byB0aGUgaG9tZSBhZ2VudA0KPj4+Pj4g Y2FuIGJlIHN1YnN0YW50aWFsbHkgcmVkdWNlZC4gIEFzIG9uZSBzaW1wbGUgZXhhbXBsZSwNCj4+ Pj4+IGlmIGhhbmRvdmVycyBhcmUgYWNjb21wbGlzaGVkIGxvY2FsbHkgYmV0d2VlbiB0cnVzdGVk DQo+Pj4+PiBhY2Nlc3MgYWdlbnRzIChyb3V0ZXJzLCA4MDIuMTEgYWNjZXNzIGNvbnRyb2xsZXJz LCAuLi4pDQo+Pj4+PiB0aGVuIHRoZSBhY3R1YWwgdGltaW5nIG9mIHR1bm5lbCByZWRpcmVjdGlv biBmcm9tIHRoZQ0KPj4+Pj4gaG9tZSBhZ2VudCBiZWNvbWVzIG11Y2ggbGVzcyBjcml0aWNhbC4g IFRoaXMgaXMgYWxzbw0KPj4+Pj4gaW50cmljYXRlbHkgaW50ZXJ0d2luZWQgd2l0aCBhdXRoZW50 aWNhdGlvbi4NCj4+Pj4+DQo+Pj4+PiBJZiB0aGUgSG9tZSBBZ2VudCB3ZXJlIHJlY29nbml6ZWQg YXMgYSByb2J1c3Qgc2VjdXJpdHkNCj4+Pj4+IGFwcGxpYW5jZSwgdGhlbiBpdCBjb3VsZCBuYXR1 cmFsbHkgc2l0IG9uIHRoZSBuZXR3b3JrDQo+Pj4+PiBib3VuZGFyeSBhcyBhbiBJUC1hZGRyZXNz YWJsZSBkZXZpY2UuICBNb2JpbGUgSVANCj4+Pj4+IGF1dGhlbnRpY2F0aW9uIGNvdWxkIGJlY29t ZSB0aGUgcHJpbWFyeSBtZWFucyBvZg0KPj4+Pj4gdmFsaWRhdGluZyB1c2VyIGFjY2VzcywgaW5z dGVhZCBvZiBhbiBhZnRlcnRob3VnaHQNCj4+Pj4+IHRvIGVuYWJsZSBJUC1hZGRyZXNzIHByZXNl cnZhdGlvbiBhZnRlciBhbGwgdGhlIGhlYXZ5DQo+Pj4+PiBsaWZ0aW5nIGhhcyBiZWVuIGRvbmUg YSBsb3dlciBsZXZlbHMuDQo+Pj4+Pg0KPj4+Pj4gSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgdGhh dCBpbiB0aGlzIHdvcmtpbmcgZ3JvdXAgd2UNCj4+Pj4+IHNob3VsZCBnbyBhYm91dCBtYWtpbmcg dGhpcyBoYXBwZW4uICBJdCBzZWVtcyB0byBiZQ0KPj4+Pj4gaW1wb3J0YW50LCBhbmQgdW5kZW5p YWJseSBhbGlnbmVkIHdpdGggb3VyIHdvcmtpbmcNCj4+Pj4+IGdyb3VwIHJlc3BvbnNpYmlsaXRp ZXMuDQo+Pj4+Pg0KPj4+Pj4gUmVnYXJkcywNCj4+Pj4+IENoYXJsaWUgUC4NCj4+Pj4+DQo+Pj4+ Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+IE1FWFQgbWFpbGluZyBsaXN0DQo+Pj4+PiBNRVhUQGlldGYub3JnPG1haWx0bzpNRVhU QGlldGYub3JnPg0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t ZXh0DQo+Pj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+PiBNRVhUIG1haWxpbmcgbGlzdA0KPj4+PiBNRVhUQGlldGYub3JnPG1haWx0 bzpNRVhUQGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21leHQNCj4+Pj4NCj4+Pg0KPj4NCj4+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj5NRVhUIG1haWxpbmcgbGlzdA0KPk1FWFRAaWV0Zi5vcmc8 bWFpbHRvOk1FWFRAaWV0Zi5vcmc+DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tZXh0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpNRVhUIG1haWxpbmcgbGlzdA0KTUVYVEBpZXRmLm9yZzxtYWlsdG86TUVYVEBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dA0KDQoNCg0KLS0N CklNQVJBIFRlYW0sIElOUklBLCBGcmFuY2UuDQpKb25nLUh5b3VrIExlZSwgbGl2aW5nIHNvbWV3 aGVyZSBiZXR3ZWVuIC9kZXYvbnVsbCBhbmQgL2Rldi9yYW5kb20uDQoNCiNlbWFpbDogaHVycnlv biAoYXQpIGdtYWlsIChkb3QpIGNvbSB8fCBqb25nLWh5b3VrLmxlZSAoYXQpIGlucmlhIChkb3Qp IGZyDQojd2VicGFnZTogaHR0cHM6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvaHVycnlvbi8NCg== --_000_CA7C1A7DF9ECbasavarajpatilnokiacom_ Content-Type: text/html; charset="euc-kr" Content-ID: <6582C9DCBC3C5B4AB1553BC231E1F163@nokia.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5BIEJVIGlzIHByb2Nlc3NlZCBieSBhbiBIQSBpZiB0aGVyZSBpcyBhIHZhbGlk IFNBIGJldHdlZW4gdGhlIE1OIGFuZCBIQS4gU28gdGhlIHBvaW50IGlzIGlmIHRoZSBTQSBjYW4g YmUgZXN0YWJsaXNoZWQgKHVzaW5nIG1hdGVyaWFsIGZyb20gdGhlIGFjY2VzcyBhdXRoKSB3aXRo b3V0IGhhdmluZyB0byBkbyBhbm90aGVyIGF1dGhlbnRpY2F0aW9uIGluIElLRXYyLjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjps ZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZU OiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBB RERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1S SUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5leHQgSm9uZy1IeW91ayBMZWUgJmx0OzxhIGhyZWY9 Im1haWx0bzpqb25nLWh5b3VrLmxlZUBpbnJpYS5mciI+am9uZy1oeW91ay5sZWVAaW5yaWEuZnI8 L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+ VGh1LCAyNSBBdWcgMjAxMSAyMjoyMzozMyAmIzQzOzAyMDA8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5CYXNhdmFyYWogUGF0aWwgJmx0OzxhIGhyZWY9Im1h aWx0bzpiYXNhdmFyYWoucGF0aWxAbm9raWEuY29tIj5iYXNhdmFyYWoucGF0aWxAbm9raWEuY29t PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4m bHQ7PGEgaHJlZj0ibWFpbHRvOm1jY2FwQHBldG9uaS5vcmciPm1jY2FwQHBldG9uaS5vcmc8L2E+ Jmd0OywgQ2hhcmxlcyBQZXJraW5zICZsdDs8YSBocmVmPSJtYWlsdG86Y2hhcmxpZXBAY29tcHV0 ZXIub3JnIj5jaGFybGllcEBjb21wdXRlci5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFp bHRvOm1leHRAaWV0Zi5vcmciPm1leHRAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86bWV4dEBpZXRmLm9yZyI+bWV4dEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW01FWFRdIFshISBTUEFN XSBSZTogV2VsbC1rbm93biBwcm9ibGVtIHdpdGggYXV0aGVudGljYXRpb24vZXRjLiBpbiB3aXJl bGVzcyBuZXR3b3Jrczxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCmF1dGhlbnRpY2F0 aW9uIGZvciBhY2Nlc3MgbmV0d29yayBhbmQgYXV0aGVudGljYXRpb24gZm9yIGJpbmRpbmcgdXBk YXRlIGFyZSBkaWZmZXJlbnQuPGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9u IFRodSwgQXVnIDI1LCAyMDExIGF0IDEwOjA1IFBNLCA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhy ZWY9Im1haWx0bzpCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tIj5CYXNhdmFyYWouUGF0aWxAbm9r aWEuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNv bGlkO3BhZGRpbmctbGVmdDoxZXg7Ij4NCjxicj4NClRoYXSp9nMgYSBnb29kIHN1bW1hcml6YXRp b24gUGV0ZS48YnI+DQpCdXQgd2UgZG8gbXVsdGlwbGUgYXV0aGVudGljYXRpb25zIHRvZGF5Ljxi cj4NCldlIGRvIGFjY2VzcyBhdXRoZW50aWNhdGlvbiAoMSkgYW5kIHRoZW4gd2UgaGF2ZSB0byBh dXRoZW50aWNhdGUgd2l0aCB0aGU8YnI+DQpIQSB5ZXQgYWdhaW4gaW4gKDMpLjxicj4NClRoYXQg Y291bGQgYmUgb3B0aW1pemVkLjxicj4NCjxicj4NCi1SYWo8YnI+DQo8ZGl2Pg0KPGRpdj48L2Rp dj4NCjxkaXYgY2xhc3M9Img1Ij48YnI+DQo8YnI+DQpPbiA4LzI1LzExIDI6NTQgUE0sICZxdW90 O2V4dCBQZXRlIE1jQ2FubiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jY2FwQHBldG9uaS5v cmciPm1jY2FwQHBldG9uaS5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7SGksIENo YXJsaWUsPGJyPg0KJmd0Ozxicj4NCiZndDtUaGUgcHJvYmxlbSBzZWVtcyB0byBiZSB3ZSBoYXZl IHRoZSBmb2xsb3dpbmcgdGhyZWUgc3RlcHMgdGhhdCBoYXZlPGJyPg0KJmd0O3RvIGJlIGNhcnJp ZWQgb3V0IGluIG9yZGVyOjxicj4NCiZndDs8YnI+DQomZ3Q7MSkgYWNjZXNzIGF1dGhlbnRpY2F0 aW9uPGJyPg0KJmd0OzIpIGFkZHJlc3MgYXNzaWdubWVudDxicj4NCiZndDszKSBtb2JpbGl0eSBt YW5hZ2VtZW50PGJyPg0KJmd0Ozxicj4NCiZndDsoMykgZGVwZW5kcyBvbiAoMikgYmVjYXVzZSB5 b3UgY2FuJ3QgYmluZCB5b3VyIGhvbWUgYWRkcmVzcyB0byBhPGJyPg0KJmd0O2NhcmUtb2YgYWRk cmVzcyB1bnRpbCB5b3UgaGF2ZSBhIGNhcmUtb2YgYWRkcmVzcy4gJm5ic3A7KDIpIGRlcGVuZHMg b24gKDEpPGJyPg0KJmd0O2JlY2F1c2Ugb3BlcmF0b3JzIGRvbid0IGxpa2UgdG8gZ2l2ZSBvdXQg cmVzb3VyY2VzIHVudGlsIHRoZXkga25vdyB0aGV5PGJyPg0KJmd0O3dpbGwgZ2V0IHBhaWQuPGJy Pg0KJmd0Ozxicj4NCiZndDtJdCdzIHBvc3NpYmxlIHRvIGNvbWJpbmUgYWxsIHRoZXNlIHRoaW5n cyBpbnRvIG9uZSBwcm90b2NvbCAocGVyaGFwcyBQQU5BPGJyPg0KJmd0O2NvdWxkIGhhdmUgYmVl biB0aGF0IHZlaGljbGUsIGlmIGNlcnRhaW4gZGVjaXNpb25zIGhhZCBub3QgYmVlbiBtYWRlKSBi dXQ8YnI+DQomZ3Q7dGhlIElFVEYgc2VlbXMgdG8gbGlrZSBicmVha2luZyBwcm9ibGVtcyBkb3du IGludG8gbGF5ZXJlZCBzb2x1dGlvbnMuPGJyPg0KJmd0Ozxicj4NCiZndDstUGV0ZTxicj4NCiZn dDs8YnI+DQomZ3Q7T24gVGh1LCBBdWcgMjUsIDIwMTEgYXQgMzoxOSBQTSwgQ2hhcmxlcyBFLiBQ ZXJraW5zPGJyPg0KJmd0OyZsdDs8YSBocmVmPSJtYWlsdG86Y2hhcmxpZXBAY29tcHV0ZXIub3Jn Ij5jaGFybGllcEBjb21wdXRlci5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBIZWxs byBQZXRlLDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgWWVzLCBwdXR0aW5nIE1vYmlsZSBJ UCBpbnNpZGUgb2YgRUFQIHdvdWxkIGJlIG9uZSBhcHByb2FjaC48YnI+DQomZ3Q7Jmd0OyBJdCB3 b3VsZCBoYXZlIHNvbWUgaW50ZXJlc3RpbmcgYWR2YW50YWdlcy4gJm5ic3A7T3RoZXIgYXBwcm9h Y2hlczxicj4NCiZndDsmZ3Q7IG1pZ2h0IGJlIG1vcmUgcHJvcGVybHkgZG9uZSBpbiBbbmV0ZXh0 XSAtLSBvciBwZXJoYXBzIGhhdmU8YnI+DQomZ3Q7Jmd0OyBhbHJlYWR5IGJlZW4gbG9va2VkOyBJ IGNvdWxkIGhhdmUgcG9zc2libHkgbWlzc2VkIHNvbWUgb2Y8YnI+DQomZ3Q7Jmd0OyB0aGUgcmVs ZXZhbnQgZGlzY3Vzc2lvbiB0aGVyZS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFJlZ2Fy ZHMsPGJyPg0KJmd0OyZndDsgQ2hhcmxpZSBQLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE9uIDgvMjUvMjAxMSAxMTo0MCBBTSwgUGV0ZSBN Y0Nhbm4gd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEhpLCBKdWxp ZW4sPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEFyZSB5b3UgdGFsa2luZyBh Ym91dCBFQVAgaW5zaWRlIElLRXYyPyAmbmJzcDtUaGF0IHByZXN1cHBvc2VzIHRoYXQgdGhlIE1O PGJyPg0KJmd0OyZndDsmZ3Q7IGlzIGFscmVhZHkgYXR0YWNoZWQgdG8gdGhlIG5ldHdvcmsgc29t ZXdoZXJlIGFuZCBoYXMgYW4gSVAgYWRkcmVzczxicj4NCiZndDsmZ3Q7Jmd0OyhpLmUuLDxicj4N CiZndDsmZ3Q7Jmd0OyBpdCBoYXMgYWxyZWFkeSBwYXNzZWQgYWNjZXNzIGF1dGhlbnRpY2F0aW9u KS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgSXQgbWF5IGJlIGludGVyZXN0 aW5nIHRvIGxvb2sgYXQgd2hldGhlciBhY2Nlc3MgYXV0aGVudGljYXRpb24gYW5kPGJyPg0KJmd0 OyZndDsmZ3Q7IG1vYmlsaXR5PGJyPg0KJmd0OyZndDsmZ3Q7IG1hbmFnZW1lbnQgY2FuIGJlIGNv bWJpbmVkLiAmbmJzcDtGb3IgZXhhbXBsZSwgd2UgY291bGQgcHV0IE1vYmlsZSBJUCAob3I8YnI+ DQomZ3Q7Jmd0OyZndDsgc29tZSB2YXJpYW50IG9mIGl0KSBpbnNpZGUgYW4gRUFQIGV4Y2hhbmdl IHVzZWQgZm9yIGFjY2Vzczxicj4NCiZndDsmZ3Q7Jmd0O2F1dGhlbnRpY2F0aW9uLjxicj4NCiZn dDsmZ3Q7Jmd0OyBDaGFybGllLCBhcmUgeW91IHByb3Bvc2luZyBzb21ldGhpbmcgbGlrZSB0aGlz Pzxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAtUGV0ZTxicj4NCiZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBPbiBUaHUsIEF1ZyAyNSwgMjAxMSBhdCAxOjQ0IFBNLCBK dWxpZW4gTGFnYW5pZXImbHQ7PGEgaHJlZj0ibWFpbHRvOmp1bGllbi5pZXRmQGdtYWlsLmNvbSI+ anVsaWVuLmlldGZAZ21haWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJm5ic3A7d3Jv dGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgQ2hhcmxpZSw8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJIGFtIG5vdCBzdXJl IEkgdW5kZXJzdGFuZCB3aGF0IGlzIG1pc3NpbmcgaW4gTUlQdjY7IGEgTU4gYW5kIGFuIEhBPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyBjYW4gYWxyZWFkeSBtdXR1YWxseSBhdXRoZW50aWNhdGUgdXNp bmcgRUFQLCBhbmQgdGhpcyBpcyBpbmNpZGVudGFsbHk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHdo YXQgM0dQUCBsZXZlcmFnZXMgb24sIHRvZ2V0aGVyIHdpdGggdGhlIEVBUC1BS0EgbWV0aG9kLiBX aGF0IGlzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBtaXNzaW5nPzxicj4NCiZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IC0tanVsaWVuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgT24gV2VkLCBBdWcgMjQsIDIwMTEgYXQgMTI6MDYgUE0sIENo YXJsZXMgRS4gUGVya2luczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpjaGFybGllcEBjb21wdXRlci5vcmciPmNoYXJsaWVwQGNvbXB1dGVyLm9yZzwvYT4mZ3Q7ICZu YnNwO3dyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgSGVsbG8gZm9sa3MsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBJdCdzIG5vdyAyMDExLiAmbmJzcDtNb2JpbGUgSVAgd2FzIHN0YW5kYXJk aXplZCBsYXRlIGluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgMTk5NiwgYWZ0ZXIgd29yayBo YWQgYWxyZWFkeSBiZWVuIHN0YXJ0ZWQgbmVhcmx5PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg dGVuIHllYXJzIGJlZm9yZS4gJm5ic3A7T3ZlciB0d28gZGVjYWRlcyEgLS0gYW5kIHJlZ2FyZGxl c3M8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvZiBsaXAgc2VydmljZSB0byBmaXhlZC9tb2Jp bGUgY29udmVyZ2VuY2Ugd2Ugc3RpbGw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkb24ndCBo YXZlIHNlYW1sZXNzIG1vYmlsaXR5IGluIHVzZXIgZGV2aWNlcyBhY3Jvc3M8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBoZXRlcm9nZW5lb3VzIG1lZGlhLCBhbmQgc3RhbmRhcmRzIG9yZ2FuaXph dGlvbnM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAobm90YWJseSAzR1BQKSBhcmUgbm90IHBy b3Blcmx5IHRha2luZyBhZHZhbnRhZ2Ugb2Y8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3aGF0 IE1vYmlsZSBJUCBjYW4gZG8uIFRoZSBsb3NlcnMgYXJlIHRoZSBlbmQtdXNlcnMsPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgd2hpY2ggbWVhbnMgYWxsIG9mIHVzLjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlcmUgYXJlIG1hbnkgcmVhc29u cyBmb3IgdGhpcywgYnV0IG9uZSBvZiB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtYWlu IHJlYXNvbnMgaGFzIHRvIGRvIHdpdGggYXV0aGVudGljYXRpb24gYXQgdGhlPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgYWNjZXNzIG5ldHdvcmsuICZuYnNwO0VBUCBpbiB2YXJpb3VzIGZvcm1z IGlzIGJlaW5nPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdXRpbGl6ZWQgZm9yIHRoaXMgcHVy cG9zZSwgYW5kIE1vYmlsZSBJUCBpcyBub3QsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZXZl biB0aG91Z2ggdGhlcmUgaGFzIG5ldmVyIGJlZW4gYW55IHJlcG9ydGVkPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsgZmFpbHVyZSBvZiB0aGUgUkZDIDU5NDQgb3IgUkZDIDQyODUgb3IgUkZDIDYy NzU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAodG8gbXkga25vd2xlZGdlKS4gJm5ic3A7TW9y ZW92ZXIsIHVubGVzcyB0aGVyZSBpczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNvbWV0aGlu ZyB3cm9uZyB3aXRoIHRoZSBjcnlwdG9ncmFwaHkgdGhhdCBhbHNvPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgaGFzIG5vdCBiZWVuIHJlcG9ydGVkLCB0aGVzZSBhdXRoZW50aWNhdGlvbiBtZXRo b2RzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZW5hYmxlIF9tdXR1YWxfIGF1dGhlbnRpY2F0 aW9uIGJldHdlZW4gdGhlIG5ldHdvcms8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbmQgdGhl IGNsaWVudCwgbm90IGp1c3QgY2xpZW50IGF1dGhlbnRpY2F0aW9uLjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSW4gb3JkZXIgZm9yIE1vYmlsZSBJ UCB0byBlbmFibGUgdGhlIHJlYWwgcHJvbWlzZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9m IGhpZ2ggcGVyZm9ybWFuY2UgaGV0ZXJvZ2VuZW91cyBuZXR3b3JraW5nLCB3ZTxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IGhhdmUgdG8gZG8gc29tZSBtb3JlIHdvcmsuICZuYnNwO0kgd291bGQg bGlrZSB0byBpbml0aWF0ZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNvbWUgbW9yZSBkaXNj dXNzaW9uIGFib3V0IHRoaXMuICZuYnNwO0RNTSBpcyBpbnRlcmVzdGluZzxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGluIGl0cyBvd24gcmlnaHQsIGJ1dCBpdCdzIG5vdCBhdCBhbGwgdGhlIHdo b2xlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3RvcnkuICZuYnNwO01vcmVvdmVyLCB3aXRo IHByb3BlciBkZXNpZ24sIGl0IGlzIGxpa2VseTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRo ZSBzdXBwb3NlZCBidXJkZW4gb2Ygc2lnbmFsaW5nIHRvIHRoZSBob21lIGFnZW50PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgY2FuIGJlIHN1YnN0YW50aWFsbHkgcmVkdWNlZC4gJm5ic3A7QXMg b25lIHNpbXBsZSBleGFtcGxlLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlmIGhhbmRvdmVy cyBhcmUgYWNjb21wbGlzaGVkIGxvY2FsbHkgYmV0d2VlbiB0cnVzdGVkPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsgYWNjZXNzIGFnZW50cyAocm91dGVycywgODAyLjExIGFjY2VzcyBjb250cm9s bGVycywgLi4uKTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZW4gdGhlIGFjdHVhbCB0aW1p bmcgb2YgdHVubmVsIHJlZGlyZWN0aW9uIGZyb20gdGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgaG9tZSBhZ2VudCBiZWNvbWVzIG11Y2ggbGVzcyBjcml0aWNhbC4gJm5ic3A7VGhpcyBpcyBh bHNvPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW50cmljYXRlbHkgaW50ZXJ0d2luZWQgd2l0 aCBhdXRoZW50aWNhdGlvbi48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IElmIHRoZSBIb21lIEFnZW50IHdlcmUgcmVjb2duaXplZCBhcyBhIHJvYnVz dCBzZWN1cml0eTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFwcGxpYW5jZSwgdGhlbiBpdCBj b3VsZCBuYXR1cmFsbHkgc2l0IG9uIHRoZSBuZXR3b3JrPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgYm91bmRhcnkgYXMgYW4gSVAtYWRkcmVzc2FibGUgZGV2aWNlLiAmbmJzcDtNb2JpbGUgSVA8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhdXRoZW50aWNhdGlvbiBjb3VsZCBiZWNvbWUgdGhl IHByaW1hcnkgbWVhbnMgb2Y8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB2YWxpZGF0aW5nIHVz ZXIgYWNjZXNzLCBpbnN0ZWFkIG9mIGFuIGFmdGVydGhvdWdodDxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IHRvIGVuYWJsZSBJUC1hZGRyZXNzIHByZXNlcnZhdGlvbiBhZnRlciBhbGwgdGhlIGhl YXZ5PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGlmdGluZyBoYXMgYmVlbiBkb25lIGEgbG93 ZXIgbGV2ZWxzLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgdGhhdCBpbiB0aGlzIHdvcmtpbmcgZ3JvdXAg d2U8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzaG91bGQgZ28gYWJvdXQgbWFraW5nIHRoaXMg aGFwcGVuLiAmbmJzcDtJdCBzZWVtcyB0byBiZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlt cG9ydGFudCwgYW5kIHVuZGVuaWFibHkgYWxpZ25lZCB3aXRoIG91ciB3b3JraW5nPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgZ3JvdXAgcmVzcG9uc2liaWxpdGllcy48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgQ2hhcmxpZSBQLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IE1FWFQgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJl Zj0ibWFpbHRvOk1FWFRAaWV0Zi5vcmciPk1FWFRAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tZXh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tZXh0PC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgTUVYVCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IDxhIGhyZWY9Im1haWx0bzpNRVhUQGlldGYub3JnIj5NRVhUQGlldGYub3JnPC9hPjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tZXh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tZXh0PC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0O19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0O01FWFQgbWFpbGluZyBsaXN0PGJy Pg0KJmd0OzxhIGhyZWY9Im1haWx0bzpNRVhUQGlldGYub3JnIj5NRVhUQGlldGYub3JnPC9hPjxi cj4NCiZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21l eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21leHQ8L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpNRVhUIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpN RVhUQGlldGYub3JnIj5NRVhUQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWV4dDwvYT48YnI+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KLS0gPGJyPg0KSU1BUkEgVGVhbSwgSU5SSUEsIEZyYW5jZS4gPGJyPg0KSm9u Zy1IeW91ayBMZWUsIGxpdmluZyBzb21ld2hlcmUgYmV0d2VlbiAvZGV2L251bGwgYW5kIC9kZXYv cmFuZG9tLjxicj4NCjxicj4NCiNlbWFpbDogaHVycnlvbiAoYXQpIGdtYWlsIChkb3QpIGNvbSB8 fCBqb25nLWh5b3VrLmxlZSAoYXQpIGlucmlhIChkb3QpIGZyPGJyPg0KI3dlYnBhZ2U6IDxhIGhy ZWY9Imh0dHBzOi8vc2l0ZXMuZ29vZ2xlLmNvbS9zaXRlL2h1cnJ5b24vIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvaHVycnlvbi88L2E+PGJyPg0KPC9zcGFu Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CA7C1A7DF9ECbasavarajpatilnokiacom_-- From Basavaraj.Patil@nokia.com Thu Aug 25 13:42:31 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828C121F8C2F for ; Thu, 25 Aug 2011 13:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zlkcVF3U02T for ; Thu, 25 Aug 2011 13:42:30 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5B40621F8C21 for ; Thu, 25 Aug 2011 13:42:30 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7PKhcj7022177; Thu, 25 Aug 2011 23:43:39 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Aug 2011 23:43:33 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 25 Aug 2011 22:43:33 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0323.007; Thu, 25 Aug 2011 22:43:32 +0200 From: To: , , Thread-Topic: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks Thread-Index: AQHMY1wFXQKtm0ixAkGph0+eSVzEr5Ut2WuAgAAIHQD//7G2gA== Date: Thu, 25 Aug 2011 20:43:31 +0000 Message-ID: In-Reply-To: <4E56AF52.3070306@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [172.19.59.133] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8B2494A2F768A04E84D04EEB7C1F2AC5@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Aug 2011 20:43:33.0356 (UTC) FILETIME=[A7B85AC0:01CC6367] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 20:42:31 -0000 Hi Charlie, Inline: On 8/25/11 3:23 PM, "ext Charles E. Perkins" wrote: > >Hello Pete, > >Your analysis of operator concerns is quite correct, >it seems to me, but on the other hand maybe the IETF >would be able to alleviate operator concerns once >they are properly understood. And, if operators >could be assured that they would suffer no harm by >following some revised IETF protocol steps, there >would be a good chance for progress. > >Address assignment is perhaps the stickiest case. >Here are some observations: >- The UE doesn't necessarily have to know its > care-of address until after handover is complete > (and, according to [netext], not even then) >- The access network does not have to complete the > assignment of the care-of address until it has > verified the authentication >- As mentioned before, the home agent is a viable > candidate for AAA relay, actually appearing as the > AAA server to the access network >- An IPv6 address can't really be considered a > valuable resource if it isn't routable, and so > even if UE knew its IPv6 care-of address, it would > not get any benefit until authentication completes. > >If there is any disagreement about these points, I would >be surprised, but every day brings new surprises. I am >proposing that we should try to make a higher-performance >handover specification that is less complicated than, say, >S101/S102/S103. Almost anything the IETF could possibly >do would be less complicated than those, and I fully >expect much easier to configure, administer, and operate. > >So, the problem statement could be: > >Enable Mobile IP to provide high-performance mobility management that >is better able to be deployed in modern wireless access networks >that already utilize alternate access authentication protocols. >Determine the suitability of network-based versus client-based >variations of the candidate solutions. I think that the above problem statement is still fairly vague. What would be the benchmark mobility protocol against which you could evaluate whether you have a high-performance mobility management protocol? I think we can work on optimizations to Mobile IP which would make it more attractive from a deployment perspective. Simplifying Mobile IP would also help in making it more viable for use in wireless/cellular networks. Mobile IP (DSMIP6) can be deployed and used in current gen cellular networks when the MN is attached to a wifi network or a non-3GPP access network (S2c reference point in 3GPP). That=B9s a start. Relevant use-cases would ensure that the HA is a part of the P-GW and mobile hosts implement/support client functionality. -Basavaraj > > >Regards, >Charlie P. > > > >On 8/25/2011 12:54 PM, Pete McCann wrote: >> Hi, Charlie, >> >> The problem seems to be we have the following three steps that have >> to be carried out in order: >> >> 1) access authentication >> 2) address assignment >> 3) mobility management >> >> (3) depends on (2) because you can't bind your home address to a >> care-of address until you have a care-of address. (2) depends on (1) >> because operators don't like to give out resources until they know they >> will get paid. >> >> It's possible to combine all these things into one protocol (perhaps >>PANA >> could have been that vehicle, if certain decisions had not been made) >>but >> the IETF seems to like breaking problems down into layered solutions. >> >> -Pete >> >> On Thu, Aug 25, 2011 at 3:19 PM, Charles E. Perkins >> wrote: >>> Hello Pete, >>> >>> Yes, putting Mobile IP inside of EAP would be one approach. >>> It would have some interesting advantages. Other approaches >>> might be more properly done in [netext] -- or perhaps have >>> already been looked; I could have possibly missed some of >>> the relevant discussion there. >>> >>> Regards, >>> Charlie P. >>> >>> >>> >>> On 8/25/2011 11:40 AM, Pete McCann wrote: >>>> >>>> Hi, Julien, >>>> >>>> Are you talking about EAP inside IKEv2? That presupposes that the MN >>>> is already attached to the network somewhere and has an IP address >>>>(i.e., >>>> it has already passed access authentication). >>>> >>>> It may be interesting to look at whether access authentication and >>>> mobility >>>> management can be combined. For example, we could put Mobile IP (or >>>> some variant of it) inside an EAP exchange used for access >>>>authentication. >>>> Charlie, are you proposing something like this? >>>> >>>> -Pete >>>> >>>> On Thu, Aug 25, 2011 at 1:44 PM, Julien >>>>Laganier >>>> wrote: >>>>> >>>>> Charlie, >>>>> >>>>> I am not sure I understand what is missing in MIPv6; a MN and an HA >>>>> can already mutually authenticate using EAP, and this is incidentally >>>>> what 3GPP leverages on, together with the EAP-AKA method. What is >>>>> missing? >>>>> >>>>> --julien >>>>> >>>>> On Wed, Aug 24, 2011 at 12:06 PM, Charles E. Perkins >>>>> wrote: >>>>>> >>>>>> Hello folks, >>>>>> >>>>>> It's now 2011. Mobile IP was standardized late in >>>>>> 1996, after work had already been started nearly >>>>>> ten years before. Over two decades! -- and regardless >>>>>> of lip service to fixed/mobile convergence we still >>>>>> don't have seamless mobility in user devices across >>>>>> heterogeneous media, and standards organizations >>>>>> (notably 3GPP) are not properly taking advantage of >>>>>> what Mobile IP can do. The losers are the end-users, >>>>>> which means all of us. >>>>>> >>>>>> There are many reasons for this, but one of the >>>>>> main reasons has to do with authentication at the >>>>>> access network. EAP in various forms is being >>>>>> utilized for this purpose, and Mobile IP is not, >>>>>> even though there has never been any reported >>>>>> failure of the RFC 5944 or RFC 4285 or RFC 6275 >>>>>> (to my knowledge). Moreover, unless there is >>>>>> something wrong with the cryptography that also >>>>>> has not been reported, these authentication methods >>>>>> enable _mutual_ authentication between the network >>>>>> and the client, not just client authentication. >>>>>> >>>>>> In order for Mobile IP to enable the real promise >>>>>> of high performance heterogeneous networking, we >>>>>> have to do some more work. I would like to initiate >>>>>> some more discussion about this. DMM is interesting >>>>>> in its own right, but it's not at all the whole >>>>>> story. Moreover, with proper design, it is likely >>>>>> the supposed burden of signaling to the home agent >>>>>> can be substantially reduced. As one simple example, >>>>>> if handovers are accomplished locally between trusted >>>>>> access agents (routers, 802.11 access controllers, ...) >>>>>> then the actual timing of tunnel redirection from the >>>>>> home agent becomes much less critical. This is also >>>>>> intricately intertwined with authentication. >>>>>> >>>>>> If the Home Agent were recognized as a robust security >>>>>> appliance, then it could naturally sit on the network >>>>>> boundary as an IP-addressable device. Mobile IP >>>>>> authentication could become the primary means of >>>>>> validating user access, instead of an afterthought >>>>>> to enable IP-address preservation after all the heavy >>>>>> lifting has been done a lower levels. >>>>>> >>>>>> I would like to propose that in this working group we >>>>>> should go about making this happen. It seems to be >>>>>> important, and undeniably aligned with our working >>>>>> group responsibilities. >>>>>> >>>>>> Regards, >>>>>> Charlie P. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> MEXT mailing list >>>>>> MEXT@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>> >>>>> _______________________________________________ >>>>> MEXT mailing list >>>>> MEXT@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mext >>>>> >>>> >>> >>> >> > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext From mccap@petoni.org Thu Aug 25 13:54:49 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABB821F8C6C for ; Thu, 25 Aug 2011 13:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-lxTH+f4cTC for ; Thu, 25 Aug 2011 13:54:48 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 365D621F8B7C for ; Thu, 25 Aug 2011 13:54:48 -0700 (PDT) Received: by fxe6 with SMTP id 6so2272001fxe.31 for ; Thu, 25 Aug 2011 13:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petoni.org; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TVoaWcW7/chOXAAclO22lXxQ4Z6luzNA5cgsr/PHaUw=; b=UzuMwOy3+TW2TBe9oJqntUBUL6dVLrvu5UTWqFhxXzR1EU6rtPb8Rl5W8Uc+ZSfenO jgz5kFchYrQi6/sHgH4sJbUl/CWQwcy9eQlVPC9h1xxIYdVIuiHkvF7jIjsyLnTgTKl2 3dhOHB2RWtIkc3SW40U1A0B6m5zzWI/p5G2Us= MIME-Version: 1.0 Received: by 10.223.91.147 with SMTP id n19mr316859fam.53.1314305761797; Thu, 25 Aug 2011 13:56:01 -0700 (PDT) Received: by 10.223.144.143 with HTTP; Thu, 25 Aug 2011 13:56:01 -0700 (PDT) X-Originating-IP: [4.28.5.163] In-Reply-To: <4E56AF52.3070306@computer.org> References: <4E554BAA.9080409@computer.org> <4E56A052.1000604@computer.org> <4E56AF52.3070306@computer.org> Date: Thu, 25 Aug 2011 16:56:01 -0400 Message-ID: From: Pete McCann To: charliep@computer.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 20:54:49 -0000 Hi, Charlie, On Thu, Aug 25, 2011 at 4:23 PM, Charles E. Perkins wrote: > > Hello Pete, > > Your analysis of operator concerns is quite correct, > it seems to me, but on the other hand maybe the IETF > would be able to alleviate operator concerns once > they are properly understood. =A0And, if operators > could be assured that they would suffer no harm by > following some revised IETF protocol steps, there > would be a good chance for progress. > > Address assignment is perhaps the stickiest case. > Here are some observations: > - The UE doesn't necessarily have to know its > =A0care-of address until after handover is complete > =A0(and, according to [netext], not even then) Some agent somewhere has to know it prior to binding it to a home address. > - The access network does not have to complete the > =A0assignment of the care-of address until it has > =A0verified the authentication What do you mean by "complete"? > - As mentioned before, the home agent is a viable > =A0candidate for AAA relay, actually appearing as the > =A0AAA server to the access network > - An IPv6 address can't really be considered a > =A0valuable resource if it isn't routable, and so > =A0even if UE knew its IPv6 care-of address, it would > =A0not get any benefit until authentication completes. I assume a visited network would allocate at least a /64 and probably more (a shorter prefix) if it wanted to enable NEMO. Depending on the amount of address space allocated to that particular point of attachment, I could imagine it being quickly exhausted by an attacker that didn't have to pass authentication. And given that cells are getting smaller and more numerous, there will be less and less address space allocated to each one. > If there is any disagreement about these points, I would > be surprised, but every day brings new surprises. =A0I am > proposing that we should try to make a higher-performance > handover specification that is less complicated than, say, > S101/S102/S103. =A0Almost anything the IETF could possibly > do would be less complicated than those, and I fully > expect much easier to configure, administer, and operate. If we could simply convince 3GPP operators to allow direct Internet access as the default option (in the LIPA style) I think it would tend to dramatically cut down on the complex interfaces. Right now the default option seems to be home-routed traffic and hiding mobility from the UE as much as possible. > So, the problem statement could be: > > Enable Mobile IP to provide high-performance mobility management that > is better able to be deployed in modern wireless access networks > that already utilize alternate access authentication protocols. > Determine the suitability of network-based versus client-based > variations of the candidate solutions. It would be nice if EAP could be used as an air interface authentication method in an LTE network. If we had that and direct LIPA style connectivit= y it would be possible to build something interesting on top. -Pete From julien.ietf@gmail.com Thu Aug 25 14:01:33 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC8821F8C88 for ; Thu, 25 Aug 2011 14:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkR1C94Qf3R5 for ; Thu, 25 Aug 2011 14:01:33 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7828521F8C86 for ; Thu, 25 Aug 2011 14:01:30 -0700 (PDT) Received: by wwf5 with SMTP id 5so1911608wwf.13 for ; Thu, 25 Aug 2011 14:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fPzVh7OEgaRavtxAoV5p3JAPHk5Cz5mzEa4gIb/0Gh8=; b=ex4n7QV+SDgj21nqlskj01SK4POY8hToDr75cJp2U5PGtFAwS+X/D+IFcQ/kn13Ylu Ioff+bVjiaNWoVc6677+nhLP4j2dD+hwzXMJhqNZ5OTqNtdixAjAcPS3tVWZ4a+uoLwb QZTs+FNt5WoYY3OBX0d0He6OYshhBOUqYIbMo= MIME-Version: 1.0 Received: by 10.227.11.206 with SMTP id u14mr188713wbu.51.1314306162931; Thu, 25 Aug 2011 14:02:42 -0700 (PDT) Received: by 10.227.141.79 with HTTP; Thu, 25 Aug 2011 14:02:42 -0700 (PDT) In-Reply-To: References: <4E554BAA.9080409@computer.org> Date: Thu, 25 Aug 2011 14:02:42 -0700 Message-ID: From: Julien Laganier To: Pete McCann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: charliep@computer.org, mext Subject: Re: [MEXT] Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 21:01:33 -0000 Hi Pete, On Thu, Aug 25, 2011 at 11:40 AM, Pete McCann wrote: > Hi, Julien, > > Are you talking about EAP inside IKEv2? =A0That presupposes that the MN > is already attached to the network somewhere and has an IP address (i.e., > it has already passed access authentication). Yes, EAP authentication for IKEv2. Yes the MN needs to attach to the network first, as hosts currently do today already. > It may be interesting to look at whether access authentication and mobili= ty > management can be combined. I don' t know what problem we would be solving by combining the two. --julien > On Thu, Aug 25, 2011 at 1:44 PM, Julien Laganier = wrote: >> Charlie, >> >> I am not sure I understand what is missing in MIPv6; a MN and an HA >> can already mutually authenticate using EAP, and this is incidentally >> what 3GPP leverages on, together with the EAP-AKA method. What is >> missing? >> >> --julien >> >> On Wed, Aug 24, 2011 at 12:06 PM, Charles E. Perkins >> wrote: >>> >>> Hello folks, >>> >>> It's now 2011. =A0Mobile IP was standardized late in >>> 1996, after work had already been started nearly >>> ten years before. =A0Over two decades! -- and regardless >>> of lip service to fixed/mobile convergence we still >>> don't have seamless mobility in user devices across >>> heterogeneous media, and standards organizations >>> (notably 3GPP) are not properly taking advantage of >>> what Mobile IP can do. The losers are the end-users, >>> which means all of us. >>> >>> There are many reasons for this, but one of the >>> main reasons has to do with authentication at the >>> access network. =A0EAP in various forms is being >>> utilized for this purpose, and Mobile IP is not, >>> even though there has never been any reported >>> failure of the RFC 5944 or RFC 4285 or RFC 6275 >>> (to my knowledge). =A0Moreover, unless there is >>> something wrong with the cryptography that also >>> has not been reported, these authentication methods >>> enable _mutual_ authentication between the network >>> and the client, not just client authentication. >>> >>> In order for Mobile IP to enable the real promise >>> of high performance heterogeneous networking, we >>> have to do some more work. =A0I would like to initiate >>> some more discussion about this. =A0DMM is interesting >>> in its own right, but it's not at all the whole >>> story. =A0Moreover, with proper design, it is likely >>> the supposed burden of signaling to the home agent >>> can be substantially reduced. =A0As one simple example, >>> if handovers are accomplished locally between trusted >>> access agents (routers, 802.11 access controllers, ...) >>> then the actual timing of tunnel redirection from the >>> home agent becomes much less critical. =A0This is also >>> intricately intertwined with authentication. >>> >>> If the Home Agent were recognized as a robust security >>> appliance, then it could naturally sit on the network >>> boundary as an IP-addressable device. =A0Mobile IP >>> authentication could become the primary means of >>> validating user access, instead of an afterthought >>> to enable IP-address preservation after all the heavy >>> lifting has been done a lower levels. >>> >>> I would like to propose that in this working group we >>> should go about making this happen. =A0It seems to be >>> important, and undeniably aligned with our working >>> group responsibilities. >>> >>> Regards, >>> Charlie P. >>> >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > From mccap@petoni.org Thu Aug 25 15:11:42 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0326B21F85F2 for ; Thu, 25 Aug 2011 15:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HH5IXC2gg0Im for ; Thu, 25 Aug 2011 15:11:41 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 19B2C21F85B5 for ; Thu, 25 Aug 2011 15:11:40 -0700 (PDT) Received: by fxe6 with SMTP id 6so2313484fxe.31 for ; Thu, 25 Aug 2011 15:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petoni.org; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n+RuvaBzA/Uq+yhTK6lxUaZL9erheHMHoYHfkHxaAgE=; b=PnG46/pQXxrpC8wis1Btrn88fyWg/a/+hMVq26Tbzuet85zGamIiYRKOHwYJCyPEfB He+Oa+Z40LqrJ7FzYl1u83ALidDLCeuUVmICK2iAUrxj+O2Mmykbz3GhQJYnDuoZlc6J kmGAyh6iZbpq1hFWD3h38R6riDEmwQoFQi2PU= MIME-Version: 1.0 Received: by 10.223.35.210 with SMTP id q18mr371085fad.148.1314310374894; Thu, 25 Aug 2011 15:12:54 -0700 (PDT) Received: by 10.223.144.143 with HTTP; Thu, 25 Aug 2011 15:12:54 -0700 (PDT) X-Originating-IP: [68.45.157.93] In-Reply-To: References: <4E554BAA.9080409@computer.org> Date: Thu, 25 Aug 2011 18:12:54 -0400 Message-ID: From: Pete McCann To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Cc: charliep@computer.org, mext Subject: Re: [MEXT] Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 22:11:42 -0000 Hi, Julien, On Thu, Aug 25, 2011 at 5:02 PM, Julien Laganier wrote: > Yes, EAP authentication for IKEv2. Yes the MN needs to attach to the > network first, as hosts currently do today already. Right. I think Charlie was asking whether MIP could be the network access authentication protocol. >> It may be interesting to look at whether access authentication and mobility >> management can be combined. > > I don' t know what problem we would be solving by combining the two. Making initial establishment of the SA with the HA (upon network attachment) more efficient. Making handovers faster and more efficient by reducing the number of round-trip messages required. -Pete From julien.ietf@gmail.com Thu Aug 25 15:38:20 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0AC21F8B84 for ; Thu, 25 Aug 2011 15:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrWJbYC28UAN for ; Thu, 25 Aug 2011 15:38:19 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8102E21F8B82 for ; Thu, 25 Aug 2011 15:38:19 -0700 (PDT) Received: by wwf5 with SMTP id 5so1953880wwf.13 for ; Thu, 25 Aug 2011 15:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UYNFo/VnNUtfyor/+gDESrM6djY0tVyqQ3fAknj4eKg=; b=Iick9edyOFHcutGZzIml5cbtf6g9j6gGcYMarxGRQIZfxztl49ddd2IYl98qDrvi0A Ym3TCimkYCmqjSO3TFPHe/SIx/+u3zalaLiSpREPBN/foaYlcLS9A1iQQrM2kvkknHFV 4pEYbdydxZ/VyqYRQSS2Zge10RLD2ycdd/kCQ= MIME-Version: 1.0 Received: by 10.227.11.141 with SMTP id t13mr260506wbt.36.1314311973361; Thu, 25 Aug 2011 15:39:33 -0700 (PDT) Received: by 10.227.141.79 with HTTP; Thu, 25 Aug 2011 15:39:33 -0700 (PDT) In-Reply-To: References: <4E554BAA.9080409@computer.org> Date: Thu, 25 Aug 2011 15:39:33 -0700 Message-ID: From: Julien Laganier To: Pete McCann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: charliep@computer.org, mext Subject: Re: [MEXT] Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 22:38:20 -0000 Hi Pete, On Thu, Aug 25, 2011 at 3:12 PM, Pete McCann wrote: > Hi, Julien, > > On Thu, Aug 25, 2011 at 5:02 PM, Julien Laganier = wrote: >> Yes, EAP authentication for IKEv2. Yes the MN needs to attach to the >> network first, as hosts currently do today already. > > Right. =A0I think Charlie was asking whether MIP could be the network acc= ess > authentication protocol. > >>> It may be interesting to look at whether access authentication and mobi= lity >>> management can be combined. >> >> I don' t know what problem we would be solving by combining the two. > > Making initial establishment of the SA with the HA (upon network attachme= nt) > more efficient. Making handovers faster and more efficient by reducing th= e > number of round-trip messages required. In the context of this discussion, optimizing Mobile IPv6 handover speed seems to imply that slowness of those is the root cause of that lack of MIPv6 deployment, which I don' t think is the case. On the other hand, coupling network access authentication with mobility management would arguably reduces deployment flexibility and thus harm rather than help potential MIPv6 deployments. Thus I am still not sure what the problem is. --julien From mccap@petoni.org Thu Aug 25 19:22:33 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E2321F8586 for ; Thu, 25 Aug 2011 19:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbsaABF4OWri for ; Thu, 25 Aug 2011 19:22:32 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A8E0C21F8500 for ; Thu, 25 Aug 2011 19:22:31 -0700 (PDT) Received: by fxe6 with SMTP id 6so2416203fxe.31 for ; Thu, 25 Aug 2011 19:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petoni.org; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MD/HVOdvSn6F53VSnQpY2kh38LbtWVvJhHuP8LsDvyA=; b=bpfGO8lxIgqPoIDEP349j1eZRfDijCEK/1ngZnYKISlOaYpOzyYvJ63fpfOgXGT92r UwWKFoeNcum3hhSlcmBE0Y1eVxjHBkn6xjpJl7/3ab4z/AXtbM9/No6pg2RJdeIJfTh4 EnGWswPPIloEuUNiF8c3lkP8mQnc8JyqWpu1E= MIME-Version: 1.0 Received: by 10.223.22.150 with SMTP id n22mr725452fab.110.1314325425925; Thu, 25 Aug 2011 19:23:45 -0700 (PDT) Received: by 10.223.144.143 with HTTP; Thu, 25 Aug 2011 19:23:45 -0700 (PDT) X-Originating-IP: [68.45.157.93] In-Reply-To: References: <4E554BAA.9080409@computer.org> Date: Thu, 25 Aug 2011 22:23:45 -0400 Message-ID: From: Pete McCann To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Cc: charliep@computer.org, mext Subject: Re: [MEXT] Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 02:22:33 -0000 Hi, Julien, On Thu, Aug 25, 2011 at 6:39 PM, Julien Laganier wrote: > > In the context of this discussion, optimizing Mobile IPv6 handover > speed seems to imply that slowness of those is the root cause of that > lack of MIPv6 deployment, which I don' t think is the case. On the > other hand, coupling network access authentication with mobility > management would arguably reduces deployment flexibility and thus harm > rather than help potential MIPv6 deployments. You're right that performance is probably not why 3GPP went the way they did. I think there were a variety of motivations that boil down to a desire on the part of operators to control the handling of UE traffic, mainly by routing it back through policy enforcement points. They built a network-based mobility management scheme that borrowed very little from Mobile IP. There was also a legacy authentication infrastructure built around AKA that they wanted to re-use. They didn't build algorithm agility into their UE authentication protocol. One could argue that in an LTE network the mobility is very much tied to the access authentication, and it's one reason why MIPv6 has missed the boat here. > Thus I am still not sure what the problem is. There's probably very little impetus for change no matter what MEXT does. -Pete From charliep@computer.org Fri Aug 26 11:37:01 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9918A21F8B83 for ; Fri, 26 Aug 2011 11:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqjTSb+gyQ5P for ; Fri, 26 Aug 2011 11:37:01 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id F35E921F8B65 for ; Fri, 26 Aug 2011 11:37:00 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.96.89]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Qx1IG-00064a-K0; Fri, 26 Aug 2011 14:38:16 -0400 Message-ID: <4E57E814.4020607@computer.org> Date: Fri, 26 Aug 2011 11:38:12 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Pete McCann References: <4E554BAA.9080409@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8645f02cca18be5ee1720de8cca5142a31350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: mext Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wirelessnetworks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 18:37:01 -0000 Hello Pete, I might be stepping out on another limb here, but anyway... On 8/25/2011 7:23 PM, Pete McCann wrote: > You're right that performance is probably not why 3GPP went the > way they did. ... Check. > There was also a legacy authentication infrastructure built around > AKA that they wanted to re-use. They didn't build algorithm agility > into their UE authentication protocol. One could argue that in an > LTE network the mobility is very much tied to the access authentication, > and it's one reason why MIPv6 has missed the boat here. Double check. >> Thus I am still not sure what the problem is. The problem is that they can't do very effective handovers. Worse, they are designing _per-application_ handover systems. This is wrong by most reasonable engineering standards, regardless on the positive effect it might have for standards junkies and permanent employment for engineers. > There's probably very little impetus for change no matter what MEXT > does. I agree that, if [mext] does nothing, there won't be much impetus for change. But if we do something that is (a) secure, (b) deployable, (c) easier to administer, and (d) considerably better performance, then I reckon they'd have to be purposefully resistant to insist on ignoring it. Regards, Charlie P. From Basavaraj.Patil@nokia.com Fri Aug 26 12:00:16 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7281221F8C56 for ; Fri, 26 Aug 2011 12:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiQXJUJJRH+J for ; Fri, 26 Aug 2011 12:00:15 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 91D7A21F8C3A for ; Fri, 26 Aug 2011 12:00:14 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7QJ1Q02020350; Fri, 26 Aug 2011 22:01:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Aug 2011 22:01:26 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 26 Aug 2011 21:01:26 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0323.007; Fri, 26 Aug 2011 21:01:25 +0200 From: To: , Thread-Topic: [MEXT] Re: Well-known problem with authentication/etc. in wirelessnetworks Thread-Index: AQHMZCKNFDj0Wzp3c0CY7C8n0YRSkA== Date: Fri, 26 Aug 2011 19:01:24 +0000 Message-ID: In-Reply-To: <4E57E814.4020607@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [172.19.59.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <888D2843564A00439E95F9FA6D931DE8@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Aug 2011 19:01:26.0729 (UTC) FILETIME=[8E610390:01CC6422] X-Nokia-AV: Clean Cc: mext@ietf.org Subject: Re: [MEXT] Well-known problem with authentication/etc. in wirelessnetworks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 19:00:16 -0000 Hi Charlie, On 8/26/11 1:38 PM, "ext Charles E. Perkins" wrote: > >>> Thus I am still not sure what the problem is. > > >The problem is that they can't do very effective handovers. >Worse, they are designing _per-application_ handover systems. >This is wrong by most reasonable engineering standards, >regardless on the positive effect it might have for >standards junkies and permanent employment for engineers. Effective handovers between what networks? Handovers within the scope of an HSPA or LTE access for example work fine. If you are referring to handovers between 3G accesses and wifi (non-3GPP access) then yes. But the handover performance in such a scenario is hampered by other factors such as latency in connectivity and authentication etc. -Basavaraj > > >> There's probably very little impetus for change no matter what MEXT >> does. > > >I agree that, if [mext] does nothing, >there won't be much impetus for change. >But if we do something that is (a) secure, >(b) deployable, (c) easier to administer, >and (d) considerably better performance, >then I reckon they'd have to be purposefully >resistant to insist on ignoring it. > >Regards, >Charlie P. > >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext From charliep@computer.org Fri Aug 26 12:24:02 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF4421F8C9E for ; Fri, 26 Aug 2011 12:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rh3SXYKXqKyr for ; Fri, 26 Aug 2011 12:24:01 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 69FF021F8C8E for ; Fri, 26 Aug 2011 12:24:01 -0700 (PDT) Received: from [64.105.168.146] (helo=[10.1.100.70]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Qx21l-0007Cy-8k; Fri, 26 Aug 2011 15:25:17 -0400 Message-ID: <4E57F317.8080900@computer.org> Date: Fri, 26 Aug 2011 12:25:11 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86239f482120826744fb4bc95835ecae31350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.168.146 Cc: mext@ietf.org Subject: Re: [MEXT] Well-known problem with authentication/etc. in wirelessnetworks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 19:24:02 -0000 Hello Basavaraj, Thanks for your correction/clarification. Yes, I agree that in certain cases LTE can do very fast handovers, of course, given the installation of sufficiently high-performance hardware to handle the additional signaling requirement as designed for the special cases, or homogeneous physical media. And, eventually, they could do fast handovers for all physical media, with perhaps m*n^^2 hardware solutions for m applications and n physical media. I think that we could reasonably expect to do better handovers in almost all cases with a more flexible design based on Mobile IP, FMIP, and PMIP. I also agree that handovers are hampered by authentication requirements serialized after link establishment. Pre-registration techniques have been shown to ameliorate this problem quite well even with "single-radio" handset operation. This "should" have been integrated with FMIP, in my opinion. Regards, Charlie P. On 8/26/2011 12:01 PM, Basavaraj.Patil@nokia.com wrote: > > Hi Charlie, > > On 8/26/11 1:38 PM, "ext Charles E. Perkins" wrote: >> >>>> Thus I am still not sure what the problem is. >> >> >> The problem is that they can't do very effective handovers. >> Worse, they are designing _per-application_ handover systems. >> This is wrong by most reasonable engineering standards, >> regardless on the positive effect it might have for >> standards junkies and permanent employment for engineers. > > Effective handovers between what networks? Handovers within the scope of > an HSPA or LTE access for example work fine. > If you are referring to handovers between 3G accesses and wifi (non-3GPP > access) then yes. > But the handover performance in such a scenario is hampered by other > factors such as latency in connectivity and authentication etc. > > -Basavaraj > > >> >> >>> There's probably very little impetus for change no matter what MEXT >>> does. >> >> >> I agree that, if [mext] does nothing, >> there won't be much impetus for change. >> But if we do something that is (a) secure, >> (b) deployable, (c) easier to administer, >> and (d) considerably better performance, >> then I reckon they'd have to be purposefully >> resistant to insist on ignoring it. >> >> Regards, >> Charlie P. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From julien.ietf@gmail.com Fri Aug 26 12:59:16 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B33721F8C49 for ; Fri, 26 Aug 2011 12:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTmghEFiugnN for ; Fri, 26 Aug 2011 12:59:15 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2314521F8C1F for ; Fri, 26 Aug 2011 12:59:14 -0700 (PDT) Received: by wwf5 with SMTP id 5so2601072wwf.13 for ; Fri, 26 Aug 2011 13:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rWgkIser63PwoJrexMcJN6r/6ODZfaJL/yoAsonB1ic=; b=EAe4NCiYfVYwHyVW3qn49STl4oLY+vx1T1jygods+Q7R4ZRDlqWJfzQGnzBkkzfwM+ c7zY+f/3u2y/8UFXXb2gxMr1NbDEW+eoSBkbfIpra3FDm3oDGTB7/ECLOzEUCz1TNIN1 ynMm3tVDvhj2Fspt1C+zUSMUKB01cYrtwOENI= MIME-Version: 1.0 Received: by 10.227.11.206 with SMTP id u14mr1295889wbu.51.1314388829659; Fri, 26 Aug 2011 13:00:29 -0700 (PDT) Received: by 10.227.141.79 with HTTP; Fri, 26 Aug 2011 13:00:29 -0700 (PDT) In-Reply-To: References: <4E57E814.4020607@computer.org> Date: Fri, 26 Aug 2011 13:00:29 -0700 Message-ID: From: Julien Laganier To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: charliep@computer.org, mccap@petoni.org, mext@ietf.org Subject: Re: [MEXT] Well-known problem with authentication/etc. in wirelessnetworks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 19:59:16 -0000 Hi Raj, On Fri, Aug 26, 2011 at 12:01 PM, wrote: > > Hi Charlie, > > On 8/26/11 1:38 PM, "ext Charles E. Perkins" wrote: >> >>>> Thus I am still not sure what the problem is. >> >> >>The problem is that they can't do very effective handovers. >>Worse, they are designing _per-application_ handover systems. >>This is wrong by most reasonable engineering standards, >>regardless on the positive effect it might have for >>standards junkies and permanent employment for engineers. > > Effective handovers between what networks? Handovers within the scope of > an HSPA or LTE access for example work fine. > If you are referring to handovers between 3G accesses and wifi (non-3GPP > access) then yes. > But the handover performance in such a scenario is hampered by other > factors such as latency in connectivity and authentication etc. In the latter (handover between 3GPP and non-3GPP), given that the source and target system are accessed by different radio systems, I do not see handover performance has a factor hampering the usability or desirability of the inter-system handover scheme in use. --julien From Basavaraj.Patil@nokia.com Fri Aug 26 13:08:04 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5600D21F8C10 for ; Fri, 26 Aug 2011 13:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.097 X-Spam-Level: X-Spam-Status: No, score=-103.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwLjZezLKOyo for ; Fri, 26 Aug 2011 13:08:03 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id B243C21F8B82 for ; Fri, 26 Aug 2011 13:08:03 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7QK9DZS020754; Fri, 26 Aug 2011 23:09:14 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Aug 2011 23:09:06 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 26 Aug 2011 22:09:06 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.007; Fri, 26 Aug 2011 22:09:05 +0200 From: To: Thread-Topic: [MEXT] Well-known problem with authentication/etc. in wirelessnetworks Thread-Index: AQHMZCrT9oQoyLvVokSYBH51m22hNJUvGloA Date: Fri, 26 Aug 2011 20:09:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [172.19.59.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <25F670312A692B4EA6386698DFB1316B@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Aug 2011 20:09:06.0640 (UTC) FILETIME=[02464500:01CC642C] X-Nokia-AV: Clean Cc: charliep@computer.org, mccap@petoni.org, mext@ietf.org Subject: Re: [MEXT] Well-known problem with authentication/etc. in wirelessnetworks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 20:08:04 -0000 Hi Julien, On 8/26/11 3:00 PM, "ext Julien Laganier" wrote: >Hi Raj, > >On Fri, Aug 26, 2011 at 12:01 PM, wrote: >> >> Hi Charlie, >> >> On 8/26/11 1:38 PM, "ext Charles E. Perkins" >>wrote: >>> >>>>> Thus I am still not sure what the problem is. >>> >>> >>>The problem is that they can't do very effective handovers. >>>Worse, they are designing _per-application_ handover systems. >>>This is wrong by most reasonable engineering standards, >>>regardless on the positive effect it might have for >>>standards junkies and permanent employment for engineers. >> >> Effective handovers between what networks? Handovers within the scope of >> an HSPA or LTE access for example work fine. >> If you are referring to handovers between 3G accesses and wifi (non-3GPP >> access) then yes. >> But the handover performance in such a scenario is hampered by other >> factors such as latency in connectivity and authentication etc. > >In the latter (handover between 3GPP and non-3GPP), given that the >source and target system are accessed by different radio systems, I do >not see handover performance has a factor hampering the usability or >desirability of the inter-system handover scheme in use. You mean the impact (in terms of lower performance) of handovers across 3GPP and non-3GPP handovers does not really matter because those applications that rely on high performing handovers will anyway not rely on such? But you could make a case that we could see applications (eg. Skype) that would benefit from lower latency handovers across the different radio systems. -Raj > >--julien From julien.ietf@gmail.com Fri Aug 26 13:10:30 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61CC21F8C6B for ; Fri, 26 Aug 2011 13:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.484 X-Spam-Level: X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EyfuzgDDN-u for ; Fri, 26 Aug 2011 13:10:30 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 317FE21F8C69 for ; Fri, 26 Aug 2011 13:10:30 -0700 (PDT) Received: by wwf5 with SMTP id 5so2607281wwf.13 for ; Fri, 26 Aug 2011 13:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qf6GlyuRpILNPVKd1oe8WarqcAZhPTchuP1mAqmc2B8=; b=BcWc5m7b1S3Or9OCh8SE8RwmjNTmLsz3zjSmGjrM2ZlLzSVtTzJq97qZhN9xtiMK+9 dXmA/g/fpjrMMaQKbYJ0jnqmJ8MlyRzVUdd7KPlWaYA393xP57ZQ0ZhDcJsGPymc1tCw cbDL6WidHvFBHr5xkXF1UaulRihdJUFD+4n8A= MIME-Version: 1.0 Received: by 10.227.28.4 with SMTP id k4mr1343974wbc.21.1314389494323; Fri, 26 Aug 2011 13:11:34 -0700 (PDT) Received: by 10.227.141.79 with HTTP; Fri, 26 Aug 2011 13:11:34 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Aug 2011 13:11:34 -0700 Message-ID: From: Julien Laganier To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: charliep@computer.org, mccap@petoni.org, mext@ietf.org Subject: Re: [MEXT] Well-known problem with authentication/etc. in wirelessnetworks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 20:10:31 -0000 Hi Raj, On Fri, Aug 26, 2011 at 1:09 PM, wrote: > > Hi Julien, > > On 8/26/11 3:00 PM, "ext Julien Laganier" wrote: > >>Hi Raj, >> >>On Fri, Aug 26, 2011 at 12:01 PM, =A0 wrote: >>> >>> Hi Charlie, >>> >>> On 8/26/11 1:38 PM, "ext Charles E. Perkins" >>>wrote: >>>> >>>>>> Thus I am still not sure what the problem is. >>>> >>>> >>>>The problem is that they can't do very effective handovers. >>>>Worse, they are designing _per-application_ handover systems. >>>>This is wrong by most reasonable engineering standards, >>>>regardless on the positive effect it might have for >>>>standards junkies and permanent employment for engineers. >>> >>> Effective handovers between what networks? Handovers within the scope o= f >>> an HSPA or LTE access for example work fine. >>> If you are referring to handovers between 3G accesses and wifi (non-3GP= P >>> access) then yes. >>> But the handover performance in such a scenario is hampered by other >>> factors such as latency in connectivity and authentication etc. >> >>In the latter (handover between 3GPP and non-3GPP), given that the >>source and target system are accessed by different radio systems, I do >>not see handover performance has a factor hampering the usability or >>desirability of the inter-system handover scheme in use. > > You mean the impact (in terms of lower performance) of handovers across > 3GPP and non-3GPP handovers does not really matter because those > applications that rely on high performing handovers will anyway not rely > on such? No I meant that because the MN has different radio systems, it can turn one on and send a BU while still receiving/sending data via the old one, and thus MIP handover performance isn't in a critical path in that situation. For single radio the situation is obviously different. --julien From charliep@computer.org Fri Aug 26 13:11:04 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE9F21F8BFB for ; Fri, 26 Aug 2011 13:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj0w+XP1V+AH for ; Fri, 26 Aug 2011 13:11:04 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 7C36F21F8BD8 for ; Fri, 26 Aug 2011 13:11:04 -0700 (PDT) Received: from [64.105.168.146] (helo=[10.1.100.70]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Qx2lE-0004UN-R5; Fri, 26 Aug 2011 16:12:17 -0400 Message-ID: <4E57FDF3.9040904@computer.org> Date: Fri, 26 Aug 2011 13:11:31 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Julien Laganier References: <4E57E814.4020607@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86ee99e09b77ce41a0d8458427cee8cc11350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.168.146 Cc: mext@ietf.org Subject: Re: [MEXT] Well-known problem with authentication/etc. inwirelessnetworks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 20:11:05 -0000 Hello Julien, On 8/26/2011 1:00 PM, Julien Laganier wrote: > In the latter (handover between 3GPP and non-3GPP), given that the > source and target system are accessed by different radio systems, I do > not see handover performance has a factor hampering the usability or > desirability of the inter-system handover scheme in use. It is definitely true that a handset with two different radio interfaces, given proper infrastructure support and software, can maintain excellent user experience as the application session is maintained seamlessly while the handset changes its care-of address to reflect its new point of attachment to the Internet from a new radio interface. Is this what you meant? But the way in which authentication is carried out during handovers has a crucial impact on the handover performance. Do you not agree? Regards, Charlie P. From Basavaraj.Patil@nokia.com Fri Aug 26 13:13:14 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAFE21F8BD8 for ; Fri, 26 Aug 2011 13:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeKgd-HekrrG for ; Fri, 26 Aug 2011 13:13:13 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 109A221F8AFB for ; Fri, 26 Aug 2011 13:13:12 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7QKEPD6009707; Fri, 26 Aug 2011 23:14:25 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Aug 2011 23:14:20 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 26 Aug 2011 22:14:20 +0200 Received: from 008-AM1MPN1-051.mgdnok.nokia.com ([169.254.1.86]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0323.007; Fri, 26 Aug 2011 22:14:20 +0200 From: To: Thread-Topic: [MEXT] Well-known problem with authentication/etc. in wirelessnetworks Thread-Index: AQHMZCrT9oQoyLvVokSYBH51m22hNJUvGloAgABUfQD//6z6gA== Date: Fri, 26 Aug 2011 20:14:19 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [172.19.59.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <140DE8BB24B8D842BF5171CDDC2F1659@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Aug 2011 20:14:20.0822 (UTC) FILETIME=[BD8AA360:01CC642C] X-Nokia-AV: Clean Cc: charliep@computer.org, mccap@petoni.org, mext@ietf.org Subject: Re: [MEXT] Well-known problem with authentication/etc. in wirelessnetworks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 20:13:14 -0000 On 8/26/11 3:11 PM, "ext Julien Laganier" wrote: >Hi Raj, > >On Fri, Aug 26, 2011 at 1:09 PM, wrote: >> >> Hi Julien, >> >> On 8/26/11 3:00 PM, "ext Julien Laganier" wrote: >> >>>Hi Raj, >>> >>>On Fri, Aug 26, 2011 at 12:01 PM, wrote: >>>> >>>> Hi Charlie, >>>> >>>> On 8/26/11 1:38 PM, "ext Charles E. Perkins" >>>>wrote: >>>>> >>>>>>> Thus I am still not sure what the problem is. >>>>> >>>>> >>>>>The problem is that they can't do very effective handovers. >>>>>Worse, they are designing _per-application_ handover systems. >>>>>This is wrong by most reasonable engineering standards, >>>>>regardless on the positive effect it might have for >>>>>standards junkies and permanent employment for engineers. >>>> >>>> Effective handovers between what networks? Handovers within the scope >>>>of >>>> an HSPA or LTE access for example work fine. >>>> If you are referring to handovers between 3G accesses and wifi >>>>(non-3GPP >>>> access) then yes. >>>> But the handover performance in such a scenario is hampered by other >>>> factors such as latency in connectivity and authentication etc. >>> >>>In the latter (handover between 3GPP and non-3GPP), given that the >>>source and target system are accessed by different radio systems, I do >>>not see handover performance has a factor hampering the usability or >>>desirability of the inter-system handover scheme in use. >> >> You mean the impact (in terms of lower performance) of handovers across >> 3GPP and non-3GPP handovers does not really matter because those >> applications that rely on high performing handovers will anyway not rely >> on such? > >No I meant that because the MN has different radio systems, it can >turn one on and send a BU while still receiving/sending data via the >old one, and thus MIP handover performance isn't in a critical path in >that situation. For single radio the situation is obviously different. Agree. Such a scenario would essentially result in a make-before-break handover and hence the latency resulting from attach and authentication would not be as much of a concern. Thx for the clarification. > >--julien From julien.ietf@gmail.com Fri Aug 26 13:23:33 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87D921F8C09 for ; Fri, 26 Aug 2011 13:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JkWSI9mAhGI for ; Fri, 26 Aug 2011 13:23:33 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0190E21F8BE5 for ; Fri, 26 Aug 2011 13:23:32 -0700 (PDT) Received: by wyg8 with SMTP id 8so3117614wyg.31 for ; Fri, 26 Aug 2011 13:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9/gs+FnGPMZjce/lpqVInD7v3agWy0rVjbZXysplLO4=; b=aV2mPLaibM3w1aCYMxDLFqf95Vj7Q1oaNwZHgNHZZIOz79ChQKOgx3njtk+f8E5Ag6 cXbhsRi34lDVtaiINsodWpX3GHUYBEcGE0wrC8UUM8C14SICI771k+DqrE76P9irkAsg E5cs+KvHPZIh976syq5WCRureMxHMZEZGRmXs= MIME-Version: 1.0 Received: by 10.227.13.130 with SMTP id c2mr1345701wba.6.1314390289469; Fri, 26 Aug 2011 13:24:49 -0700 (PDT) Received: by 10.227.141.79 with HTTP; Fri, 26 Aug 2011 13:24:49 -0700 (PDT) In-Reply-To: <4E57FDF3.9040904@computer.org> References: <4E57E814.4020607@computer.org> <4E57FDF3.9040904@computer.org> Date: Fri, 26 Aug 2011 13:24:49 -0700 Message-ID: From: Julien Laganier To: charliep@computer.org Content-Type: text/plain; charset=ISO-8859-1 Cc: mext@ietf.org Subject: Re: [MEXT] Well-known problem with authentication/etc. inwirelessnetworks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 20:23:33 -0000 Hello Charlie, On Fri, Aug 26, 2011 at 1:11 PM, Charles E. Perkins wrote: > Hello Julien, > > > On 8/26/2011 1:00 PM, Julien Laganier wrote: > >> In the latter (handover between 3GPP and non-3GPP), given that the >> source and target system are accessed by different radio systems, I do >> not see handover performance has a factor hampering the usability or >> desirability of the inter-system handover scheme in use. > > It is definitely true that a handset with two different > radio interfaces, given proper infrastructure support and > software, can maintain excellent user experience as the > application session is maintained seamlessly while the handset > changes its care-of address to reflect its new point of > attachment to the Internet from a new radio interface. > > Is this what you meant? Yes. > But the way in which authentication is carried out during > handovers has a crucial impact on the handover performance. > Do you not agree? As above, I've been saying that Mobile IP handover performance does not seem to be a factor in how desirable it is for use in a 3GPP system. --julien From hesham@elevatemobile.com Sat Aug 27 02:40:17 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FF921F8A58 for ; Sat, 27 Aug 2011 02:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lteNXiNYtVy for ; Sat, 27 Aug 2011 02:40:16 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 8576721F8A56 for ; Sat, 27 Aug 2011 02:40:15 -0700 (PDT) Received: from [203.219.211.243] (helo=[192.168.0.11]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1QxFNw-0008JB-OZ; Sat, 27 Aug 2011 19:41:04 +1000 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Sat, 27 Aug 2011 19:40:58 +1000 From: Hesham Soliman To: Julien Laganier , Pete McCann Message-ID: Thread-Topic: [MEXT] Well-known problem with authentication/etc. in wireless networks In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: charliep@computer.org, mext Subject: Re: [MEXT] Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 09:40:17 -0000 FWIW, I agree 100% with Julien. First, access authentication and HA auth are two completely different issues for different purposes. Second, I don't think MIPv6 is not deployed because it adds a one-off SA setup with the HA. I wish that was the reason. Hesham -----Original Message----- From: Julien Laganier Date: Thu, 25 Aug 2011 15:39:33 -0700 To: Pete McCann Cc: , mext Subject: Re: [MEXT] Well-known problem with authentication/etc. in wireless networks >Hi Pete, > >On Thu, Aug 25, 2011 at 3:12 PM, Pete McCann wrote: >> Hi, Julien, >> >> On Thu, Aug 25, 2011 at 5:02 PM, Julien Laganier >> wrote: >>> Yes, EAP authentication for IKEv2. Yes the MN needs to attach to the >>> network first, as hosts currently do today already. >> >> Right. I think Charlie was asking whether MIP could be the network >>access >> authentication protocol. >> >>>> It may be interesting to look at whether access authentication and >>>>mobility >>>> management can be combined. >>> >>> I don' t know what problem we would be solving by combining the two. >> >> Making initial establishment of the SA with the HA (upon network >>attachment) >> more efficient. Making handovers faster and more efficient by reducing >>the >> number of round-trip messages required. > >In the context of this discussion, optimizing Mobile IPv6 handover >speed seems to imply that slowness of those is the root cause of that >lack of MIPv6 deployment, which I don' t think is the case. On the >other hand, coupling network access authentication with mobility >management would arguably reduces deployment flexibility and thus harm >rather than help potential MIPv6 deployments. > >Thus I am still not sure what the problem is. > >--julien >_______________________________________________ >MEXT mailing list >MEXT@ietf.org >https://www.ietf.org/mailman/listinfo/mext From alexandru.petrescu@gmail.com Sat Aug 27 10:16:21 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0112521F86AA for ; Sat, 27 Aug 2011 10:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dODF6LF-zJE8 for ; Sat, 27 Aug 2011 10:16:20 -0700 (PDT) Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 480D421F85C6 for ; Sat, 27 Aug 2011 10:16:18 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id C796994011A for ; Sat, 27 Aug 2011 19:17:32 +0200 (CEST) Message-ID: <4E5926A4.4030709@gmail.com> Date: Sat, 27 Aug 2011 19:17:24 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: mext@ietf.org References: <4E554BAA.9080409@computer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 110827-0, 27/08/2011), Outbound message X-Antivirus-Status: Clean Subject: Re: [MEXT] doubting a 3GPP MIP, because requires SIM, BS, spectrum, code (was: Well-known problem with authentication/etc. in wireless networks) X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 17:16:21 -0000 Le 26/08/2011 00:12, Pete McCann a écrit : > Hi, Julien, > > On Thu, Aug 25, 2011 at 5:02 PM, Julien > Laganier wrote: >> Yes, EAP authentication for IKEv2. Yes the MN needs to attach to >> the network first, as hosts currently do today already. > > Right. I think Charlie was asking whether MIP could be the network > access authentication protocol. I read that so too. I have a side note. I have a big doubt about making Mobile IP at IETF more attractive to 3GPP, be that in the security domain (EAP, access control) or any other. Specifying IETF protocol is often backed by significant implementation effort. And it is hard to do implementation effort when prerequisite tools are: (0) licensed spectrum, (1) a SIM card paid subscription, (2) a real 3GPP Base Station and (3) operator's source code, compared to implementation effort using cheap WiFi equipment, cheap-free open source code and unlicensed spectrum. I fail to see how a better MIP could be designed for 3GPP if a large number of implementers don't have access to these tools. Or maybe speculating, logically extending, behaviour on WiFi to 3GPP - once again. That is why I doubt an effort to make Mobile IP more attractive to 3GPP could happen at IETF. (this is not to say MIP is not good for mobility - it is very good when handing over from 3GPP link to e.g. WiFi, from one operator to another). (also, at various points in time I personally did have access to these tools but no intention could there be to talk at IETF about the inner workings of these tools, nor to modify them). Alex > >>> It may be interesting to look at whether access authentication >>> and mobility management can be combined. >> >> I don' t know what problem we would be solving by combining the >> two. > > Making initial establishment of the SA with the HA (upon network > attachment) more efficient. Making handovers faster and more > efficient by reducing the number of round-trip messages required. > > -Pete _______________________________________________ MEXT mailing > list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext > From charliep@computer.org Mon Aug 29 11:48:29 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210E921F8CDD for ; Mon, 29 Aug 2011 11:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHnMPEO89rmv for ; Mon, 29 Aug 2011 11:48:28 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8E75621F8C96 for ; Mon, 29 Aug 2011 11:48:28 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.96.89]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Qy6u2-0002gy-0C; Mon, 29 Aug 2011 14:49:46 -0400 Message-ID: <4E5BDF45.9040702@computer.org> Date: Mon, 29 Aug 2011 11:49:41 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad863f51f62756571665039a5e2a1aaac138350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: Julien Laganier , mext , Pete McCann Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 18:48:29 -0000 Hello Hesham, On 8/27/2011 2:40 AM, Hesham Soliman wrote: > First, access authentication and HA auth are two > completely different issues for different purposes. That is highly debatable, and I certainly disagree that they are required to be completely separate. Moreover, the authentication often relies on access to the same authentication server. Doesn't sound completely separate to me! Why is it good to enforce multiple round trips to bottleneck systems just to ask the same question multiple times? Actually, I know the answer: "That's just how it's done". Do you _really_ think that ought to be good enough? I think these serialized authentications are a major impediment to good performance, and that proper design would maintain robust security while enabling much better performance. And, to reiterate, I strongly disagree that tunnel redirection is fundamentally required to be separated from establishing access to the wireless media. Do you agree that we should give up on single-radio? What about multi-radio devices with N interfaces? Should we just run all the network interfaces? Sounds bad to me. > Second, I don't think MIPv6 is not deployed > because it adds a one-off SA setup with the HA. The above authentications are not "one-off". They happen at every new WiFi network, or more generally at every new point of attachment to a different radio access technology. I'm fine with setting up a SA with the home agent, but that's not the problem. > I wish that was the reason. Well, in your opinion what _is_ the reason? Regards, Charlie P. From charliep@computer.org Mon Aug 29 11:50:01 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF1821F8CE5 for ; Mon, 29 Aug 2011 11:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCMcEsSdOK6k for ; Mon, 29 Aug 2011 11:50:01 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6296121F8CDE for ; Mon, 29 Aug 2011 11:50:01 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.96.89]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Qy6vb-0000Qu-Vo; Mon, 29 Aug 2011 14:51:24 -0400 Message-ID: <4E5BDFA8.9060509@computer.org> Date: Mon, 29 Aug 2011 11:51:20 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Behcet Sarikaya References: <1314642743.56913.YahooMailNeo@web111403.mail.gq1.yahoo.com> In-Reply-To: <1314642743.56913.YahooMailNeo@web111403.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86c30f00d7db56a5081af5e8afcd314f50350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: mext Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 18:50:01 -0000 Hello Behcet, On 8/29/2011 11:32 AM, Behcet Sarikaya wrote: > Folks, let's get back to what was decided in IETF 81 Wednesday morning meeting. O.K. Which part do you think we should discuss first? Regards, Charlie P. From behcetsarikaya@yahoo.com Wed Aug 31 08:16:58 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B890721F8B1B for ; Wed, 31 Aug 2011 08:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yy0Wai1Cyu7i for ; Wed, 31 Aug 2011 08:16:57 -0700 (PDT) Received: from nm23-vm0.bullet.mail.sp2.yahoo.com (nm23-vm0.bullet.mail.sp2.yahoo.com [98.139.91.224]) by ietfa.amsl.com (Postfix) with SMTP id B844021F8862 for ; Wed, 31 Aug 2011 08:16:57 -0700 (PDT) Received: from [98.139.91.61] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 31 Aug 2011 15:18:25 -0000 Received: from [98.139.91.32] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 31 Aug 2011 15:18:25 -0000 Received: from [127.0.0.1] by omp1032.mail.sp2.yahoo.com with NNFMP; 31 Aug 2011 15:18:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 919046.38622.bm@omp1032.mail.sp2.yahoo.com Received: (qmail 84272 invoked by uid 60001); 31 Aug 2011 15:18:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1314803905; bh=iuHCMkoxuzJQSRTVHIPTksIU+atH5wkPdeYPJxGHUHs=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rWfMGhreSR+IUXEurX4CaQ/0gevRKDI244uuoZUJsAjbBZlhbBXZRF4JGE5E6t5xQvCfSPz/CX9xjJhOve2TO99myn64pWemJXCay1COk/4Scaxf7CnJMorW72tki7EYSBoa4oTEmBPX6x9IZbaEgDX5E7vx+yS8c21LPJsLbzo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IjKme9m9/fmTPKDvb70Wv6CEBrQ5WHP9Corx1xUgxPfkWN6nh4SrkQrmeinYzdeDlBoghfdsgy25s35tVUwIpblxyD49f9s0NqU3k0T/BITWDsP2by14b+xzmEKq7YfutbpjF8JVEpB+w3RoK8UHoWLmPS3xwRlwoGpbxBxIJm0=; X-YMail-OSG: KhWdK.sVM1lwItuYfHkIw2JgZHBhfNKN3Nz9dpteEuhknwn 1__FtYnm_c_m55ssnWy0_.KHpcituwhcUUWlFM98cxEPAem4dRs14kFZILjo GH7StAyzXQlxq868_PeLFEfxzEUf7vAxnFgOVfXmxXTgqdN6hTjRXfE._NQ0 4q3LF19MLjItI.qWCQdCDqb50tZovNiKnjxeKIdMRwSQjRvibwxiGyEYcrt4 5SorugZUa39XhYGYiuKJkQinXfjK24H_QgZFItIY2sSC5Fa6QRvEZy40bPRV LwP.jc5HHtX8QJeeATq3YcVKHxTpOK09o.YzxmEi2I5Sgxm_5XdhPI3SN9DE 7eoP5Va3_V3mlaRm2B7N4v.Ww87Fb_lxsaU_IBqLGnCCs0b7u8bjnBYuO8DL yFpeCtndIBNkXPCFvuoFNTfcybPAEcFXkc1y53iUokS5notFf3HMJ_Qp.WfI lALyjwNY- Received: from [50.58.7.243] by web111401.mail.gq1.yahoo.com via HTTP; Wed, 31 Aug 2011 08:18:25 PDT X-Mailer: YahooMailWebService/0.8.113.315625 References: <1314642743.56913.YahooMailNeo@web111403.mail.gq1.yahoo.com> <4E5BDFA8.9060509@computer.org> Message-ID: <1314803905.83081.YahooMailNeo@web111401.mail.gq1.yahoo.com> Date: Wed, 31 Aug 2011 08:18:25 -0700 (PDT) From: Behcet Sarikaya To: "charliep@computer.org" In-Reply-To: <4E5BDFA8.9060509@computer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 15:16:58 -0000 Hi Charlie,=0AMaybe we are overreacting.=0AIPv6 has not picked up yet, curr= ently IPv6 traffic seems to be less than 2% of IPv4 traffic. More time is n= eeded for IPv6 deployment which could be followed by IPv6 mobility deployme= nt.=0A=0ARegards,=0A=0ABehcet=0A=0A> =0A> Hello Behcet,=0A> =0A> On 8/29/20= 11 11:32 AM, Behcet Sarikaya wrote:=0A> =0A>> Folks, let's get back to wha= t was decided in IETF 81 Wednesday morning =0A> meeting.=0A> =0A> O.K.=A0 W= hich part do you think we should discuss first?=0A> =0A> Regards,=0A> Charl= ie P.=0A> =0A> _______________________________________________=0A> MEXT mai= ling list=0A> MEXT@ietf.org=0A> https://www.ietf.org/mailman/listinfo/mext= =0A> From charliep@computer.org Wed Aug 31 09:39:13 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C8221F8D60 for ; Wed, 31 Aug 2011 09:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5C-DRNd5Et5 for ; Wed, 31 Aug 2011 09:39:13 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4833721F8D29 for ; Wed, 31 Aug 2011 09:39:13 -0700 (PDT) Received: from [138.111.58.2] (helo=[172.17.52.50]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1QynqE-0008To-Ma; Wed, 31 Aug 2011 12:40:42 -0400 Message-ID: <4E5E6407.6000904@computer.org> Date: Wed, 31 Aug 2011 09:40:39 -0700 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Behcet Sarikaya References: <1314642743.56913.YahooMailNeo@web111403.mail.gq1.yahoo.com><4E5BDFA8.9060509@computer.org> <1314803905.83081.YahooMailNeo@web111401.mail.gq1.yahoo.com> In-Reply-To: <1314803905.83081.YahooMailNeo@web111401.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86e7610ae1b54247d1e0d7ad383828c47a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: Behcet Sarikaya , mext Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem withauthentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: charliep@computer.org List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:39:13 -0000 Hello Behcet, On 8/31/2011 8:18 AM, Behcet Sarikaya wrote: > Maybe we are overreacting. > IPv6 has not picked up yet, currently IPv6 traffic seems to be less > than 2% of IPv4 traffic. That's less than 0.2%. It's pitiful. > More time is needed for IPv6 deployment which could be followed by > IPv6 mobility deployment. More time is needed for deployment, but we are behind on what is needed for standardization. As I discussed before, unless we provide a credible alternative, we are looking forward to extraordinarily complicated and rickety systems (per application!) (per RAT!) that have high operational expense. It does not at all bode well for the end-users (e.g., you and me). We ought to act ASAP. Regards, Charlie P. >> Hello Behcet, >> >> On 8/29/2011 11:32 AM, Behcet Sarikaya wrote: >> >>> Folks, let's get back to what was decided in IETF 81 Wednesday morning >> meeting. >> >> O.K. Which part do you think we should discuss first? >> >> Regards, >> Charlie P. >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From julien.ietf@gmail.com Wed Aug 31 12:10:21 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A615D21F8E3A for ; Wed, 31 Aug 2011 12:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPgzSRpK1Djg for ; Wed, 31 Aug 2011 12:10:18 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E363421F8CFD for ; Wed, 31 Aug 2011 12:10:14 -0700 (PDT) Received: by wyg8 with SMTP id 8so889206wyg.31 for ; Wed, 31 Aug 2011 12:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KYlvr2dh3oa3CzgH9blH4qo9d5oQ5WQ63pbM8ApJc30=; b=DT9+CP+2xzuUEfwHRr6T6tViyM23hZBv/4LN7wTLMDTZ7//aS3MieUgY1HynyCjGpc nsvVEEtXCXWtLEtsWXUegvE8V5GHWfjc0DU6iQW76YCFdGrQeVncPmhG7pST6T8+aIb7 phJ7tfuBnlZnq8FIPgOr0QCBHLrAvfILYzyJo= MIME-Version: 1.0 Received: by 10.227.168.139 with SMTP id u11mr712099wby.14.1314817904026; Wed, 31 Aug 2011 12:11:44 -0700 (PDT) Received: by 10.227.27.141 with HTTP; Wed, 31 Aug 2011 12:11:43 -0700 (PDT) In-Reply-To: <4E5BDF45.9040702@computer.org> References: <4E5BDF45.9040702@computer.org> Date: Wed, 31 Aug 2011 12:11:43 -0700 Message-ID: From: Julien Laganier To: charliep@computer.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Pete McCann , mext Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 19:10:22 -0000 Hello Charlie, Mutual authentication between the MN and the HA is only required at binding creation to set-up the MIPv6 security association that is keyed with the Home Address; the same security association is then used to protect further binding updates. Thus there is no serialization of authentication used for network access and MIPv6. Whether or not network access authentication has to be repeated at every attachment to a new network is also not a given. There are a certain number of optimizations that avoid re-running full network access authentication procedures. In any case I would like to note that the issues in that space seems to be not specific to MIPv6/MEXT and more appropriately belongs to different fora, e.g., PANA for IETF-specified network access authentication, the security area for what pertains to authentication mechanism per se, or the SDO in charge of the specific underlying technology encountering problem. Let's try to focus discussions on this mailing lists to what we are chartered to work on. Regards, --julien On Mon, Aug 29, 2011 at 11:49 AM, Charles E. Perkins wrote: > Hello Hesham, > > On 8/27/2011 2:40 AM, Hesham Soliman wrote: > >> First, access authentication and HA auth are two >> completely different issues for different purposes. > > That is highly debatable, and I certainly disagree that > they are required to be completely separate. =A0Moreover, > the authentication often relies on access to the same > authentication server. =A0Doesn't sound completely separate > to me! =A0Why is it good to enforce multiple round trips > to bottleneck systems just to ask the same question > multiple times? =A0Actually, I know the answer: > "That's just how it's done". =A0Do you _really_ think > that ought to be good enough? > > I think these serialized authentications are a major > impediment to good performance, and that proper design > would maintain robust security while enabling much > better performance. =A0And, to reiterate, I strongly > disagree that tunnel redirection is fundamentally > required to be separated from establishing access > to the wireless media. > > Do you agree that we should give up on single-radio? > > What about multi-radio devices with N interfaces? > Should we just run all the network interfaces? > Sounds bad to me. > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Second, I don't think MIPv6 is not de= ployed >> because it adds a one-off SA setup with the HA. > > The above authentications are not "one-off". =A0They happen > at every new WiFi network, or more generally at every new > point of attachment to a different radio access technology. > I'm fine with setting up a SA with the home agent, but that's > not the problem. > >> I wish that was the reason. > > Well, in your opinion what _is_ the reason? > > Regards, > Charlie P. > > From mccap@petoni.org Wed Aug 31 16:44:12 2011 Return-Path: X-Original-To: mext@ietfa.amsl.com Delivered-To: mext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C2A21F8B84 for ; Wed, 31 Aug 2011 16:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymLQpPsIGlCT for ; Wed, 31 Aug 2011 16:44:11 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A19421F8B35 for ; Wed, 31 Aug 2011 16:44:10 -0700 (PDT) Received: by bkar4 with SMTP id r4so1626515bka.31 for ; Wed, 31 Aug 2011 16:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petoni.org; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tgF8HnJyOJkC1gUQLVKIa+imR5EXJKevp7+faLMB7to=; b=JvPJqw4ibBXJ5kNGyOuFZrR0mTywCYA3fy3pJD9Zq4z9k3Q/jAJcokA2/Sd5MB5C7M YL5F+A+SoY60ErmkKUP/TvUYWPuglJiQXmOuw6ZV/mKHZY42uG74mMA8jPbMXAvGQYPE kN6N4KPtT14u1BkwB4zhdRkoiJXuWsChG9k4o= MIME-Version: 1.0 Received: by 10.204.146.137 with SMTP id h9mr544921bkv.316.1314834341673; Wed, 31 Aug 2011 16:45:41 -0700 (PDT) Received: by 10.205.81.205 with HTTP; Wed, 31 Aug 2011 16:45:41 -0700 (PDT) X-Originating-IP: [68.45.157.93] In-Reply-To: References: <4E5BDF45.9040702@computer.org> Date: Wed, 31 Aug 2011 19:45:41 -0400 Message-ID: From: Pete McCann To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Cc: charliep@computer.org, mext Subject: Re: [MEXT] [!! SPAM] Re: Well-known problem with authentication/etc. in wireless networks X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 23:44:12 -0000 Julien, On Wed, Aug 31, 2011 at 3:11 PM, Julien Laganier wrote: > Hello Charlie, > > Mutual authentication between the MN and the HA is only required at > binding creation to set-up the MIPv6 security association that is > keyed with the Home Address; the same security association is then > used to protect further binding updates. Thus there is no > serialization of authentication used for network access and MIPv6. Many of the DMM proposals seem to contemplate getting a new HA upon every new attachment to the network. It seems to me that it would be in scope to consider optimization of the setup of the security association with the newly met HA and that this could somehow leverage the network access authentication that has just taken place. -Pete