From mext-bounces@ietf.org Sun Aug 05 15:28:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHllg-00013Y-7V; Sun, 05 Aug 2007 15:28:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHlle-00013R-GT for mext@ietf.org; Sun, 05 Aug 2007 15:27:58 -0400 Received: from amailer.gwdg.de ([134.76.10.18]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHlld-0000Qa-NS for mext@ietf.org; Sun, 05 Aug 2007 15:27:58 -0400 Received: from p5b03af08.dip0.t-ipconnect.de ([91.3.175.8] helo=[192.168.0.183]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1IHllc-0000TZ-2c for mext@ietf.org; Sun, 05 Aug 2007 21:27:56 +0200 Message-ID: <46B624B8.7090901@cs.uni-goettingen.de> Date: Sun, 05 Aug 2007 21:27:52 +0200 From: Xiaoming Fu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated: Id:xfu X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Subject: [MEXT] Call for participation: MobiArch'07 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org Dear all, Hope the following workshop call for participation be of interest for the group here. Best regards, Xiaoming ------------------------------------------------------------------------------------------------------------------------- CALL FOR PARTICIPATION --------------------------------------------------------------------------------------------------- MobiArch 2007 - The Second International Workshop on Mobility in the Evolving Internet Architecture, August 27, 2007, Kyoto, Japan sponsored by ACM SIGCOMM in cooperation with ACM SIGMOBILE http://www.sigcomm.org/sigcomm2007/mobiarch/ in conjunction with ACM SIGCOMM 2007, August 27-31, 2007 --------------------------------------------------------------------------------------------------- Two keynotes will be speaking on latest advances and selected topics in the emerging and future wireless/mobile network architectures. They are: Krishan K. Sabnani (Bell Labs): Key Technologies and Architectures for the Next-Generation Mobile Networks Victor Bahl (Microsoft Research): Are Self Managing Networks in Our Future? Further information please find in http://user.informatik.uni-goettingen.de/~mobiarch/2007/keynote.html Besides presentations and discussions of 11 technical papers selected through a rigorous peer-review process, there will be a panel session on the deployment issues of 4G and beyond, led by active researchers from both the industry and academia. Registration information is available at http://www.sigcomm.org/sigcomm2007/registration.html We look forward to seeing you at the MobiArch'07 workshop in three weeks! - The MobiArch'07 organizating team --------------------------------------------------------------------------------------------------- MobiArch'07 Program http://user.informatik.uni-goettingen.de/~mobiarch/2007/#program 9:00 - 9:10 Welcome messages and introduction: Chairs 9:10 - 10:05 Session "Mobility Architectures" Mobility as an Integrated Service Through the Use of Naming Randall Atkinson (Extreme Networks, USA); Saleem Bhatti (University of St Andrews, United Kingdom); Stephen Hailes (University College London, United Kingdom) An Architecture for Seamless Mobility in Spontaneous Wireless Mesh Networks Franck Rousseau (IMAG, France); Martin Heusse (LSR IMAG, France); Yan Grunenberger (LSR Laboratory, France); Vincent Untz (LSR-IMAG Laboratory, France); Eryk Schiller (INPG - Institut National Politechnique, France); Paul Starzetz (LSR, France); Fabrice Theoleyre (INP Grenoble, France); Olivier Alphand (INP Grenoble, France); Andrzej Duda (INP Grenoble, LIG Laboratory, France) A Framework for Evolutionary Networking Gautam Gupta (Indian Institute of Technology Madras, India); S.v. Raghavan (Indian Institute of Technology, Madras, Chennai, India) 10:05 - 11:00 Keynote speech 1 11:15 - 12:10 Session "Locator/Identifier Separation" Performance of Host Identity Protocol on Lightweight Hardware Andrey Khurri (HIIT, Finland); Ekaterina Vorobyeva (HIIT, Finland); Andrei Gurtov (Helsinki Institute for Information Technology, Finland) Evaluating the Benefits of the Locator/Identifier Separation Bruno Quoitin (Universite Catholique de Louvain, Belgium); Luigi Iannone (Université Catholique de Louvain, Belgium); Cédric de Launois (Université catholique de Louvain, Belgium); Olivier Bonaventure (Université Catholique de Louvain, Belgium) Embedding Identity in Mobile Environments Rui Aguiar (Universidade de Aveiro, Portugal); Alfredo Matos (Universidade de Aveiro, Portugal); Susana Sargento (Universidade de Aveiro, Portugal, Portugal) 13:15 - 13:50 Session "Delay Tolerant Networks" Distributed Community Detection in Delay Tolerant Networks Pan Hui (Univeristy of Cambridge, United Kingdom); Eiko Yoneki (University of Cambridge, United Kingdom); Shu-Yan Chan (University of Cambridge, United Kingdom); Jon Crowcroft (University of Cambridge, United Kingdom) Redundancy and Distributed Caching in Mobile DTNs Mikko Pitkanen (Helsinki Institute of Physics, Finland); Joerg Ott (Helsinki University of Technology, Finland) 13:55 - 14:50 Keynote speech 2 15:05 - 16:00 Panel session: Stagnation of deployment of 4G and beyond? Chair: Ryuji Wakikawa (Keio University, JP) Panelists: Lars Eggert (Nokia Research Center, FI) Yoshiro Ohba (Toshiba Research, US) Joerg Ott (Helsinki University of Technology, FI) K. K. Ramakrishnan (AT&T Labs, US) Jun Takei (Intel Corporation, JP) 16:05 - 17:00 Session "Handover, Multihoming and Data Management" Kerberized Handover Keying: A Media-Independent Handover Key Management Architecture Yoshihiro Ohba (TARI, USA); Subir Das (Telcordia Technologies, USA); Ashutosh Dutta (Telcordia Technologies, USA) A Policy Management Framework for Flow Distribution on Multihomed End Nodes Koshiro Mitsuya (Keio University, Japan); Romain Kuntz (Louis Pasteur University, France); Shinta Sugimoto (Keio University, Japan); Ryuji Wakikawa (Keio University, Japan); Jun Murai (Keio University, Japan) The Case for a Unified Extensible Data-centric Mobility Infrastructure Yun Mao (University of Pennsylvania, USA); Boon Thau Loo (University of Pennsylvania, USA); Zachary Ives (University of Pennsylvania, USA); Jonathan Smith (University of Pennsylvania, USA) _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Mon Aug 06 18:14:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIAqh-0001eV-H4; Mon, 06 Aug 2007 18:14:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIAqf-0001eH-GO; Mon, 06 Aug 2007 18:14:49 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIAqe-0004Pf-0P; Mon, 06 Aug 2007 18:14:49 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l76MEEQQ021877; Tue, 7 Aug 2007 01:14:17 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 01:14:15 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 17:14:01 -0500 Received: from 172.19.244.162 ([172.19.244.162]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 6 Aug 2007 22:14:01 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 06 Aug 2007 17:14:07 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List , Message-ID: Thread-Topic: WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt Thread-Index: AcfYdxsOWcs/5kRqEdy1KAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Aug 2007 22:14:02.0036 (UTC) FILETIME=[18192F40:01C7D877] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Gopal Dommety , thierry.ernst@inria.fr, Basavaraj Patil , tj@kniveton.com Subject: [Mip6] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, This is a joint working group last call between for I-D: Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) URL: http://ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-05.txt This I-D is a standards track document and is a joint MIP6/NEMO WG I-D. Please review the ID and submit your comments to the MIP6 and NEMO WG mailing lists by August 22nd, 07. -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Aug 10 06:26:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJRhL-0005KE-7U; Fri, 10 Aug 2007 06:26:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJRhJ-00059n-CO for mip6@ietf.org; Fri, 10 Aug 2007 06:26:25 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IJRhI-0001Xu-VZ for mip6@ietf.org; Fri, 10 Aug 2007 06:26:25 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1186741583!24075722!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 2005 invoked from network); 10 Aug 2007 10:26:23 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-6.tower-128.messagelabs.com with SMTP; 10 Aug 2007 10:26:23 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l7AAQJCC019965; Fri, 10 Aug 2007 03:26:19 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l7AAQInq020671; Fri, 10 Aug 2007 05:26:18 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l7AAQGjh020580; Fri, 10 Aug 2007 05:26:17 -0500 (CDT) Message-ID: <46BC3D42.6060609@gmail.com> Date: Fri, 10 Aug 2007 12:26:10 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000764-3, 09/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Mobile IPv6 Mailing List Subject: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I think the current DS-MIPv6 doc supports a very limited scope of deployment/applicability and, within its class of goals, has competitors more advanced technologically and with wider deployments (IPv6-transition-mechanisms, STUN, ICE). Alex Basavaraj Patil wrote: > Hello, > > This is a joint working group last call between for I-D: > Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) > > > URL: > http://ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-05.txt > > This I-D is a standards track document and is a joint MIP6/NEMO WG I-D. > > Please review the ID and submit your comments to the MIP6 and NEMO WG > mailing lists by August 22nd, 07. > > -Raj > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 13 11:25:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbnD-0008LD-ES; Mon, 13 Aug 2007 11:25:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbnB-0008GK-6d; Mon, 13 Aug 2007 11:25:17 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKbn9-0008JF-TS; Mon, 13 Aug 2007 11:25:17 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l7DFUfMG012923; Mon, 13 Aug 2007 10:30:41 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:25:10 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:25:09 -0500 Message-ID: <46C077DE.6010702@ericsson.com> Date: Mon, 13 Aug 2007 11:25:18 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2007 15:25:09.0792 (UTC) FILETIME=[22A21200:01C7DDBE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: nemo@ietf.org, Gopal Dommety , tj@kniveton.com, Basavaraj Patil , Mobile IPv6 Mailing List , thierry.ernst@inria.fr Subject: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, I have gone through the latest version of this draft. I think this draft is very useful and I believe that the draft is ready to advance to the IESG. Thanks Suresh Basavaraj Patil wrote: > Hello, > > This is a joint working group last call between for I-D: > Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) > > > URL: > http://ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-05.txt > > This I-D is a standards track document and is a joint MIP6/NEMO WG I-D. > > Please review the ID and submit your comments to the MIP6 and NEMO WG > mailing lists by August 22nd, 07. > > -Raj > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 13 11:27:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbp6-0003VM-Is; Mon, 13 Aug 2007 11:27:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbp4-0003VG-IY for mip6@ietf.org; Mon, 13 Aug 2007 11:27:14 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKbp3-0008Mz-8h for mip6@ietf.org; Mon, 13 Aug 2007 11:27:14 -0400 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l7DFVDet016021; Mon, 13 Aug 2007 10:31:14 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:27:11 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:27:11 -0500 Message-ID: <46C07857.1050109@ericsson.com> Date: Mon, 13 Aug 2007 11:27:19 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt References: <46BC3D42.6060609@gmail.com> In-Reply-To: <46BC3D42.6060609@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Aug 2007 15:27:11.0498 (UTC) FILETIME=[6B2CEEA0:01C7DDBE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex, I think the IPv6 transition mechanisms are complementary to DSMIPv6 and not necessarily competitors. DSMIPv6 allows for some scenarios which the IPv6 transition mechanisms cannot support. e.g. Which IPv6 mechanism you mentioned would allow you to have a IPv4 home address over MIPv6 signaling? Cheers Suresh Alexandru Petrescu wrote: > I think the current DS-MIPv6 doc supports a very limited scope of > deployment/applicability and, within its class of goals, has competitors > more advanced technologically and with wider deployments > (IPv6-transition-mechanisms, STUN, ICE). > > Alex > > Basavaraj Patil wrote: >> Hello, >> >> This is a joint working group last call between for I-D: >> Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) >> >> >> URL: >> http://ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-05.txt >> >> This I-D is a standards track document and is a joint MIP6/NEMO WG I-D. >> >> Please review the ID and submit your comments to the MIP6 and NEMO WG >> mailing lists by August 22nd, 07. >> >> -Raj >> >> >> > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Aug 14 00:52:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKoO8-0006Lw-4S; Tue, 14 Aug 2007 00:52:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKoO6-0006Lq-Sj for mip6@ietf.org; Tue, 14 Aug 2007 00:52:14 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKoO4-0004Ck-Sv for mip6@ietf.org; Tue, 14 Aug 2007 00:52:14 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7E4q9Wc023003; Tue, 14 Aug 2007 07:52:09 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 07:51:53 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 23:51:51 -0500 Received: from 10.241.59.111 ([10.241.59.111]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Aug 2007 04:51:50 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 13 Aug 2007 23:51:50 -0500 Subject: Re: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt From: Basavaraj Patil To: Suresh Krishnan , Alexandru Petrescu Message-ID: Thread-Topic: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt Thread-Index: AcfeLtNnEhpI8UoiEdyAwgARJNUNiA== In-Reply-To: <46C07857.1050109@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Aug 2007 04:51:51.0239 (UTC) FILETIME=[D424C570:01C7DE2E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I agree with Suresh. I believe we have discussed this topic before. There are many transition mechanisms that have been defined. For MIP6 deployment the WG believes this is an optimal solution since it requires only additional capability in the MN and HA. Hence there is no reason to debate or compare the pros/cons of DS-MIP6 with other transition mechanisms. -Raj On 8/13/07 10:27 AM, "ext Suresh Krishnan" wrote: > Hi Alex, > I think the IPv6 transition mechanisms are complementary to DSMIPv6 > and not necessarily competitors. DSMIPv6 allows for some scenarios which > the IPv6 transition mechanisms cannot support. e.g. Which IPv6 mechanism > you mentioned would allow you to have a IPv4 home address over MIPv6 > signaling? > > Cheers > Suresh > > Alexandru Petrescu wrote: >> I think the current DS-MIPv6 doc supports a very limited scope of >> deployment/applicability and, within its class of goals, has competitors >> more advanced technologically and with wider deployments >> (IPv6-transition-mechanisms, STUN, ICE). >> >> Alex >> >> Basavaraj Patil wrote: >>> Hello, >>> >>> This is a joint working group last call between for I-D: >>> Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) >>> >>> >>> URL: >>> http://ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-05.txt >>> >>> This I-D is a standards track document and is a joint MIP6/NEMO WG I-D. >>> >>> Please review the ID and submit your comments to the MIP6 and NEMO WG >>> mailing lists by August 22nd, 07. >>> >>> -Raj >>> >>> >>> >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Aug 14 03:46:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKr6t-00071P-8b; Tue, 14 Aug 2007 03:46:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKr6s-0006wJ-Dq for mip6@ietf.org; Tue, 14 Aug 2007 03:46:38 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IKr6r-0007iC-3q for mip6@ietf.org; Tue, 14 Aug 2007 03:46:38 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-153.messagelabs.com!1187077595!5187694!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 8721 invoked from network); 14 Aug 2007 07:46:36 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-9.tower-153.messagelabs.com with SMTP; 14 Aug 2007 07:46:36 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l7E7kZXs008529; Tue, 14 Aug 2007 00:46:35 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l7E7kO6K024224; Tue, 14 Aug 2007 02:46:24 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l7E7kMuj024164; Tue, 14 Aug 2007 02:46:23 -0500 (CDT) Message-ID: <46C15DC8.1030305@gmail.com> Date: Tue, 14 Aug 2007 09:46:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Suresh Krishnan Subject: Re: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt References: <46BC3D42.6060609@gmail.com> <46C07857.1050109@ericsson.com> In-Reply-To: <46C07857.1050109@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000765-1, 13/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Suresh Krishnan wrote: > Hi Alex, I think the IPv6 transition mechanisms are complementary to > DSMIPv6 and not necessarily competitors. Would DS-MIPv6 work with IPv4-over-IPv6 rfc2473? It doesn't cite it. > DSMIPv6 allows for some scenarios which the IPv6 transition > mechanisms cannot support. e.g. Which IPv6 mechanism you mentioned > would allow you to have a IPv4 home address over MIPv6 signaling? Not sure what you're asking... are you asking "which other protocol is DS-MIPv6"? Otherwise, if genuinely interested on how to transport IPv4 over IPv6 then one would look at rfc2473, the same RFC which offers IPv6 over IPv6 for MIPv6. It is cited by rfc3775 but ignored by draft-ietf-mip6-nemo-v4traversal-05.txt. > DSMIPv6 allows for some scenarios which the IPv6 transition > mechanisms cannot support... I think they are very limited. Networks that support only native IPv6 are very rare and are most often _core_ networks, not access networks. (In this respect, if I remember correctly, DS-MIPv6 does not allow the HA to be native IPv6; it forces the HA to be IPv4 addressable. Or, it's most probably the HA to be deployed on a IPv6-only network.) What I'm trying to say is that DS-MIPv6 is not addressing some important deployment scenarios (its NAT traversal doesn't support dst-port-changing NATs, doesn't traverse HTTP proxy gateways, doesn't negotiate the traversal mechanism) and it addresses some scenarios which are limited in scope. Look at it this way: deploy a DS-MIPv6 HA and take a MN running DS-MIPv6 and go to a publicly deployed wifi hotspot: most probably it won't work. Most probably because of the typical NAT/firewall/httpproxy being in place. Now take a recent VoIP MN with the most recent traversal software and go to the same wifi hotspot and chances are one is reachable at his/her permanent identifier. If DS-MIPv6 offered traversal mechanisms as powerful as VoIP's then I'd be very happy with it. Alex > > Cheers Suresh > > Alexandru Petrescu wrote: >> I think the current DS-MIPv6 doc supports a very limited scope of >> deployment/applicability and, within its class of goals, has >> competitors more advanced technologically and with wider >> deployments (IPv6-transition-mechanisms, STUN, ICE). >> >> Alex >> >> Basavaraj Patil wrote: >>> Hello, >>> >>> This is a joint working group last call between for I-D: Mobile >>> IPv6 support for dual stack Hosts and Routers (DSMIPv6) >>> >>> >>> URL: >>> http://ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-05.txt >>> >>> >>> >>> >>> >>> This I-D is a standards track document and is a joint MIP6/NEMO >>> WG I-D. >>> >>> Please review the ID and submit your comments to the MIP6 and >>> NEMO WG mailing lists by August 22nd, 07. >>> >>> -Raj >>> >>> >>> >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> >> >> >> >> _______________________________________________ Mip6 mailing list >> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Aug 14 03:55:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKrF6-0003yG-1k; Tue, 14 Aug 2007 03:55:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKrF5-0003w7-66 for mip6@ietf.org; Tue, 14 Aug 2007 03:55:07 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IKrF3-0007tQ-Sl for mip6@ietf.org; Tue, 14 Aug 2007 03:55:07 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1187078104!24443051!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 21848 invoked from network); 14 Aug 2007 07:55:04 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 14 Aug 2007 07:55:04 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l7E7t4Jl018012; Tue, 14 Aug 2007 00:55:04 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l7E7t3OV025764; Tue, 14 Aug 2007 02:55:03 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l7E7t0oW025674; Tue, 14 Aug 2007 02:55:01 -0500 (CDT) Message-ID: <46C15FCF.4020708@gmail.com> Date: Tue, 14 Aug 2007 09:54:55 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000765-1, 13/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Basavaraj Patil wrote: > I agree with Suresh. I believe we have discussed this topic before. > There are many transition mechanisms that have been defined. For MIP6 > deployment the WG believes this is an optimal solution since it > requires only additional capability in the MN and HA. Hence there is > no reason to debate or compare the pros/cons of DS-MIP6 with other > transition mechanisms. Raj, right, we've discussed these in the past. I'm not looking at debating and comparing. Just take the best from both. ds-mipv6 would benefit from citing a ipv4-over-ipv6 or a ipv6-over-ipv6 document. Because it actually uses it. Without it it won't work. Why don't you want to refer this? Do you have other-than-rfc2473 in mind? ds-mipv6 would benefit from more powerful nat/firewall/httpproxy standard traversal mechanisms. Why don't you want to refer this? Do you have other-than-stun-ice in mind? Non-standard traversal ala skype? Ignoring these is leaving place for possibly bad interpretations. Alex > > -Raj > > > On 8/13/07 10:27 AM, "ext Suresh Krishnan" > wrote: > >> Hi Alex, I think the IPv6 transition mechanisms are complementary >> to DSMIPv6 and not necessarily competitors. DSMIPv6 allows for some >> scenarios which the IPv6 transition mechanisms cannot support. >> e.g. Which IPv6 mechanism you mentioned would allow you to have a >> IPv4 home address over MIPv6 signaling? >> >> Cheers Suresh >> >> Alexandru Petrescu wrote: >>> I think the current DS-MIPv6 doc supports a very limited scope of >>> deployment/applicability and, within its class of goals, has >>> competitors more advanced technologically and with wider >>> deployments (IPv6-transition-mechanisms, STUN, ICE). >>> >>> Alex >>> >>> Basavaraj Patil wrote: >>>> Hello, >>>> >>>> This is a joint working group last call between for I-D: >>>> Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) >>>> >>>> >>>> URL: >>>> http://ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-05.txt >>>> >>>> >>>> >>>> This I-D is a standards track document and is a joint MIP6/NEMO >>>> WG I-D. >>>> >>>> Please review the ID and submit your comments to the MIP6 and >>>> NEMO WG mailing lists by August 22nd, 07. >>>> >>>> -Raj >>>> >>>> >>>> >>> >>> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security >>> System. For more information please visit >>> http://www.messagelabs.com/email >>> ______________________________________________________________________ >>> >>> >>> >>> _______________________________________________ Mip6 mailing list >>> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Aug 14 06:58:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKu6Q-0001l9-Of; Tue, 14 Aug 2007 06:58:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKu6P-0001l4-J4 for mip6@ietf.org; Tue, 14 Aug 2007 06:58:21 -0400 Received: from omta02sl.mx.bigpond.com ([144.140.93.154]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKu6O-0005xb-Tk for mip6@ietf.org; Tue, 14 Aug 2007 06:58:21 -0400 Received: from oaamta02sl.mx.bigpond.com ([124.190.104.34]) by omta02sl.mx.bigpond.com with ESMTP id <20070814105817.TTOV14429.omta02sl.mx.bigpond.com@oaamta02sl.mx.bigpond.com>; Tue, 14 Aug 2007 10:58:17 +0000 Received: from PC20005 ([124.190.104.34]) by oaamta02sl.mx.bigpond.com with ESMTP id <20070814105817.OJTY29821.oaamta02sl.mx.bigpond.com@PC20005>; Tue, 14 Aug 2007 10:58:17 +0000 From: "Hesham Soliman" To: "'Alexandru Petrescu'" , "'Suresh Krishnan'" Subject: RE: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt Date: Tue, 14 Aug 2007 20:58:14 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <46C15DC8.1030305@gmail.com> Thread-Index: AcfeR3WTIDlUNy/YQAKatReO4DWYeAAGUQIg X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > Would DS-MIPv6 work with IPv4-over-IPv6 rfc2473? It doesn't cite it. => Of course it does, that's generic tunnelling in IPv6. We can cite it, I'm taking that as a comment not a suggestion for an applicability statement. > > (In this respect, if I remember correctly, DS-MIPv6 does not > allow the > HA to be native IPv6; it forces the HA to be IPv4 addressable. => You raised this point several times and several people told you that this is incorrect. An IPv6 only HA would obviously work for an IPv6 only deployment. It's not that DSMIP mandates a dual stack HA, the requirements come from deployments, if they want a dual stack network then we accomodate that. > What I'm trying to say is that DS-MIPv6 is not addressing > some important > deployment scenarios (its NAT traversal doesn't support > dst-port-changing NATs, => Again, Henrik answered this point many times before. You're the only one who talks about NATs that randomly change port numbers. No one else with NAT experience has mentioned that. If there is a public independent pointer to such NATs then please send it to the list, otherwise we won't consider this issue. doesn't traverse HTTP proxy gateways, => Huh? Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Aug 14 08:11:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKvFQ-0002BX-1H; Tue, 14 Aug 2007 08:11:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKvFO-0002AX-R8 for mip6@ietf.org; Tue, 14 Aug 2007 08:11:42 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKvFO-0001bC-5n for mip6@ietf.org; Tue, 14 Aug 2007 08:11:42 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1187093500!1909923!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 17291 invoked from network); 14 Aug 2007 12:11:40 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-153.messagelabs.com with SMTP; 14 Aug 2007 12:11:40 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l7ECBZWn003424; Tue, 14 Aug 2007 05:11:40 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l7ECBZN3011607; Tue, 14 Aug 2007 07:11:35 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l7ECBXEx011527; Tue, 14 Aug 2007 07:11:33 -0500 (CDT) Message-ID: <46C19BEF.30209@gmail.com> Date: Tue, 14 Aug 2007 14:11:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000765-1, 13/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: 'Mobile IPv6 Mailing List' , 'Alexandru Petrescu' , 'Suresh Krishnan' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham Soliman wrote: >> Would DS-MIPv6 work with IPv4-over-IPv6 rfc2473? It doesn't cite >> it. > > => Of course it does, that's generic tunnelling in IPv6. We can cite > it, I'm taking that as a comment not a suggestion for an > applicability statement. Thanks Hesham, yes please cite it, take it as a comment. >> (In this respect, if I remember correctly, DS-MIPv6 does not allow >> the HA to be native IPv6; it forces the HA to be IPv4 addressable. >> >> > > => You raised this point several times and several people told you > that this is incorrect. An IPv6 only HA would obviously work for an > IPv6 only deployment. It's not that DSMIP mandates a dual stack HA, > the requirements come from deployments, if they want a dual stack > network then we accomodate that. Sorry, I don't think I've made myself clear enough. Some deployments do require that the HA stays IPv6-only and its MNs attach to IPv4-only access networks. A HA that must be dual-stacked in order for its MNs to access IPv4-only networks (what DS-MIPv6 does) has its applicability too, but more limited. >> What I'm trying to say is that DS-MIPv6 is not addressing some >> important deployment scenarios (its NAT traversal doesn't support >> dst-port-changing NATs, > > => Again, Henrik answered this point many times before. You're the > only one who talks about NATs that randomly change port numbers. No > one else with NAT experience has mentioned that. If there is a public > independent pointer to such NATs then please send it to the list, > otherwise we won't consider this issue. I don't have a public independent pointer. It's NAT randomly changing UDP dst port numbers of outgoing packets, not all port numbers. Every 5min (corresponding to a typical 5min voice call, or to a TCP typical connection rfcnumber here). >> doesn't traverse HTTP proxy gateways, > > => Huh? Not sure how to take your question mark, but let me just signal that when one goes to _any_ deployed wifi hotspot one has to deal with http proxy gateways at least as first step of accepting the sales conditions. And then there are the http authenticating proxy gateways that won't let out of network anything but http/s. Widely deployed. DS-MIPv6 doesn't deal with any of these, so it has limited applicability, IMHO. Some STUN/ICE do, so they have larger applicability. Alex > > Hesham > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Aug 14 08:23:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKvQf-0004Uy-Qa; Tue, 14 Aug 2007 08:23:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKvQe-0004UC-Um for mip6@ietf.org; Tue, 14 Aug 2007 08:23:20 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKvQd-0001vr-RF for mip6@ietf.org; Tue, 14 Aug 2007 08:23:20 -0400 Received: from oaamta04sl.mx.bigpond.com ([124.190.104.34]) by omta04sl.mx.bigpond.com with ESMTP id <20070814122316.FYIF4018.omta04sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com>; Tue, 14 Aug 2007 12:23:16 +0000 Received: from PC20005 ([124.190.104.34]) by oaamta04sl.mx.bigpond.com with ESMTP id <20070814122316.YHMB5086.oaamta04sl.mx.bigpond.com@PC20005>; Tue, 14 Aug 2007 12:23:16 +0000 From: "Hesham Soliman" To: "'Alexandru Petrescu'" Subject: RE: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt Date: Tue, 14 Aug 2007 22:23:14 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <46C19BEF.30209@gmail.com> Thread-Index: AcfebEd03Ew1pGwTQL65pGvMnIWpjgAAJRQw X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: 'Mobile IPv6 Mailing List' , 'Suresh Krishnan' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Sorry, I don't think I've made myself clear enough. > > Some deployments do require that the HA stays IPv6-only and its MNs > attach to IPv4-only access networks. > > A HA that must be dual-stacked in order for its MNs to > access IPv4-only > networks (what DS-MIPv6 does) has its applicability too, but > more limited. => I think you're referring to the case that Pascal suggested earlier about splitting the IPv4 stack away from the HA. We discussed this and we didn't think it was worth solving. We haven't heard anyone from the operational areas or from the operator community complaining about the lack of support for this scenario. Every solution is limited to subset of almost infinite scenarios, it's a question of solving the ones that people deploying networks need. We also agreed that if there is a clear need for extensions this can be done separately at a later stage. > > independent pointer to such NATs then please send it to the list, > > otherwise we won't consider this issue. > > I don't have a public independent pointer. > => Ok. I'm afraid, in the absence of any support for this behaviour we can't really consider it. > >> doesn't traverse HTTP proxy gateways, > > > > => Huh? > > Not sure how to take your question mark, but let me just signal that > when one goes to _any_ deployed wifi hotspot one has to deal > with http > proxy gateways at least as first step of accepting the sales > conditions. > > And then there are the http authenticating proxy gateways > that won't let > out of network anything but http/s. Widely deployed. > > DS-MIPv6 doesn't deal with any of these, so it has limited > applicability, IMHO. Some STUN/ICE do, so they have larger > applicability. => You're comparing apples and oranges of course. We're not going to go around admins demands to show people how to hack networks. If they chose not to let anything other than HTTP through then they're aware of what they don't want. We're not going to tunnel MIPv6 in HTTP! For the record, I used hotspots in at least a dozen different countries and not one spot asked me to use an HTTP proxy. Seems like a silly thing to do in a public network. Hesham > > Alex > > > > > Hesham > > > > > > > > > _____________________________________________________________ > _________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > _____________________________________________________________ > _________ > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Aug 14 08:58:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKvyN-0004wk-Bq; Tue, 14 Aug 2007 08:58:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKvyM-0004wf-3g for mip6@ietf.org; Tue, 14 Aug 2007 08:58:10 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKvyL-0003Lj-J9 for mip6@ietf.org; Tue, 14 Aug 2007 08:58:09 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l7ED3fES029667; Tue, 14 Aug 2007 08:03:41 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 07:58:07 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 07:58:06 -0500 Message-ID: <46C1A6EE.1020700@ericsson.com> Date: Tue, 14 Aug 2007 08:58:22 -0400 From: Suresh Krishnan User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt References: <46BC3D42.6060609@gmail.com> <46C07857.1050109@ericsson.com> <46C15DC8.1030305@gmail.com> In-Reply-To: <46C15DC8.1030305@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2007 12:58:07.0014 (UTC) FILETIME=[C242BC60:01C7DE72] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex, Alexandru Petrescu wrote: > Suresh Krishnan wrote: >> Hi Alex, I think the IPv6 transition mechanisms are complementary to >> DSMIPv6 and not necessarily competitors. > > Would DS-MIPv6 work with IPv4-over-IPv6 rfc2473? It doesn't cite it. > The question is, does it need to? My reading of the charter says the solution needs to handle dual stacked nodes (I guess RFC4213). I have no opinions for or against citing other transition mechanisms. > What I'm trying to say is that DS-MIPv6 is not addressing some important > deployment scenarios (its NAT traversal doesn't support > dst-port-changing NATs, doesn't traverse HTTP proxy gateways, doesn't > negotiate the traversal mechanism) and it addresses some scenarios which > are limited in scope. This is a totally different ballgame. The scenarios addressed by this draft are listed in section 1.2. I would consider this section to be analogous to an applicability statement. I am perfectly happy if these scenarios (and only these) are well covered by the draft. Are you saying that this list scenarios of scenarios is incomplete? I think it would be difficult to add to these at this point. > > Look at it this way: deploy a DS-MIPv6 HA and take a MN running DS-MIPv6 > and go to a publicly deployed wifi hotspot: most probably it won't work. > Most probably because of the typical NAT/firewall/httpproxy being in > place. > > Now take a recent VoIP MN with the most recent traversal software and go > to the same wifi hotspot and chances are one is reachable at his/her > permanent identifier. > > If DS-MIPv6 offered traversal mechanisms as powerful as VoIP's then I'd > be very happy with it. Perhaps a generic "IPv6 over IPv4+NAT+firewall+authenticating_http_proxy+other_obstacles" draft would be a better way of addressing this. Cheers Suresh _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Aug 14 09:44:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwhE-0005ip-MF; Tue, 14 Aug 2007 09:44:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwhD-0005ik-H0 for mip6@ietf.org; Tue, 14 Aug 2007 09:44:31 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IKwhC-0001mH-7j for mip6@ietf.org; Tue, 14 Aug 2007 09:44:31 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1187099069!12783824!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 21132 invoked from network); 14 Aug 2007 13:44:29 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-128.messagelabs.com with SMTP; 14 Aug 2007 13:44:29 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l7EDiOLQ007148; Tue, 14 Aug 2007 06:44:28 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l7EDiOQm023164; Tue, 14 Aug 2007 08:44:24 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l7EDiKAh023060; Tue, 14 Aug 2007 08:44:22 -0500 (CDT) Message-ID: <46C1B1AE.9090508@gmail.com> Date: Tue, 14 Aug 2007 15:44:14 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000765-1, 13/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham Soliman wrote: > >> Sorry, I don't think I've made myself clear enough. >> >> Some deployments do require that the HA stays IPv6-only and its MNs >> attach to IPv4-only access networks. >> >> A HA that must be dual-stacked in order for its MNs to access >> IPv4-only networks (what DS-MIPv6 does) has its applicability too, >> but more limited. > > => I think you're referring to the case that Pascal suggested earlier > about splitting the IPv4 stack away from the HA. We discussed this > and we didn't think it was worth solving. We haven't heard anyone > from the operational areas or from the operator community complaining > about the lack of support for this scenario. Every solution is > limited to subset of almost infinite scenarios, it's a question of > solving the ones that people deploying networks need. We also agreed > that if there is a clear need for extensions this can be done > separately at a later stage. Ok, let's see later. >>> independent pointer to such NATs then please send it to the list, >>> otherwise we won't consider this issue. >> >> I don't have a public independent pointer. >> > > => Ok. I'm afraid, in the absence of any support for this behaviour > we can't really consider it. Ok, what if I ask: Please point me to a public independent pointer ceritfiying at least one NAT implementation complying with rfc4787 "NAT UDP Unicast Requirements", this latter saying that the 5min mapping timer shouldn't expire when no traffic. Absent that proof I don't see why assuming it. (you do). Then have a look at rfc2993 which says that the port mapping for a connection shouldn't change at least during 4 minutes, it explains why. Then it goes on saying why this requirement is a burden on NAT implementers, especially those who must accommodate large number of users: rfc2993 "Architectural Implications of NAT" > For address-and-port translators to comply with this requirement, > they similarly must refrain from assigning the same host/port pair > until 2*MSL has elapsed since the end of its first use. While these > requirements are simple to state, they can place a great deal of > pressure on the NAT, because they temporarily reduce the pool of > available addresses and ports. Consequently, it will be tempting or > NAT implementers to ignore or shorten the TCP_TIME_WAIT > requirements, at the cost of some of TCP's strong reliability. Note > that in the case where the strong reliability is in fact compromised > by the appearance of an old packet, the failure can manifest itself > as the receiver accepting incorrect data. I don't have any other proof than the two rfcs and noted implementation of deployed systems. What kind of proof do you have about how you assume the NAT behaviour not changing the src port number of outgoing udp connections? >>>> doesn't traverse HTTP proxy gateways, >>> >>> => Huh? >> >> Not sure how to take your question mark, but let me just signal >> that when one goes to _any_ deployed wifi hotspot one has to deal >> with http proxy gateways at least as first step of accepting the >> sales conditions. >> >> And then there are the http authenticating proxy gateways that >> won't let out of network anything but http/s. Widely deployed. >> >> DS-MIPv6 doesn't deal with any of these, so it has limited >> applicability, IMHO. Some STUN/ICE do, so they have larger >> applicability. > > => You're comparing apples and oranges of course. We're not going to > go around admins demands to show people how to hack networks. Rhetorics... You want handovers between deployed IPv4 networks. > If they chose not to let anything other than HTTP through then > they're aware of what they don't want. We're not going to tunnel > MIPv6 in HTTP! Too bad, because other people tunnel other things in http when necessary, and are happy with it, because it offers the opportunity to connect to a wider set of access networks. Isn't this one of the holy grails of MIP, to connect to everywhere? > For the record, I used hotspots in at least a dozen different > countries and not one spot asked me to use an HTTP proxy. Seems like > a silly thing to do in a public network. Didn't these hotspots ask you to first accept some commercial conditions on a web page before opening the filters? I can't imagine MIP going through these systems without first accepting these http things. Are we talking the same kind of deployment? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Aug 14 09:56:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwsU-000589-Ad; Tue, 14 Aug 2007 09:56:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwsT-000580-4y for mip6@ietf.org; Tue, 14 Aug 2007 09:56:09 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKwsS-0004zb-Ko for mip6@ietf.org; Tue, 14 Aug 2007 09:56:09 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1187099767!18385785!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 18101 invoked from network); 14 Aug 2007 13:56:07 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-15.tower-128.messagelabs.com with SMTP; 14 Aug 2007 13:56:07 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l7EDu7Qi024882; Tue, 14 Aug 2007 06:56:07 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l7EDu62X021311; Tue, 14 Aug 2007 08:56:06 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l7EDtwWb021151; Tue, 14 Aug 2007 08:56:01 -0500 (CDT) Message-ID: <46C1B467.9010301@gmail.com> Date: Tue, 14 Aug 2007 15:55:51 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Suresh Krishnan Subject: Re: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt References: <46BC3D42.6060609@gmail.com> <46C07857.1050109@ericsson.com> <46C15DC8.1030305@gmail.com> <46C1A6EE.1020700@ericsson.com> In-Reply-To: <46C1A6EE.1020700@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000765-1, 13/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Suresh Krishnan wrote: > Hi Alex, > > Alexandru Petrescu wrote: >> Suresh Krishnan wrote: >>> Hi Alex, I think the IPv6 transition mechanisms are complementary to >>> DSMIPv6 and not necessarily competitors. >> >> Would DS-MIPv6 work with IPv4-over-IPv6 rfc2473? It doesn't cite it. >> > > The question is, does it need to? My reading of the charter says the > solution needs to handle dual stacked nodes (I guess RFC4213). I have no > opinions for or against citing other transition mechanisms. I think we say the same thing actually. I am happy if you don't oppose citing rfc2473 by DS-MIPv6. >> What I'm trying to say is that DS-MIPv6 is not addressing some important >> deployment scenarios (its NAT traversal doesn't support >> dst-port-changing NATs, doesn't traverse HTTP proxy gateways, doesn't >> negotiate the traversal mechanism) and it addresses some scenarios which >> are limited in scope. > > This is a totally different ballgame. The scenarios addressed by this > draft are listed in section 1.2. I would consider this section to be > analogous to an applicability statement. I am perfectly happy if these > scenarios (and only these) are well covered by the draft. Are you saying > that this list scenarios of scenarios is incomplete? I think it would be > difficult to add to these at this point. I am happy with that section listing 4 scenarios DS-MIPv6 addresses. Scenario 2 - MN behind NAT - is deceivingly simple compared to what IPv4 access networks are deployed out there. That makes the applicability statement very thin IMHO. >> Look at it this way: deploy a DS-MIPv6 HA and take a MN running DS-MIPv6 >> and go to a publicly deployed wifi hotspot: most probably it won't work. >> Most probably because of the typical NAT/firewall/httpproxy being in >> place. >> >> Now take a recent VoIP MN with the most recent traversal software and go >> to the same wifi hotspot and chances are one is reachable at his/her >> permanent identifier. >> >> If DS-MIPv6 offered traversal mechanisms as powerful as VoIP's then I'd >> be very happy with it. > > Perhaps a generic "IPv6 over > IPv4+NAT+firewall+authenticating_http_proxy+other_obstacles" draft would > be a better way of addressing this. :-) Alex > > > Cheers > Suresh > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Aug 16 03:49:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILa6o-00048s-4m; Thu, 16 Aug 2007 03:49:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILa6m-0003z3-L1 for mip6@ietf.org; Thu, 16 Aug 2007 03:49:32 -0400 Received: from mail1.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILa6l-0005lL-FF for mip6@ietf.org; Thu, 16 Aug 2007 03:49:32 -0400 X-AuditID: c26e2f18-00000a94000005f8-4e-46c401740020 Received: from camaro.eu.tieto.com ([192.176.143.43]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 10:49:08 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 09:49:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt Date: Thu, 16 Aug 2007 09:49:27 +0200 Message-ID: In-Reply-To: <46C1B1AE.9090508@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt Thread-Index: AcfeeWgmsNbvq33ARseLTM5y+eZRFQAt6+9A References: <46C1B1AE.9090508@gmail.com> From: To: , X-OriginalArrivalTime: 16 Aug 2007 07:49:28.0157 (UTC) FILETIME=[F8FCE8D0:01C7DFD9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, I agree that Alexandru has a point on the NAT traversal issue in that NAT keep alives may not keep the NAT mapping active. If we compare with IP Sec NAT traversal (RFC 4306 and RFC 3948)=20 the issue is there sought mitigated by allowing "seamless"=20 replacement of the NAT address, i.e., (section 2.23)=20 "There are cases where a NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). To recover in these cases, hosts that are not behind a NAT SHOULD send all packets (including retransmission packets) to the IP address and port from the last valid authenticated packet from the other end (i.e., dynamically update the address). A host behind a NAT SHOULD NOT do this because it opens a DoS attack possibility. Any authenticated IKE packet or any authenticated UDP-encapsulated ESP packet can be used to detect that the IP address or the port has changed." The fact that the packets are authenticated does not protect the NAT assigned address, but it assures that the NAT assigned address in IKE and IP Sec SAs=20 only can be manipulated when high jacking the packets. And if an attacker can highjack all packets, well then :-) The corresponding issue for DSMIP is what to do with respect to MIP bindings and UDP tunnel addresses when the NAT binding expires and the exterior NAT address allocated for the next=20 out-going packet from the MN thus is a new one. When IPSec is used on the tunnel, RFC 3948, the issue is handled one way. I.e., in accordance with what is said above, the old address should be replaced with the new one automatically. But what would happen when IP Sec is not deployed ?=20 Presumably the HA will discard the=20 encapsulated packet, at least this seems=20 the best way to ensure compliance with RFC 3775, section 10.4.5. It would thus be up to the mobile node to detect that the tunnel is no longer=20 working and resend a BU. Letting the HA send binding refresh=20 requests in this situation does not work due to DoS. I agree that it could be good to add some lines discussing this. An altogether different comment: Section 4.2, second paragraph: When the home agent receives the encapsulated binding update it compares the IPv4 address of the source address field in the IPv4 header with the IPv4 address in the source address of the IPv6 header.=20 =20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Replace by : the Ipv4 Care of address option. BR, Karen =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Tuesday, August 14, 2007 3:44 PM > To: Hesham Soliman > Cc: 'Mobile IPv6 Mailing List' > Subject: Re: [Mip6] Re: [nemo] WG LC:=20 > draft-ietf-mip6-nemo-v4traversal-05.txt >=20 > Hesham Soliman wrote: > >=20 > >> Sorry, I don't think I've made myself clear enough. > >>=20 > >> Some deployments do require that the HA stays IPv6-only and its MNs > >> attach to IPv4-only access networks. > >>=20 > >> A HA that must be dual-stacked in order for its MNs to access=20 > >> IPv4-only networks (what DS-MIPv6 does) has its applicability too, > >> but more limited. > >=20 > > =3D> I think you're referring to the case that Pascal=20 > suggested earlier > > about splitting the IPv4 stack away from the HA. We discussed this=20 > > and we didn't think it was worth solving. We haven't heard anyone=20 > > from the operational areas or from the operator community=20 > complaining > > about the lack of support for this scenario. Every solution is=20 > > limited to subset of almost infinite scenarios, it's a question of=20 > > solving the ones that people deploying networks need. We also agreed > > that if there is a clear need for extensions this can be done=20 > > separately at a later stage. >=20 > Ok, let's see later. >=20 > >>> independent pointer to such NATs then please send it to the list, > >>> otherwise we won't consider this issue. > >>=20 > >> I don't have a public independent pointer. > >>=20 > >=20 > > =3D> Ok. I'm afraid, in the absence of any support for this = behaviour=20 > > we can't really consider it. >=20 > Ok, what if I ask: Please point me to a public independent > pointer ceritfiying at least one NAT implementation complying with > rfc4787 "NAT UDP Unicast Requirements", this latter saying=20 > that the 5min > mapping timer shouldn't expire when no traffic. >=20 > Absent that proof I don't see why assuming it. (you do). >=20 > Then have a look at rfc2993 which says that the port mapping for a > connection shouldn't change at least during 4 minutes, it=20 > explains why. > Then it goes on saying why this requirement is a burden on NAT > implementers, especially those who must accommodate large=20 > number of users: >=20 > rfc2993 "Architectural Implications of NAT" > > For address-and-port translators to comply with this requirement,=20 > > they similarly must refrain from assigning the same host/port pair=20 > > until 2*MSL has elapsed since the end of its first use. While these > > requirements are simple to state, they can place a great deal of=20 > > pressure on the NAT, because they temporarily reduce the pool of=20 > > available addresses and ports. Consequently, it will be tempting or > > NAT implementers to ignore or shorten the TCP_TIME_WAIT > > requirements, at the cost of some of TCP's strong reliability. Note > > that in the case where the strong reliability is in fact compromised > > by the appearance of an old packet, the failure can manifest itself > > as the receiver accepting incorrect data. >=20 > I don't have any other proof than the two rfcs and noted=20 > implementation > of deployed systems. >=20 > What kind of proof do you have about how you assume the NAT behaviour=20 > not changing the src port number of outgoing udp connections? >=20 > >>>> doesn't traverse HTTP proxy gateways, > >>>=20 > >>> =3D> Huh? > >>=20 > >> Not sure how to take your question mark, but let me just signal=20 > >> that when one goes to _any_ deployed wifi hotspot one has to deal=20 > >> with http proxy gateways at least as first step of accepting the=20 > >> sales conditions. > >>=20 > >> And then there are the http authenticating proxy gateways that=20 > >> won't let out of network anything but http/s. Widely deployed. > >>=20 > >> DS-MIPv6 doesn't deal with any of these, so it has limited=20 > >> applicability, IMHO. Some STUN/ICE do, so they have larger=20 > >> applicability. > >=20 > > =3D> You're comparing apples and oranges of course. We're not going = to > > go around admins demands to show people how to hack networks. >=20 > Rhetorics... >=20 > You want handovers between deployed IPv4 networks. >=20 > > If they chose not to let anything other than HTTP through then=20 > > they're aware of what they don't want. We're not going to tunnel=20 > > MIPv6 in HTTP! >=20 > Too bad, because other people tunnel other things in http when > necessary, and are happy with it, because it offers the=20 > opportunity to=20 > connect to a wider set of access networks. Isn't this one of=20 > the holy=20 > grails of MIP, to connect to everywhere? >=20 > > For the record, I used hotspots in at least a dozen different > > countries and not one spot asked me to use an HTTP proxy. Seems like > > a silly thing to do in a public network. >=20 > Didn't these hotspots ask you to first accept some commercial=20 > conditions=20 > on a web page before opening the filters? I can't imagine MIP going=20 > through these systems without first accepting these http things. >=20 > Are we talking the same kind of deployment? >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Aug 16 04:44:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILaxj-0002hA-UV; Thu, 16 Aug 2007 04:44:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILaxi-0002h0-Md for mip6@ietf.org; Thu, 16 Aug 2007 04:44:14 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILaxh-00072C-Gi for mip6@ietf.org; Thu, 16 Aug 2007 04:44:13 -0400 Received: from oaamta04sl.mx.bigpond.com ([124.190.104.34]) by omta04sl.mx.bigpond.com with ESMTP id <20070816084410.YNXY4018.omta04sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com> for ; Thu, 16 Aug 2007 08:44:10 +0000 Received: from PC20005 ([124.190.104.34]) by oaamta04sl.mx.bigpond.com with ESMTP id <20070816084409.WICH11359.oaamta04sl.mx.bigpond.com@PC20005>; Thu, 16 Aug 2007 08:44:09 +0000 From: "Hesham Soliman" To: , Subject: RE: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt Date: Thu, 16 Aug 2007 18:43:50 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: Thread-Index: AcfeeWgmsNbvq33ARseLTM5y+eZRFQAt6+9AACvmLQA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I don't think you and Alex are talking about the same thing. Alex seemed to be referring to NATs that simply disregard any timeouts and randomly change outgoing ports, he can explain himself better if I misunderstood. What you're describing below is a failure situation due to an unusual case like a reboot. We briefly discussed this when we were discussing issue 93. > The corresponding issue for DSMIP is what to do with respect to MIP > bindings and > UDP tunnel addresses when the NAT binding expires and the > exterior NAT > address allocated for the next > out-going packet from the MN thus is a new one. => If the NAT binding expired then we assume that either: A. The MN didn't refresh the binding, or, B. An unusual event like a reboot took place. > > When IPSec is used on the tunnel, RFC 3948, the issue is handled one > way. > I.e., in accordance with what is said above, > the old address should be replaced with the new one automatically. > > But what would happen when IP Sec is not deployed ? > Presumably the HA will discard the > encapsulated packet, at least this seems > the best way to ensure compliance with RFC 3775, section 10.4.5. => Yes. > > It would thus be up to the mobile node to detect that the > tunnel is no > longer > working and resend a BU. => Correct. In the same way that the mobile node is expected to do that when the HA crashes. RFC 3775 doesn't talk about detecting that, but somehow, an implementation can have the intelligence to resend the BU as a diagnostic measure for instance. > I agree that it could be good to add some lines discussing this. => That's fine with me. But I think you're raising a new issue, which can be addressed as part of this LC. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Aug 16 04:52:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILb5D-00086l-Nb; Thu, 16 Aug 2007 04:51:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILb5C-00086f-0k for mip6@ietf.org; Thu, 16 Aug 2007 04:51:58 -0400 Received: from omta04sl.mx.bigpond.com ([144.140.93.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILb5A-0007EH-41 for mip6@ietf.org; Thu, 16 Aug 2007 04:51:57 -0400 Received: from oaamta04sl.mx.bigpond.com ([124.190.104.34]) by omta04sl.mx.bigpond.com with ESMTP id <20070816085153.YWEE4018.omta04sl.mx.bigpond.com@oaamta04sl.mx.bigpond.com> for ; Thu, 16 Aug 2007 08:51:53 +0000 Received: from PC20005 ([124.190.104.34]) by oaamta04sl.mx.bigpond.com with ESMTP id <20070816085153.WKGT11359.oaamta04sl.mx.bigpond.com@PC20005>; Thu, 16 Aug 2007 08:51:53 +0000 From: "Hesham Soliman" To: "'Alexandru Petrescu'" Subject: RE: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt Date: Thu, 16 Aug 2007 18:51:03 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <46C1B1AE.9090508@gmail.com> Thread-Index: AcfeeT9vpufrr3krQn6sL/FaZM9RTAAZ+/fQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 1.1 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Ok, what if I ask: Please point me to a public independent > pointer ceritfiying at least one NAT implementation complying with > rfc4787 "NAT UDP Unicast Requirements", this latter saying > that the 5min > mapping timer shouldn't expire when no traffic. > > Absent that proof I don't see why assuming it. (you do). => I assume it because it is the assumption that most people go by, including those building and operating NATs. And because I haven't seen the behaviour you talk about anywhere, hence my questions for public docs. > I don't have any other proof than the two rfcs and noted > implementation > of deployed systems. => Do those deployed systems have a name? a spec? a vendor who can back your claims? Are they widely deployed or limited to ten people? > > If they chose not to let anything other than HTTP through then > > they're aware of what they don't want. We're not going to tunnel > > MIPv6 in HTTP! > > Too bad, because other people tunnel other things in http when > necessary, and are happy with it, because it offers the > opportunity to > connect to a wider set of access networks. Isn't this one > of the holy > grails of MIP, to connect to everywhere? => No, not through HTTP tunnels, I don't remember reading that requirement anywhere. > > For the record, I used hotspots in at least a dozen different > > countries and not one spot asked me to use an HTTP proxy. > Seems like > > a silly thing to do in a public network. > > Didn't these hotspots ask you to first accept some > commercial conditions > on a web page before opening the filters? I can't imagine MIP going > through these systems without first accepting these http things. => This is nonsense really. HTTP redirect for authentication has nothing to do with mandating HTTP only traffic and HTTP ALGs. Two completely unrelated issues. Of course MIP will work fine after the filters are opened. > > Are we talking the same kind of deployment? => I don't think so. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Aug 16 17:13:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILmec-00062f-9J; Thu, 16 Aug 2007 17:13:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILmea-00062N-SF for mip6@ietf.org; Thu, 16 Aug 2007 17:13:17 -0400 Received: from rv-out-0910.google.com ([209.85.198.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILmea-0005Od-6f for mip6@ietf.org; Thu, 16 Aug 2007 17:13:16 -0400 Received: by rv-out-0910.google.com with SMTP id l15so273281rvb for ; Thu, 16 Aug 2007 14:13:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=A1gbgDEFIQAPl2+FQdvmid8YJPE/bAcVluRzr1K81SY2GE7k+lUB04xKwROKRlFPS2zynPTnDCnxlkP18bV1Tteo8utl8zUGmW6gbdpOvpBRECllI4BME3uaUaaxNGqbNE5eIhH5ESV67f6R/oBRY3k2tUULxr2+RfCgP/AS5o0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=g2BXljQ85X2Lnko34xf0dmBPJORD0iwaXYvnlvrA6aHaQoygV6x0bMTdvoQli1Zs9A30BlwcNp9nLQpI9z+r3YGhz069M0rAiqILnr+mQiLP4AklBUP6ic0G/5BmLeTLolCEHA+2d7fjfa3RHu2hMsG9qHUSJV2JZFgxTAH05ho= Received: by 10.114.195.19 with SMTP id s19mr52139waf.1187298794899; Thu, 16 Aug 2007 14:13:14 -0700 (PDT) Received: from ?133.27.62.74? ( [133.27.62.74]) by mx.google.com with ESMTPS id n6sm1389232wag.2007.08.16.14.13.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Aug 2007 14:13:08 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <81AF2C3A-2F4F-49E8-A5E5-4BFB76E96D18@gmail.com> Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt Date: Fri, 17 Aug 2007 06:12:58 +0900 To: Hesham Soliman X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: 'Mobile IPv6 Mailing List' , 'Alexandru Petrescu' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi First of all, I am fine with the latest DSMIP doc. Thanks Hesham for updating doc. HTTP proxy isn't scope of this document. As Hesham said, most of deployed http proxy in access networks is for authentication to open filters. After opening filters, DSMIP should work fine. DT discussed the NAT box reboot/crash scenarios at some conf-call. Someone raised this problem, but we concluded that these are not usual cases. In these scenarios, MN should take the first action to recover from these failures, because HA cannot reach to the MN after NAT states are erased. Therefore, the use of binding update sounds very reasonable to me. In addition, MN can configure the shorter binding lifetime at the NAT scenarios in order to recover from these events and to keep NAT states. regards, ryuji ps. Alex, if you want to skip http-proxy auth, try DNS tunnel. It sometime works fine;-) On 2007/08/16, at 17:51, Hesham Soliman wrote: > >> Ok, what if I ask: Please point me to a public independent >> pointer ceritfiying at least one NAT implementation complying with >> rfc4787 "NAT UDP Unicast Requirements", this latter saying >> that the 5min >> mapping timer shouldn't expire when no traffic. >> >> Absent that proof I don't see why assuming it. (you do). > > => I assume it because it is the assumption that most people go by, > including those building and operating NATs. And because I haven't > seen the > behaviour you talk about anywhere, hence my questions for public docs. > >> I don't have any other proof than the two rfcs and noted >> implementation >> of deployed systems. > > => Do those deployed systems have a name? a spec? a vendor who can > back your > claims? Are they widely deployed or limited to ten people? > >>> If they chose not to let anything other than HTTP through then >>> they're aware of what they don't want. We're not going to tunnel >>> MIPv6 in HTTP! >> >> Too bad, because other people tunnel other things in http when >> necessary, and are happy with it, because it offers the >> opportunity to >> connect to a wider set of access networks. Isn't this one >> of the holy >> grails of MIP, to connect to everywhere? > > => No, not through HTTP tunnels, I don't remember reading that > requirement > anywhere. > >>> For the record, I used hotspots in at least a dozen different >>> countries and not one spot asked me to use an HTTP proxy. >> Seems like >>> a silly thing to do in a public network. >> >> Didn't these hotspots ask you to first accept some >> commercial conditions >> on a web page before opening the filters? I can't imagine MIP going >> through these systems without first accepting these http things. > > => This is nonsense really. HTTP redirect for authentication has > nothing to > do with mandating HTTP only traffic and HTTP ALGs. Two completely > unrelated > issues. Of course MIP will work fine after the filters are opened. > >> >> Are we talking the same kind of deployment? > > => I don't think so. > > Hesham > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Aug 17 10:43:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM32r-0000O1-4K; Fri, 17 Aug 2007 10:43:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM32m-0000Kb-NK; Fri, 17 Aug 2007 10:43:20 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM32m-0005vf-9A; Fri, 17 Aug 2007 10:43:20 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 28E5A26E71; Fri, 17 Aug 2007 14:43:20 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IM32m-0003AZ-2Q; Fri, 17 Aug 2007 10:43:20 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 17 Aug 2007 10:43:20 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: mip6 mailing list , mip6 chair , Internet Architecture Board , RFC Editor Subject: [Mip6] Protocol Action: 'Mobile IPv6 bootstrapping in split scenario' to Proposed Standard X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The IESG has approved the following document: - 'Mobile IPv6 bootstrapping in split scenario ' as a Proposed Standard This document is the product of the Mobility for IPv6 Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-07.txt Technical Summary A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials preconfigured on the Mobile Node. The solution defined in this document solves the bootstrapping problem from draft-ietf-mip6-bootstrapping-ps-02 when the Mobile Node's mobility service is authorized by a different service provider than basic network access, and is therefore generically applicable to any bootstrapping case. Working Group Summary No major concerns or issues have come up in the WG w.r.t this I-D. Protocol Quality No known implementations of this protocol are available at this time. Several WG members have indicated plans to implement this specification. This work is also relevant for bootstrapping of MIP6 and may be adopted by other SDOs. All relevant reviewers and contributors have been acknowledged. This specification has been reviewed by Jari Arkko for the IESG. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Aug 17 11:15:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3Y4-0003qj-PK; Fri, 17 Aug 2007 11:15:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3Xx-0003fw-GK; Fri, 17 Aug 2007 11:15:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM3Xx-0002Dv-3C; Fri, 17 Aug 2007 11:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 979F9175AC; Fri, 17 Aug 2007 15:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IM3XS-0005hl-2e; Fri, 17 Aug 2007 11:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 17 Aug 2007 11:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-cn-ipsec-05.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Using IPsec between Mobile and Correspondent IPv6 Nodes Author(s) : F. Dupont, J. Combes Filename : draft-ietf-mip6-cn-ipsec-05.txt Pages : 9 Date : 2007-8-17 Mobile IPv6 uses IPsec to protect signaling between the Mobile Node and the Home Agent. This document defines how IPsec can be used between the Mobile Node and Correspondent Nodes for Home Address Option validation (aka. triangular routing) and protection of mobility signaling for Route Optimization. The configuration details for IPsec and IKE are also provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-cn-ipsec-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-cn-ipsec-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-cn-ipsec-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-17104013.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-cn-ipsec-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-cn-ipsec-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-17104013.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Fri Aug 17 11:16:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3YR-0004FQ-UV; Fri, 17 Aug 2007 11:16:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3YQ-0004Eu-OU for mip6@ietf.org; Fri, 17 Aug 2007 11:16:02 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM3YP-00070J-8f for mip6@ietf.org; Fri, 17 Aug 2007 11:16:02 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2B650198680; Fri, 17 Aug 2007 18:16:00 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id CBB51198676; Fri, 17 Aug 2007 18:15:59 +0300 (EEST) Message-ID: <46C5BBAF.8080805@piuha.net> Date: Fri, 17 Aug 2007 18:15:59 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Mobile IPv6 Mailing List , draft-ietf-mip6-cn-ipsec@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Mip6] cn-ipsec status update X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, The new version that appeared in the directories today has addressed everything from my AD review, thanks! The document will now go into Last Call. We also had the question of whether this document is appropriate for the Standards Track or if it should be designated as Experimental. As you may recall, I requested information about potential users or other arguments in favor of a PS status. Based on discussions with the authors, a new substantially improved document revision, and privately received information about potential users of this specification I eventually agreed that the document can be progressed on the Standards Track. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Aug 17 12:23:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM4bc-0008Qb-DV; Fri, 17 Aug 2007 12:23:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM4bX-0008Pf-VW; Fri, 17 Aug 2007 12:23:20 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM4bX-0005La-LY; Fri, 17 Aug 2007 12:23:19 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 8F76E2AC8C; Fri, 17 Aug 2007 16:22:49 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IM4b0-0000Cx-5f; Fri, 17 Aug 2007 12:22:46 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 17 Aug 2007 12:22:46 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip6@ietf.org Subject: [Mip6] Last Call: draft-ietf-mip6-cn-ipsec (Using IPsec between Mobile and Correspondent IPv6 Nodes) to Proposed Standard X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The IESG has received a request from the Mobility for IPv6 WG (mip6) to consider the following document: - 'Using IPsec between Mobile and Correspondent IPv6 Nodes ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-08-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mip6-cn-ipsec-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12676&rfc_flag=0 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Aug 17 13:57:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM64s-0000dW-9C; Fri, 17 Aug 2007 13:57:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM64q-0000d0-Hn for mip6@ietf.org; Fri, 17 Aug 2007 13:57:40 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IM64p-0004TG-C2 for mip6@ietf.org; Fri, 17 Aug 2007 13:57:40 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1187373458!20215357!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 8756 invoked from network); 17 Aug 2007 17:57:38 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-119.messagelabs.com with SMTP; 17 Aug 2007 17:57:38 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l7HHvVDC002413; Fri, 17 Aug 2007 10:57:33 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l7HHvV9o004410; Fri, 17 Aug 2007 12:57:31 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.195]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l7HHvSoH004382; Fri, 17 Aug 2007 12:57:29 -0500 (CDT) Message-ID: <46C5E188.6070808@gmail.com> Date: Fri, 17 Aug 2007 19:57:28 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000766-1, 17/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: mip6@ietf.org, alexandru.petrescu@gmail.com, Karen.Nielsen@tietoenator.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham Soliman wrote: > I don't think you and Alex are talking about the same thing. Alex > seemed to be referring to NATs that simply disregard any timeouts and > randomly change outgoing ports, he can explain himself better if I > misunderstood. Hesham, I've explained NAT-forced-change-of-outgoing-src-port-number several times and I seem to fall on deaf ears here; except Karen now seems to acknowledge this may be an issue with IPsec. I agree with Karen that there is an issue with IPsec too when the port numbers change. I know I can't convince you, and thus all I can say is that DS-MIPv6 has a limited applicability scope as it is now. And I also support advancement of this document as I said several times too. > What you're describing below is a failure situation due to an unusual > case like a reboot. We briefly discussed this when we were > discussing issue 93. > >> The corresponding issue for DSMIP is what to do with respect to MIP >> bindings and UDP tunnel addresses when the NAT binding expires and >> the exterior NAT address allocated for the next out-going packet >> from the MN thus is a new one. > > => If the NAT binding expired then we assume that either: A. The MN > didn't refresh the binding, or, B. An unusual event like a reboot > took place. > >> >> When IPSec is used on the tunnel, RFC 3948, the issue is handled >> one way. I.e., in accordance with what is said above, the old >> address should be replaced with the new one automatically. >> >> But what would happen when IP Sec is not deployed ? Presumably the >> HA will discard the encapsulated packet, at least this seems the >> best way to ensure compliance with RFC 3775, section 10.4.5. > > => Yes. > >> >> It would thus be up to the mobile node to detect that the tunnel is >> no longer working and resend a BU. > > => Correct. In the same way that the mobile node is expected to do > that when the HA crashes. RFC 3775 doesn't talk about detecting that, > but somehow, an implementation can have the intelligence to resend > the BU as a diagnostic measure for instance. > >> I agree that it could be good to add some lines discussing this. > > => That's fine with me. But I think you're raising a new issue, which > can be addressed as part of this LC. I agree. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Aug 17 14:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM6Fv-00035R-IM; Fri, 17 Aug 2007 14:09:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM6Fu-00035L-Sn for mip6@ietf.org; Fri, 17 Aug 2007 14:09:06 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IM6Fu-0001TW-FK for mip6@ietf.org; Fri, 17 Aug 2007 14:09:06 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1187374145!19127966!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 13590 invoked from network); 17 Aug 2007 18:09:05 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-119.messagelabs.com with SMTP; 17 Aug 2007 18:09:05 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l7HI95e8006082; Fri, 17 Aug 2007 11:09:05 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l7HI94tl021921; Fri, 17 Aug 2007 13:09:05 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.195]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l7HI92E8021884; Fri, 17 Aug 2007 13:09:03 -0500 (CDT) Message-ID: <46C5E43D.90708@gmail.com> Date: Fri, 17 Aug 2007 20:09:01 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RYUJI WAKIKAWA Subject: Re: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt References: <81AF2C3A-2F4F-49E8-A5E5-4BFB76E96D18@gmail.com> In-Reply-To: <81AF2C3A-2F4F-49E8-A5E5-4BFB76E96D18@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000766-1, 17/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'Mobile IPv6 Mailing List' , 'Alexandru Petrescu' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org RYUJI WAKIKAWA wrote: > Hi > > First of all, I am fine with the latest DSMIP doc. Thanks Hesham for > updating doc. > > HTTP proxy isn't scope of this document. As Hesham said, most of > deployed http proxy in access networks is for authentication to open > filters. After opening filters, DSMIP should work fine. Absolutely agree DSMIP would work after the filters are open. But one can't imagine a user authenticating the http proxy with a mouse click and then starting DS-MIPv6 each time s/he accesses a new wifi network... this is clearly a burden. > DT discussed the NAT box reboot/crash scenarios at some conf-call. > Someone raised this problem, but we concluded that these are not > usual cases. The case of NAT changing the the outgoing src port number every 5 minutes is _not_ a NAT-reboot issue. I've measured this behaviour during hours and it happens so. One can't imagine that the NAT box reboots every 5 minutes. Also, a normal user of that NAT (doing http queries or other similar behaviour) won't notice anything. Only a ftp/streaming user will notice. > In these scenarios, MN should take the first action to recover from > these failures, because HA cannot reach to the MN after NAT states > are erased. Yes. > Therefore, the use of binding update sounds very reasonable to me. In > addition, MN can configure the shorter binding lifetime at the NAT > scenarios in order to recover from these events and to keep NAT > states. Imagine MN sends a BU every 2minutes, to fill the 5min NAT changes. But then imagine that CN streams the first packet to MN at a moment when the NAT src port number has just changed. The HA will have to wait at least 2min for CN to be able to reach MN. And you also need the HA to be specified to memorize the state related to MN to something more than just the quadruple (ipsrc,ipdst,portsrc,portdst), and that can only be a new id in packet... Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Aug 18 02:27:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMHmQ-0005wM-Ef; Sat, 18 Aug 2007 02:27:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMHmP-0005sr-Ko for mip6@ietf.org; Sat, 18 Aug 2007 02:27:25 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IMHmP-000204-0Z for mip6@ietf.org; Sat, 18 Aug 2007 02:27:25 -0400 Received: by nf-out-0910.google.com with SMTP id c10so414236nfd for ; Fri, 17 Aug 2007 23:27:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=UETG9+t3ifyJAcW3ERHwkiDzSMGwBkxllIaK96MRVLIFCA1PyWzJhAvC552/PQNG8kYq74lOExCqDtsoK2bvScy2v7k/kRjzBi2kJzE4h1RzRR/pzV2AN9H45B9tzfG6iBbcQ/icPHc7+uetfsWYNx+Sfw3jsyhxODlGVYvMvwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=F79p5cuewfEqdlBtViolDmflwC9p/UfBgo3odzRQ0SlkOWOnP+LCqkRgKe4SoBOwxT5mkfXHG+GiXakvPTj03rsFSufilDs8OpajFIzsr49cjTK15/J91zDPRXSKv5XOqAVB/0314Qe6+pukNv3i4lVxGDPtR8H7B2ZCuFEoN7s= Received: by 10.78.123.5 with SMTP id v5mr1229047huc.1187418444048; Fri, 17 Aug 2007 23:27:24 -0700 (PDT) Received: from ?203.178.135.119? ( [203.178.135.119]) by mx.google.com with ESMTPS id 18sm1141801hue.2007.08.17.23.27.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Aug 2007 23:27:22 -0700 (PDT) In-Reply-To: <46C5E43D.90708@gmail.com> References: <81AF2C3A-2F4F-49E8-A5E5-4BFB76E96D18@gmail.com> <46C5E43D.90708@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt Date: Sat, 18 Aug 2007 15:27:06 +0900 To: Alexandru Petrescu X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alex, On 2007/08/18, at 3:09, Alexandru Petrescu wrote: > RYUJI WAKIKAWA wrote: >> Hi >> First of all, I am fine with the latest DSMIP doc. Thanks Hesham for >> updating doc. >> HTTP proxy isn't scope of this document. As Hesham said, most of >> deployed http proxy in access networks is for authentication to open >> filters. After opening filters, DSMIP should work fine. > > Absolutely agree DSMIP would work after the filters are open. But one > can't imagine a user authenticating the http proxy with a mouse click > and then starting DS-MIPv6 each time s/he accesses a new wifi > network... > this is clearly a burden. are you suggesting that DSMIP should open the port through http-proxy somehow?? If so, I disagree. ex. If the web page ask you to fill the credit card number, will DSMIP carry the card information:-p > >> DT discussed the NAT box reboot/crash scenarios at some conf-call. >> Someone raised this problem, but we concluded that these are not >> usual cases. > > The case of NAT changing the the outgoing src port number every 5 > minutes is _not_ a NAT-reboot issue. I've measured this behaviour > during hours and it happens so. One can't imagine that the NAT box > reboots every 5 minutes. Your problem is the suggested default value in the DSMIP? I think this value was suggested by MIPv4 traversal deployment?! > Also, a normal user of that NAT (doing http queries or other similar > behaviour) won't notice anything. Only a ftp/streaming user will > notice. > >> In these scenarios, MN should take the first action to recover >> from these failures, because HA cannot reach to the MN after NAT >> states >> are erased. > > Yes. > >> Therefore, the use of binding update sounds very reasonable to me. In >> addition, MN can configure the shorter binding lifetime at the NAT >> scenarios in order to recover from these events and to keep NAT >> states. > > Imagine MN sends a BU every 2minutes, to fill the 5min NAT > changes. But then imagine that CN streams the first packet to MN > at a moment when the NAT src port number has just changed. The HA > will have to wait at least 2min for CN to be able to reach MN. The use of BU to keep NAT state was discussed and agreed (consensus) in WGs before. If 2 min absence is problem, how fast do you want MN to recover from the NAT state changes? 1msec, 10msec, 1 sec, 5sec, 10sec?? Even we use explicit signaling (like ping) to check NAT, it takes some time to recover the NAT state. > And you also need the HA to be specified to memorize the state > related to MN to something more than just the quadruple > (ipsrc,ipdst,portsrc,portdst), and that can only be a new id in > packet... why?? MN binding is not erased on HA unless the lifetime is expired. Do you suggest to buffer the CN's packets during NAT reboot/crash? This is not belong to the DSMIP goal. No additional specification is required in DSMIP. regards, ryuji > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 20 05:37:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN3hD-0003IF-CR; Mon, 20 Aug 2007 05:37:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN3hC-0003Dw-Bv for mip6@ietf.org; Mon, 20 Aug 2007 05:37:14 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IN3hB-0007JK-07 for mip6@ietf.org; Mon, 20 Aug 2007 05:37:14 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1187602631!6264101!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9633 invoked from network); 20 Aug 2007 09:37:11 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-153.messagelabs.com with SMTP; 20 Aug 2007 09:37:11 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l7K9b7YQ010908; Mon, 20 Aug 2007 02:37:07 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l7K9b6aJ027198; Mon, 20 Aug 2007 04:37:06 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l7K9axir026926; Mon, 20 Aug 2007 04:36:59 -0500 (CDT) Message-ID: <46C960AC.8090604@gmail.com> Date: Mon, 20 Aug 2007 11:36:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RYUJI WAKIKAWA Subject: Re: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt References: <81AF2C3A-2F4F-49E8-A5E5-4BFB76E96D18@gmail.com> <46C5E43D.90708@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000766-1, 17/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: 'Mobile IPv6 Mailing List' , Alexandru Petrescu X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org RYUJI WAKIKAWA wrote: > Alex, > > On 2007/08/18, at 3:09, Alexandru Petrescu wrote: > >> RYUJI WAKIKAWA wrote: >>> Hi First of all, I am fine with the latest DSMIP doc. Thanks >>> Hesham for updating doc. HTTP proxy isn't scope of this document. >>> As Hesham said, most of deployed http proxy in access networks >>> is for authentication to open filters. After opening filters, >>> DSMIP should work fine. >> >> Absolutely agree DSMIP would work after the filters are open. But >> one can't imagine a user authenticating the http proxy with a mouse >> click and then starting DS-MIPv6 each time s/he accesses a new wifi >> network... this is clearly a burden. > > are you suggesting that DSMIP should open the port through http-proxy > somehow?? If so, I disagree. ex. If the web page ask you to fill the > credit card number, will DSMIP carry the card information:-p I think this is a matter of requirements discussion. I don't mean to modify DSMIP solution right now. (I think it should be possible for DS-MIPv6 to be able to identify the environment in which it is working (firewalls, traversal method necessary, etc) and adapt to it. How that is done is a solution space.) But I think the applicability statements of DS-MIPv6 could be modified to say that the current DS-MIPv6 is not running through public IPv4 hotspots that demand user intervention on html pages prior to connection opening, or credit card as you say. >>> DT discussed the NAT box reboot/crash scenarios at some >>> conf-call. Someone raised this problem, but we concluded that >>> these are not usual cases. >> >> The case of NAT changing the the outgoing src port number every 5 >> minutes is _not_ a NAT-reboot issue. I've measured this behaviour >> during hours and it happens so. One can't imagine that the NAT >> box reboots every 5 minutes. > > Your problem is the suggested default value in the DSMIP? I think > this value was suggested by MIPv4 traversal deployment?! Ok. >> Also, a normal user of that NAT (doing http queries or other >> similar behaviour) won't notice anything. Only a ftp/streaming >> user will notice. >> >>> In these scenarios, MN should take the first action to recover >>> from these failures, because HA cannot reach to the MN after NAT >>> states are erased. >> >> Yes. >> >>> Therefore, the use of binding update sounds very reasonable to >>> me. In addition, MN can configure the shorter binding lifetime at >>> the NAT scenarios in order to recover from these events and to >>> keep NAT states. >> >> Imagine MN sends a BU every 2minutes, to fill the 5min NAT changes. >> But then imagine that CN streams the first packet to MN at a >> moment when the NAT src port number has just changed. The HA will >> have to wait at least 2min for CN to be able to reach MN. > > The use of BU to keep NAT state was discussed and agreed (consensus) > in WGs before. I'm not sure what you call consensus... There exist a number of NATs that will _not_ keep state bindings (ipsrc/dst, portsrc/dst) even if ongoing traffic go through it continuously. > If 2 min absence is problem, how fast do you want MN to recover from > the NAT state changes? 1msec, 10msec, 1 sec, 5sec, 10sec?? Even we > use explicit signaling (like ping) to check NAT, it takes some time > to recover the NAT state. This is again solution space. And it's not now the time to modify the DS-MIPv6 solution. I want the MN to send heartbeats through NAT with a variable frequency that (1) depends on a particular NAT frequenct changing the state of a connection and (2) makes sure HA has that state reflected in a delay of maximum 50ms. As you see this looks more as a requirement. There are several possible solutions satisfying that requirement. >> And you also need the HA to be specified to memorize the state >> related to MN to something more than just the quadruple >> (ipsrc,ipdst,portsrc,portdst), and that can only be a new id in >> packet... > > why?? MN binding is not erased on HA unless the lifetime is expired. I don't mean MIP binding, but UDP addr/port state. The DSMIP binding doesn't contain port numbers but these are essential for NAT traversal with UDP, especially when dynamically changing. > Do you suggest to buffer the CN's packets during NAT reboot/crash? > This is not belong to the DSMIP goal. No additional specification is > required in DSMIP. No, I don't suggest HA buffers packets. I agree not a relevant goal for HA. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 20 13:44:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INBIc-0001ld-3t; Mon, 20 Aug 2007 13:44:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INBIa-0001lX-U8; Mon, 20 Aug 2007 13:44:20 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INBIZ-0003yc-9C; Mon, 20 Aug 2007 13:44:20 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7KHiBNa005135; Mon, 20 Aug 2007 20:44:13 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 20:44:11 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 12:44:09 -0500 Received: from 172.19.244.162 ([172.19.244.162]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 20 Aug 2007 17:44:09 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 20 Aug 2007 12:44:17 -0500 From: Basavaraj Patil To: ext Jari Arkko , Message-ID: Thread-Topic: Request to progress MIP6 WG I-D: draft-ietf-mip6-whyauthdataoption-03.txt Thread-Index: AcfjUbrZ+Z/0MU9EEdySLAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Aug 2007 17:44:09.0605 (UTC) FILETIME=[B670CB50:01C7E351] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: Gopal Dommety , Mobile IPv6 Mailing List , Basavaraj Patil Subject: [Mip6] Request to progress MIP6 WG I-D: draft-ietf-mip6-whyauthdataoption-03.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello Jari, The WG I-D: Why Authentication Data suboption is needed for MIP6 < draft-ietf-mip6-whyauthdataoption-03.txt> has completed WG last call and is ready to be progressed. Intended status for publication: Informational Below is the IESG writeup for progressing this I-D. -Raj ========================== (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document shepherd: Basavaraj Patil I am also the author of this document and hence the question of review does not arise. However it has been reviewed by other WG members. The I-D is ready for for forwarding to the IESG and publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Adequate review has been done by WG members and non-WG members. No concerns about the depth or breadth of reviews exist. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. This I-D was basically written as a means to justify the need for an alternative mechanism for securing the MIP6 signaling. It is necessary to publish this I-D for historical reasons and to ensure there is a document explaining the arguments made for the authentication protocol which has been published as an Informational RFC (RFC 4285). (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is WG consensus. This I-D has been discussed in the WG a couple of years ago. The justification for the authentication protocol subsequently passed and RFC4285 has been published. This I-D is required as a means to capture the intent. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The I-D has been run through the nits checker and all issues corrected. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. The references are split into normative and informative sections. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? IANA considerations section exists. However this document does not need any IANA action. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not applicable to this I-D. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Mobile IPv6 defines a set of messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec SA that is established between the MN and HA. The MIP6 working group has proposed a mechanism to secure the binding update and binding acknowledgement messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain deployment environments. Working Group Summary This document was written to consolidate the arguments and justifications for an alternative to the IPsec based default mechanism specified for MIP6 signaling security. RFC4285 has been subsequently published which specifies the authentication protocol. The intent is to capture for historical purposes the reasoning behind the publication of the authentication protocol. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? This I-D is Informational and hence the question about implementations is N/A. Reviewers have been acked. The document does not specify any MIB or media types. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Document shepherd: Basavaraj Patil Responsible AD: Jari Arkko _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 20 16:20:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDjB-0002Eg-SU; Mon, 20 Aug 2007 16:19:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDj9-0002EW-Ms for mip6@ietf.org; Mon, 20 Aug 2007 16:19:55 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INDj8-0008VX-9i for mip6@ietf.org; Mon, 20 Aug 2007 16:19:55 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7KKJntS019622; Mon, 20 Aug 2007 23:19:50 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 23:19:40 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 15:19:32 -0500 Received: from 172.19.244.162 ([172.19.244.162]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 20 Aug 2007 20:19:31 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 20 Aug 2007 15:19:40 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List Message-ID: Thread-Topic: WG LC: I-D draft-ietf-mip6-rfc4285bis-00.txt Thread-Index: AcfjZ2/KrjJQxE9aEdySLAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Aug 2007 20:19:32.0186 (UTC) FILETIME=[6B21C3A0:01C7E367] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: alpesh@cisco.com, "Kent Leung \(kleung\)" , haseebak@nortel.com Subject: [Mip6] WG LC: I-D draft-ietf-mip6-rfc4285bis-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, This is a WG last call for the I-D: Authentication Protocol for Mobile IPv6 This I-D revises RFC4285 and corrects the key-length issue which has been discussed in the past. Please send your comments by Sept 5th, 07 to the mailing list or the authors. -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 22 07:58:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INor8-0002Qi-TE; Wed, 22 Aug 2007 07:58:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INor6-0002Od-TZ; Wed, 22 Aug 2007 07:58:36 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INor5-0007L9-R1; Wed, 22 Aug 2007 07:58:36 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Aug 2007 13:58:33 +0200 X-IronPort-AV: i="4.19,294,1183327200"; d="scan'208"; a="151186549:sNHT65560172" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7MBwW3T005679; Wed, 22 Aug 2007 13:58:32 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7MBw1dm009380; Wed, 22 Aug 2007 11:58:32 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Aug 2007 13:58:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Aug 2007 13:58:21 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC045F8EFD@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt Thread-Index: AcfYdxsOWcs/5kRqEdy1KAARJNUNiAMNcGPA References: From: "Pascal Thubert \(pthubert\)" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" , X-OriginalArrivalTime: 22 Aug 2007 11:58:28.0004 (UTC) FILETIME=[C04F2640:01C7E4B3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7125; t=1187783912; x=1188647912; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20[nemo]=20WG=20LC=3A=20draft-ietf-mip6-nemo-v4traversa l-05.txt=20 |Sender:=20; bh=4C+LsFjXCfsLKp4h3xBd35XCfKkWTuHFDtaeas9uiI8=; b=PNHeeUVg9gYg9m915CMwfjLZhBR45ErL7BuxDNv//IDHXmrBcWCi3AE620adVSCKPqJ2rkhe zicllq/l0eU3Qv+AnQMrDOCPDNFAimll+Sqs35BSu0nAP69N+s3dK9Gk; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: "Gopal Dommety \(gdommety\)" , thierry.ernst@inria.fr, tj@kniveton.com, Basavaraj Patil Subject: [Mip6] RE: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj I hope you're doing well. Here are my comments on the draft. I think some of them were already pointed out some time ago, but I prefer to list them all. Page 5:=20 ---------------------- - Mobile nodes should be able to use an IPv4 and IPv6 home or care-of address simultaneously and update their home agents accordingly. This is true for the home address which are used in parallel, but not for the CoA are used exclusively. Either v6 if there is one or V4 if that's all what's available. ---------------------- Page 7:=20 ---------------------- =09 Effectively, the mobile node establishes two different tunnels, one for its IPv4 traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) with a single binding update. Not necessarily two different tunnels. A tunnel is just another interface for the router and with this spec, we support both IP protocols on that interface. ---------------------- Page 8: ---------------------- The routing header in the binding update MUST include the mobile node's IPv6 home address as specified in [MIPv6]. In fact we do not need the routing header and it should be omitted. This applies to the BA format detailed page 18 as well. Also, the routing header is present in BA, not BU. ---------------------- Page 9: ---------------------- All entries MUST point to the mobile node's IPv4 care-of address included in the source address of the IPv6 packet and represented as an IPv4-mapped IPv6 address. I'll miss the mapped address ;) In any case, the CoA that the HA cares for is the source of the IPv4 packet, not the address in the CoA option so this text was doubly wrong. In the spec we call both addresses (the private and the natted) the IPv4 CoA, which ends up with this kind of trouble. ---------------------- Page 9 also: ---------------------- The inner IPv6 packet will contain the home agent's IPv6 address as a source address and the mobile node's IPv6 home address in the destination address field. I think that this text should be moved earlier, in 2.3.2. It is common to all IPv4 encaps cases. The text could also mention that UDP is always used for the BU/BA flow, with the destination port for BU set to a well-known value (TBD) defined in section 8. ---------------------- Page 10: ---------------------- P A flag indicating, when set, that the mobile node requests a mobile network prefix. This flag is only relevant for new requests, and must be ignored for binding refreshes. I'd drop this field and the whole prefix delegation support from this spec and move it to:=20 draft-ietf-nemo-prefix-delegation-* . Applies also on page 13 for the Pref field. TJ and I will submit a refresh and if Hesham wishes to join and help, this could be done swiftly. ---------------------- Page 16: ---------------------- When the home agent receives the encapsulated binding update it compares the IPv4 address of the source address field in the IPv4 header with the IPv4 address in the source address of the IPv6 Then again, now it is the CoA option.=20 ---------------------- Page 17: ---------------------- The source port in the packet is the home agent's source port. The source port in the packet is the well-known port TBD allocated by IANA in section 8 for this specification ---------------------- Page 17: ---------------------- unless the home agent forces UDP encapsulation using the F flag.=20 - >unless the home agent or the mobile node forces UDP encapsulation using the F flag.=20 The same happens page 20. ---------------------- Page 17: ---------------------- A mobile node MUST always tunnel binding updates in UDP when located in an IPv4-only network. Essentially, this process allows for perpetual NAT detection.=20 More precisely, this enables the BU / BA flow to complete whether there is a NAT or not, which might be hard to guess when the MN gets a new CoA. ----------------------=20 Page 17: ---------------------- Similarly, the home agent MUST encapsulate binding acknowledgements in a UDP header whenever the binding update is encapsulated in UDP. This means always; this is why I suggest to move that discussion in 2.3.2. ---------------------- Page 18: ---------------------- B. Binding acknowledgement sent by the home agent: IPv4 header (src=3D HA_V4ADDR, dst=3DV4ADDR) UDP header IPv6 header (src=3DHAADDR, dst=3DV6HOA) Route HDR Type 2 V6HOA (IPv6 home address) Mobility header BA ([IPv4 ACK], NAT DET) RH2 should be omitted -----------------------=20 Page 19: ---------------------- - The IPv6 packet is encapsulated in the vanilla UDP encapsulation format. I'd add that the destination port is set to the well-known port TBD defined section 8. ---------------------- Page 19: ---------------------- node did not have a static home address it MAY include the unspecified IPv4 address, which acts as a request for a dynamic IPv4 home address. Alternatively, one or more IPv4 home address I'm not sure whether the unspecified IPv4 address is specified anywhere? For IPv6 people it makes all the sense in the world, but may we could=20 stick to all zeroes unless it's actually defined in a reference - that I missed? ---------------------- Page 19: ---------------------- Alternatively, one or more IPv4 home address options may be included with requests for IPv4 prefixes (i.e. with the P flag set.). As I proposed, let's move this to the NEMO prefix delegation spec. ---------------------- Page 20: ---------------------- Where the UDP header is only used if a NAT were detected between the mobile node and the home agent, or if the home agent forced UDP encapsulation. or if the home agent or the MN forced the encapsulation. ---------------------- I hope this helps... Pascal >-----Original Message----- >From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >Sent: Tuesday, August 07, 2007 12:14 AM >To: Mobile IPv6 Mailing List; nemo@ietf.org >Cc: Gopal Dommety (gdommety); thierry.ernst@inria.fr; Basavaraj Patil; tj@kniveton.com >Subject: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt > > >Hello, > >This is a joint working group last call between for I-D: >Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) > > >URL: >http://ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4traversal-05.txt > >This I-D is a standards track document and is a joint MIP6/NEMO WG I-D. > >Please review the ID and submit your comments to the MIP6 and NEMO WG >mailing lists by August 22nd, 07. > >-Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 22 12:02:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INsfN-0006KA-SY; Wed, 22 Aug 2007 12:02:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INsfM-0006Jx-J4; Wed, 22 Aug 2007 12:02:44 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1INsfM-0004v8-5u; Wed, 22 Aug 2007 12:02:44 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1187798562!374181!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 15092 invoked from network); 22 Aug 2007 16:02:42 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-128.messagelabs.com with SMTP; 22 Aug 2007 16:02:42 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l7MG2aFi016174; Wed, 22 Aug 2007 09:02:37 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l7MG2Z9N008231; Wed, 22 Aug 2007 11:02:35 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l7MG2UlT007918; Wed, 22 Aug 2007 11:02:31 -0500 (CDT) Message-ID: <46CC5E08.7040906@gmail.com> Date: Wed, 22 Aug 2007 18:02:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC045F8EFD@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC045F8EFD@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000767-3, 21/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: nemo@ietf.org, "Gopal Dommety \(gdommety\)" , tj@kniveton.com, Basavaraj Patil , Mobile IPv6 Mailing List , thierry.ernst@inria.fr Subject: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Pascal Thubert (pthubert) wrote: [...] > Page 10: > ---------------------- > P A flag indicating, when set, that the mobile > node requests a mobile network prefix. This flag > is only relevant for new requests, and must be > ignored for binding refreshes. > > I'd drop this field and the whole prefix delegation support from this > spec and move it to: > draft-ietf-nemo-prefix-delegation-* . Applies also on page 13 for the > Pref field. > TJ and I will submit a refresh and if Hesham wishes to join and help, > this could be done swiftly. I agree with this suggestion to move all assignment of prefixes to draft-ietf-nemo-prefix-delegation draft (away from ds-mipv6). Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 22 12:22:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INsyK-0006DL-U4; Wed, 22 Aug 2007 12:22:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INsyJ-0006DE-JB for mip6@ietf.org; Wed, 22 Aug 2007 12:22:19 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.143]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INsyJ-0005HU-1C for mip6@ietf.org; Wed, 22 Aug 2007 12:22:19 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l7MGMGhZ026747 for ; Wed, 22 Aug 2007 12:22:16 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l7MGMGvw511246 for ; Wed, 22 Aug 2007 12:22:16 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l7MGMGDV017009 for ; Wed, 22 Aug 2007 12:22:16 -0400 Received: from cichlid.raleigh.ibm.com (wecm-9-67-169-143.wecm.ibm.com [9.67.169.143]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7MGMFOE016954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Aug 2007 12:22:16 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id l7MGLn1t011757; Wed, 22 Aug 2007 12:21:59 -0400 Message-Id: <200708221621.l7MGLn1t011757@cichlid.raleigh.ibm.com> To: Basavaraj Patil Subject: Re: [Mip6] WG LC: I-D draft-ietf-mip6-rfc4285bis-00.txt In-reply-to: References: Comments: In-reply-to Basavaraj Patil message dated "Mon, 20 Aug 2007 15:19:40 -0500." Date: Wed, 22 Aug 2007 12:21:49 -0400 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Mobile IPv6 Mailing List , "Kent Leung \(kleung\)" , haseebak@nortel.com, alpesh@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Very quick comment. Where is the changes section outlining what has changed relative to the RFC it replaces? That is the first question I had... Thomas _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 22 12:42:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INtHe-0004xH-0Y; Wed, 22 Aug 2007 12:42:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INtHd-0004x9-8f; Wed, 22 Aug 2007 12:42:17 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INtHc-0005iX-TZ; Wed, 22 Aug 2007 12:42:17 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 22 Aug 2007 09:42:01 -0700 X-IronPort-AV: i="4.19,295,1183359600"; d="scan'208"; a="516053082:sNHT3721353994" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7MGg0bA002323; Wed, 22 Aug 2007 09:42:00 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l7MGfupa024251; Wed, 22 Aug 2007 16:41:56 GMT Date: Wed, 22 Aug 2007 09:41:56 -0700 (PDT) From: Sri Gundavelli To: Mobile IPv6 Mailing List Subject: Re: [Mip6] Re: [nemo] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt In-Reply-To: <46CC5E08.7040906@gmail.com> Message-ID: References: <7892795E1A87F04CADFCCF41FADD00FC045F8EFD@xmb-ams-337.emea.cisco.com> <46CC5E08.7040906@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=493; t=1187800921; x=1188664921; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Re=3A=20[Mip6]=20Re=3A=20[nemo]=20WG=20LC=3A=20draft-ietf-mip 6-nemo-v4traversal-05.txt |Sender:=20; bh=Q5RbkQmpSve58siNiIoanXSbWKqhNUtWN4E9tKvtHnc=; b=QKhWsvCw1baT+dcNfpsqTIgRNSQg4yUtdxZgZejB5lhF1gGPw6N0PShXN/gyXa8pS72C8KdM ZVJOMAy11eEwdr0kKumLsls7VMXCcHFdDFeuCC+YSifKy9dtCjfXzCJSwTjYjRSsss7/RHz8Lf 3dwibYS/GD4pNau5zPVaGNe2M=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: nemo@ietf.org, "Gopal Dommety \(gdommety\)" , tj@kniveton.com, thierry.ernst@inria.fr, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I've reviewed the earlier version of this document and I think it should be advanced to the next stage. We have a normative dependency on this draft for our PMIP6 IPv4 support document. I hope this will be cleared in the timely manner. If there are concerns on the approach this document takes w.r.t not adopting a generic transition solution, future work can define alternate solutions based on generic transition solutions, IMO. That should not stop this work, My 2c. Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 22 13:00:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INtZT-0003zy-HG; Wed, 22 Aug 2007 13:00:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INtZR-0003zS-LQ; Wed, 22 Aug 2007 13:00:41 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INtZR-000618-8Y; Wed, 22 Aug 2007 13:00:41 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7MH0a617816; Wed, 22 Aug 2007 17:00:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt Date: Wed, 22 Aug 2007 12:00:31 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371164A9DB1@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt Thread-Index: AcfYdxsOWcs/5kRqEdy1KAARJNUNiAMZmRgQ References: From: "Ahmad Muhanna" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Gopal Dommety , thierry.ernst@inria.fr, tj@kniveton.com, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I have reviewed the latest draft and I believe it is in a good shape. However, as I mentioned to Hesham earlier, the new proposed mechanism for addressing the IPv4 CoA using a separate option, requires the use of the MN IPv6 HoA as a source address for the IPv6 header. This is a new functionality on the HA and if we all ok with that, then there is no issue. Thanks. Regards, Ahmad =20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Monday, August 06, 2007 5:14 PM > To: Mobile IPv6 Mailing List; nemo@ietf.org > Cc: Gopal Dommety; thierry.ernst@inria.fr; Basavaraj Patil;=20 > tj@kniveton.com > Subject: [Mip6] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt >=20 >=20 > Hello, >=20 > This is a joint working group last call between for I-D: > Mobile IPv6 support for dual stack Hosts and Routers=20 > (DSMIPv6) >=20 > URL: > http://ietf.org/internet-drafts/draft-ietf-mip6-nemo-v4travers al-05.txt >=20 > This I-D is a standards track document and is a joint=20 > MIP6/NEMO WG I-D. >=20 > Please review the ID and submit your comments to the MIP6 and=20 > NEMO WG mailing lists by August 22nd, 07. >=20 > -Raj >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 22 18:15:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyTq-0000z5-8C; Wed, 22 Aug 2007 18:15:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyTf-0000oj-TW; Wed, 22 Aug 2007 18:15:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INyTf-0002yM-Du; Wed, 22 Aug 2007 18:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 07659175F7; Wed, 22 Aug 2007 22:15:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1INyTe-0007Q1-Fs; Wed, 22 Aug 2007 18:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 22 Aug 2007 18:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-whyauthdataoption-03.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Why Authentication Data suboption is needed for MIP6 Author(s) : B. Patil, G. Dommety Filename : draft-ietf-mip6-whyauthdataoption-03.txt Pages : 16 Date : 2007-8-22 Mobile IPv6 defines a set of messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec SA that is established between the MN and HA. The MIP6 working group has proposed a mechanism to secure the binding update and binding acknowledgement messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain deployment environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-whyauthdataoption-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-whyauthdataoption-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-whyauthdataoption-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-22171921.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-whyauthdataoption-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-whyauthdataoption-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-22171921.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Wed Aug 22 18:22:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyaa-0001cE-K3; Wed, 22 Aug 2007 18:22:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyaY-0001c8-Q4; Wed, 22 Aug 2007 18:22:10 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INyaX-0005Fi-Km; Wed, 22 Aug 2007 18:22:10 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7MMLavM022081; Thu, 23 Aug 2007 01:21:39 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 01:21:28 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Aug 2007 17:21:23 -0500 Received: from 10.241.58.216 ([10.241.58.216]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 22 Aug 2007 22:21:23 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 22 Aug 2007 17:21:32 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List , , ext Jari Arkko Message-ID: Thread-Topic: Request to progress MIP6 WG I-D: draft-ietf-mip6-ha-switch-03.txt Thread-Index: AcflCsroCS+8OVD+EdyuUQARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Aug 2007 22:21:23.0617 (UTC) FILETIME=[C5E91910:01C7E50A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: Gopal Dommety , ext James Kempf , Vijay Devarapalli , brian.haley@hp.com, Hui Deng Subject: [Mip6] Request to progress MIP6 WG I-D: draft-ietf-mip6-ha-switch-03.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Jari, The MIP6 WG I-D: Mobility Header Home Agent Switch Message has completed working group last call in March 07. The document is ready for IESG review and to be progressed for publication. This I-D is intended to be progressed as a standards track document. The IESG writeup for the I-D is included below. -Basavaraj ========================================= (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document shepherd: Basavaraj Patil I have reviewed this I-D and believe it is ready for IESG review and publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed as part of the WG last call. It has also been discussed previously and been presented to the WG in several meetings. I do not have any concerns about the depth or breadth of the reviews that have been performed. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? I believe that the document has been reviewed sufficiently and there is no need for further reviews or to broaden the scope of the reviews. The complexity of the I-D and enhancement to base MIP6 being proposed in this I-D is fairly small and hence the current level of reviews is sufficient. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No issues or concerns exist with this I-D. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong WG consensus on this I-D. I believe the WG (majority) understands this I-D and the need for the extension being proposed. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No discontent has been expressed about this I-D in the WG. There has been no issue about appeals against the I-D being made. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. I have verified the I-D via the ID-nits checker and it has reported no errors. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References have been split into normative and informative sections. There are no normative references which are not ready for advancement at this time. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The IANA considerations section exists and is satisfactory. The document does not propose any new registries. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? This question is not applicable to the current I-D. There are no MIB definitions, BNF rules or XML code in this I-D. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies a new Mobility Header message type that can be used between a home agent and mobile node to signal a mobile node that it should acquire a new home agent. Working Group Summary This I-D has been presented to the WG and discussed in WG meetings several times. There is strong consensus on the need for the message extension being specified in this I-D. Document Quality No known implementations of this protocol extension exist at the present time. However there is interest by several vendors in implementing this extenstion. All the relevant reviewers have been acknowledged. The I-D has not been reviewed by MIB doctors since it does not specify a MIB. Personnel Document Shepherd: Basavaraj Patil Responsible AD: Jari Arkko _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Aug 23 13:16:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOGIK-0001gP-Iz; Thu, 23 Aug 2007 13:16:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOGIJ-0001gB-99 for mip6@ietf.org; Thu, 23 Aug 2007 13:16:31 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOGIH-0003zA-PF for mip6@ietf.org; Thu, 23 Aug 2007 13:16:31 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7NHGGno028838; Thu, 23 Aug 2007 20:16:26 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 20:16:25 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 12:15:42 -0500 Received: from 10.241.59.136 ([10.241.59.136]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 23 Aug 2007 17:15:42 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 23 Aug 2007 12:15:54 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List Message-ID: Thread-Topic: Consensus call: Adopting I-D Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Aug 2007 17:15:43.0060 (UTC) FILETIME=[3C7FF140:01C7E5A9] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Gopal Dommety Subject: [Mip6] Consensus call: Adopting I-D X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, This is a consensus call for adopting I-D: Binding Revocation for IPv6 Mobility as a MIP6 WG document. The I-D has been discussed on the ML in the past and was also presented at IETF69 in Chicago. So please opine on the following statement: The binding revocation feature specified in I-D draft-muhanna-mip6-binding-revocation-01.txt is essential for MIP6 deployments and hence should be made a MIP6 WG document and progressed as a standards track doc. Yes [ ] No [ ] -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Aug 23 14:46:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOHhQ-00055e-OF; Thu, 23 Aug 2007 14:46:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOHhQ-00055X-0J for mip6@ietf.org; Thu, 23 Aug 2007 14:46:32 -0400 Received: from web84115.mail.mud.yahoo.com ([68.142.206.202]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IOHhP-00080i-GI for mip6@ietf.org; Thu, 23 Aug 2007 14:46:31 -0400 Received: (qmail 14082 invoked by uid 60001); 23 Aug 2007 18:46:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=bjh1RxznnpV1Z2EEShC4P5CDotLV2l+L7lRrK54TWXsH21LS8cTBNgUw3AS1VVclZoSAA5IhXOZ872vtX3VI8394krN+0mzeTcceWdJ5oBMPoX91Geqgq4X26fHovE8nppcEmTM9s2ZApFuuVT5ksAv6bG2GHy4OjKH4HerNHws=; X-YMail-OSG: LeJbDPEVM1lsz70lV5626dptVvp8.yEqJcWa4uYrw_Z6rcs_YTYP1ypu6Zyyn_Pw4d.rULZUhOIbB0LYbgV0wmgqxLtZew7f0AkYBpS94o_a8u8- Received: from [206.16.17.212] by web84115.mail.mud.yahoo.com via HTTP; Thu, 23 Aug 2007 11:46:30 PDT X-Mailer: YahooMailRC/651.48 YahooMailWebService/0.7.119 Date: Thu, 23 Aug 2007 11:46:30 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [Mip6] Consensus call: Adopting I-D To: Basavaraj Patil , Mobile IPv6 Mailing List MIME-Version: 1.0 Message-ID: <992044.13374.qm@web84115.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0733529965==" Errors-To: mip6-bounces@ietf.org --===============0733529965== Content-Type: multipart/alternative; boundary="0-94759632-1187894790=:13374" --0-94759632-1187894790=:13374 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Raj,=0A My vote below.=0A=0AI hope you are having a nice summer.=0A=0A-= -behcet=0A=0A----- Original Message ----=0AFrom: Basavaraj Patil =0ATo: Mobile IPv6 Mailing List =0ACc: Gopal = Dommety =0ASent: Thursday, August 23, 2007 12:15:54 PM= =0ASubject: [Mip6] Consensus call: Adopting I-D=0A=0A=0AHello,=0A=0AThis is= a consensus call for adopting I-D: Binding Revocation for IPv6=0AMobility = as a MIP6 WG=0Adocument.=0A= =0AThe I-D has been discussed on the ML in the past and was also presented = at=0AIETF69 in Chicago.=0A=0ASo please opine on the following statement:=0A= =0AThe binding revocation feature specified in I-D=0Adraft-muhanna-mip6-bin= ding-revocation-01.txt is essential for MIP6=0Adeployments and hence should= be made a MIP6 WG document and progressed as a=0Astandards track doc.=0A= =0AYes [X ]=0ANo [ ]=0A=0A-Raj=0A=0A=0A___________________________________= ____________=0AMip6 mailing list=0AMip6@ietf.org=0Ahttps://www1.ietf.org/ma= ilman/listinfo/mip6=0A=0A=0A=0A=0A --0-94759632-1187894790=:13374 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi Raj,
  My vote below.

I hope you are= having a nice summer.

--behcet

----- Original Messag= e ----
From: Basavaraj Patil <basavaraj.patil@nsn.com>
To: Mobi= le IPv6 Mailing List <mip6@ietf.org>
Cc: Gopal Dommety <gdommet= y@cisco.com>
Sent: Thursday, August 23, 2007 12:15:54 PM
Subject: = [Mip6] Consensus call: Adopting I-D


Hello,

This is a= consensus call for adopting I-D: Binding Revocation for IPv6
Mobility &= lt;draft-muhanna-mip6-binding-revocation-01.txt> as a MIP6 WG
documen= t.

The I-D has been discussed on the ML in the past and was also presented at
IETF69 in Chicago.

So please opine on the following= statement:

The binding revocation feature specified in I-D
draft= -muhanna-mip6-binding-revocation-01.txt is essential for MIP6
deployment= s and hence should be made a MIP6 WG document and progressed as a
standa= rds track doc.

Yes [X ]
No  [ ]

-Raj


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

--0-94759632-1187894790=:13374-- --===============0733529965== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0733529965==-- From mip6-bounces@ietf.org Thu Aug 23 16:21:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOJBe-0003mG-P9; Thu, 23 Aug 2007 16:21:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOJBd-0003fQ-NT; Thu, 23 Aug 2007 16:21:49 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOJBc-0001YD-0H; Thu, 23 Aug 2007 16:21:49 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7NKLKX8015263; Thu, 23 Aug 2007 23:21:34 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 23:21:19 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 15:21:09 -0500 Received: from 10.241.59.136 ([10.241.59.136]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 23 Aug 2007 20:21:09 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 23 Aug 2007 15:21:20 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List , , ext Jari Arkko Message-ID: Thread-Topic: Request to progress I-Ds: 1. draft-ietf-mip6-experimental-messages-01.txt AND 2. draft-ietf-mip6-vsm-01.txt Thread-Index: AcflwyqiaXw1rlG2EdyuUQARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Aug 2007 20:21:09.0559 (UTC) FILETIME=[2468F470:01C7E5C3] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: Gopal Dommety , Vijay Devarapalli , Basavaraj Patil Subject: [Mip6] Request to progress I-Ds: 1. draft-ietf-mip6-experimental-messages-01.txt AND 2. draft-ietf-mip6-vsm-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Jari, The following MIP6 WG I-Ds have completed WG last call and ready for AD review and to be progressed forward. I-Ds: 1. Mobile IPv6 Experimental Messages 2. Mobile IPv6 Vendor Specific Option Both I-Ds are intended to be progressed as standards track documents. The IESG writeup for these I-Ds is attached below. -Basavaraj Please note that this writeup is for two MIP6 WG I-Ds. =============================================== (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document Shepherd: Basavaraj Patil I have reviewed the I-Ds and believe the documents are ready to be forwarded to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The documents have been reviewed sufficiently. They are fairly simple I-Ds and proposing vendor specific extensions for the mobility header messages and a new experimental MH message. I do not have any concerns about the depth or breadth of the reviews or the need for any further reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? I do not believe there is a need for further reviews or to broaden the scope of the reviews. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I believe the documents are ready and do not have any concerns progressing them. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The documents have been presented to the MIP6 WG at meetings and there is consensus on the proposed extensions contained in these I-Ds. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No appeal threats or otherwise have been made for these I-Ds. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. Yes. I have run the I-Ds through the ID-nits checker at tools.ietf.org and no issues were indicated. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. The documents have split the references into normative and informative sections. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The IANA section exists and is satisfactory. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not applicable to the I-Ds being discussed here. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary I-D: draft-ietf-mip6-experimental-messages This document defines a new experimental Mobility header message and a mobility option that can be used for experimental extensions to the Mobile IPv6 protocol. I-D: draft-ietf-mip6-vsm There is a need for vendor specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes. This document defines a new vendor specific mobility option. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? No controversy has been raised or identified with these I-Ds. The I-Ds are fairly simple and the extensions useful for the MIP6 protocol. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? No known implementations of the extensions being proposed here exist. No media types of MIB exists in the documents. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Document Shepherd: Basavaraj Patil Responsible AD: Jari Arkko _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Aug 23 16:28:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOJHb-00008E-QO; Thu, 23 Aug 2007 16:27:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOJHa-000088-SQ for mip6@ietf.org; Thu, 23 Aug 2007 16:27:58 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOJHa-0002dI-9T for mip6@ietf.org; Thu, 23 Aug 2007 16:27:58 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l7NKPpL23680; Thu, 23 Aug 2007 20:25:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call: Adopting I-D Date: Thu, 23 Aug 2007 16:27:54 -0400 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711654F3EF@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Consensus call: Adopting I-D Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiAAFISOgAAGKfIA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711654F3EF@zrc2hxm2.corp.nortel.com> From: "Barnaba Barnowski" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello Raj: My vote is 'Yes [x]'. Regards, Barney=20 >=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Thursday, August 23, 2007 12:16 PM > To: Mobile IPv6 Mailing List > Cc: Gopal Dommety > Subject: [Mip6] Consensus call: Adopting I-D >=20 >=20 > Hello, >=20 > This is a consensus call for adopting I-D: Binding Revocation=20 > for IPv6 Mobility=20 > as a MIP6 WG document. >=20 > The I-D has been discussed on the ML in the past and was also=20 > presented at > IETF69 in Chicago. >=20 > So please opine on the following statement: >=20 > The binding revocation feature specified in I-D=20 > draft-muhanna-mip6-binding-revocation-01.txt is essential for=20 > MIP6 deployments and hence should be made a MIP6 WG document=20 > and progressed as a standards track doc. >=20 > Yes [X] > No [ ] >=20 > -Raj >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Aug 23 16:49:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOJcc-0005Sk-Au; Thu, 23 Aug 2007 16:49:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOJca-0005Sb-Gs for mip6@ietf.org; Thu, 23 Aug 2007 16:49:40 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOJcY-0002JX-OV for mip6@ietf.org; Thu, 23 Aug 2007 16:49:40 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7NKnaZA029544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Aug 2007 13:49:36 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7NKnZ9I022608; Thu, 23 Aug 2007 13:49:35 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Aug 2007 13:49:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call: Adopting I-D Date: Thu, 23 Aug 2007 13:49:11 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Consensus call: Adopting I-D Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiAAHbzXw References: From: "Narayanan, Vidya" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" X-OriginalArrivalTime: 23 Aug 2007 20:49:15.0682 (UTC) FILETIME=[116AE820:01C7E5C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Raj, Was there a conclusion on how this draft relates to draft-haley?=20 Sorry if I missed it.=20 Vidya=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Thursday, August 23, 2007 10:16 AM > To: Mobile IPv6 Mailing List > Cc: Gopal Dommety > Subject: [Mip6] Consensus call: Adopting I-D >=20 >=20 > Hello, >=20 > This is a consensus call for adopting I-D: Binding Revocation=20 > for IPv6 Mobility=20 > as a MIP6 WG document. >=20 > The I-D has been discussed on the ML in the past and was also=20 > presented at > IETF69 in Chicago. >=20 > So please opine on the following statement: >=20 > The binding revocation feature specified in I-D=20 > draft-muhanna-mip6-binding-revocation-01.txt is essential for=20 > MIP6 deployments and hence should be made a MIP6 WG document=20 > and progressed as a standards track doc. >=20 > Yes [ ] > No [ ] >=20 > -Raj >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Aug 23 18:13:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOKvR-0004YJ-Ln; Thu, 23 Aug 2007 18:13:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOKvQ-0004Xb-Eo; Thu, 23 Aug 2007 18:13:12 -0400 Received: from venus.verizonwireless.com ([162.115.163.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOKvQ-0006f9-3P; Thu, 23 Aug 2007 18:13:12 -0400 DomainKey-Signature: s=privmail; d=verizonwireless.com; c=nofws; q=dns; b=AWqr/uS5NlnZ32jwHJ5aJNpEGV9q8p2V1G6lwedliiRgZPtRebB5g64Raywdh3B2Yr421+tJacGXaWPNvdgrZQZznNwjlDbR94YQdhOuRmIk3PZshjuynQDmsqSgI0Z0; From: Lalit.Kotecha@VerizonWireless.com Received: from cairvexsmtp20.uswin.ad.vzwcorp.com ([10.10.173.32]) by venus.verizonwireless.com with ESMTP; 23 Aug 2007 15:13:10 -0700 Received: from carcrdexmb20.uswin.ad.vzwcorp.com ([10.4.102.60]) by cairvexsmtp20.uswin.ad.vzwcorp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 15:13:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt Date: Thu, 23 Aug 2007 15:13:06 -0700 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt Thread-Index: AcflwyqiaXw1rlG2EdyuUQARJNUNiAADxapA References: To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" , , "ext Jari Arkko" X-OriginalArrivalTime: 23 Aug 2007 22:13:10.0538 (UTC) FILETIME=[CA6CF6A0:01C7E5D2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Kalyani.Bogineni@VerizonWireless.com, Gerry.Libunao@VerizonWireless.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Message-Id: Raj, I have reviewed this draft and support in favor of submitting this draft to IESG. I think IPv4/IPv6 support is extremely important in DS-MIPv6 as well as PMIPv6. Regards Lalit=20 The information contained in this message and any attachment may be proprietary, confidential, and privileged or subject to the work product doctrine and thus protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to this message and deleting it and all copies and backups thereof. Thank you. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Aug 23 22:57:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOPMr-0007ve-Fj; Thu, 23 Aug 2007 22:57:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOPMq-0007pY-5d for mip6@ietf.org; Thu, 23 Aug 2007 22:57:48 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOPMo-0003YK-N1 for mip6@ietf.org; Thu, 23 Aug 2007 22:57:48 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7O2vYD6027770; Fri, 24 Aug 2007 05:57:42 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 05:57:04 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 21:57:02 -0500 Received: from 10.241.59.196 ([10.241.59.196]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 24 Aug 2007 02:57:01 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 23 Aug 2007 21:57:15 -0500 Subject: Re: [Mip6] Consensus call: Adopting I-D From: Basavaraj Patil To: "ext Narayanan, Vidya" , Mobile IPv6 Mailing List Message-ID: Thread-Topic: [Mip6] Consensus call: Adopting I-D Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiAAHbzXwAAzed1o= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 24 Aug 2007 02:57:02.0061 (UTC) FILETIME=[720121D0:01C7E5FA] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vidya, Yes... There was a conclusion and basically we agreed that the MH message specified in draft-haley can be used as the means for revocation. This draft specifies the details of the Reg-revocation message, the behavior and operation of the MN and HA in the context of binding revocation. -Raj On 8/23/07 3:49 PM, "ext Narayanan, Vidya" wrote: > Raj, > Was there a conclusion on how this draft relates to draft-haley? > > Sorry if I missed it. > > Vidya > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Thursday, August 23, 2007 10:16 AM >> To: Mobile IPv6 Mailing List >> Cc: Gopal Dommety >> Subject: [Mip6] Consensus call: Adopting I-D >> >> >> Hello, >> >> This is a consensus call for adopting I-D: Binding Revocation >> for IPv6 Mobility >> as a MIP6 WG document. >> >> The I-D has been discussed on the ML in the past and was also >> presented at >> IETF69 in Chicago. >> >> So please opine on the following statement: >> >> The binding revocation feature specified in I-D >> draft-muhanna-mip6-binding-revocation-01.txt is essential for >> MIP6 deployments and hence should be made a MIP6 WG document >> and progressed as a standards track doc. >> >> Yes [ ] >> No [ ] >> >> -Raj >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Aug 24 01:16:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IORWf-0007Pi-SB; Fri, 24 Aug 2007 01:16:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IORWb-0007GQ-2B for mip6@ietf.org; Fri, 24 Aug 2007 01:16:01 -0400 Received: from rv-out-0910.google.com ([209.85.198.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IORWZ-0005s1-Qz for mip6@ietf.org; Fri, 24 Aug 2007 01:16:01 -0400 Received: by rv-out-0910.google.com with SMTP id l15so538860rvb for ; Thu, 23 Aug 2007 22:15:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=NxbIUrcqGaOcHgwF8mdWM1149rm4VahnzHwNbeLulty+yZTpH9G0vkvoGQ2pEHqDV91+qYnnFWHfrsd4FFh4fHUNMyUF2S9ijAldnqxQwdjrR7CyQCw1hgjW6n4YBafjcebIGOIFhe162qLjqfYWzxVF8AL/pEy01ZqRAqgnmL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=cGHs/izoVus4s3eYSvXf6f0tdT6ZuS7xTqv0S7D3kFi9+/Lhm8NO7uXN8Q12Y1eKetT+HOuy9zhFAEnzhpYFlN/CNFYWrcgztleeHkro6L81/LZ5VPjwUOC7tjZZpmnd8GRLw9yc4Ra6G9V1vIEHFc5tiSYZQQkJXCc7aa7i8bI= Received: by 10.141.141.3 with SMTP id t3mr1228675rvn.1187932559031; Thu, 23 Aug 2007 22:15:59 -0700 (PDT) Received: from ?10.0.1.200? ( [219.110.223.34]) by mx.google.com with ESMTPS id k2sm6030866rvb.2007.08.23.22.15.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2007 22:15:57 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: [Mip6] Consensus call: Adopting I-D Date: Fri, 24 Aug 2007 14:15:53 +0900 To: Basavaraj Patil X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Gopal Dommety , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, Yes, I support this document as a WG item. ryuji On 2007/08/24, at 2:15, Basavaraj Patil wrote: > > Hello, > > This is a consensus call for adopting I-D: Binding Revocation for IPv6 > Mobility as a MIP6 WG > document. > > The I-D has been discussed on the ML in the past and was also > presented at > IETF69 in Chicago. > > So please opine on the following statement: > > The binding revocation feature specified in I-D > draft-muhanna-mip6-binding-revocation-01.txt is essential for MIP6 > deployments and hence should be made a MIP6 WG document and > progressed as a > standards track doc. > > Yes [ x] > No [ ] > > -Raj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Aug 24 04:26:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOUUx-0005hl-JQ; Fri, 24 Aug 2007 04:26:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOUUv-0005hf-HD for mip6@ietf.org; Fri, 24 Aug 2007 04:26:29 -0400 Received: from mout.perfora.net ([74.208.4.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOUUv-00042M-6u for mip6@ietf.org; Fri, 24 Aug 2007 04:26:29 -0400 Received: from ehw.hotels-on-air.de [217.194.76.54] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1IOUUo2YgI-0008Nv; Fri, 24 Aug 2007 04:26:27 -0400 From: "Alper Yegin" To: "'Basavaraj Patil'" , "'Mobile IPv6 Mailing List'" Subject: RE: [Mip6] Consensus call: Adopting I-D Date: Fri, 24 Aug 2007 10:26:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiAAfx2mA Message-Id: <0MKp8S-1IOUUo2YgI-0008Nv@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+yzmBt1aS5hyocR93nyIDuaLgP1Zeook3XrI3 zk06n8Ohb40w0xzKJ4RoxYsYElxuxZrc2RAFRJh4GtJPDQgzWU 6UKs7mxQYDMbLeVICTOOw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: 'Gopal Dommety' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > The binding revocation feature specified in I-D > draft-muhanna-mip6-binding-revocation-01.txt is essential for MIP6 > deployments and hence should be made a MIP6 WG document and progressed as > a > standards track doc. > > Yes [X] > No [ ] _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Aug 24 04:51:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOUsn-0005da-RG; Fri, 24 Aug 2007 04:51:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOUsm-0005dU-Er for mip6@ietf.org; Fri, 24 Aug 2007 04:51:08 -0400 Received: from fk-out-0910.google.com ([209.85.128.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOUsl-0002So-6n for mip6@ietf.org; Fri, 24 Aug 2007 04:51:08 -0400 Received: by fk-out-0910.google.com with SMTP id z23so633837fkz for ; Fri, 24 Aug 2007 01:51:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=WXunGSP6p8UDn6Nwk6ANFZWz62CijH7UuLAFshGmonKM12UMQ7eBJ59Tsl5eIemlLr0h3R9JAQ8M6jkMNoLQpaKpzlZMXR3IMCh8lngJNrybr/HArVz8eKeZZfrMJWyPwhManCsa+wd1SRpqU5VgFSZW7dhy274eVCg/2EJjYAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=OIjXrkirqQhY2uB0GT3GiurtLTQam1tYxwkTJY+Lt4iS4EBl/nfWLSgbKT2aee8+VElf133rhhlufyq/f0r2vuAN84Et1uWtu+fGrXpnSR6GBBuDag2Sl0tl+Dxj1WEalz6B5Zc34FuICwxsrIlpuXD3FVB9f8cyg9Jt3z03jWg= Received: by 10.82.156.12 with SMTP id d12mr6255944bue.1187945465892; Fri, 24 Aug 2007 01:51:05 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id h6sm8761530nfh.2007.08.24.01.51.03 (version=SSLv3 cipher=OTHER); Fri, 24 Aug 2007 01:51:04 -0700 (PDT) From: Julien Laganier To: mip6@ietf.org Subject: Re: [Mip6] Consensus call: Adopting I-D Date: Fri, 24 Aug 2007 10:51:00 +0200 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708241051.01266.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On Thursday 23 August 2007, Basavaraj Patil wrote: > > So please opine on the following statement: > > The binding revocation feature specified in I-D > draft-muhanna-mip6-binding-revocation-01.txt is essential for MIP6 > deployments and hence should be made a MIP6 WG document and > progressed as a standards track doc. Yes [X] No [ ] --julien _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Aug 24 09:40:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOZOK-0000PM-R0; Fri, 24 Aug 2007 09:40:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOZOJ-0000Iz-Ek for mip6@ietf.org; Fri, 24 Aug 2007 09:39:59 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOZOH-000150-Tn for mip6@ietf.org; Fri, 24 Aug 2007 09:39:59 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7ODdgV26950; Fri, 24 Aug 2007 13:39:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call: Adopting I-D Date: Fri, 24 Aug 2007 08:39:35 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711659F3C3@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Consensus call: Adopting I-D Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiAAHbzXwACJJuAA= References: From: "Ahmad Muhanna" To: "Narayanan, Vidya" , "Basavaraj Patil" , "Mobile IPv6 Mailing List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vidya/All, I just would like to give some clarification, the most up-to-date solution of the draft, which was based on latest discussion on the MIP6 mailing list, was presented during MIPv6 meeting in Chicago. We basically presented the use of one MH type "Generic Notification message" with a subtype field. The subtype is used to differentiate Binding revocation signaling messages from other notification signaling. For more information, please take a look at the details in the revocation slides at the link below. http://www3.ietf.org/proceedings/07jul/slides/mip6-3/sld1.htm Regards, Ahmad =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Thursday, August 23, 2007 3:49 PM > To: Basavaraj Patil; Mobile IPv6 Mailing List > Cc: Gopal Dommety > Subject: RE: [Mip6] Consensus call: Adopting I-D >=20 > Raj, > Was there a conclusion on how this draft relates to draft-haley?=20 >=20 > Sorry if I missed it.=20 >=20 > Vidya=20 >=20 > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > Sent: Thursday, August 23, 2007 10:16 AM > > To: Mobile IPv6 Mailing List > > Cc: Gopal Dommety > > Subject: [Mip6] Consensus call: Adopting I-D > >=20 > >=20 > > Hello, > >=20 > > This is a consensus call for adopting I-D: Binding=20 > Revocation for IPv6=20 > > Mobility as=20 > a MIP6 WG=20 > > document. > >=20 > > The I-D has been discussed on the ML in the past and was also=20 > > presented at > > IETF69 in Chicago. > >=20 > > So please opine on the following statement: > >=20 > > The binding revocation feature specified in I-D=20 > > draft-muhanna-mip6-binding-revocation-01.txt is essential for > > MIP6 deployments and hence should be made a MIP6 WG document and=20 > > progressed as a standards track doc. > >=20 > > Yes [ ] > > No [ ] > >=20 > > -Raj > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Aug 24 15:15:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOecc-0000B9-RH; Fri, 24 Aug 2007 15:15:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOecY-0000AV-Vy; Fri, 24 Aug 2007 15:15:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOecY-0003HO-EK; Fri, 24 Aug 2007 15:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 476AA26E5C; Fri, 24 Aug 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IOecY-00071J-5N; Fri, 24 Aug 2007 15:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 24 Aug 2007 15:15:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-whyauthdataoption-04.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Why Authentication Data suboption is needed for MIP6 Author(s) : B. Patil, G. Dommety Filename : draft-ietf-mip6-whyauthdataoption-04.txt Pages : 16 Date : 2007-8-24 Mobile IPv6 defines a set of messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec SA that is established between the MN and HA. The MIP6 working group has proposed a mechanism to secure the binding update and binding acknowledgement messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain deployment environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-whyauthdataoption-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-whyauthdataoption-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-whyauthdataoption-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-24142622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-whyauthdataoption-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-whyauthdataoption-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-24142622.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Fri Aug 24 18:28:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOhdg-0001L1-GP; Fri, 24 Aug 2007 18:28:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOhde-0001Ia-7r for mip6@ietf.org; Fri, 24 Aug 2007 18:28:22 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOhdc-0004yP-Iz for mip6@ietf.org; Fri, 24 Aug 2007 18:28:22 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7OMSDIR027944 for ; Sat, 25 Aug 2007 01:28:16 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Aug 2007 01:28:13 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 17:28:11 -0500 Received: from 10.241.59.253 ([10.241.59.253]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 24 Aug 2007 22:28:11 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 24 Aug 2007 17:28:24 -0500 From: Basavaraj Patil To: Mobile IPv6 Mailing List Message-ID: Thread-Topic: IETF69: MIP6 WG meeting minutes Thread-Index: AcfmnhVNU6+E8lKREdyuUQARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 24 Aug 2007 22:28:11.0155 (UTC) FILETIME=[0DA5F630:01C7E69E] X-Nokia-AV: Clean X-Spam-Score: 3.5 (+++) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Subject: [Mip6] IETF69: MIP6 WG meeting minutes X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Minutes of: Mobility for IPv6 (mip6) WG At: IETF69 (Chicago) TUESDAY, July 24, 2007 from 1520-1720 Chairs: Basavaraj Patil Gopal Dommety Credit for these minutes: 1. Kilian Weniger (Kilian.Weniger@eu.panasonic.com) 2. Jabber scribe: T.J Kniveton (tj@kniveton.com) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Agenda review, Blue sheets and volunteers for notes and Jabber 5 Mins 2. WG status and I-Ds update 10 Mins ---------------------- - Raj announces public Home Agent Service Refer to slides for details of HA service. - Status of MIP6 WG - last meeting as MIP6 WG. - Status of MEXT (jari) - charter approved at IESG - remaining thing is to select chairs - Document status - RFCs published - draft-ietf-mip6-ikev2-ipsec (prop standard) - draft-ietf-mip6-privacy-ps (informational) - RFC ed queue - draft-ietf-mip6-dsmip-problem (informational) - IESG review - draft-ietf-mip6-bootstrapping-split (prop standard) - AD review - draft-ietf-mip6-cn-ipsec (experiremtal) - draft-ietf-mip6-bootstrapping-integrated-dhc (proposed standard) - waiting for draft-hiopt - new WG docs - haley-mip6-mh-signaling ( - completed last call - whyauthdataoption - aaa-ha-goals - hiopt - vsm - experimental-messages - ready for WGLC - rfc4285bis - hareliability - nemo-v4traversal - misc - draft-ietf-nip6-radius (waiting for AAA-goals ID compl=C8tion) * discussion - Vijay: aaa-ha-goals document is far from complete. Basic stuff is missing= . - Raj: this doc is expired. Please send comments to ml. 3. Mobile IPv6 bootstrapping in split scenario I-D: draft-ietf-mip6-bootstrapping-split-06 15 Mins Vijay Devarapalli ----------------------------------------- * presentation - changes since last version: - anycast-based HA assignment removed during security AD review because it may be applied elsewhere too (not only MIPv6) - use of PKI/certificates was underspecified - what to do if HA does not respond to IKE_SA_INIT was underspecified - format of MIP6_HOME_PREFIX attribute had mistakes - clarifications on home address authz * discussion - jari: no DISCUSSes anymore. Doc is ready to progress 4. DHCP Option for Home Information Discovery in MIPv6 I-D: draft-ietf-mip6-hiopt-05.txt 10 Mins Heejin Jang -------------------------------------- * presentation - changes since last version: - no HoA assignment support anymore - clarification of meaning of id-types - clarification of use of multiple HN identifier options - new fields in HN information option - deleted MN-NAI option in relay-forward msg * discussion - none 5. Binding Revocation for IPv6 Mobility I-D: draft-muhanna-mip6-binding-revocation-01.txt 15 min Ahmad Muhanna ------------------------------------- * presentation - motivation for binding revocation - binding revocation msg format - proposes to adopt as WG item and change charter * discussion - Greg: Why is this better than sending BA with lifetime 0? - Sri: you can't revoke all binding with single BA msg - Greg: don't see how this can be secure - Ahmad: in case of PMIP, there is no per-MN SA - Vijay: Why revoke a specific CoA in case of monami6 - Sri: just to revoke one particular flow - Raj: You said motivation is maintenance etc. Now you say its for monami6 to selective revoke flows. Those are other, more complicated scenarios=20 - Hesham: Not sure if this works, since MN can switch flow to other BIDs. So this flow is not stopped. To revoke all flows, you don'T need BID=20 - Kuntal: Example were it makes sense to revoke single binding is, e.g., in IMS scenarios - Hesham: Clarification: I think there are many ways to revoke particular flows. Don't think this should be done by MIP HA - Vijay: we just need simple revocation mechanism based on MN identifier or HoA. Not more (not revoke specific flows) - Raj: agree, that would be too complex - alex: supports use of binding refresh request - alex: another technical comment to be sent on the mailing list - alex: proposes another code, that tells HA to keep sessions up when MN wants that=20 - Raj: in such case MN should go find another HA - Kuntal: Important use cases are handover and clear-up of ressources on old gateway. Maintenance is rare use case - Ruji: We can treat every binding of multiple binding as single binding. Support revocation of one of multiple bindings of a MN - ?: thinks this draft is useful - TJ: this should be kept simple. - Greg: binding revocation must be sent by entity that MN has binding with - chairs: How many of WG think that we should do binding revocation - extension for MIP6? - yes: 8+ - no: 0 - chairs: - Let's have discussion on ml and then decide about adoption of draft as WG doc 6. Firewall Recommendations for MIPv6 I-D: draft-krishnan-mip6-firewall-01 15 min Suresh Krishnan -------------------------------------- * presentation: - different scenario: firewall protecting HA, MN, CN, respectively - recommends which kind of traffic should not be blocked by firewalls - Adopt as WG draft? * discussion - hesham: just to clarify, only some firewalls in enterprise networks block ipsec. Not in public networks - frank: your solution makes network less safe (let all IPsec traffic to HA through). =20 - Suresh: but this is the HA service, you have to let this traffic through - Alex: some operators don't want to allow RO due to security weaknessses - Suresh: that's why we separated rules for RO and for non-RO - chairs: status of design team? Are they finished? - suresh: there is some stuff more forward looking, e.g., - talking to firewall. This draft is the first/essential step - Jari: the future stuff sounds a bit dangerous. Why not rely on - access mechanisms? Why need something specific for MIP6. - suresh: Hannes wants to extend existing ipv6 protocol for mip6 - jari: this makes more sense - jari: so question is whether we do the BCP for the firewall rules here or leave it for MEXT? You can work on that under current charter=20 7. Mobile IPv6 Extension for Configuration Options I-D: draft-bharatia-mip6-gen-ext-01.txt 15 min Kuntal Chowdhury ------------------------------------- * presentation: - motivation: get configuration from home network - idea: MN includes option in MIP6 BU to request list of host config options. BA contains config info. Config information format is re-used from DHCP * discussion - Frank: Why use MN-HA interaction? BU is not very flexible. Why not use AAA? Tomorrow we have another service, then we again need to change specification. - Kuntal: if new service shall be discovered, then we just need to define another option code. AAA doesn't work, since MN does not talk to AAA server - Ruji: 1. on home link, this mechanism doesn't work. 2. in PMIP, better to decouple binding signaling and address assignment. You an use DHCP=20 - Greg: we have SLP, DHCP, MIH, Router discovery. So why do we need to another discovery protocol, which we have to secure etc. - Raj: we should discuss this on the ml - hesham: I agree with greg. Same discussion about that for mip4 some years ago and IESG was against. - Kuntal: this work is currently done in mip4 - kent: sees difference between mip4 and mip6 case, since we have a bootstrapping mechanism in mip6. Why not use it? - Kuntal: you could add AAA attributes + DHCP relay - Jari: we don't do anything here before we know what happens to the mip4 document=20 - Henrik: agree. we can't just assume that mip4 and mip6 case are the same. Why not just use DHCP on link? 8. IP Tunneling Optimization in a Mobile Environment I-D: draft-haddad-mip6-tunneling-optimization-01 10 min Wassim Haddad ------------------------------------ * presentation - motivation: reduce tunneling overhead - idea: removing inner tunnel header in MIP, PMIP,... - PAD translator, which is XOR of inner and outer header - PAD translator is updated by HA when receiving BU * discussion - chairs: There is an IPR disclosure on this draft - sri: is it compatible with existing header compression like rohc? - suresh: yes, can use Rohc on outer header - alex: it can work. Good to mention that it has IPR. rohc is much more powerful.=20 - suresh: rohc has different stands than this one - alex: this is no longer MIP6. So is this an alternative to MIPv6? - suresh: this could be done below MIPv6 - Hesham: this is fantastic. Good idea. And IPR is defensive, right - suresh: yes - greg: this is good. The killer application is maintaining 1500bytes MTU. You can't do that with rohc. But may not work immediately with all CN addresses=20 - Henrik: should define term BT. First though on Bittorrent, bluetooth ;) 9. Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions I-D: draft-qi-mip6-ikev2-interfacing-00.txt 5 Min Yang Peng --------------------------------- * presentation - provide interface between IKEv2 and MIP6 * discussion - chairs: this has to be discussed based on the MEXT charter 10. Next Steps Chairs 10 Mins ---------------------------- - upcoming WGLCs and submissions to IESG _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Aug 26 12:18:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPKon-0001gl-2i; Sun, 26 Aug 2007 12:18:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPKol-0001gZ-IK; Sun, 26 Aug 2007 12:18:27 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IPKok-0006DO-Gf; Sun, 26 Aug 2007 12:18:27 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2546d1b6ce; Mon, 27 Aug 2007 00:30:34 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jma146cd2f72; Thr, 23 Aug 2007 06:29:51 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Thr, 23 Aug 2007 06:29:51 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyTp-0000vn-Ru; Wed, 22 Aug 2007 18:15:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INyTf-0000oj-TW; Wed, 22 Aug 2007 18:15:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INyTf-0002yM-Du; Wed, 22 Aug 2007 18:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 07659175F7; Wed, 22 Aug 2007 22:15:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1INyTe-0007Q1-Fs; Wed, 22 Aug 2007 18:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 22 Aug 2007 18:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-whyauthdataoption-03.txt X-BeenThere: mip6@ietf.org Reply-To: internet-drafts@ietf.org List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Why Authentication Data suboption is needed for MIP6 Author(s) : B. Patil, G. Dommety Filename : draft-ietf-mip6-whyauthdataoption-03.txt Pages : 16 Date : 2007-8-22 Mobile IPv6 defines a set of messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec SA that is established between the MN and HA. The MIP6 working group has proposed a mechanism to secure the binding update and binding acknowledgement messages using an authentication option, similar to the authentication option in Mobile IPv4, carried within the messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain deployment environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-whyauthdataoption-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-whyauthdataoption-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-whyauthdataoption-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-22171921.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-whyauthdataoption-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-whyauthdataoption-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-22171921.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Sun Aug 26 15:22:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPNgQ-0003LC-Rh; Sun, 26 Aug 2007 15:22:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPNgP-0003KU-EE for mip6@ietf.org; Sun, 26 Aug 2007 15:22:01 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IPNgN-0001ui-RJ for mip6@ietf.org; Sun, 26 Aug 2007 15:22:01 -0400 Received: (qmail invoked by alias); 26 Aug 2007 19:21:58 -0000 Received: from p54987ADA.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.122.218] by mail.gmx.net (mp038) with SMTP; 26 Aug 2007 21:21:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+xsoBRLWGxwlrUXcAK0n2mVFuQ4AfssnFKhc6QIk WucAJzY43h+rAh Message-ID: <46D1D2D1.9060808@gmx.net> Date: Sun, 26 Aug 2007 21:21:53 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: mip6@ietf.org Subject: [Mip6] WGLC: Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, this message marks the issuance of a working group last call (WGLC) on DIME's Internet Draft entitled "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction" (draft-ietf-dime-mip6-integrated-05.txt). You may view this document at http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-05.txt Please post comments and questions to the DIME mailing list no later than 9 September 2007. Ciao Hannes & Dave _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 03:50:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPZMi-00080x-2M; Mon, 27 Aug 2007 03:50:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPZMg-0007zx-8q for mip6@ietf.org; Mon, 27 Aug 2007 03:50:26 -0400 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPZMe-00054E-BP for mip6@ietf.org; Mon, 27 Aug 2007 03:50:26 -0400 Received: from rodin.i2r.a-star.edu.sg (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 2460013B68E; Mon, 27 Aug 2007 15:49:43 +0800 (SGT) Received: from mailfe01.teak.local.net (unknown [192.122.134.9]) by rodin.i2r.a-star.edu.sg (Postfix) with ESMTP id 13F8613B68D; Mon, 27 Aug 2007 15:49:43 +0800 (SGT) Received: from DELL9150 ([192.168.137.186]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 15:49:23 +0800 Message-ID: <00b601c7e87e$f5a9fcb0$ba89a8c0@DELL9150> From: "QIU Ying" To: , "Basavaraj Patil" References: Subject: Re: [Mip6] IETF69: MIP6 WG meeting minutes -- Firewall Recommendations for MIPv6 Date: Mon, 27 Aug 2007 15:50:38 +0800 MIME-Version: 1.0 Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 27 Aug 2007 07:49:23.0576 (UTC) FILETIME=[C8CD2780:01C7E87E] Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.7 (++) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, Regarding the draft of "Firewall Recommendations for MIPv6", my 2 cents=20 below. > 6. Firewall Recommendations for MIPv6 > I-D: draft-krishnan-mip6-firewall-01 15 min > Suresh Krishnan > -------------------------------------- > * presentation: > - different scenario: firewall protecting HA, MN, CN, respectively > - recommends which kind of traffic should not be blocked by firewalls > - Adopt as WG draft? > > * discussion > - hesham: just to clarify, only some firewalls in enterprise networks > block ipsec. Not in public networks > - frank: your solution makes network less safe (let all IPsec traffic > to HA through). > - Suresh: but this is the HA service, you have to let this > traffic through Frankly, in practice realm, home agents are very special nodes: 1) only f= ew=20 nodes are charged as home agents within a networks. 2) Home agent is=20 normally functioned as a server or a stationary machine at least, so it i= s=20 strong enough to protect itself (e.g. Jari mentioned access mechanisms) a= nd=20 not have to rely on the protection of firewall. A firewall that opens few channels for some specified robust nodes do not= =20 means to weaken the strength of network security. But in order to prevent the flood attacks, the firewall can constrain the= =20 throughput of these channels. > - Alex: some operators don't want to allow RO due to security weaknesss= es > - Suresh: that's why we separated rules for RO and for non-RO No matter RO or non RO, the issue of IPsec packets through a firewall can= =20 not avoid due to home binding update. Regards Qiu Ying > Date: Fri, 24 Aug 2007 17:28:24 -0500 > From: Basavaraj Patil > Subject: [Mip6] IETF69: MIP6 WG meeting minutes > To: Mobile IPv6 Mailing List > Message-ID: > Content-Type: text/plain; charset=3D"ISO-8859-1" > > > Minutes of: > Mobility for IPv6 (mip6) WG > At: IETF69 (Chicago) > TUESDAY, July 24, 2007 from 1520-1720 > > Chairs: Basavaraj Patil > Gopal Dommety > > Credit for these minutes: > > 1. Kilian Weniger (Kilian.Weniger@eu.panasonic.com) > > 2. Jabber scribe: T.J Kniveton (tj@kniveton.com) > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > > 1. Agenda review, Blue sheets and volunteers for > notes and Jabber 5 Mins > > 2. WG status and I-Ds update 10 Mins > ---------------------- > - Raj announces public Home Agent Service > Refer to slides for details of HA service. > > - Status of MIP6 WG > - last meeting as MIP6 WG. > > - Status of MEXT (jari) > - charter approved at IESG > - remaining thing is to select chairs > > - Document status > - RFCs published > - draft-ietf-mip6-ikev2-ipsec (prop standard) > - draft-ietf-mip6-privacy-ps (informational) > - RFC ed queue > - draft-ietf-mip6-dsmip-problem (informational) > - IESG review > - draft-ietf-mip6-bootstrapping-split (prop standard) > - AD review > - draft-ietf-mip6-cn-ipsec (experiremtal) > - draft-ietf-mip6-bootstrapping-integrated-dhc (proposed standar= d) > - waiting for draft-hiopt > - new WG docs > - haley-mip6-mh-signaling ( > - completed last call > - whyauthdataoption > - aaa-ha-goals > - hiopt > - vsm > - experimental-messages > - ready for WGLC > - rfc4285bis > - hareliability > - nemo-v4traversal > - misc > - draft-ietf-nip6-radius (waiting for AAA-goals ID compl=C8tion) > > * discussion > - Vijay: aaa-ha-goals document is far from complete. Basic stuff is=20 > missing. > - Raj: this doc is expired. Please send comments to ml. > > 3. Mobile IPv6 bootstrapping in split scenario > I-D: draft-ietf-mip6-bootstrapping-split-06 15 Mins > Vijay Devarapalli > ----------------------------------------- > * presentation > - changes since last version: > - anycast-based HA assignment removed during security AD > review because it may be applied elsewhere too (not only MIPv6) > - use of PKI/certificates was underspecified > - what to do if HA does not respond to IKE_SA_INIT was underspecifie= d > - format of MIP6_HOME_PREFIX attribute had mistakes > - clarifications on home address authz > > * discussion > - jari: no DISCUSSes anymore. Doc is ready to progress > > > 4. DHCP Option for Home Information Discovery in MIPv6 > I-D: draft-ietf-mip6-hiopt-05.txt 10 Mins > Heejin Jang > -------------------------------------- > * presentation > - changes since last version: > - no HoA assignment support anymore > - clarification of meaning of id-types > - clarification of use of multiple HN identifier options > - new fields in HN information option > - deleted MN-NAI option in relay-forward msg > > * discussion > - none > > 5. Binding Revocation for IPv6 Mobility > I-D: draft-muhanna-mip6-binding-revocation-01.txt 15 min > Ahmad Muhanna > ------------------------------------- > * presentation > - motivation for binding revocation > - binding revocation msg format > - proposes to adopt as WG item and change charter > > * discussion > - Greg: Why is this better than sending BA with lifetime 0? > - Sri: you can't revoke all binding with single BA msg > - Greg: don't see how this can be secure > - Ahmad: in case of PMIP, there is no per-MN SA > - Vijay: Why revoke a specific CoA in case of monami6 > - Sri: just to revoke one particular flow > - Raj: You said motivation is maintenance etc. Now you say its for > monami6 to selective revoke flows. Those are other, more complicated > scenarios > - Hesham: Not sure if this works, since MN can switch flow to other > BIDs. So this flow is not stopped. To revoke all flows, you don'T need > BID > - Kuntal: Example were it makes sense to revoke single binding is, > e.g., in IMS scenarios > - Hesham: Clarification: I think there are many ways to revoke > particular flows. Don't think this should be done by MIP HA > - Vijay: we just need simple revocation mechanism based on MN > identifier or HoA. Not more (not revoke specific flows) > - Raj: agree, that would be too complex > - alex: supports use of binding refresh request > - alex: another technical comment to be sent on the mailing list > - alex: proposes another code, that tells HA to keep sessions up when > MN wants that > - Raj: in such case MN should go find another HA > - Kuntal: Important use cases are handover and clear-up of ressources > on old gateway. Maintenance is rare use case > - Ruji: We can treat every binding of multiple binding as single > binding. Support revocation of one of multiple bindings of a MN > - ?: thinks this draft is useful > - TJ: this should be kept simple. > > - Greg: binding revocation must be sent by entity that MN has binding w= ith > > - chairs: How many of WG think that we should do binding revocation > - extension for MIP6? > - yes: 8+ > - no: 0 > - chairs: > - Let's have discussion on ml and then decide about adoption > of draft as WG doc > > > > 6. Firewall Recommendations for MIPv6 > I-D: draft-krishnan-mip6-firewall-01 15 min > Suresh Krishnan > -------------------------------------- > * presentation: > - different scenario: firewall protecting HA, MN, CN, respectively > - recommends which kind of traffic should not be blocked by firewalls > - Adopt as WG draft? > > * discussion > - hesham: just to clarify, only some firewalls in enterprise networks > block ipsec. Not in public networks > - frank: your solution makes network less safe (let all IPsec traffic > to HA through). > - Suresh: but this is the HA service, you have to let this > traffic through > - Alex: some operators don't want to allow RO due to security weaknesss= es > - Suresh: that's why we separated rules for RO and for non-RO > > - chairs: status of design team? Are they finished? > - suresh: there is some stuff more forward looking, e.g., > - talking to firewall. This draft is the first/essential step > - Jari: the future stuff sounds a bit dangerous. Why not rely on > - access mechanisms? Why need something specific for MIP6. > - suresh: Hannes wants to extend existing ipv6 protocol for mip6 > - jari: this makes more sense > > - jari: so question is whether we do the BCP for the firewall rules > here or leave it for MEXT? You can work on that under current > charter > > > 7. Mobile IPv6 Extension for Configuration Options > I-D: draft-bharatia-mip6-gen-ext-01.txt 15 min > Kuntal Chowdhury > ------------------------------------- > * presentation: > - motivation: get configuration from home network > - idea: MN includes option in MIP6 BU to request list of host config > options. BA contains config info. Config information format is > re-used from DHCP > > * discussion > - Frank: Why use MN-HA interaction? BU is not very flexible. Why not > use AAA? Tomorrow we have another service, then we again need to > change specification. > - Kuntal: if new service shall be discovered, then we just > need to define another option code. AAA doesn't work, since MN > does not talk to AAA server > - Ruji: 1. on home link, this mechanism doesn't work. 2. in PMIP, > better to decouple binding signaling and address assignment. You an > use DHCP > - Greg: we have SLP, DHCP, MIH, Router discovery. So why do we need to > another discovery protocol, which we have to secure etc. > - Raj: we should discuss this on the ml > - hesham: I agree with greg. Same discussion about that for mip4 some > years ago and IESG was against. > - Kuntal: this work is currently done in mip4 > - kent: sees difference between mip4 and mip6 case, since we have a > bootstrapping mechanism in mip6. Why not use it? > - Kuntal: you could add AAA attributes + DHCP relay > - Jari: we don't do anything here before we know what happens to the > mip4 document > - Henrik: agree. we can't just assume that mip4 and mip6 case > are the same. Why not just use DHCP on link? > > 8. IP Tunneling Optimization in a Mobile Environment > I-D: draft-haddad-mip6-tunneling-optimization-01 10 min > Wassim Haddad > ------------------------------------ > * presentation > - motivation: reduce tunneling overhead > - idea: removing inner tunnel header in MIP, PMIP,... > - PAD translator, which is XOR of inner and outer header > - PAD translator is updated by HA when receiving BU > > * discussion > - chairs: There is an IPR disclosure on this draft > - sri: is it compatible with existing header compression like rohc? > - suresh: yes, can use Rohc on outer header > - alex: it can work. Good to mention that it has IPR. rohc is much > more powerful. > - suresh: rohc has different stands than this one > - alex: this is no longer MIP6. So is this an alternative to MIPv6? > - suresh: this could be done below MIPv6 > - Hesham: this is fantastic. Good idea. And IPR is defensive, right > - suresh: yes > - greg: this is good. The killer application is maintaining 1500bytes > MTU. You can't do that with rohc. But may not work immediately with > all CN addresses > - Henrik: should define term BT. First though on Bittorrent, bluetooth = ;) > > 9. Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions > I-D: draft-qi-mip6-ikev2-interfacing-00.txt 5 Min > Yang Peng > --------------------------------- > * presentation > - provide interface between IKEv2 and MIP6 > > * discussion > - chairs: this has to be discussed based on the MEXT charter > > > 10. Next Steps Chairs 10 Mins > ---------------------------- > - upcoming WGLCs and submissions to IESG > > > > > > ------------------------------ > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > > End of Mip6 Digest, Vol 40, Issue 15 > ************************************=20 ------------ Institute For Infocomm Research - Disclaimer -------------Th= is email is confidential and may be privileged. If you are not the inten= ded recipient, please delete it and notify us immediately. Please do not = copy or use it for any purpose, or disclose its contents to any other per= son. Thank you.-------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 07:30:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPcng-0007HC-QS; Mon, 27 Aug 2007 07:30:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPcnf-0007H4-1o; Mon, 27 Aug 2007 07:30:31 -0400 Received: from otm-mgo00.iij.ad.jp ([210.138.20.174]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPcnd-0001Fy-PB; Mon, 27 Aug 2007 07:30:30 -0400 Received: OTM-MO(otm-mgo00) id l7RBULqJ011395; Mon, 27 Aug 2007 20:30:21 +0900 (JST) Received: OTM-MIX(otm-mix01) id l7RBULWf011505; Mon, 27 Aug 2007 20:30:21 +0900 (JST) Received: from [127.0.0.1] (jc-ssh00.iij.ad.jp [192.168.174.22]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp01) id l7RBUJKK078022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Aug 2007 20:30:20 +0900 (JST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Keiichi SHIMA Subject: Re: [Mip6] WG LC: draft-ietf-mip6-nemo-v4traversal-05.txt Date: Mon, 27 Aug 2007 20:30:14 +0900 To: Basavaraj Patil X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: nemo@ietf.org, Gopal Dommety , "KNIVETON T.J." , Basavaraj Patil , Mobile IPv6 Mailing List , ERNST Thierry X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, I've read draft-ietf-mip6-nemo-v4traversal-05. The draft seems good to me basically. Here are some (maybe minor) comments for the draft. Since many other people have already reviewed the draft, some comments are duplicated or have already been pointed out previously. Because it is difficult to check which comments are duplicated, I just send all my comments here. ---- page 3, 2nd paragraph: "Using this specification, mobile nodes would only need Mobile IPv6 and [NEMO] to manage mobility" => "Using this specification, mobile nodes would only need [MIPv6] and [NEMO] to manage mobility" ---- page 6, 3rd paragraph: "In case the home agents are behind a NAT box, there are two options, 1)configure a public IPv4 address for each home agent on the NAT box, 2) configure one public address and make the home agents share the public address." => I don't understand the case 2). Why can we share one public IP address between multiple HAs behind a NAT box? Maybe some more description is needed? ---- page 7, Section 2.3.1, first paragraph: "Effectively, the mobile node establishes two different tunnels, one for its IPv4 traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) with a single binding update." => I'm not sure the wording 'the mobile node establishes two different tunnels' is good, although I understand what the author wants to say. In my sense, the tunnel is only one (the IPvX in IPv6 tunnel when in the IPv6 Internet, or the IPvX in IPv4 tunnel when in the IPv4 Internet). ---- page 8, Section 2.3.2: "A mobile node SHOULD NOT assume that its IPv4 address is globally unique if a NAT device was not detected." => Do we need to mention this in this draft? It seems to me that the above fact doesn't have anything to do with the DSMIPv6 draft. ---- page 8, Section 2.3.2.1, 1st paragraph: "The binding update will contain the mobile node's IPv6 home address." => "The binding update will contain the mobile node's IPv6 home address in the source address field of the inner header." ---- page 9, 1st paragraph: "The binding update is encapsulated to the IPv4 care-of address" => "The binding acknowledgment is encapsulated to the IPv4 care-of address" ---- page 9, 1st paragraph: "(represented as an IPv4-mapped IPv6 address in the binding update)" => "(represented as an IPv4 source address encapsulating the binding update)" ---- page 9, Section 2.3.2.2, 3rd paragraph: "All entries MUST point to the mobile node's IPv4 care-of address included in the source address of the IPv6 packet and represented as an IPv4-mapped IPv6 address." => "All entries MUST point to the mobile node's IPv4 care-of address included in the IPv4 Care-of Address option in the binding update." ---- page 9, Section 2.3.2.2, 3rd paragraph: "that includes the home agent's IPv4 address in the source address field and the mobile node's IPv4 careof address in the destination address field." => "that includes the home agent's IPv4 address in the source address field and the global address of the NAT box to which the mobile node is attached." ---- page 10, Section 2.3, 2nd paragraph: "That is, traffic addressed to the mobile node's IPv4 home address." => incomplete sentence? ---- page 14, in the description of the 'Refresh time': "If set to zero, it is ignored." => What does this mean? Does it mean a mobile node has to decide the refresh time based on its local policy? If so, it would be better to explicitly mention so. ---- page 16, about the TVL type field: => What is the type 3 (IPsec)? I don't understand what it is for. (UDP-ESP tunnel?) ---- page 16, last paragraph: "it compares the IPv4 address of the source address field in the IPv4 header with the IPv4 address in the source address of the IPv6 header." => "it compares the IPv4 address of the source address field in the IPv4 header with the IPv4 address in the IPv4 Care-of Address option." ---- page 17, in the figure of the BU message format: "BU [IPv4 HAO] IPv4 CoA option" => Shouldn't it be written as "BU [IPv4 HAO, IPv4 CoA]"? to be consistent with the figure B. ---- page 18, in the figure of the BA message format: => The ESP header is missing between 'Route HDR' and 'Mobility header'. ---- page 20, 2nd paragraph: "- If no IPv4 address acknowledgement option were present, and an IPv4 home address option was present in the binding update, the mobile node MUST only create one binding update list entry for its IPv6 home address. The mobile node MAY include the IPv4 home address option in future binding updates." => This text is conflicting with the text in page 7 (see below). "If this option is not included in the binding acknowledgement and the IPv4 home address option was included in the binding update, the mobile node MUST assume that the home agent does not support the IPv4 home address option and therefore SHOULD NOT include the option in future binding updates to that home agent address." ---- page 21, Section 4.5, 3rd paragraph: "In order to comply with this specification, the home agent MUST be able to find the IPv4 home address of a mobile node when given the IPv6 home address. That is, given an IPv6 home address, the home agent MUST store the corresponding IPv4 home address if a static one is present. If a dynamic address were requested by the mobile node, the home agent MUST store that address (associated with the IPv6 home address) after it's allocated to the mobile node." => When I first read this paragraph, I could not understand what it meant. Once I completed reading the Security Consideration section, I finally understood that the paragraph was talking about security binding between the IPv6 HoA and IPv4 HoA. If the draft has some more text in this paragraph, it would be better. ---- page 22, last paragraph: "When sending IPv4 packets to When mobile nodes in an IPv6 network, the home agent must encapsulate the IPv4 packets in IPv6." => broken sentence? --- Keiichi SHIMA IIJ Research Laboratory WIDE Project _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 07:52:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPd8m-0006nx-Ft; Mon, 27 Aug 2007 07:52:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPd8l-0006nr-TP for mip6@ietf.org; Mon, 27 Aug 2007 07:52:19 -0400 Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPd8l-0001gq-FX for mip6@ietf.org; Mon, 27 Aug 2007 07:52:19 -0400 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly43d.srv.mailcontrol.com (MailControl) with SMTP id l7RBqFOk023041 for ; Mon, 27 Aug 2007 12:52:15 +0100 Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 2cfa_fac4ec52_5492_11dc_8a1d_0030482aac25; Mon, 27 Aug 2007 13:45:15 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007082713521392-536713 ; Mon, 27 Aug 2007 13:52:13 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.113,BAYES_00: -1.665,TOTAL_SCORE: -1.552 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de for mip6@ietf.org; Mon, 27 Aug 2007 13:52:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Subject: RE: [Mip6] Consensus call: Adopting I-D In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Consensus call: Adopting I-D Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiAC6NuKA References: To: "Mobile IPv6 Mailing List" Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB48A0CF@lan-ex-02.panasonic.de> Date: Mon, 27 Aug 2007 13:50:31 +0200 From: "Kilian Weniger" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-07-08-00 (www.mailcontrol.com) on 10.68.0.153 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > The binding revocation feature specified in I-D > draft-muhanna-mip6-binding-revocation-01.txt is essential for MIP6 > deployments and hence should be made a MIP6 WG document and=20 > progressed as a > standards track doc. >=20 > Yes [x ] > No [ ] >=20 BR, Kilian Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 08:36:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPdpp-0005R1-Eu; Mon, 27 Aug 2007 08:36:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPdpn-0005Ql-C8 for mip6@ietf.org; Mon, 27 Aug 2007 08:36:47 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IPdpl-0002aW-I1 for mip6@ietf.org; Mon, 27 Aug 2007 08:36:47 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1188218203!3935647!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 23802 invoked from network); 27 Aug 2007 12:36:44 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-12.tower-153.messagelabs.com with SMTP; 27 Aug 2007 12:36:44 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l7RCahno024553; Mon, 27 Aug 2007 05:36:43 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l7RCagEV026769; Mon, 27 Aug 2007 07:36:43 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l7RCad8h026720; Mon, 27 Aug 2007 07:36:40 -0500 (CDT) Message-ID: <46D2C554.7090403@gmail.com> Date: Mon, 27 Aug 2007 14:36:36 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] Request to progress MIP6 WG I-D: draft-ietf-mip6-whyauthdataoption-03.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000768-4, 26/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.3 (/) X-Scan-Signature: f4e722e9456ead69ba4cdd21dd3d3600 Cc: Gopal Dommety , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Basavaraj Patil wrote: > Hello Jari, > > The WG I-D: Why Authentication Data suboption is needed for MIP6 < > draft-ietf-mip6-whyauthdataoption-03.txt> has completed WG last call > and is ready to be progressed. > > Intended status for publication: Informational > > Below is the IESG writeup for progressing this I-D. Some comments on the draft... > The authentication option specified in the Authentication Protocol > for MIP6 [RFC4285] is applicable in certain types of networks that > have the following characteristics: [...] > 3. Networks in which the home agent and home address needs to be > assigned on a dynamic basis. Not sure how authopt is better than IPsec concerning the dynamic assignment of HA address and/or home address? Any authentication mechanism has tough issues when the endpoints are to be discovered. > 4. Networks which are bandwidth constrained (such as cellular > wireless networks) and there exists a need to minimize the number of > signaling messages sent over such interfaces. I think there may be some confusion here? Authenticating messages with AH vs authopt is not very different in terms of bandwidth consumption. Both include additional authentication data to each MIP6 signalling message (BU/BAck, BRR, BErretc.) IKE may take longer than not using IKE, but MIP6 can work without IKE and with pre-established SAs. > cdma2000 networks deployed and operational today use Mobile IPv4 for > IP mobility. Operators have gained a significant amount of > operational experience in the process of deploying and operating > these networks. 3GPP2 is now in the process of specifying Mobile IPv6 > in Revision D of the 3GPP2 X.S0011-D [3GPP2 X.S0011-D] specification > (which specifies the packet data architecture). The following are > the deployment constraints that existing CDMA networks have to deal > with when deploying Mobility service based on IPv6: > > o Operators intend to leverage the Mobile IPv4 deployment and > operational experience by ensuring that Mobile IPv6 has a similar > deployment and operating model. I agree, yes, fully. > o Operators will have two parallel networks, one that offers IPv4 > mobility with MIP4 and another providing IPv6 mobility using MIP6. I think however it is nonsense to say that an operator has two parallel networks whenever a new technology comes up. Usually they keep the modifications very much localized in order to _not_ having to maintain several parallel networks. Imagine an operator will have to deploy a third and fourth such network in parallel for PMIPv6 and PMIPv4? > o The same backend subscriber profile database, security keys etc. > are intended to be used for both Mobile IPv4 and, Mobile IPv6 > service. I agree, mostly. > o The same user configuration information, i.e the identity and keys > associated with a user will be used for IP mobility service in IPv4 > and/or IPv6 networks. The only security association that is > preconfigured is a shared secret between the mobile node and the > home-AAA server. I don't agree. An operator can't share the same key with all his/her customers. Besides, you use the term "security association"??? If there's a preconfigured SA between MN and HAAA then BU/BAck can be authenticated with AH and that key; simply the operator has to copy that same key on the HA from HAAA. > o The current Mobile IPv6 specification does not support the dynamic > assignment of home agent and home address. PReviously you said it does for HA (not HoA) and indeed it does: DHAAD. > The mechanism defined in Authentication protocol for Mobile IPv6 > [RFC4285] is capable of handling authentication even in the case of > dynamic assignments (and is similar to what is used in current MIPv4 > deployments). This is very much speculation. Authopt is and can not be any more stronger than IKE/IPsec with respect to discovery mechanisms. The first degree of this speculation is that it previously says that discovery mechanisms are under development, so we don't know yet what they are. The second degree of the speculation is that it assumes they can be easier secured with authopt than IPsec/IKE. _If_ the HA discovery mechanism relies on DNS discovery then we need a secure DNS discovery mechanism, and that is based on IPsec not authopt. Similar for DHCP. > o The identity of a user in MIP4-based cdma2000 networks is an MN > Identifier Option for MIP6 [RFC4283]. I agree, but the "for MIP6" text seems redundant; but I get the sense. > The use of IPsec for performing Registration with a home agent is not > always an optimal solution. While it is true that IPsec is an > integral part of the IPv6 stack, it is still a considerable overhead > from a deployment perspective of using IPsec as the security > mechanism for the signaling messages between the MN and HA. I'm not sure what you mean here. Authenticating a message exchange with AH vs with authopt is about the same size. Or do you mean _IKE_ may take too many messages? In this way, do you actually compare IKE vs some other unknown key distribution system? and not authopt vs IPsec? > Deployment of Mobile IPv6 on a large scale is possible only when the > protocol is flexible for being adapted to various scenarios. Do you call cdma2000 "Large Scale"?... sorry I couldn't abstain. I consider "Large Scale" more like Internet scale where different operators talk to each other, open systems, IPv6 address to a grain, etc. > Typically, the Mobile Node shares a security association with the > AAA-Home entity. This is great. > This is the preferred mode of operation over having a shared secret > between the MN and HA because the AAA-Home entity provides a central > location for provisioning and administering the shared secrets for a > large number of mobiles (millions). I think IKE can do more than just millions of mobiles. > This mode of operation also makes dynamic home address and dynamic > home agent assignment easier. Provided that it all happens in a closed system, not across Internet. It won't scale for Internet. > cdma2000 network operators are extremely conscious in terms of the > number of messages sent and received over the air-interface for > signaling. This is good, but authopt doesn't exchange less messages than IPsec HA, it's the same actually. > Another downside of IKE for setting up the IPsec SA between the MN > and HA is that IKE does not integrate very well with the Radius based > AAA back-end. Since operators rely on the AAA infrastrucure to > provision subscribers as well as define profiles, keys etc. in the > AAA-Home, there is no getting away from the use of AAA in cdma2000 > networks. IKEv2 does address this problem. However from a timeline > perspective the availability of IKEv2 specifications for Mobile IPv6 > Operation with IKEv2 and the revised IPsec Architecture [RFC4877] and > implementations did not meet the need of operators that are currently > relying on 3GPP2 specifications. I really am not sure that 3GPP2 timelines should prevail. There are other timelines as well. Overall, I do agree with many of the points in this draft, and with the deployment necessity aspects. But I don't see it as a standards track alternative to IPsec for MIPv6. Just imagine the confusion this may bring to implementations. Nits: > It should be noted that some of the challenges of deploying MIP6 in > certain types of networks arise from the dependence on IKE which does > not integrate will with a AAA backend infrastructure. well Alex > > -Raj > > ========================== > > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the document > and, in particular, does he or she believe this version is ready for > forwarding to the IESG for publication? > > Document shepherd: Basavaraj Patil I am also the author of this > document and hence the question of review does not arise. However it > has been reviewed by other WG members. The I-D is ready for for > forwarding to the IESG and publication. > > > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have any > concerns about the depth or breadth of the reviews that have been > performed? > > Adequate review has been done by WG members and non-WG members. No > concerns about the depth or breadth of reviews exist. > > > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, e.g., > security, operational complexity, someone familiar with AAA, > internationalization, or XML? > > No. > > > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director and/or > the IESG should be aware of? For example, perhaps he or she is > uncomfortable with certain parts of the document, or has concerns > whether there really is a need for it. In any event, if the WG has > discussed those issues and has indicated that it still wishes to > advance the document, detail those concerns here. Has an IPR > disclosure related to this document been filed? If so, please > include a reference to the disclosure and summarize the WG discussion > and conclusion on this issue. > > This I-D was basically written as a means to justify the need for an > alternative mechanism for securing the MIP6 signaling. It is > necessary to publish this I-D for historical reasons and to ensure > there is a document explaining the arguments made for the > authentication protocol which has been published as an Informational > RFC (RFC 4285). > > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with it? > > > > > > > > > There is WG consensus. This I-D has been discussed in the WG a couple > of years ago. The justification for the authentication protocol > subsequently passed and RFC4285 has been published. This I-D is > required as a means to capture the intent. > > > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarize the areas of conflict in > separate email messages to the Responsible Area Director. (It should > be in a separate email because this questionnaire is entered into > the ID Tracker.) > > No. > > > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not > enough; this check needs to be thorough. Has the document met all > formal review criteria it needs to, such as the MIB Doctor, media > type, and URI type reviews? If the document does not already > indicate its intended status at the top of the first page, please > indicate the intended status here. > > The I-D has been run through the nits checker and all issues > corrected. > > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that are > not ready for advancement or are otherwise in an unclear state? If > such normative references exist, what is the strategy for their > completion? Are there normative references that are downward > references, as described in [RFC3967]? If so, list these downward > references to support the Area Director in the Last Call procedure > for them [RFC3967]. > > Yes. The references are split into normative and informative > sections. > > > (1.i) Has the Document Shepherd verified that the document's IANA > Considerations section exists and is consistent with the body of the > document? If the document specifies protocol extensions, are > reservations requested in appropriate IANA registries? Are the IANA > registries clearly identified? If the document creates a new > registry, does it define the proposed initial contents of the > registry and an allocation procedure for future registrations? Does > it suggest a reasonable name for the new registry? See [RFC2434]. > If the document describes an Expert Review process, has the Document > Shepherd conferred with the Responsible Area Director so that the > IESG can appoint the needed Expert during IESG Evaluation? > > IANA considerations section exists. However this document does not > need any IANA action. > > > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML code, BNF > rules, MIB definitions, etc., validate correctly in an automated > checker? > > Not applicable to this I-D. > > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document Announcement > Write-Up. Recent examples can be found in the "Action" announcements > for approved documents. The approval announcement contains the > following sections: > > Technical Summary > > Mobile IPv6 defines a set of messages that enable the mobile node > (MN) to authenticate and perform registration with its home agent > (HA). These authentication signaling messages between the mobile > node and home agent are secured by an IPsec SA that is established > between the MN and HA. The MIP6 working group has proposed a > mechanism to secure the binding update and binding acknowledgement > messages using an authentication option, similar to the > authentication option in Mobile IPv4, carried within the messages > that are exchanged between the MN and HA to establish a binding. This > document provides the justifications as to why the authentication > option mechanism is needed for Mobile IPv6 deployment in certain > deployment environments. > > Working Group Summary > > This document was written to consolidate the arguments and > justifications for an alternative to the IPsec based default > mechanism specified for MIP6 signaling security. RFC4285 has been > subsequently published which specifies the authentication protocol. > The intent is to capture for historical purposes the reasoning behind > the publication of the authentication protocol. > > Document Quality Are there existing implementations of the protocol? > Have a significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that merit > special mention as having done a thorough review, e.g., one that > resulted in important changes or a conclusion that the document had > no substantive issues? If there was a MIB Doctor, Media Type, or > other Expert Review, what was its course (briefly)? In the case of a > Media Type Review, on what date was the request posted? > > This I-D is Informational and hence the question about > implementations is N/A. Reviewers have been acked. The document does > not specify any MIB or media types. > > > Personnel Who is the Document Shepherd for this document? Who is the > Responsible Area Director? If the document requires IANA > experts(s), insert 'The IANA Expert(s) for the registries in this > document are .' > > Document shepherd: Basavaraj Patil Responsible AD: Jari Arkko > > > _______________________________________________ Mip6 mailing list > Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 09:01:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPeDl-000878-Ky; Mon, 27 Aug 2007 09:01:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPeDj-000873-Ms for mip6@ietf.org; Mon, 27 Aug 2007 09:01:31 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IPeDi-00081z-95 for mip6@ietf.org; Mon, 27 Aug 2007 09:01:31 -0400 Received: (qmail invoked by alias); 27 Aug 2007 13:01:28 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp039) with SMTP; 27 Aug 2007 15:01:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/HXWcpJyvHuTK9RI5af3e0iBDX9cfS+BBAcG3gzr xBdpcZte313WG9 Message-ID: <46D2CB26.6000108@gmx.net> Date: Mon, 27 Aug 2007 15:01:26 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] Request to progress MIP6 WG I-D: draft-ietf-mip6-whyauthdataoption-03.txt References: <46D2C554.7090403@gmail.com> In-Reply-To: <46D2C554.7090403@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Gopal Dommety , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I have to pick on a few selected items: >> 4. Networks which are bandwidth constrained (such as cellular >> wireless networks) and there exists a need to minimize the number of >> signaling messages sent over such interfaces. > > I think there may be some confusion here? > > Authenticating messages with AH vs authopt is not very different in > terms of bandwidth consumption. Both include additional > authentication data to each MIP6 signalling message (BU/BAck, BRR, > BErretc.) > > IKE may take longer than not using IKE, but MIP6 can work without IKE > and with pre-established SAs. > The actual protection of the signaling traffic does not differ too much from a bandwidth point of view. However, if you compare the number of messages that are exchanged for IKEv2 and for the Auth Protocol then there is obviously a big difference. > > >> o The same user configuration information, i.e the identity and keys >> associated with a user will be used for IP mobility service in IPv4 >> and/or IPv6 networks. The only security association that is >> preconfigured is a shared secret between the mobile node and the >> home-AAA server. > > I don't agree. An operator can't share the same key with all his/her > customers. > > Besides, you use the term "security association"??? If there's a > preconfigured SA between MN and HAAA then BU/BAck can be authenticated > with AH and that key; simply the operator has to copy that same key on > the HA from HAAA. The text does not say that the operator shares the same key with all its customers. Instead, it says that the keys are established between the MN and the home AAA server. > > >> The use of IPsec for performing Registration with a home agent is not >> always an optimal solution. While it is true that IPsec is an >> integral part of the IPv6 stack, it is still a considerable overhead >> from a deployment perspective of using IPsec as the security >> mechanism for the signaling messages between the MN and HA. > > I'm not sure what you mean here. Authenticating a message exchange with > AH vs with authopt is about the same size. Or do you mean _IKE_ may > take too many messages? > > In this way, do you actually compare IKE vs some other unknown key > distribution system? and not authopt vs IPsec? > You need to compare the complete system, which is IPsec + IKEv2 + AAA interaction vs. Auth Protocol + AAA interaction. From a performance point of view the latter is much better. Ciao Hannes _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 09:18:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPeUI-0006Cp-NJ; Mon, 27 Aug 2007 09:18:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPeUH-0006Ck-CE for mip6@ietf.org; Mon, 27 Aug 2007 09:18:37 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IPeUG-0003Qo-EG for mip6@ietf.org; Mon, 27 Aug 2007 09:18:37 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1188220715!15080390!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 15410 invoked from network); 27 Aug 2007 13:18:35 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-14.tower-128.messagelabs.com with SMTP; 27 Aug 2007 13:18:35 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l7RDIY0b019841; Mon, 27 Aug 2007 06:18:35 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l7RDIXDQ026945; Mon, 27 Aug 2007 08:18:34 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l7RDISYk026858; Mon, 27 Aug 2007 08:18:29 -0500 (CDT) Message-ID: <46D2CF20.4040004@gmail.com> Date: Mon, 27 Aug 2007 15:18:24 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] WG LC: I-D draft-ietf-mip6-rfc4285bis-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000768-4, 26/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: Mobile IPv6 Mailing List , "Kent Leung \(kleung\)" , haseebak@nortel.com, alpesh@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Basavaraj Patil wrote: > Hello, > > This is a WG last call for the I-D: Authentication Protocol for > Mobile IPv6 > > This I-D revises RFC4285 and corrects the key-length issue which has > been discussed in the past. > > Please send your comments by Sept 5th, 07 to the mailing list or the > authors. Hi Raj, here are some comments on this draft. Overall, I support it and its advancement (I have some comments for improvement), but I don't believe it on the Standards Track; mainly because it has an established alternative and widely deployed which scales. > The authentication option specified in Section 5 is applicable in > certain types of networks that have the following characteristics: > > - Networks in which the authentication of the MN for network access > is done by an authentication server in the home network via the home > agent. The security association is established by the network > operator (provisioning methods) I wouldn't use the term "security association" because that's IPsec. > The security association is created via an out-of-band mechanism or > by non Mobile IPv6 signaling. Mobile IPv6 signalling doesn't establish SAs anyways. If the SA is established somehow then it's sufficient to use AH (of IPsec) protection, no need of authopt Mobility Message Authentication Data. It doesn't gain anything at all, and IPsec AH code is already there everywhere. > IKEv2 as a technology has yet to reach maturity status and widespread > implementations needed for commercial deployments on a large scale. > At the time of this writing [IKEv2-REF] is yet to be published as an > RFC. Just FYI, IKEv2 is RFC4306 since December 2005, references will have to be updated. > MIP6 signaling which relies on IKE as the primary means for setting > up an SA between the MN and HA requires more signaling messages > compared with the use of an authentication option carried in the > BU/BAck messages. I'm not sure I understand this. IKE establishes keys. Authopt by this draft doesn't. If keys are pre-established (either pre-shared, or via out of band means, or via 'provisioning') then authopt authentication takes precisely same number of message-on-wire as IPsec AH - it's the BU/BAck. I think you're in one sense comparing IKEv2 vs the 'provisioning' mechanism while at the same time comparing authopt authentication vs AH authentication, drawing false conclusions. > The authentication option described in Section 5 may be used by the > mobile node to transfer authentication data when the mobile node and > the home agent are utilizing a mobility SPI (a number in the range > [0-4294967296] used to index into the shared-key based mobility > security associations). to index between multiple mobility security > associations. I think this paragraph is difficult to understand, the dot before 'to' seems redundant. But I agree with the intent and it describes the needed behaviour. > This section defines a message authentication mobility option that > may be used to secure Binding Update and Binding Acknowledgement > messages. From an implementation perspective, the authopt could be used for MPD, for BErr and for BReq as well, I think it should. Otherwise IPsec AH is needed for these messages. One wouldn't want BU/BAck auth'ed with authopt and BErr/BReq/MPD auth'ed with IPsec AH, right? > Option Length: > > > > 8-bit unsigned integer, representing the length in octets of the > Sub-type, mobility Security Parameter Index (SPI) and Authentication > Data fields. [...] > Alignment requirements : > > > > The alignment requirement for this option is 4n + 1. (1) Where and when to pad in order to reach this alignment? (2) Shouldn't the option length be expressed in 4n octets instead of simply octets? That's what many other IPv6 users do. (3) _if_ precisely 96bits of message digest are used then the length is constand and no need of alignment requirements specification, or ellipsis in message descriptio - just fill constants in. Right? > The authentication algorithm is HMAC_SHA1. I think it should be at least SHA2 or SHA256 because of known weaknesses. I think choice should be offered to operators so they can choose which algo to use depending on various factors such as security strength needed, local legislation, existing implementation, and so on. Do you know that SHA1 has security issues? > If the Timestamp option is used for replay protection as defined in > Section 6, the mobility security association includes a "close > enough" field to account for clock drift. I wouldn't recommend to anyone caring about security to use timestamps for replay protection. The other alternative is better (seq numbers). > The Mobile Node or Home Agent receiving this option MUST verify the > authentication data in the option. How and what to verify? This should be specified. Namely the HA receiving a BU should hash the received packet and compare the 96bits with the ones in the recv'd auth header. Also what happens if the HA doesn't support the type of the authentication required in the packet? (eg only supports MN-HA option, not MN-AAA option). Should it discard? Send BErr? > If authentication fails, the Home Agent MUST send BA with Status Code > MIPV6-AUTH-FAIL. Authenticated BAck or non-authenticated? > If the Home Agent does not have shared-key based mobility SA, Home > Agent MUST discard the BU. The Home Agent MAY log such events. I agree. > If mobility SPI has the well-known value HMAC_SHA1_SPI, then > hash_fn() is HMAC_SHA1. What other than the (weak) SHA1 can the SPI contain? Is there another digest algorithm? > In case of authentication failure, the Home Agent MUST send a Binding > Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node, > if a shared-key based mobility security association to be used > between Mobile Node and Home Agent for authentication exists. If > there is no shared-key based mobility security association, HA drops > the Binding Update. HA may log the message for administrative > action. > > Upon receiving a Binding Acknowledgement with status code MIPV6-AUTH- > FAIL, the Mobile Node SHOULD stop sending new Binding Updates to the > Home Agent. If the BAck is not protected itself with a authopt then isn't there a strong risk of DoS attack on MN? Attacker sends BAck MIPv6-AUTH-FAIL to all MNs, they don't authenticate it, and thus they stop sending BUs to their HAs. Thanks, Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mext-bounces@ietf.org Mon Aug 27 09:22:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPeWF-00073i-MF; Mon, 27 Aug 2007 09:20:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPeWE-00073Z-RY; Mon, 27 Aug 2007 09:20:38 -0400 Received: from ndjsbar01.ndc.nasa.gov ([198.120.25.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPeWD-0003U9-0W; Mon, 27 Aug 2007 09:20:37 -0400 Received: from ndjsxgw03.ndc.nasa.gov (ndjsxgw03.ndc.nasa.gov [129.166.32.111]) by ndjsbar01.ndc.nasa.gov (Spam Firewall) with ESMTP id 7F5394170F0; Mon, 27 Aug 2007 08:20:35 -0500 (CDT) Received: from NDJSEVS23A.ndc.nasa.gov ([129.166.32.223]) by ndjsxgw03.ndc.nasa.gov with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 08:20:35 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Aug 2007 08:20:26 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RO requirements for aerospace Thread-Index: AcforQgl0zcXVAMaRFucWKeOhCsozg== From: "Ivancic, William D. (GRC-RCN0)" To: "IETF NEMO WG" , X-OriginalArrivalTime: 27 Aug 2007 13:20:35.0662 (UTC) FILETIME=[0D7CD6E0:01C7E8AD] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Subject: [MEXT] RO requirements for aerospace X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mext-bounces@ietf.org We have updated the draft-eddy-nemo-aero-reqs-01 document," Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks," per feedback from the IETF69 meeting. Changes from draft-eddy-nemo-aero-reqs-01 A diff file is available at the following URL: http://roland.grc.nasa.gov/~ivancic/shared/ietf/draft-eddy-nemo-aero-req -01-to-02.htm At the IETF69 nemo meeting, consensus was reached to have the aeronautics, car-to-car, electronics devices, and any other groups develop individual requirements documents. At a later date, these individual requirements documents are likely to be combined into one document. Thus, the draft-eddy-nemo-aero-req-01 document has been revised as follows: The document has been renamed as draft-eddy-nemo-aero-reqs-02. Once MEXT gets organized, this document will become an ietf-mext working document per IETF69 consensus. However, in order to get this document out for comment during the transition period, it has been release at this time as an individual submission. In Req1 - Separability the wording has been changed such that selection is base on traffic types rather than applications. It was noted during the IETF69 NEMO meeting that requiring a RO to determine separability by application is not practical but use of techniques such as traffic classification may be. Req5 - Integrity has been changed to Req5 - Packet Loss. Within the IETF integrity has a different meaning than packet loss. Within the aviation community, integrity, as used here, refers to path integrity or data flow integrity. Within the IETF, integrity implies good data rather than good path. Thus, in order to improve clarity within the IETF, the wording has been changed. Req7 - Throughput has been changed to Req7 - Efficient Signaling. Overall throughput is relative to the bandwidth of the available links and is relatively independent of the RO implementation. Rather, the real requirement is for RO to be deployable over low bandwidth systems (e.g. VHDL links of 8 kbps for today's aeronautical communication links). Thus, the wording has been change to reflect the actual requirement. Acronyms have been defined the first time they are used. The requirements section has been re-written to read more like a contract. Thus, we have requirements and rationale with the rationale being numbered paragraphs. The idea is that, if so desired at a later date, this should enable combining of the various requirement documents into a single requirements document. In addition, we hope that the changes will make this document easier for an implementer to utilize. =20 ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Lab 216-433-2620 Mobile 440-503-4892 http://roland.grc.nasa.gov/~ivancic=20 _______________________________________________ MEXT mailing list MEXT@ietf.org https://www1.ietf.org/mailman/listinfo/mext From mip6-bounces@ietf.org Mon Aug 27 09:24:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPeZY-0008BA-Po; Mon, 27 Aug 2007 09:24:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPeZX-0008B5-My for mip6@ietf.org; Mon, 27 Aug 2007 09:24:03 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IPeZW-0008Uz-9t for mip6@ietf.org; Mon, 27 Aug 2007 09:24:03 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-153.messagelabs.com!1188221040!6609732!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 1895 invoked from network); 27 Aug 2007 13:24:00 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-4.tower-153.messagelabs.com with SMTP; 27 Aug 2007 13:24:00 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l7RDO0ij023995; Mon, 27 Aug 2007 06:24:00 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l7RDNxHr018456; Mon, 27 Aug 2007 08:23:59 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l7RDNtrR018392; Mon, 27 Aug 2007 08:23:56 -0500 (CDT) Message-ID: <46D2D067.4080609@gmail.com> Date: Mon, 27 Aug 2007 15:23:51 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Mip6] Request to progress MIP6 WG I-D: draft-ietf-mip6-whyauthdataoption-03.txt References: <46D2C554.7090403@gmail.com> <46D2CB26.6000108@gmx.net> In-Reply-To: <46D2CB26.6000108@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000768-4, 26/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Gopal Dommety , Mobile IPv6 Mailing List , Alexandru Petrescu X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hannes Tschofenig wrote: > I have to pick on a few selected items: > > >>> 4. Networks which are bandwidth constrained (such as cellular >>> wireless networks) and there exists a need to minimize the number of >>> signaling messages sent over such interfaces. >> >> I think there may be some confusion here? >> >> Authenticating messages with AH vs authopt is not very different in >> terms of bandwidth consumption. Both include additional >> authentication data to each MIP6 signalling message (BU/BAck, BRR, >> BErretc.) >> >> IKE may take longer than not using IKE, but MIP6 can work without IKE >> and with pre-established SAs. >> > The actual protection of the signaling traffic does not differ too much > from a bandwidth point of view. > However, if you compare the number of messages that are exchanged for > IKEv2 and for the Auth Protocol then there is obviously a big difference. Sorry, authopt doesn't establish any key, right? The number of messages exchanged is the same MIP6 messages, be it with AH authentication or with authopt authentication, right? Do I miss any big thing here. >>> o The same user configuration information, i.e the identity and keys >>> associated with a user will be used for IP mobility service in IPv4 >>> and/or IPv6 networks. The only security association that is >>> preconfigured is a shared secret between the mobile node and the >>> home-AAA server. >> >> I don't agree. An operator can't share the same key with all his/her >> customers. >> >> Besides, you use the term "security association"??? If there's a >> preconfigured SA between MN and HAAA then BU/BAck can be authenticated >> with AH and that key; simply the operator has to copy that same key on >> the HA from HAAA. > > The text does not say that the operator shares the same key with all its > customers. Instead, it says that the keys are established between the MN > and the home AAA server. Ok. >>> The use of IPsec for performing Registration with a home agent is not >>> always an optimal solution. While it is true that IPsec is an >>> integral part of the IPv6 stack, it is still a considerable overhead >>> from a deployment perspective of using IPsec as the security >>> mechanism for the signaling messages between the MN and HA. >> >> I'm not sure what you mean here. Authenticating a message exchange with >> AH vs with authopt is about the same size. Or do you mean _IKE_ may >> take too many messages? >> >> In this way, do you actually compare IKE vs some other unknown key >> distribution system? and not authopt vs IPsec? >> > You need to compare the complete system, which is IPsec + IKEv2 + AAA > interaction vs. Auth Protocol + AAA interaction. > From a performance point of view the latter is much better. I mostly agree it can offer a higher performance in a small closed system... but that doesn't scale to large open systems. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 09:40:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPepJ-0005sy-QM; Mon, 27 Aug 2007 09:40:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPepI-0005ss-2c for mip6@ietf.org; Mon, 27 Aug 2007 09:40:20 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPepG-0000RP-Ks for mip6@ietf.org; Mon, 27 Aug 2007 09:40:20 -0400 Received: from [127.0.0.1] ([192.130.196.87]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 06:40:17 -0700 Message-ID: <46D2D436.3050402@azairenet.com> Date: Mon, 27 Aug 2007 06:40:06 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] WG LC: I-D draft-ietf-mip6-rfc4285bis-00.txt References: <46D2CF20.4040004@gmail.com> In-Reply-To: <46D2CF20.4040004@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2007 13:40:17.0581 (UTC) FILETIME=[CDF75DD0:01C7E8AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Mobile IPv6 Mailing List , "Kent Leung \(kleung\)" , haseebak@nortel.com, alpesh@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex, Responding to a few comments that caught my eye.... Alexandru Petrescu wrote: > Overall, I support it and its advancement (I have some comments for > improvement), but I don't believe it on the Standards Track; mainly > because it has an established alternative and widely deployed which > scales. I think the target for this document is Informational. >> The authentication option specified in Section 5 is applicable in >> certain types of networks that have the following characteristics: >> >> - Networks in which the authentication of the MN for network access is >> done by an authentication server in the home network via the home >> agent. The security association is established by the network >> operator (provisioning methods) > > I wouldn't use the term "security association" because that's IPsec. No this is not correct. Security association is a generic term. When you want to associate it with IPsec, you have to explicitly say "IPsec SA". RFC 2002 (which was standardized in 1996) already used the term "mobility security association". >> The alignment requirement for this option is 4n + 1. > > (1) Where and when to pad in order to reach this alignment? Before the Type field. > (2) Shouldn't the option length be expressed in 4n octets instead of > simply octets? That's what many other IPv6 users do. For all mobility options, the length field is in terms of octets. No reason to change that. > (3) _if_ precisely 96bits of message digest are used then the length is > constand and no need of alignment requirements specification, or > ellipsis in message descriptio - just fill constants in. Right? The alignment requirement comes from the presence of a 32-bit integer field, the Mobility SPI, in the option and the desire to have this field fall on the 4 byte boundary. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 09:51:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPf01-0003yZ-HP; Mon, 27 Aug 2007 09:51:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPf00-0003wt-JL for mip6@ietf.org; Mon, 27 Aug 2007 09:51:24 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IPf00-0004G1-44 for mip6@ietf.org; Mon, 27 Aug 2007 09:51:24 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1188222682!19720877!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 20773 invoked from network); 27 Aug 2007 13:51:23 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-9.tower-119.messagelabs.com with SMTP; 27 Aug 2007 13:51:23 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l7RDpIUb000849; Mon, 27 Aug 2007 06:51:22 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l7RDpHZ9007849; Mon, 27 Aug 2007 08:51:17 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l7RDpDbs007769; Mon, 27 Aug 2007 08:51:14 -0500 (CDT) Message-ID: <46D2D6CD.9040708@gmail.com> Date: Mon, 27 Aug 2007 15:51:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] WG LC: I-D draft-ietf-mip6-rfc4285bis-00.txt References: <46D2CF20.4040004@gmail.com> <46D2D436.3050402@azairenet.com> In-Reply-To: <46D2D436.3050402@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000768-4, 26/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Alexandru Petrescu , alpesh@cisco.com, "Kent Leung \(kleung\)" , haseebak@nortel.com, Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Hi Alex, > > Responding to a few comments that caught my eye.... > > Alexandru Petrescu wrote: >> Overall, I support it and its advancement (I have some comments for >> improvement), but I don't believe it on the Standards Track; mainly >> because it has an established alternative and widely deployed which >> scales. > > I think the target for this document is Informational. I agree then. >>> The authentication option specified in Section 5 is applicable in >>> certain types of networks that have the following characteristics: >>> >>> - Networks in which the authentication of the MN for network access >>> is done by an authentication server in the home network via the home >>> agent. The security association is established by the network >>> operator (provisioning methods) >> >> I wouldn't use the term "security association" because that's IPsec. > > No this is not correct. Security association is a generic term. When you > want to associate it with IPsec, you have to explicitly say "IPsec SA". > RFC 2002 (which was standardized in 1996) already used the term > "mobility security association". Ok, I didn't know that. But I'm not sure what other type of "security association" is implemented, I mean I have only seen IPsec SAs. What would the AuthOpt SA look like? What is the length of the key? Would a AuthOpt SA database be standardized? (like the IPsec SA database). >>> The alignment requirement for this option is 4n + 1. >> >> (1) Where and when to pad in order to reach this alignment? > > Before the Type field. Why not picturing it? A simple Pad0 there. >> (2) Shouldn't the option length be expressed in 4n octets instead of >> simply octets? That's what many other IPv6 users do. > > For all mobility options, the length field is in terms of octets. No > reason to change that. Ok. >> (3) _if_ precisely 96bits of message digest are used then the length is >> constand and no need of alignment requirements specification, or >> ellipsis in message descriptio - just fill constants in. Right? > > The alignment requirement comes from the presence of a 32-bit integer > field, the Mobility SPI, in the option and the desire to have this field > fall on the 4 byte boundary. But do you agree that the length field always contains the same value (103 decimal)? There's no variable-length subfield here, right? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 10:13:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPfKx-00061j-HE; Mon, 27 Aug 2007 10:13:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPfKw-00061d-U3 for mip6@ietf.org; Mon, 27 Aug 2007 10:13:02 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPfKw-0004qz-2F for mip6@ietf.org; Mon, 27 Aug 2007 10:13:02 -0400 Received: from [127.0.0.1] ([192.130.196.87]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 07:13:00 -0700 Message-ID: <46D2DBE6.6080609@azairenet.com> Date: Mon, 27 Aug 2007 07:12:54 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] WG LC: I-D draft-ietf-mip6-rfc4285bis-00.txt References: <46D2CF20.4040004@gmail.com> <46D2D436.3050402@azairenet.com> <46D2D6CD.9040708@gmail.com> In-Reply-To: <46D2D6CD.9040708@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2007 14:13:00.0559 (UTC) FILETIME=[5FFE09F0:01C7E8B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Mobile IPv6 Mailing List , "Kent Leung \(kleung\)" , haseebak@nortel.com, alpesh@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > What would the AuthOpt SA look like? What is the length of the key? The draft already describes this The shared-key based mobility security association between Mobile Node and Home Agent used within this specification consists of a mobility SPI, a key, an authentication algorithm and the replay protection mechanism in use. The mobility SPI is a number in range [0-4294967296], where the range [0-255] is reserved. The key consists of an arbitrary value and is 20 octets in length. The authentication algorithm is HMAC_SHA1. > Would a AuthOpt SA database be standardized? (like the IPsec SA database). I don't see a need for that. >>>> The alignment requirement for this option is 4n + 1. >>> >>> (1) Where and when to pad in order to reach this alignment? >> >> Before the Type field. > > Why not picturing it? A simple Pad0 there. You never do that. Lets say before adding the authentication option, the length of the packet is 121 bytes, then you would add the authentication option without any padding. If it is 118 bytes, you would add 3 bytes of padding before the authentication option. >>> (2) Shouldn't the option length be expressed in 4n octets instead of >>> simply octets? That's what many other IPv6 users do. >> >> For all mobility options, the length field is in terms of octets. No >> reason to change that. > > Ok. > >>> (3) _if_ precisely 96bits of message digest are used then the length is >>> constand and no need of alignment requirements specification, or >>> ellipsis in message descriptio - just fill constants in. Right? >> >> The alignment requirement comes from the presence of a 32-bit integer >> field, the Mobility SPI, in the option and the desire to have this >> field fall on the 4 byte boundary. > > But do you agree that the length field always contains the same value > (103 decimal)? There's no variable-length subfield here, right? True, but RFC 3775 says all mobility options have a type and length fields. :) See section 6.2.1 in RFC 3775. And it makes processing on the receiving side easy. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 10:40:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPfk2-0000mE-RV; Mon, 27 Aug 2007 10:38:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPfk1-0000fh-PG for mip6@ietf.org; Mon, 27 Aug 2007 10:38:57 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IPfjy-00065p-3O for mip6@ietf.org; Mon, 27 Aug 2007 10:38:54 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1188225532!5466567!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 20166 invoked from network); 27 Aug 2007 14:38:52 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-13.tower-153.messagelabs.com with SMTP; 27 Aug 2007 14:38:52 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l7REcqk9025114; Mon, 27 Aug 2007 07:38:52 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l7REcpLn002073; Mon, 27 Aug 2007 09:38:51 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l7REcnvw002037; Mon, 27 Aug 2007 09:38:49 -0500 (CDT) Message-ID: <46D2E1F4.2050401@gmail.com> Date: Mon, 27 Aug 2007 16:38:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] WG LC: I-D draft-ietf-mip6-rfc4285bis-00.txt References: <46D2CF20.4040004@gmail.com> <46D2D436.3050402@azairenet.com> <46D2D6CD.9040708@gmail.com> <46D2DBE6.6080609@azairenet.com> In-Reply-To: <46D2DBE6.6080609@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000768-4, 26/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: > >> What would the AuthOpt SA look like? What is the length of the >> key? > > The draft already describes this > > The shared-key based mobility security association between Mobile > Node and Home Agent used within this specification consists of a > mobility SPI, a key, an authentication algorithm and the replay > protection mechanism in use. The mobility SPI is a number in range > [0-4294967296], where the range [0-255] is reserved. The key > consists of an arbitrary value and is 20 octets in length. The > authentication algorithm is HMAC_SHA1. Look, when I read "mobility security association" I can understand the text better. But in at least one place the draft talks about "shared-key based security association", other place "shared mobility security association" and means "shared-key based mobility security association". This is very confusing. The fix to this can be very easy. >> Would a AuthOpt SA database be standardized? (like the IPsec SA >> database). > > I don't see a need for that. Ok. >>>>> The alignment requirement for this option is 4n + 1. >>>> >>>> (1) Where and when to pad in order to reach this alignment? >>> >>> Before the Type field. >> >> Why not picturing it? A simple Pad0 there. > > You never do that. Lets say before adding the authentication option, > the length of the packet is 121 bytes, then you would add the > authentication option without any padding. If it is 118 bytes, you > would add 3 bytes of padding before the authentication option. If you pad _before_ this option header then the alignment shouldn't be specified at all by this option. I think above you're talking about the overall Mobility Header alignment requirement, and this is already specified, no need to put it here. >>>> (3) _if_ precisely 96bits of message digest are used then the >>>> length is constand and no need of alignment requirements >>>> specification, or ellipsis in message descriptio - just fill >>>> constants in. Right? >>> >>> The alignment requirement comes from the presence of a 32-bit >>> integer field, the Mobility SPI, in the option and the desire to >>> have this field fall on the 4 byte boundary. >> >> But do you agree that the length field always contains the same >> value (103 decimal)? There's no variable-length subfield here, >> right? > > True, but RFC 3775 says all mobility options have a type and length > fields. :) See section 6.2.1 in RFC 3775. And it makes processing on > the receiving side easy. Right... makes sense... maybe it is sufficient to just say that there is a length field and its contents is constant 103 decimal, no? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 10:46:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPfrF-0000N8-89; Mon, 27 Aug 2007 10:46:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPfrD-0000N3-Na for mip6@ietf.org; Mon, 27 Aug 2007 10:46:23 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPfrD-0006PO-An for mip6@ietf.org; Mon, 27 Aug 2007 10:46:23 -0400 Received: from [127.0.0.1] ([192.130.196.87]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 07:46:21 -0700 Message-ID: <46D2E3AE.3090100@azairenet.com> Date: Mon, 27 Aug 2007 07:46:06 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] WG LC: I-D draft-ietf-mip6-rfc4285bis-00.txt References: <46D2CF20.4040004@gmail.com> <46D2D436.3050402@azairenet.com> <46D2D6CD.9040708@gmail.com> <46D2DBE6.6080609@azairenet.com> <46D2E1F4.2050401@gmail.com> In-Reply-To: <46D2E1F4.2050401@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2007 14:46:22.0114 (UTC) FILETIME=[09031820:01C7E8B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: >>>>>> The alignment requirement for this option is 4n + 1. >>>>> >>>>> (1) Where and when to pad in order to reach this alignment? >>>> >>>> Before the Type field. >>> >>> Why not picturing it? A simple Pad0 there. >> >> You never do that. Lets say before adding the authentication option, >> the length of the packet is 121 bytes, then you would add the >> authentication option without any padding. If it is 118 bytes, you >> would add 3 bytes of padding before the authentication option. > > If you pad _before_ this option header then the alignment shouldn't be > specified at all by this option. > > I think above you're talking about the overall Mobility Header alignment > requirement, and this is already specified, no need to put it here. No. When you specify an alignment requirement for an option, it points to what padding might be required *before* the option. Each option would have its own alignment requirement (some none). >> True, but RFC 3775 says all mobility options have a type and length >> fields. :) See section 6.2.1 in RFC 3775. And it makes processing on >> the receiving side easy. > > Right... makes sense... maybe it is sufficient to just say that there is > a length field and its contents is constant 103 decimal, no? But why would you hard code something in the spec? No need to. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 11:04:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPg8o-0007Bo-3A; Mon, 27 Aug 2007 11:04:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPg8m-00079X-JY for mip6@ietf.org; Mon, 27 Aug 2007 11:04:32 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IPg8l-00075M-PP for mip6@ietf.org; Mon, 27 Aug 2007 11:04:32 -0400 Received: (qmail invoked by alias); 27 Aug 2007 15:04:30 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp056) with SMTP; 27 Aug 2007 17:04:30 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+GowpvdbaG40iLFC7WvXd6Bmk2dEGaTeT7mNY1t2 ZS+VJp6vjbB+SB Message-ID: <46D2E802.8050009@gmx.net> Date: Mon, 27 Aug 2007 17:04:34 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] Request to progress MIP6 WG I-D: draft-ietf-mip6-whyauthdataoption-03.txt References: <46D2C554.7090403@gmail.com> <46D2CB26.6000108@gmx.net> <46D2D067.4080609@gmail.com> In-Reply-To: <46D2D067.4080609@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: Gopal Dommety , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex, a few quick comments below: Alexandru Petrescu wrote: > Hannes Tschofenig wrote: >> I have to pick on a few selected items: >> >> >>>> 4. Networks which are bandwidth constrained (such as cellular >>>> wireless networks) and there exists a need to minimize the number >>>> of signaling messages sent over such interfaces. >>> >>> I think there may be some confusion here? >>> >>> Authenticating messages with AH vs authopt is not very different in >>> terms of bandwidth consumption. Both include additional >>> authentication data to each MIP6 signalling message (BU/BAck, BRR, >>> BErretc.) >>> >>> IKE may take longer than not using IKE, but MIP6 can work without IKE >>> and with pre-established SAs. >>> >> The actual protection of the signaling traffic does not differ too >> much from a bandwidth point of view. >> However, if you compare the number of messages that are exchanged for >> IKEv2 and for the Auth Protocol then there is obviously a big >> difference. > > Sorry, authopt doesn't establish any key, right? > The Auth. Protocol document does not talk about generation of new MN<-->AAAH keying material changes and the IETF has not developed a "bootstrapping" mechanism for it either. Note, however, that some other SDOs produce solutions that use the network access authentication procedure to generate new keying material. That is pretty close to what is done with the integrated scenario expect that the keying material is not used for IKEv2/EAP. > The number of messages exchanged is the same MIP6 messages, be it with > AH authentication or with authopt authentication, right? You need to differentiate (a) pure message protection from the (b) authentication and key exchange. For (a) both methods to the same. IPsec is more difficult to implement than the MIP6 auth protocol but that's another story. For (b) there are obviously the differences and Raj is talking about (b) rather than (a). > > Do I miss any big thing here. > >>>> o The same user configuration information, i.e the identity and keys >>>> associated with a user will be used for IP mobility service in >>>> IPv4 and/or IPv6 networks. The only security association that is >>>> preconfigured is a shared secret between the mobile node and the >>>> home-AAA server. >>> >>> I don't agree. An operator can't share the same key with all his/her >>> customers. >>> >>> Besides, you use the term "security association"??? If there's a >>> preconfigured SA between MN and HAAA then BU/BAck can be authenticated >>> with AH and that key; simply the operator has to copy that same key on >>> the HA from HAAA. >> >> The text does not say that the operator shares the same key with all >> its customers. Instead, it says that the keys are established between >> the MN and the home AAA server. > > Ok. > >>>> The use of IPsec for performing Registration with a home agent is not >>>> always an optimal solution. While it is true that IPsec is an >>>> integral part of the IPv6 stack, it is still a considerable overhead >>>> from a deployment perspective of using IPsec as the security >>>> mechanism for the signaling messages between the MN and HA. >>> >>> I'm not sure what you mean here. Authenticating a message exchange >>> with >>> AH vs with authopt is about the same size. Or do you mean _IKE_ may >>> take too many messages? >>> >>> In this way, do you actually compare IKE vs some other unknown key >>> distribution system? and not authopt vs IPsec? >>> >> You need to compare the complete system, which is IPsec + IKEv2 + AAA >> interaction vs. Auth Protocol + AAA interaction. >> From a performance point of view the latter is much better. > > I mostly agree it can offer a higher performance in a small closed > system... but that doesn't scale to large open systems. I am not sure why you say "small closed system" vs. "large open system". The mobile node does not run the exchange with an arbitrary node. It runs the exchange with its home agent (that further relays the messages to the home AAA server using RADIUS or Diameter). I can understand that some guys don't want to use IKEv2 to protect the MIPv6 signaling traffic between the MN and the HA since the mechanism to secure the actual MIPv6 signaling turns out to be far more complex than the MIPv6 signaling itself. I can also understand why some guys "develop" a mechanism for MIP6 that is essentially the same as the one for MIPv4. Ciao Hannes > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 11:18:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPgM8-000399-0Q; Mon, 27 Aug 2007 11:18:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPgM6-00038s-S1 for mip6@ietf.org; Mon, 27 Aug 2007 11:18:18 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IPgM6-0007eI-A9 for mip6@ietf.org; Mon, 27 Aug 2007 11:18:18 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1188227894!4775004!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 27797 invoked from network); 27 Aug 2007 15:18:14 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-5.tower-153.messagelabs.com with SMTP; 27 Aug 2007 15:18:14 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l7RFIEtp026710; Mon, 27 Aug 2007 08:18:14 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l7RFIDhU026226; Mon, 27 Aug 2007 10:18:13 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l7RFIAEj026131; Mon, 27 Aug 2007 10:18:11 -0500 (CDT) Message-ID: <46D2EB2E.7000008@gmail.com> Date: Mon, 27 Aug 2007 17:18:06 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] WG LC: I-D draft-ietf-mip6-rfc4285bis-00.txt References: <46D2CF20.4040004@gmail.com> <46D2D436.3050402@azairenet.com> <46D2D6CD.9040708@gmail.com> <46D2DBE6.6080609@azairenet.com> <46D2E1F4.2050401@gmail.com> <46D2E3AE.3090100@azairenet.com> In-Reply-To: <46D2E3AE.3090100@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000768-4, 26/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >>>>>>> The alignment requirement for this option is 4n + 1. >>>>>> >>>>>> (1) Where and when to pad in order to reach this alignment? >>>>> >>>>> Before the Type field. >>>> >>>> Why not picturing it? A simple Pad0 there. >>> >>> You never do that. Lets say before adding the authentication option, >>> the length of the packet is 121 bytes, then you would add the >>> authentication option without any padding. If it is 118 bytes, you >>> would add 3 bytes of padding before the authentication option. >> >> If you pad _before_ this option header then the alignment shouldn't be >> specified at all by this option. >> >> I think above you're talking about the overall Mobility Header alignment >> requirement, and this is already specified, no need to put it here. > > No. When you specify an alignment requirement for an option, it points > to what padding might be required *before* the option. Each option would > have its own alignment requirement (some none). We have a different understanding here... I always see the padding _after_ the option such that to reach an alignment limit, especially when there are variable length fields. But you're right... it could be equivalent... depends who reads and how. >>> True, but RFC 3775 says all mobility options have a type and length >>> fields. :) See section 6.2.1 in RFC 3775. And it makes processing on >>> the receiving side easy. >> >> Right... makes sense... maybe it is sufficient to just say that there is >> a length field and its contents is constant 103 decimal, no? > > But why would you hard code something in the spec? No need to. Some specs I read hardcode the len fields and this is much easier for implementation. You _do_ hardcode IANA numbers in specs, right? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 11:27:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPgV7-0000uL-R7; Mon, 27 Aug 2007 11:27:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPgV6-0000uF-KY for mip6@ietf.org; Mon, 27 Aug 2007 11:27:36 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IPgV5-0007vr-R3 for mip6@ietf.org; Mon, 27 Aug 2007 11:27:36 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1188228454!20857727!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 32456 invoked from network); 27 Aug 2007 15:27:34 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-7.tower-119.messagelabs.com with SMTP; 27 Aug 2007 15:27:34 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l7RFRXES008732; Mon, 27 Aug 2007 08:27:33 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l7RFRXYb007346; Mon, 27 Aug 2007 10:27:33 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l7RFRUr1007259; Mon, 27 Aug 2007 10:27:31 -0500 (CDT) Message-ID: <46D2ED5F.8030504@gmail.com> Date: Mon, 27 Aug 2007 17:27:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Mip6] Request to progress MIP6 WG I-D: draft-ietf-mip6-whyauthdataoption-03.txt References: <46D2C554.7090403@gmail.com> <46D2CB26.6000108@gmx.net> <46D2D067.4080609@gmail.com> <46D2E802.8050009@gmx.net> In-Reply-To: <46D2E802.8050009@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000768-4, 26/08/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Gopal Dommety , Mobile IPv6 Mailing List , Alexandru Petrescu X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hannes Tschofenig wrote: > Hi Alex, > > a few quick comments below: > > Alexandru Petrescu wrote: >> Hannes Tschofenig wrote: >>> I have to pick on a few selected items: >>> >>> >>>>> 4. Networks which are bandwidth constrained (such as >>>>> cellular wireless networks) and there exists a need to >>>>> minimize the number of signaling messages sent over such >>>>> interfaces. >>>> >>>> I think there may be some confusion here? >>>> >>>> Authenticating messages with AH vs authopt is not very >>>> different in terms of bandwidth consumption. Both include >>>> additional authentication data to each MIP6 signalling message >>>> (BU/BAck, BRR, BErretc.) >>>> >>>> IKE may take longer than not using IKE, but MIP6 can work >>>> without IKE and with pre-established SAs. >>>> >>> The actual protection of the signaling traffic does not differ >>> too much from a bandwidth point of view. However, if you compare >>> the number of messages that are exchanged for IKEv2 and for the >>> Auth Protocol then there is obviously a big difference. >> >> Sorry, authopt doesn't establish any key, right? >> > The Auth. Protocol document does not talk about generation of new > MN<-->AAAH keying material changes and the IETF has not developed a > "bootstrapping" mechanism for it either. Note, however, that some > other SDOs produce solutions that use the network access > authentication procedure to generate new keying material. I think we shouldn't compare SDO's network auth procedure to IKE and then conclude that we don't need IKE. I think that SDO's choice rests that SDO's choice. > That is pretty close to what is done with the integrated scenario > expect that the keying material is not used for IKEv2/EAP. > >> The number of messages exchanged is the same MIP6 messages, be it >> with AH authentication or with authopt authentication, right? > You need to differentiate (a) pure message protection from the (b) > authentication and key exchange. For (a) both methods to the same. > IPsec is more difficult to implement than the MIP6 auth protocol but > that's another story. For (b) there are obviously the differences and > Raj is talking about (b) rather than (a). >> >> Do I miss any big thing here. >> > >>>>> o The same user configuration information, i.e the identity >>>>> and keys associated with a user will be used for IP mobility >>>>> service in IPv4 and/or IPv6 networks. The only security >>>>> association that is preconfigured is a shared secret between >>>>> the mobile node and the home-AAA server. >>>> >>>> I don't agree. An operator can't share the same key with all >>>> his/her customers. >>>> >>>> Besides, you use the term "security association"??? If there's >>>> a preconfigured SA between MN and HAAA then BU/BAck can be >>>> authenticated with AH and that key; simply the operator has to >>>> copy that same key on the HA from HAAA. >>> >>> The text does not say that the operator shares the same key with >>> all its customers. Instead, it says that the keys are established >>> between the MN and the home AAA server. >> >> Ok. >> >>>>> The use of IPsec for performing Registration with a home >>>>> agent is not always an optimal solution. While it is true >>>>> that IPsec is an integral part of the IPv6 stack, it is still >>>>> a considerable overhead from a deployment perspective of >>>>> using IPsec as the security mechanism for the signaling >>>>> messages between the MN and HA. >>>> >>>> I'm not sure what you mean here. Authenticating a message >>>> exchange with AH vs with authopt is about the same size. Or do >>>> you mean _IKE_ may take too many messages? >>>> >>>> In this way, do you actually compare IKE vs some other unknown >>>> key distribution system? and not authopt vs IPsec? >>>> >>> You need to compare the complete system, which is IPsec + IKEv2 + >>> AAA interaction vs. Auth Protocol + AAA interaction. From a >>> performance point of view the latter is much better. >> >> I mostly agree it can offer a higher performance in a small closed >> system... but that doesn't scale to large open systems. > I am not sure why you say "small closed system" vs. "large open > system". The mobile node does not run the exchange with an arbitrary > node. It runs the exchange with its home agent (that further relays > the messages to the home AAA server using RADIUS or Diameter). Ok. > I can understand that some guys don't want to use IKEv2 to protect > the MIPv6 signaling traffic between the MN and the HA since the > mechanism to secure the actual MIPv6 signaling turns out to be far > more complex than the MIPv6 signaling itself. Actually I don't find the mechanism to protect the MIP6 signalling to be complex. Only the use of IKEv2 is heavy and complex (and MIP6 can work with shared-keys, no need of IKE) and the SAdb has to be tweaked with respect to the position of HoA. AuthOpt doesn't bring any faster MIP6 whatsoever, it's the same authentication data pasted on cleartext BU/BAck. AuthOpt doesn't provide confidentiality either (no ESP), but maybe those deployments don't need it anyways. > I can also understand why some guys "develop" a mechanism for MIP6 > that is essentially the same as the one for MIPv4. I understand that too, yes, for implementing appears conceptually to be easier to port a MIP4 auth feature to MIP6. But it's going to be reimplementing anyways, because the MIP4 auth feature doesn't work with IPv6 bits and fields. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 11:57:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPgxr-0001UO-Ak; Mon, 27 Aug 2007 11:57:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPgxp-0001Or-Lw for mip6@ietf.org; Mon, 27 Aug 2007 11:57:17 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IPgxo-0004sq-6i for mip6@ietf.org; Mon, 27 Aug 2007 11:57:17 -0400 Received: (qmail invoked by alias); 27 Aug 2007 15:57:14 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp003) with SMTP; 27 Aug 2007 17:57:14 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+PURFegQOP9cyBbhh7xpQC96vLpHYspX5OIZoMV+ VeaBy7hjIyrL/h Message-ID: <46D2F45C.2090302@gmx.net> Date: Mon, 27 Aug 2007 17:57:16 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] Request to progress MIP6 WG I-D: draft-ietf-mip6-whyauthdataoption-03.txt References: <46D2C554.7090403@gmail.com> <46D2CB26.6000108@gmx.net> <46D2D067.4080609@gmail.com> <46D2E802.8050009@gmx.net> <46D2ED5F.8030504@gmail.com> In-Reply-To: <46D2ED5F.8030504@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: Gopal Dommety , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex, Alexandru Petrescu wrote: > Hannes Tschofenig wrote: >> Hi Alex, >> >> a few quick comments below: >> >> Alexandru Petrescu wrote: >>> Hannes Tschofenig wrote: >>>> I have to pick on a few selected items: >>>> >>>> >>>>>> 4. Networks which are bandwidth constrained (such as cellular >>>>>> wireless networks) and there exists a need to minimize the number >>>>>> of signaling messages sent over such interfaces. >>>>> >>>>> I think there may be some confusion here? >>>>> >>>>> Authenticating messages with AH vs authopt is not very different >>>>> in terms of bandwidth consumption. Both include additional >>>>> authentication data to each MIP6 signalling message (BU/BAck, BRR, >>>>> BErretc.) >>>>> >>>>> IKE may take longer than not using IKE, but MIP6 can work without >>>>> IKE and with pre-established SAs. >>>>> >>>> The actual protection of the signaling traffic does not differ too >>>> much from a bandwidth point of view. However, if you compare the >>>> number of messages that are exchanged for IKEv2 and for the Auth >>>> Protocol then there is obviously a big difference. >>> >>> Sorry, authopt doesn't establish any key, right? >>> >> The Auth. Protocol document does not talk about generation of new >> MN<-->AAAH keying material changes and the IETF has not developed a >> "bootstrapping" mechanism for it either. Note, however, that some >> other SDOs produce solutions that use the network access >> authentication procedure to generate new keying material. > > I think we shouldn't compare SDO's network auth procedure to IKE and > then conclude that we don't need IKE. I think that SDO's choice rests > that SDO's choice. > I am not sure what you are complaining about. You have to compare similar things since otherwise the comparison is mood. In this particular space the bootstrapping solution for MIPv6 with IKEv2 may either use (a) network access authentication (see http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-05.txt) or (b) a separate protocol run (see http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-07.txt). Here is the corresponding Diameter work: http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-05.txt http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-04.txt The former document is in WGLC. The RADIUS work can be found here: http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-02.txt >> That is pretty close to what is done with the integrated scenario >> expect that the keying material is not used for IKEv2/EAP. >> >>> The number of messages exchanged is the same MIP6 messages, be it >>> with AH authentication or with authopt authentication, right? >> You need to differentiate (a) pure message protection from the (b) >> authentication and key exchange. For (a) both methods to the same. >> IPsec is more difficult to implement than the MIP6 auth protocol but >> that's another story. For (b) there are obviously the differences and >> Raj is talking about (b) rather than (a). >>> >>> Do I miss any big thing here. >>> >> >>>>>> o The same user configuration information, i.e the identity and >>>>>> keys associated with a user will be used for IP mobility service >>>>>> in IPv4 and/or IPv6 networks. The only security association that >>>>>> is preconfigured is a shared secret between the mobile node and >>>>>> the home-AAA server. >>>>> >>>>> I don't agree. An operator can't share the same key with all >>>>> his/her customers. >>>>> >>>>> Besides, you use the term "security association"??? If there's >>>>> a preconfigured SA between MN and HAAA then BU/BAck can be >>>>> authenticated with AH and that key; simply the operator has to >>>>> copy that same key on the HA from HAAA. >>>> >>>> The text does not say that the operator shares the same key with >>>> all its customers. Instead, it says that the keys are established >>>> between the MN and the home AAA server. >>> >>> Ok. >>> >>>>>> The use of IPsec for performing Registration with a home agent is >>>>>> not always an optimal solution. While it is true that IPsec is >>>>>> an integral part of the IPv6 stack, it is still >>>>>> a considerable overhead from a deployment perspective of using >>>>>> IPsec as the security mechanism for the signaling messages >>>>>> between the MN and HA. >>>>> >>>>> I'm not sure what you mean here. Authenticating a message >>>>> exchange with AH vs with authopt is about the same size. Or do >>>>> you mean _IKE_ may take too many messages? >>>>> >>>>> In this way, do you actually compare IKE vs some other unknown key >>>>> distribution system? and not authopt vs IPsec? >>>>> >>>> You need to compare the complete system, which is IPsec + IKEv2 + >>>> AAA interaction vs. Auth Protocol + AAA interaction. From a >>>> performance point of view the latter is much better. >>> >>> I mostly agree it can offer a higher performance in a small closed >>> system... but that doesn't scale to large open systems. >> I am not sure why you say "small closed system" vs. "large open >> system". The mobile node does not run the exchange with an arbitrary >> node. It runs the exchange with its home agent (that further relays >> the messages to the home AAA server using RADIUS or Diameter). > > Ok. > >> I can understand that some guys don't want to use IKEv2 to protect >> the MIPv6 signaling traffic between the MN and the HA since the >> mechanism to secure the actual MIPv6 signaling turns out to be far >> more complex than the MIPv6 signaling itself. > > Actually I don't find the mechanism to protect the MIP6 signalling to be > complex. Only the use of IKEv2 is heavy and complex (and MIP6 can work > with shared-keys, no need of IKE) and the SAdb has to be tweaked with > respect to the position of HoA. But the IPsec solution just uses IKEv2. > > AuthOpt doesn't bring any faster MIP6 whatsoever, it's the same > authentication data pasted on cleartext BU/BAck. > I wasn't able to convince you, as it seems. > AuthOpt doesn't provide confidentiality either (no ESP), but maybe those > deployments don't need it anyways. This is certainly a drawback (and also the reason for the applicability statement in the MIPv6 Auth Protocol document, if I recall it correctly). I personally would have provided confidentiality support to it as well. > >> I can also understand why some guys "develop" a mechanism for MIP6 >> that is essentially the same as the one for MIPv4. > > I understand that too, yes, for implementing appears conceptually to be > easier to port a MIP4 auth feature to MIP6. But it's going to be > reimplementing anyways, because the MIP4 auth feature doesn't work with > IPv6 bits and fields. When you consider the AAA infrastructure then it is a lot easier to just re-use things. Anyway, I am not quite sure where your comments are heading. It seems that you like IKEv2 for MIPv6 security. That's great and there are specs available. A few guys have also expressed interest to work on something that is a bit different (ignoring all the reasons for a moment). Do you think it will be of any value to re-hash the discussion? Do you think that anyone will change their mind based on this discussion? Or are you suggesting that something tries to optimize the IPsec/IKEv2 bootstrapping approach? Ciao Hannes > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 12:28:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPhRW-00049S-CF; Mon, 27 Aug 2007 12:27:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPhRU-0003wW-7w for mip6@ietf.org; Mon, 27 Aug 2007 12:27:56 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IPhRT-0001DJ-77 for mip6@ietf.org; Mon, 27 Aug 2007 12:27:56 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1188232074!21805669!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6433 invoked from network); 27 Aug 2007 16:27:54 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 27 Aug 2007 16:27:54 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l7RGRssv015878; Mon, 27 Aug 2007 09:27:54 -0700 (MST) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l7RGRmgK016860; Mon, 27 Aug 2007 11:27:50 -0500 (CDT) Message-ID: <46D2FB81.80700@gmail.com> Date: Mon, 27 Aug 2007 18:27:45 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Mip6] Request to progress MIP6 WG I-D: draft-ietf-mip6-whyauthdataoption-03.txt References: <46D2C554.7090403@gmail.com> <46D2CB26.6000108@gmx.net> <46D2D067.4080609@gmail.com> <46D2E802.8050009@gmx.net> <46D2ED5F.8030504@gmail.com> <46D2F45C.2090302@gmx.net> In-Reply-To: <46D2F45C.2090302@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000768-4, 26/08/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: Gopal Dommety , Mobile IPv6 Mailing List , Alexandru Petrescu X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hannes Tschofenig wrote: > Hi Alex, > > > Alexandru Petrescu wrote: >> Hannes Tschofenig wrote: >>> Hi Alex, >>> >>> a few quick comments below: >>> >>> Alexandru Petrescu wrote: >>>> Hannes Tschofenig wrote: >>>>> I have to pick on a few selected items: >>>>> >>>>> >>>>>>> 4. Networks which are bandwidth constrained (such as >>>>>>> cellular wireless networks) and there exists a need to >>>>>>> minimize the number of signaling messages sent over such >>>>>>> interfaces. >>>>>> >>>>>> I think there may be some confusion here? >>>>>> >>>>>> Authenticating messages with AH vs authopt is not very >>>>>> different in terms of bandwidth consumption. Both include >>>>>> additional authentication data to each MIP6 signalling >>>>>> message (BU/BAck, BRR, BErretc.) >>>>>> >>>>>> IKE may take longer than not using IKE, but MIP6 can work >>>>>> without IKE and with pre-established SAs. >>>>>> >>>>> The actual protection of the signaling traffic does not >>>>> differ too much from a bandwidth point of view. However, if >>>>> you compare the number of messages that are exchanged for >>>>> IKEv2 and for the Auth Protocol then there is obviously a big >>>>> difference. >>>> >>>> Sorry, authopt doesn't establish any key, right? >>>> >>> The Auth. Protocol document does not talk about generation of new >>> MN<-->AAAH keying material changes and the IETF has not >>> developed a "bootstrapping" mechanism for it either. Note, >>> however, that some other SDOs produce solutions that use the >>> network access authentication procedure to generate new keying >>> material. >> >> I think we shouldn't compare SDO's network auth procedure to IKE >> and then conclude that we don't need IKE. I think that SDO's >> choice rests that SDO's choice. >> > I am not sure what you are complaining about. You have to compare > similar things since otherwise the comparison is mood. In this > particular space the bootstrapping solution for MIPv6 with IKEv2 may > either use (a) network access authentication (see > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-05.txt) > or (b) a separate protocol run (see > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-07.txt). How about authenticating the access with a link-layer method and using the obtained key to generate the IPsec AH authenticators? That's what I'm complaining about. > Here is the corresponding Diameter work: > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-05.txt > > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-04.txt > > > The former document is in WGLC. > > The RADIUS work can be found here: > http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-02.txt Thanks but I don't see the relationship between these docs and the claim that authopt is any faster than IPsec-AH-based MIP6 authentication. >>> That is pretty close to what is done with the integrated scenario >>> expect that the keying material is not used for IKEv2/EAP. >>> >>>> The number of messages exchanged is the same MIP6 messages, be >>>> it with AH authentication or with authopt authentication, >>>> right? >>> You need to differentiate (a) pure message protection from the >>> (b) authentication and key exchange. For (a) both methods to the >>> same. IPsec is more difficult to implement than the MIP6 auth >>> protocol but that's another story. For (b) there are obviously >>> the differences and Raj is talking about (b) rather than (a). >>>> >>>> Do I miss any big thing here. >>>> >>> >>>>>>> o The same user configuration information, i.e the >>>>>>> identity and keys associated with a user will be used for >>>>>>> IP mobility service in IPv4 and/or IPv6 networks. The >>>>>>> only security association that is preconfigured is a >>>>>>> shared secret between the mobile node and the home-AAA >>>>>>> server. >>>>>> >>>>>> I don't agree. An operator can't share the same key with >>>>>> all his/her customers. >>>>>> >>>>>> Besides, you use the term "security association"??? If >>>>>> there's a preconfigured SA between MN and HAAA then BU/BAck >>>>>> can be authenticated with AH and that key; simply the >>>>>> operator has to copy that same key on the HA from HAAA. >>>>> >>>>> The text does not say that the operator shares the same key >>>>> with all its customers. Instead, it says that the keys are >>>>> established between the MN and the home AAA server. >>>> >>>> Ok. >>>> >>>>>>> The use of IPsec for performing Registration with a home >>>>>>> agent is not always an optimal solution. While it is >>>>>>> true that IPsec is an integral part of the IPv6 stack, it >>>>>>> is still a considerable overhead from a deployment >>>>>>> perspective of using IPsec as the security mechanism for >>>>>>> the signaling messages between the MN and HA. >>>>>> >>>>>> I'm not sure what you mean here. Authenticating a message >>>>>> exchange with AH vs with authopt is about the same size. >>>>>> Or do you mean _IKE_ may take too many messages? >>>>>> >>>>>> In this way, do you actually compare IKE vs some other >>>>>> unknown key distribution system? and not authopt vs IPsec? >>>>>> >>>>> You need to compare the complete system, which is IPsec + >>>>> IKEv2 + AAA interaction vs. Auth Protocol + AAA interaction. >>>>> From a performance point of view the latter is much better. >>>> >>>> I mostly agree it can offer a higher performance in a small >>>> closed system... but that doesn't scale to large open systems. >>> I am not sure why you say "small closed system" vs. "large open >>> system". The mobile node does not run the exchange with an >>> arbitrary node. It runs the exchange with its home agent (that >>> further relays the messages to the home AAA server using RADIUS >>> or Diameter). >> >> Ok. >> >>> I can understand that some guys don't want to use IKEv2 to >>> protect the MIPv6 signaling traffic between the MN and the HA >>> since the mechanism to secure the actual MIPv6 signaling turns >>> out to be far more complex than the MIPv6 signaling itself. >> >> Actually I don't find the mechanism to protect the MIP6 signalling >> to be complex. Only the use of IKEv2 is heavy and complex (and >> MIP6 can work with shared-keys, no need of IKE) and the SAdb has to >> be tweaked with respect to the position of HoA. > But the IPsec solution just uses IKEv2. MIP6 can use IPsec AH authentication without using IKEv2. >> AuthOpt doesn't bring any faster MIP6 whatsoever, it's the same >> authentication data pasted on cleartext BU/BAck. >> > I wasn't able to convince you, as it seems. You can't convince anybody that authopt-based authentication brings any speed to MIP6 authentication (compared to IPsec authentication), that's clear. If you compare IKEv2 to link-layer/radius/eap/diameter authentication then it's a whole different problem and I think I agree with you that the latter is quicker. >> AuthOpt doesn't provide confidentiality either (no ESP), but maybe >> those deployments don't need it anyways. > This is certainly a drawback (and also the reason for the > applicability statement in the MIPv6 Auth Protocol document, if I > recall it correctly). I personally would have provided > confidentiality support to it as well. There's no such statement about confidentiality in authopt document, or I don't see it. Maybe there should be one. >>> I can also understand why some guys "develop" a mechanism for >>> MIP6 that is essentially the same as the one for MIPv4. >> >> I understand that too, yes, for implementing appears conceptually >> to be easier to port a MIP4 auth feature to MIP6. But it's going >> to be reimplementing anyways, because the MIP4 auth feature doesn't >> work with IPv6 bits and fields. > When you consider the AAA infrastructure then it is a lot easier to > just re-use things. > > Anyway, I am not quite sure where your comments are heading. It seems > that you like IKEv2 for MIPv6 security. I don't mean that, I know IKEv2 exchanges take time, but I'm saying if we have a means to share keys then IPsec authentication of MIPv6 messages is not any heavier than authopt authentication... not sure I'm clear. > That's great and there are specs available. A few guys have also > expressed interest to work on something that is a bit different > (ignoring all the reasons for a moment). Do you think it will be of > any value to re-hash the discussion? Do you think that anyone will > change their mind based on this discussion? Or are you suggesting > that something tries to optimize the IPsec/IKEv2 bootstrapping > approach? I'm not suggesting new work to optimize the IKEv2 bootstrapping for MIP6. I'm saying the argument made by whyauthoption is not very udnerstandable by me. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 13:44:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPidv-0002w9-C6; Mon, 27 Aug 2007 13:44:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPidu-0002vy-Eb for mip6@ietf.org; Mon, 27 Aug 2007 13:44:50 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPidt-0003i7-TY for mip6@ietf.org; Mon, 27 Aug 2007 13:44:50 -0400 Received: from [127.0.0.1] ([192.130.196.87]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 10:44:45 -0700 Message-ID: <46D30D7C.8040508@azairenet.com> Date: Mon, 27 Aug 2007 10:44:28 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Basavaraj Patil , Mobile IPv6 Mailing List Subject: Re: [Mip6] Consensus call: Adopting I-D References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Aug 2007 17:44:47.0777 (UTC) FILETIME=[F615A110:01C7E8D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, I do agree that we need to standardize a binding revocation mechanism. But I am not sure about adopting draft-muhanna-mip6-binding-revocation-01.txt. If we are adopting this document, we need substantial changes. My comments at a high level 1. I had argued for using mobility options in the generic mobility header signaling message to carry the revocation information. Those changes haven't been done yet. Also, I don't believe we have consensus on changing the format of the generic mobility header signaling message to include a sub-type. I guess that is the current assumption. 2. I don't think the Binding Revocation Indication message should be sent from the MAG to the LMA. draft-muhanna-mip6-binding-revocation says In the case when the MAG receives a direct or indirect indication or the MAG finds that the MN has moved a way and no longer attached to the it, the MAG MAY send a BRI message to indicate to the LMA that the MN session binding has been cleaned up at the MAG and the LMA needs to clean up the allocated and reserved resources. If the LMA processes the BRI message and the A bit is set, the LMA MUST send a BRA message in response to the MAG. If the MN moves awas, the MAG sends a de-registration Proxy BU to the LMA. Not the BRI message. The de-registration Proxy BU would inform the LMA that the MN is no longer attached to the MAG that sent the message. The draft goes beyond and specifies handover behavior for PMIPv6. Since there is no guaranteed indication to the LMA that the MAG has sent the BRI message due to a MN move during an inter-MAG handoff, the LMA SHOULD start a T_Handoff_Progress_timer to make sure that the MN session binding survives an inter-MAG handoff. Figure 5 and 6 specify new handover procedure for PMIPv6. This does not belong in this draft. 3. From what was presented at the IETF meeting regarding this draft, I don't think bindings should be revoked based on the CoA or Home Network Prefix. The HoA, MN Identifier and the BID are sufficient. I would like clarification on when the CoA or the Home Network Prefix would be used in binding revocation messages. Hope that helps. Vijay Basavaraj Patil wrote: > Hello, > > This is a consensus call for adopting I-D: Binding Revocation for IPv6 > Mobility as a MIP6 WG > document. > > The I-D has been discussed on the ML in the past and was also presented at > IETF69 in Chicago. > > So please opine on the following statement: > > The binding revocation feature specified in I-D > draft-muhanna-mip6-binding-revocation-01.txt is essential for MIP6 > deployments and hence should be made a MIP6 WG document and progressed as a > standards track doc. > > Yes [ ] > No [ ] > > -Raj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 15:22:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPkAp-0001fU-6R; Mon, 27 Aug 2007 15:22:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPkAn-0001b0-Hu for mip6@ietf.org; Mon, 27 Aug 2007 15:22:53 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPkAm-00070q-Vz for mip6@ietf.org; Mon, 27 Aug 2007 15:22:53 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 27 Aug 2007 12:22:53 -0700 X-IronPort-AV: i="4.19,313,1183359600"; d="scan'208"; a="394801025:sNHT47447560" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7RJMqfZ013065; Mon, 27 Aug 2007 12:22:52 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7RJMh0D016017; Mon, 27 Aug 2007 19:22:52 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 12:22:49 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call: Adopting I-D Date: Mon, 27 Aug 2007 12:22:49 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52046D078B@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Consensus call: Adopting I-D Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADNksgw From: "Kent Leung \(kleung\)" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" X-OriginalArrivalTime: 27 Aug 2007 19:22:49.0827 (UTC) FILETIME=[A80F3B30:01C7E8DF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=542; t=1188242572; x=1189106572; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=20=22Kent=20Leung=20\(kleung\)=22=20 |Subject:=20RE=3A=20[Mip6]=20Consensus=20call=3A=20Adopting=20I-D |Sender:=20; bh=oXYstsD9vySbtSPwwQY+E32l7ITSwUP/Q3xGGUf52ws=; b=WyFFaCvDEXrvqwt5nECW5r90iS6RQhpD8Qg8z5os5+yD1USgqQ6/MILCGVijA8qDfH4mlHRt 4FTxKPx7bj1ylb2aagMt/6iztfYyNyjwVA6nEqbxKjI1Y3aMINbsYkLt; Authentication-Results: sj-dkim-4; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: "Gopal Dommety \(gdommety\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org =20 This is a consensus call for adopting I-D: Binding Revocation for IPv6 Mobility as a MIP6 WG document. The I-D has been discussed on the ML in the past and was also presented at IETF69 in Chicago. So please opine on the following statement: The binding revocation feature specified in I-D draft-muhanna-mip6-binding-revocation-01.txt is essential for MIP6 deployments and hence should be made a MIP6 WG document and progressed as a standards track doc. Yes [X] No [ ] _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 17:32:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPmCN-0003gl-Lg; Mon, 27 Aug 2007 17:32:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPmCM-0003gf-CG for mip6@ietf.org; Mon, 27 Aug 2007 17:32:38 -0400 Received: from outbound-dub.frontbridge.com ([213.199.154.16] helo=outbound2-dub-R.bigfish.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPmCL-0002Hy-OX for mip6@ietf.org; Mon, 27 Aug 2007 17:32:38 -0400 Received: from outbound2-dub.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-dub-R.bigfish.com (Postfix) with ESMTP id D284164813A; Mon, 27 Aug 2007 21:32:49 +0000 (UTC) Received: from mail94-dub-R.bigfish.com (unknown [10.5.252.3]) by outbound2-dub.bigfish.com (Postfix) with ESMTP id C5F4B1930011; Mon, 27 Aug 2007 21:32:49 +0000 (UTC) Received: from mail94-dub (localhost.localdomain [127.0.0.1]) by mail94-dub-R.bigfish.com (Postfix) with ESMTP id 445C010882DE; Mon, 27 Aug 2007 21:31:29 +0000 (UTC) X-BigFish: V X-MS-Exchange-Organization-Antispam-Report: OrigIP: 207.40.188.13; Service: EHS Received: by mail94-dub (MessageSwitch) id 1188250288791510_1055; Mon, 27 Aug 2007 21:31:28 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail94-dub.bigfish.com (Postfix) with ESMTP id D335B167008B; Mon, 27 Aug 2007 21:31:26 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id l7RLWWCX016633; Mon, 27 Aug 2007 16:32:33 -0500 (CDT) Received: from plswg03a.ad.sprint.com (PLSWG03A.corp.sprint.com [10.214.11.49]) by mailhost.sprintspectrum.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7RLWWK7018204; Mon, 27 Aug 2007 16:32:32 -0500 (CDT) Received: from PLSWB09C.ad.sprint.com ([208.10.70.239]) by plswg03a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Aug 2007 16:32:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call: Adopting I-D Date: Mon, 27 Aug 2007 16:32:31 -0500 Message-ID: <38586DE67CB335498A0E9BA99201311B0F884EE3@PLSWB09C.ad.sprint.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711665F0C0@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Consensus call: Adopting I-D Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADRgMmwAAB9LtA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711665F0C0@zrc2hxm2.corp.nortel.com> From: "Hirschman, Brent B [CTO]" To: X-OriginalArrivalTime: 27 Aug 2007 21:32:32.0830 (UTC) FILETIME=[C7173DE0:01C7E8F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: "Gopal Dommety \(gdommety\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Sprint Nextel supports this draft. The binding revocation feature specified in I-D draft-muhanna-mip6-binding-revocation-01.txt is essential for MIP6 deployments and hence should be made a MIP6 WG document and progressed as a standards track doc. Yes [X] No [ ] Brent Hirschman Technology Development Strategist III Global Technology Standards KSOPHD0504-5D178 6220 Sprint Parkway, Overland Park, KS 66251 Voice 913-794-4271 FAX 913-794-0420 PCS 913-593-6221 Brent.Hirschman@sprint.com IMPORTANT: This message (including any attachments) may contain = material, non-public information or proprietary information and is for = the intended recipients only. If you are not the intended recipient, you = should notify the sender and delete this message. Any disclosure, = copying, or use of this information is strictly prohibited and may = subject you to legal liability.=20 -----Original Message----- From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 Sent: Thursday, August 23, 2007 1:16 PM To: Mobile IPv6 Mailing List Cc: Gopal Dommety Subject: [Mip6] Consensus call: Adopting I-D Hello, This is a consensus call for adopting I-D: Binding Revocation for IPv6 Mobility as a MIP6 WG document. The I-D has been discussed on the ML in the past and was also presented at IETF69 in Chicago. So please opine on the following statement: The binding revocation feature specified in I-D draft-muhanna-mip6-binding-revocation-01.txt is essential for MIP6 deployments and hence should be made a MIP6 WG document and progressed as a standards track doc. Yes [ ] No [ ] -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 17:56:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPmYo-0006I3-CJ; Mon, 27 Aug 2007 17:55:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPmYn-0006Hg-Gf for mip6@ietf.org; Mon, 27 Aug 2007 17:55:49 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPmYm-0006u5-BD for mip6@ietf.org; Mon, 27 Aug 2007 17:55:49 -0400 Received: by py-out-1112.google.com with SMTP id f31so1873027pyh for ; Mon, 27 Aug 2007 14:55:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=P6F7gWdtpvYaBjZtiYwc/PIySUcZajYE5xU5PyTwevcJZULaZYCMwqO+9Pg3XocLiiXqbaBYWr54/tso7rX3VNROBfzmkC4GZx4Edhdguv+6PRqv7YYKctSNR9HyTwJjGeAdb3lSsAGASPEv+IlW2KKWIhjAoiGOeusJmJer4Uk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=cvfNGCJ/wyUwhvUrRrrNoGJWgxm1ALfUmb3NsCbEy3e941jMOlha8XnUh7m32WIVY0qCAp7X/PTA+KOH7zk4eg9t0EVEpoLw/a0uZj6CZKV8DMKk12zJU8OxdHAFjDrozpkIBlJVh/GgZ2KfJyspsEtecnHkk/dzASD7s1b3t8s= Received: by 10.35.64.8 with SMTP id r8mr8033412pyk.1188251748034; Mon, 27 Aug 2007 14:55:48 -0700 (PDT) Received: from ?10.2.242.250? ( [206.47.204.99]) by mx.google.com with ESMTPS id n27sm5980703pyh.2007.08.27.14.55.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Aug 2007 14:55:46 -0700 (PDT) Message-ID: <46D3484D.7040702@gmail.com> Date: Mon, 27 Aug 2007 16:55:25 -0500 From: Sebastian Thalanany User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] Consensus call: Adopting I-D References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Gopal Dommety , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, Raj, The binding revocation feature, specified in I-D draft-muhanna-mip6-binding-revocation-01.txt, should be progressed further. Yes [x ] No [ ] Regards, Sebastian Basavaraj Patil wrote: >Hello, > >This is a consensus call for adopting I-D: Binding Revocation for IPv6 >Mobility as a MIP6 WG >document. > >The I-D has been discussed on the ML in the past and was also presented at >IETF69 in Chicago. > >So please opine on the following statement: > >The binding revocation feature specified in I-D >draft-muhanna-mip6-binding-revocation-01.txt is essential for MIP6 >deployments and hence should be made a MIP6 WG document and progressed as a >standards track doc. > >Yes [ ] >No [ ] > >-Raj > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Aug 27 21:13:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPpe7-0002hp-0o; Mon, 27 Aug 2007 21:13:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPpe6-0002hk-Gr for mip6@ietf.org; Mon, 27 Aug 2007 21:13:30 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPpe5-0003A6-2j for mip6@ietf.org; Mon, 27 Aug 2007 21:13:30 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7S1DQF2018051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Aug 2007 18:13:27 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7S1DQwo030890; Mon, 27 Aug 2007 18:13:26 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Aug 2007 18:13:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call: Adopting I-D Date: Mon, 27 Aug 2007 18:13:27 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Consensus call: Adopting I-D Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1Arg References: From: "Narayanan, Vidya" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" X-OriginalArrivalTime: 28 Aug 2007 01:13:26.0451 (UTC) FILETIME=[A2DD5030:01C7E910] X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org A meta question concerning this draft - how does it fit into the current MIP6 or proposed MEXT charter?=20 Thanks, Vidya=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Thursday, August 23, 2007 10:16 AM > To: Mobile IPv6 Mailing List > Cc: Gopal Dommety > Subject: [Mip6] Consensus call: Adopting I-D >=20 >=20 > Hello, >=20 > This is a consensus call for adopting I-D: Binding Revocation=20 > for IPv6 Mobility=20 > as a MIP6 WG document. >=20 > The I-D has been discussed on the ML in the past and was also=20 > presented at > IETF69 in Chicago. >=20 > So please opine on the following statement: >=20 > The binding revocation feature specified in I-D=20 > draft-muhanna-mip6-binding-revocation-01.txt is essential for=20 > MIP6 deployments and hence should be made a MIP6 WG document=20 > and progressed as a standards track doc. >=20 > Yes [ ] > No [ ] >=20 > -Raj >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Aug 28 12:25:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ3sy-000818-Ip; Tue, 28 Aug 2007 12:25:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ3sx-000810-7z for mip6@ietf.org; Tue, 28 Aug 2007 12:25:47 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ3sv-0007Su-LX for mip6@ietf.org; Tue, 28 Aug 2007 12:25:47 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7SGPcDf000525; Tue, 28 Aug 2007 19:25:42 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 19:25:19 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 11:24:57 -0500 Received: from 172.19.244.133 ([172.19.244.133]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 28 Aug 2007 16:24:57 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 28 Aug 2007 11:25:15 -0500 Subject: Re: [Mip6] Consensus call: Adopting I-D From: Basavaraj Patil To: "ext Narayanan, Vidya" , Mobile IPv6 Mailing List , Jonne Soininen Message-ID: Thread-Topic: [Mip6] Consensus call: Adopting I-D Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRg= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Aug 2007 16:24:57.0743 (UTC) FILETIME=[F96A31F0:01C7E98F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vidya, In the context of the MIP6 charter: " The primary goal of the MIP6 working group will be to enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments. " Binding revocation is a feature that is required from deployments perspective and hence it fits into the current charter. Since MEXT is essentially a consolidation of multiple MIP6 related WGs, I believe this work item would be a carryover from MIP6 to MEXT. Having said that, I do however have some questions about this document scope that is related to Netlmm. This I-D is specifying a binding revocation mechanism that is applicable to MIP6 and PMIP6. The consensus call is in the MIP6 WG. I think that given the PMIP6 aspects included in this I-D, it would make sense to consult with you and Jonne (Netlmm chairs) about opinions on this I-D. The MIP6 WG charter and scope is focused on extensions to the MIP6 protocol (RFC3775) and issues related to base MIP6. From a charter and scope perspective, this I-D oversteps the boundaries of MIP6 and is treading in Netlmm waters. It is possible that the feature which addresses MIP6 and PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm). But I want to make sure that Netlmm is aware of it and supports it as well. If the binding revocation feature were to be done only as a MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would have to be removed and any enhancements needed to make binding revocation work in the case of PMIP6 would have to be done in Netlmm. -Raj On 8/27/07 8:13 PM, "ext Narayanan, Vidya" wrote: > A meta question concerning this draft - how does it fit into the current > MIP6 or proposed MEXT charter? > > Thanks, > Vidya > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Thursday, August 23, 2007 10:16 AM >> To: Mobile IPv6 Mailing List >> Cc: Gopal Dommety >> Subject: [Mip6] Consensus call: Adopting I-D >> >> >> Hello, >> >> This is a consensus call for adopting I-D: Binding Revocation >> for IPv6 Mobility >> as a MIP6 WG document. >> >> The I-D has been discussed on the ML in the past and was also >> presented at >> IETF69 in Chicago. >> >> So please opine on the following statement: >> >> The binding revocation feature specified in I-D >> draft-muhanna-mip6-binding-revocation-01.txt is essential for >> MIP6 deployments and hence should be made a MIP6 WG document >> and progressed as a standards track doc. >> >> Yes [ ] >> No [ ] >> >> -Raj >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Aug 28 15:15:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ6XK-0007Ca-Tw; Tue, 28 Aug 2007 15:15:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ6XF-00074g-T0; Tue, 28 Aug 2007 15:15:33 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ6XE-0005Gr-8J; Tue, 28 Aug 2007 15:15:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 229483289A; Tue, 28 Aug 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQ6Wk-0006vw-0s; Tue, 28 Aug 2007 15:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 28 Aug 2007 15:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-hiopt-06.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : DHCP Option for Home Information Discovery in MIPv6 Author(s) : H. Jang, et al. Filename : draft-ietf-mip6-hiopt-06.txt Pages : 23 Date : 2007-8-28 This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined which allow a mobile node to request the home agent IP address, FQDN, or home subnet prefix and obtain it via the DHCP response. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-hiopt-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-hiopt-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-8-28145516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-hiopt-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-hiopt-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-28145516.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Tue Aug 28 15:49:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ73i-00075R-Kk; Tue, 28 Aug 2007 15:49:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ73h-00075I-Rp for mip6@ietf.org; Tue, 28 Aug 2007 15:49:05 -0400 Received: from web84106.mail.mud.yahoo.com ([68.142.206.193]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IQ73h-0005ZR-5O for mip6@ietf.org; Tue, 28 Aug 2007 15:49:05 -0400 Received: (qmail 91087 invoked by uid 60001); 28 Aug 2007 19:49:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=YPcmITrYZJTMrJalQpeJhf56LfROdp7BrQF6D9fR+g0ygWImAUYGbhZsn8fy5GgXNPp7FNsWmL7jSkpIK4u0RGkrVd+fjj/4aaZ2nso3b1H5vGn923OeoCwF1rtI7sLMALeniW7EWgKp9iVKXb2MqYi8KRz70zkYhY5o3j0KfBY=; X-YMail-OSG: 8pCY4Q4VM1lXt254cg9a65GUy2Y4_EuVDpRWEEbqwr1hD7O5P_DLuJC1CVUE07xzqZqzMw-- Received: from [206.16.17.212] by web84106.mail.mud.yahoo.com via HTTP; Tue, 28 Aug 2007 12:49:04 PDT X-Mailer: YahooMailRC/651.48 YahooMailWebService/0.7.119 Date: Tue, 28 Aug 2007 12:49:04 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [Mip6] Consensus call: Adopting I-D To: Basavaraj Patil , "ext Narayanan, Vidya" , Mobile IPv6 Mailing List , Jonne Soininen MIME-Version: 1.0 Message-ID: <613032.90779.qm@web84106.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0248049819==" Errors-To: mip6-bounces@ietf.org --===============0248049819== Content-Type: multipart/alternative; boundary="0-883393852-1188330544=:90779" --0-883393852-1188330544=:90779 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable see inline.=0A=0ABehcet=0A=0A----- Original Message ----=0AFrom: Basavaraj = Patil =0ATo: "ext Narayanan, Vidya" ; Mobile IPv6 Mailing List ; Jonne Soininen =0ACc: Gopal Dommety =0ASent: Tuesday, A= ugust 28, 2007 11:25:15 AM=0ASubject: Re: [Mip6] Consensus call: Adopting I= -D=0A=0A=0AHi Vidya,=0A=0AIn the context of the MIP6 charter:=0A"=0AThe pri= mary goal of the MIP6 working group will be to enhance base=0AIPv6 mobility= by continuing work on developments that are required for=0Awide-scale depl= oyments.=0A"=0A=0ABinding revocation is a feature that is required from dep= loyments=0Aperspective and hence it fits into the current charter.=0A=0ASin= ce MEXT is essentially a consolidation of multiple MIP6 related WGs, I=0Abe= lieve this work item would be a carryover from MIP6 to MEXT.=0A=0AHaving sa= id that, I do however have some questions about this document scope=0Athat = is related to Netlmm.=0A=0AThis I-D is specifying a binding revocation mech= anism that is applicable to=0AMIP6 and PMIP6. The consensus call is in the = MIP6 WG. I think that given the=0APMIP6 aspects included in this I-D, it wo= uld make sense to consult with you=0Aand Jonne (Netlmm chairs) about opinio= ns on this I-D.=0A=0AThe MIP6 WG charter and scope is focused on extensions= to the MIP6 protocol=0A(RFC3775) and issues related to base MIP6. From a c= harter and scope=0Aperspective, this I-D oversteps the boundaries of MIP6 a= nd is treading in=0ANetlmm waters. =0AIt is possible that the feature which= addresses MIP6 and PMIP6 can be done=0Aas a joint WG item (MIP6/MEXT and N= etlmm). But I want to make sure that=0ANetlmm is aware of it and supports i= t as well.=0A=0AIf the binding revocation feature were to be done only as a= MIP6 WG=0AI-D/feature, the PMIP6 aspects in this I-D would have to be remo= ved and any=0Aenhancements needed to make binding revocation work in the ca= se of PMIP6=0Awould have to be done in Netlmm.=0A=0A[behcet] IMHO this woul= d be the right course of action.=0A=0A=0A-Raj=0A =0A=0A=0A=0A=0A=0A=0A=0A --0-883393852-1188330544=:90779 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
see inline.

Behcet

----- Origina= l Message ----
From: Basavaraj Patil <basavaraj.patil@nsn.com>
= To: "ext Narayanan, Vidya" <vidyan@qualcomm.com>; Mobile IPv6 Mailing= List <mip6@ietf.org>; Jonne Soininen <jonne.soininen@nsn.com><= br>Cc: Gopal Dommety <gdommety@cisco.com>
Sent: Tuesday, August 28= , 2007 11:25:15 AM
Subject: Re: [Mip6] Consensus call: Adopting I-D
<= br>

Hi Vidya,

In the context of the MIP6 charter:
"
Th= e primary goal of the MIP6 working group will be to enhance base
IPv6 mo= bility by continuing work on developments that are required for
wide-scale deployments.
"

Binding revocation is a feature= that is required from deployments
perspective and hence it fits into th= e current charter.

Since MEXT is essentially a consolidation of mult= iple MIP6 related WGs, I
believe this work item would be a carryover fro= m MIP6 to MEXT.

Having said that, I do however have some questions a= bout this document scope
that is related to Netlmm.

This I-D is s= pecifying a binding revocation mechanism that is applicable to
MIP6 and = PMIP6. The consensus call is in the MIP6 WG. I think that given the
PMIP= 6 aspects included in this I-D, it would make sense to consult with you
= and Jonne (Netlmm chairs) about opinions on this I-D.

The MIP6 WG ch= arter and scope is focused on extensions to the MIP6 protocol
(RFC3775) = and issues related to base MIP6. From a charter and scope
perspective, t= his I-D oversteps the boundaries of MIP6 and is treading in
Netlmm waters.
It is possible that the feature which addresses M= IP6 and PMIP6 can be done
as a joint WG item (MIP6/MEXT and Netlmm). But= I want to make sure that
Netlmm is aware of it and supports it as well.=

If the binding revocation feature were to be done only as a MIP6 WG=
I-D/feature, the PMIP6 aspects in this I-D would have to be removed and= any
enhancements needed to make binding revocation work in the case of = PMIP6
would have to be done in Netlmm.

[behcet] = IMHO this would be the right course of action.


-Raj
<= br>



--0-883393852-1188330544=:90779-- --===============0248049819== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0248049819==-- From mip6-bounces@ietf.org Tue Aug 28 17:23:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ8Wp-00067Z-TO; Tue, 28 Aug 2007 17:23:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ8Wn-00067U-MJ for mip6@ietf.org; Tue, 28 Aug 2007 17:23:13 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ8Wn-000118-0E for mip6@ietf.org; Tue, 28 Aug 2007 17:23:13 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7SLN2523158; Tue, 28 Aug 2007 21:23:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call: Adopting I-D Date: Tue, 28 Aug 2007 16:22:19 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371166B83F1@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Consensus call: Adopting I-D Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgACTzG8A== References: From: "Ahmad Muhanna" To: "Basavaraj Patil" , "ext Narayanan, Vidya" , "Mobile IPv6 Mailing List" , "Jonne Soininen" X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: Gopal Dommety , Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, I agree; the scope of the work extends to Mobile IPv6 and Proxy Mobile IPv6. As we stated in our presentation in Chicago meeting, the semantics and the messaging we are defining for supporting Binding Revocation should address the requirements of both MIP6 and Netlmm WG's. It is exactly the same as how the work of DS-MIP6 is being leveraged by NETLMM and NEMO WG's.=20 IMHO, Revocation should fall in the same category. That is the reason=20 why we titled the draft Binding Revocation for IPv6 mobility:-) The purpose of the messages, the formats and the actions can all be captured in a common document. Defining multiple documents for this simple messaging is not a good idea, I hope we as a group will=20 take the best decision on this, especially, as I just said that there is already a precedent in the case of DS-MIPv6 draft. We will be happy to work with the NETLMM chairs and the AD to get this=20 adopted as a joint WG document. Best Regards, Ahmad =20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Tuesday, August 28, 2007 12:25 PM > To: ext Narayanan, Vidya; Mobile IPv6 Mailing List; Jonne Soininen > Cc: Gopal Dommety > Subject: Re: [Mip6] Consensus call: Adopting I-D >=20 >=20 > Hi Vidya, >=20 > In the context of the MIP6 charter: > " > The primary goal of the MIP6 working group will be to enhance base > IPv6 mobility by continuing work on developments that are=20 > required for wide-scale deployments. > " >=20 > Binding revocation is a feature that is required from=20 > deployments perspective and hence it fits into the current charter. >=20 > Since MEXT is essentially a consolidation of multiple MIP6=20 > related WGs, I believe this work item would be a carryover=20 > from MIP6 to MEXT. >=20 > Having said that, I do however have some questions about this=20 > document scope that is related to Netlmm. >=20 > This I-D is specifying a binding revocation mechanism that is=20 > applicable to > MIP6 and PMIP6. The consensus call is in the MIP6 WG. I think=20 > that given the > PMIP6 aspects included in this I-D, it would make sense to=20 > consult with you and Jonne (Netlmm chairs) about opinions on this I-D. >=20 > The MIP6 WG charter and scope is focused on extensions to the=20 > MIP6 protocol > (RFC3775) and issues related to base MIP6. From a charter and=20 > scope perspective, this I-D oversteps the boundaries of MIP6=20 > and is treading in Netlmm waters.=20 > It is possible that the feature which addresses MIP6 and=20 > PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm).=20 > But I want to make sure that Netlmm is aware of it and=20 > supports it as well. >=20 > If the binding revocation feature were to be done only as a=20 > MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would have=20 > to be removed and any enhancements needed to make binding=20 > revocation work in the case of PMIP6 would have to be done in Netlmm. >=20 > -Raj > =20 >=20 >=20 > On 8/27/07 8:13 PM, "ext Narayanan, Vidya"=20 > wrote: >=20 > > A meta question concerning this draft - how does it fit into the=20 > > current > > MIP6 or proposed MEXT charter? > >=20 > > Thanks, > > Vidya > >=20 > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >> Sent: Thursday, August 23, 2007 10:16 AM > >> To: Mobile IPv6 Mailing List > >> Cc: Gopal Dommety > >> Subject: [Mip6] Consensus call: Adopting I-D > >>=20 > >>=20 > >> Hello, > >>=20 > >> This is a consensus call for adopting I-D: Binding Revocation for=20 > >> IPv6 Mobility as a=20 > >> MIP6 WG document. > >>=20 > >> The I-D has been discussed on the ML in the past and was also=20 > >> presented at > >> IETF69 in Chicago. > >>=20 > >> So please opine on the following statement: > >>=20 > >> The binding revocation feature specified in I-D=20 > >> draft-muhanna-mip6-binding-revocation-01.txt is essential for > >> MIP6 deployments and hence should be made a MIP6 WG document and=20 > >> progressed as a standards track doc. > >>=20 > >> Yes [ ] > >> No [ ] > >>=20 > >> -Raj > >>=20 > >>=20 > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Aug 28 20:43:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQBe7-0000K1-8H; Tue, 28 Aug 2007 20:42:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQBe6-0000GD-C4 for mip6@ietf.org; Tue, 28 Aug 2007 20:42:58 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQBe5-0005e2-Jg for mip6@ietf.org; Tue, 28 Aug 2007 20:42:58 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7T0gtkW011141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Aug 2007 17:42:56 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7T0gtc6006369; Tue, 28 Aug 2007 17:42:55 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Aug 2007 17:42:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) Date: Tue, 28 Aug 2007 17:42:42 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgAES6mwA== References: From: "Narayanan, Vidya" To: "Basavaraj Patil" , "Mobile IPv6 Mailing List" , "Jonne Soininen" X-OriginalArrivalTime: 29 Aug 2007 00:42:54.0779 (UTC) FILETIME=[898418B0:01C7E9D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Raj, all, I'd like to understand the need for revocation in MIP6 better. I think we've had a discussion on how to do revocation, but, not so much on why we would need it for MIP6. Please note that this is not a discussion on PMIPv6 - I'm trying to specifically understand this in the context of MIP6.=20 A revocation mechanism was developed for MIP4 to allow a clean up of resources at the mobility agents (FA/HA). The philosphy of revocation applies to managed networks and in such networks, a AAA disconnect message (or equivalent) is likely to first cut off any network access to the MNs before even MIP6 has a chance to revocate anything - so, I'm not sure I understand why we need revocation. Note that the non-MIP6 mechanism is needed regardless so that network access can be revoked for nodes not using MIP6 as well. =20 I've seen a number of people support adoption of this draft - so, perhaps there is a good reason for it that I'm just not seeing. I'd appreciate a clarification.=20 Thanks, Viday > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Tuesday, August 28, 2007 9:25 AM > To: Narayanan, Vidya; Mobile IPv6 Mailing List; Jonne Soininen > Cc: Gopal Dommety > Subject: Re: [Mip6] Consensus call: Adopting I-D >=20 >=20 > Hi Vidya, >=20 > In the context of the MIP6 charter: > " > The primary goal of the MIP6 working group will be to enhance base > IPv6 mobility by continuing work on developments that are=20 > required for wide-scale deployments. > " >=20 > Binding revocation is a feature that is required from=20 > deployments perspective and hence it fits into the current charter. >=20 > Since MEXT is essentially a consolidation of multiple MIP6=20 > related WGs, I believe this work item would be a carryover=20 > from MIP6 to MEXT. >=20 > Having said that, I do however have some questions about this=20 > document scope that is related to Netlmm. >=20 > This I-D is specifying a binding revocation mechanism that is=20 > applicable to > MIP6 and PMIP6. The consensus call is in the MIP6 WG. I think=20 > that given the > PMIP6 aspects included in this I-D, it would make sense to=20 > consult with you and Jonne (Netlmm chairs) about opinions on this I-D. >=20 > The MIP6 WG charter and scope is focused on extensions to the=20 > MIP6 protocol > (RFC3775) and issues related to base MIP6. From a charter and=20 > scope perspective, this I-D oversteps the boundaries of MIP6=20 > and is treading in Netlmm waters.=20 > It is possible that the feature which addresses MIP6 and=20 > PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm).=20 > But I want to make sure that Netlmm is aware of it and=20 > supports it as well. >=20 > If the binding revocation feature were to be done only as a=20 > MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would have=20 > to be removed and any enhancements needed to make binding=20 > revocation work in the case of PMIP6 would have to be done in Netlmm. >=20 > -Raj > =20 >=20 >=20 > On 8/27/07 8:13 PM, "ext Narayanan, Vidya"=20 > wrote: >=20 > > A meta question concerning this draft - how does it fit into the=20 > > current > > MIP6 or proposed MEXT charter? > >=20 > > Thanks, > > Vidya > >=20 > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >> Sent: Thursday, August 23, 2007 10:16 AM > >> To: Mobile IPv6 Mailing List > >> Cc: Gopal Dommety > >> Subject: [Mip6] Consensus call: Adopting I-D > >>=20 > >>=20 > >> Hello, > >>=20 > >> This is a consensus call for adopting I-D: Binding Revocation for=20 > >> IPv6 Mobility as a=20 > >> MIP6 WG document. > >>=20 > >> The I-D has been discussed on the ML in the past and was also=20 > >> presented at > >> IETF69 in Chicago. > >>=20 > >> So please opine on the following statement: > >>=20 > >> The binding revocation feature specified in I-D=20 > >> draft-muhanna-mip6-binding-revocation-01.txt is essential for > >> MIP6 deployments and hence should be made a MIP6 WG document and=20 > >> progressed as a standards track doc. > >>=20 > >> Yes [ ] > >> No [ ] > >>=20 > >> -Raj > >>=20 > >>=20 > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Aug 28 23:55:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQEeL-0000H0-9d; Tue, 28 Aug 2007 23:55:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQEeK-0000Gv-5X for mip6@ietf.org; Tue, 28 Aug 2007 23:55:24 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQEeI-0002yi-UD for mip6@ietf.org; Tue, 28 Aug 2007 23:55:24 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7T3qIv06576; Wed, 29 Aug 2007 03:52:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) Date: Tue, 28 Aug 2007 22:52:13 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371166B8800@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgAES6mwAAGAyOQ References: From: "Ahmad Muhanna" To: "Narayanan, Vidya" , "Basavaraj Patil" , "Mobile IPv6 Mailing List" , "Jonne Soininen" X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vidya, Thanks Vidya for the question. I actually was planning to check with you and Jonnie on this topic but I had been very busy here at 3GPP2 meeting and I had to go out to eat:-( I believe that we, earlier, had quite good amount of discussion on this topic, however, I must admit it was mixed with revocation applicability to PMIPv6 too. Now, let me try to address your MIPv6 specific question. There is one scenario when the HA would like to revoke the MN session, for example: administrative reasons. As you said, Disconnect message could be sent to the HA for that purpose. Now: I, at least, think of two options here: Option 1. The HA deletes the binding cache entry and forget about the mobile node and the HA starts dropping the MN packets/traffic, I would call this "a bad customer service and a bad example that operators would like to avoid such a non-graceful revocation mechanism" Option 2. As soon as the HA receives the Disconnect message, for example, the HA sends a revocation message and informs the MN that its binding has been revoked with the proper code which should indicate the reason behind revoking the MN binding. In that case, MN probably can delete its binding with other CN or, at least, gives the MN a chance to start a simple IP session, for example, etc. Now since you mentioned MIPv4 Revocation, I would like to mention that long time ago, early 2002, there has been a lot of discussion during RFC3543 development which was translated into allowing the MN to clearly indicate if it (the MN) needs to be informed when its session is revoked or NOT. There is an "I" bit in the revocation extension. That is similar to the case in MIPv6. Not only that, but RFC3543, Registration Revocation in Mobile IPv4, also addresses MIPv4 registration in the case of Co-CoA sessions. This is exactly the same as in MIPv6. Having said the above, I believe that revocation mechanism is needed in multiple scenarios which were presented in Chicago meeting as follows: 1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg) 2. Revoking a PMIPv6 session. (PMIPv6 - Netlmm wg) 3. Revoking a specific Care-of-Address for a multiple care-of-addresses sessions (Monami6 wg) The common thing for all of these scenarios is that all of them use an extension of MIPv6 protocol. Since one simple mechanism can address all of these scenarios, then one draft would be the best choice. As I said earlier there is already a precedent at IETF with DS-MIPv6. IMHO, it does make a lot of sense to address all of these scenarios which happen to extend across several wgs in a single draft using one simple and generic mechanism. Finally, in fairness to all the fine people who thus far supported this draft as MIP6 wg document, I believe their support was based on the applicability of this draft to MIPv6 and PMIPv6 and I am sure some of them also have Monami6 applicability in mind. Best Regards, Ahmad =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Tuesday, August 28, 2007 8:43 PM > To: Basavaraj Patil; Mobile IPv6 Mailing List; Jonne Soininen > Cc: Gopal Dommety > Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus=20 > call: Adopting I-D) >=20 > Raj, all, > I'd like to understand the need for revocation in MIP6=20 > better. I think we've had a discussion on how to do=20 > revocation, but, not so much on why we would need it for=20 > MIP6. Please note that this is not a discussion on > PMIPv6 - I'm trying to specifically understand this in the=20 > context of MIP6.=20 >=20 > A revocation mechanism was developed for MIP4 to allow a=20 > clean up of resources at the mobility agents (FA/HA). The=20 > philosphy of revocation applies to managed networks and in=20 > such networks, a AAA disconnect message (or equivalent) is=20 > likely to first cut off any network access to the MNs before=20 > even MIP6 has a chance to revocate anything - so, I'm not=20 > sure I understand why we need revocation. Note that the=20 > non-MIP6 mechanism is needed regardless so that network=20 > access can be revoked for nodes not using MIP6 as well. =20 >=20 > I've seen a number of people support adoption of this draft -=20 > so, perhaps there is a good reason for it that I'm just not=20 > seeing. I'd appreciate a clarification.=20 >=20 > Thanks, > Viday >=20 > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > Sent: Tuesday, August 28, 2007 9:25 AM > > To: Narayanan, Vidya; Mobile IPv6 Mailing List; Jonne Soininen > > Cc: Gopal Dommety > > Subject: Re: [Mip6] Consensus call: Adopting I-D > >=20 > >=20 > > Hi Vidya, > >=20 > > In the context of the MIP6 charter: > > " > > The primary goal of the MIP6 working group will be to enhance base > > IPv6 mobility by continuing work on developments that are=20 > required for=20 > > wide-scale deployments. > > " > >=20 > > Binding revocation is a feature that is required from deployments=20 > > perspective and hence it fits into the current charter. > >=20 > > Since MEXT is essentially a consolidation of multiple MIP6 related=20 > > WGs, I believe this work item would be a carryover from=20 > MIP6 to MEXT. > >=20 > > Having said that, I do however have some questions about=20 > this document=20 > > scope that is related to Netlmm. > >=20 > > This I-D is specifying a binding revocation mechanism that is=20 > > applicable to > > MIP6 and PMIP6. The consensus call is in the MIP6 WG. I think that=20 > > given the > > PMIP6 aspects included in this I-D, it would make sense to consult=20 > > with you and Jonne (Netlmm chairs) about opinions on this I-D. > >=20 > > The MIP6 WG charter and scope is focused on extensions to the > > MIP6 protocol > > (RFC3775) and issues related to base MIP6. From a charter and scope=20 > > perspective, this I-D oversteps the boundaries of MIP6 and=20 > is treading=20 > > in Netlmm waters. > > It is possible that the feature which addresses MIP6 and > > PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm).=20 > > But I want to make sure that Netlmm is aware of it and=20 > supports it as=20 > > well. > >=20 > > If the binding revocation feature were to be done only as a > > MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would have to be=20 > > removed and any enhancements needed to make binding=20 > revocation work in=20 > > the case of PMIP6 would have to be done in Netlmm. > >=20 > > -Raj > > =20 > >=20 > >=20 > > On 8/27/07 8:13 PM, "ext Narayanan, Vidya"=20 > > wrote: > >=20 > > > A meta question concerning this draft - how does it fit into the=20 > > > current > > > MIP6 or proposed MEXT charter? > > >=20 > > > Thanks, > > > Vidya > > >=20 > > >> -----Original Message----- > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >> Sent: Thursday, August 23, 2007 10:16 AM > > >> To: Mobile IPv6 Mailing List > > >> Cc: Gopal Dommety > > >> Subject: [Mip6] Consensus call: Adopting I-D > > >>=20 > > >>=20 > > >> Hello, > > >>=20 > > >> This is a consensus call for adopting I-D: Binding Revocation for > > >> IPv6 Mobility as a > > >> MIP6 WG document. > > >>=20 > > >> The I-D has been discussed on the ML in the past and was also=20 > > >> presented at > > >> IETF69 in Chicago. > > >>=20 > > >> So please opine on the following statement: > > >>=20 > > >> The binding revocation feature specified in I-D=20 > > >> draft-muhanna-mip6-binding-revocation-01.txt is essential for > > >> MIP6 deployments and hence should be made a MIP6 WG document and=20 > > >> progressed as a standards track doc. > > >>=20 > > >> Yes [ ] > > >> No [ ] > > >>=20 > > >> -Raj > > >>=20 > > >>=20 > > >> _______________________________________________ > > >> Mip6 mailing list > > >> Mip6@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/mip6 > > >>=20 > >=20 > >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 01:54:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQGVB-0002bf-5J; Wed, 29 Aug 2007 01:54:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQGVA-0002as-F8 for mip6@ietf.org; Wed, 29 Aug 2007 01:54:04 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQGV9-0005SP-Aw for mip6@ietf.org; Wed, 29 Aug 2007 01:54:04 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7T5s0gr009227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Aug 2007 22:54:01 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7T5s077002960; Tue, 28 Aug 2007 22:54:00 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Aug 2007 22:54:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) Date: Tue, 28 Aug 2007 22:53:55 -0700 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371166B8800@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgAES6mwAAGAyOQAAS76tA= References: <6FC4416DDE56C44DA0AEE67BC7CA4371166B8800@zrc2hxm2.corp.nortel.com> From: "Narayanan, Vidya" To: "Ahmad Muhanna" , "Basavaraj Patil" , "Mobile IPv6 Mailing List" , "Jonne Soininen" X-OriginalArrivalTime: 29 Aug 2007 05:54:00.0002 (UTC) FILETIME=[FEDB1A20:01C7EA00] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ahmad, The point I was making is that the AAA disconnect messages are sent to the NAS, not the HA - that causes network access being terminated for the MN. The MN won't even get the MIP6 revocation message once network access is revoked. =20 I realize that the MIP4 revocation is also supported in the spec for MNs in CCoA mode - but, I'm not aware of any real world use of that. =20 Regards, Vidya=20 > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 > Sent: Tuesday, August 28, 2007 8:52 PM > To: Narayanan, Vidya; Basavaraj Patil; Mobile IPv6 Mailing=20 > List; Jonne Soininen > Cc: Gopal Dommety > Subject: RE: Need for revocation in MIP6 (RE: [Mip6]=20 > Consensus call: Adopting I-D) >=20 > Hi Vidya, >=20 > Thanks Vidya for the question. I actually was planning to=20 > check with you and Jonnie on this topic but I had been very=20 > busy here at 3GPP2 meeting and I had to go out to eat:-( >=20 > I believe that we, earlier, had quite good amount of=20 > discussion on this topic, however, I must admit it was mixed=20 > with revocation applicability to PMIPv6 too. >=20 > Now, let me try to address your MIPv6 specific question.=20 > There is one scenario when the HA would like to revoke the MN=20 > session, for example: > administrative reasons. As you said, Disconnect message could=20 > be sent to the HA for that purpose. Now: I, at least, think=20 > of two options here: >=20 > Option 1. The HA deletes the binding cache entry and forget=20 > about the mobile node and the HA starts dropping the MN=20 > packets/traffic, I would call this "a bad customer service=20 > and a bad example that operators would like to avoid such a=20 > non-graceful revocation mechanism" >=20 > Option 2. As soon as the HA receives the Disconnect message,=20 > for example, the HA sends a revocation message and informs=20 > the MN that its binding has been revoked with the proper code=20 > which should indicate the reason behind revoking the MN=20 > binding. In that case, MN probably can delete its binding=20 > with other CN or, at least, gives the MN a chance to start a=20 > simple IP session, for example, etc. >=20 > Now since you mentioned MIPv4 Revocation, I would like to=20 > mention that long time ago, early 2002, there has been a lot=20 > of discussion during > RFC3543 development which was translated into allowing the MN=20 > to clearly indicate if it (the MN) needs to be informed when=20 > its session is revoked or NOT. There is an "I" bit in the=20 > revocation extension. That is similar to the case in MIPv6.=20 > Not only that, but RFC3543, Registration Revocation in Mobile=20 > IPv4, also addresses MIPv4 registration in the case of Co-CoA=20 > sessions. This is exactly the same as in MIPv6. >=20 > Having said the above, I believe that revocation mechanism is=20 > needed in multiple scenarios which were presented in Chicago=20 > meeting as follows: >=20 > 1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg) 2. Revoking a=20 > PMIPv6 session. (PMIPv6 - Netlmm wg) 3. Revoking a specific=20 > Care-of-Address for a multiple care-of-addresses sessions (Monami6 wg) >=20 > The common thing for all of these scenarios is that all of=20 > them use an extension of MIPv6 protocol. Since one simple=20 > mechanism can address all of these scenarios, then one draft=20 > would be the best choice. As I said earlier there is already=20 > a precedent at IETF with DS-MIPv6. IMHO, it does make a lot=20 > of sense to address all of these scenarios which happen to=20 > extend across several wgs in a single draft using one simple=20 > and generic mechanism. >=20 > Finally, in fairness to all the fine people who thus far=20 > supported this draft as MIP6 wg document, I believe their=20 > support was based on the applicability of this draft to MIPv6=20 > and PMIPv6 and I am sure some of them also have Monami6=20 > applicability in mind. >=20 >=20 > Best Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Tuesday, August 28, 2007 8:43 PM > > To: Basavaraj Patil; Mobile IPv6 Mailing List; Jonne Soininen > > Cc: Gopal Dommety > > Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus > > call: Adopting I-D) > >=20 > > Raj, all, > > I'd like to understand the need for revocation in MIP6 better. I=20 > > think we've had a discussion on how to do revocation, but,=20 > not so much=20 > > on why we would need it for MIP6. Please note that this is not a=20 > > discussion on > > PMIPv6 - I'm trying to specifically understand this in the=20 > context of=20 > > MIP6. > >=20 > > A revocation mechanism was developed for MIP4 to allow a=20 > clean up of=20 > > resources at the mobility agents (FA/HA). The philosphy of=20 > revocation=20 > > applies to managed networks and in such networks, a AAA disconnect=20 > > message (or equivalent) is likely to first cut off any=20 > network access=20 > > to the MNs before even MIP6 has a chance to revocate anything - so,=20 > > I'm not sure I understand why we need revocation. Note that the > > non-MIP6 mechanism is needed regardless so that network=20 > access can be=20 > > revoked for nodes not using MIP6 as well. > >=20 > > I've seen a number of people support adoption of this draft - so,=20 > > perhaps there is a good reason for it that I'm just not=20 > seeing. I'd=20 > > appreciate a clarification. > >=20 > > Thanks, > > Viday > >=20 > > > -----Original Message----- > > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > Sent: Tuesday, August 28, 2007 9:25 AM > > > To: Narayanan, Vidya; Mobile IPv6 Mailing List; Jonne Soininen > > > Cc: Gopal Dommety > > > Subject: Re: [Mip6] Consensus call: Adopting I-D > > >=20 > > >=20 > > > Hi Vidya, > > >=20 > > > In the context of the MIP6 charter: > > > " > > > The primary goal of the MIP6 working group will be to enhance base > > > IPv6 mobility by continuing work on developments that are > > required for > > > wide-scale deployments. > > > " > > >=20 > > > Binding revocation is a feature that is required from deployments=20 > > > perspective and hence it fits into the current charter. > > >=20 > > > Since MEXT is essentially a consolidation of multiple=20 > MIP6 related=20 > > > WGs, I believe this work item would be a carryover from > > MIP6 to MEXT. > > >=20 > > > Having said that, I do however have some questions about > > this document > > > scope that is related to Netlmm. > > >=20 > > > This I-D is specifying a binding revocation mechanism that is=20 > > > applicable to > > > MIP6 and PMIP6. The consensus call is in the MIP6 WG. I=20 > think that=20 > > > given the > > > PMIP6 aspects included in this I-D, it would make sense=20 > to consult=20 > > > with you and Jonne (Netlmm chairs) about opinions on this I-D. > > >=20 > > > The MIP6 WG charter and scope is focused on extensions to the > > > MIP6 protocol > > > (RFC3775) and issues related to base MIP6. From a charter=20 > and scope=20 > > > perspective, this I-D oversteps the boundaries of MIP6 and > > is treading > > > in Netlmm waters. > > > It is possible that the feature which addresses MIP6 and > > > PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm).=20 > > > But I want to make sure that Netlmm is aware of it and > > supports it as > > > well. > > >=20 > > > If the binding revocation feature were to be done only as a > > > MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would=20 > have to be=20 > > > removed and any enhancements needed to make binding > > revocation work in > > > the case of PMIP6 would have to be done in Netlmm. > > >=20 > > > -Raj > > > =20 > > >=20 > > >=20 > > > On 8/27/07 8:13 PM, "ext Narayanan, Vidya"=20 > > > wrote: > > >=20 > > > > A meta question concerning this draft - how does it fit=20 > into the=20 > > > > current > > > > MIP6 or proposed MEXT charter? > > > >=20 > > > > Thanks, > > > > Vidya > > > >=20 > > > >> -----Original Message----- > > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > >> Sent: Thursday, August 23, 2007 10:16 AM > > > >> To: Mobile IPv6 Mailing List > > > >> Cc: Gopal Dommety > > > >> Subject: [Mip6] Consensus call: Adopting I-D > > > >>=20 > > > >>=20 > > > >> Hello, > > > >>=20 > > > >> This is a consensus call for adopting I-D: Binding=20 > Revocation for > > > >> IPv6 Mobility=20 > as a > > > >> MIP6 WG document. > > > >>=20 > > > >> The I-D has been discussed on the ML in the past and was also=20 > > > >> presented at > > > >> IETF69 in Chicago. > > > >>=20 > > > >> So please opine on the following statement: > > > >>=20 > > > >> The binding revocation feature specified in I-D=20 > > > >> draft-muhanna-mip6-binding-revocation-01.txt is essential for > > > >> MIP6 deployments and hence should be made a MIP6 WG=20 > document and=20 > > > >> progressed as a standards track doc. > > > >>=20 > > > >> Yes [ ] > > > >> No [ ] > > > >>=20 > > > >> -Raj > > > >>=20 > > > >>=20 > > > >> _______________________________________________ > > > >> Mip6 mailing list > > > >> Mip6@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/mip6 > > > >>=20 > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 02:01:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQGci-0002Ye-IZ; Wed, 29 Aug 2007 02:01:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQGch-0002YX-9a for mip6@ietf.org; Wed, 29 Aug 2007 02:01:51 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQGcf-0005h0-KN for mip6@ietf.org; Wed, 29 Aug 2007 02:01:51 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 08:01:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG LC: I-D draft-ietf-mip6-rfc4285bis-00.txt Date: Wed, 29 Aug 2007 08:01:47 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED30222C950@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG LC: I-D draft-ietf-mip6-rfc4285bis-00.txt Thread-Index: AcfjZ2/KrjJQxE9aEdySLAARJNUNiAGWK8Ew References: From: To: , X-OriginalArrivalTime: 29 Aug 2007 06:01:47.0770 (UTC) FILETIME=[15AAD5A0:01C7EA02] X-Spam-Score: -4.0 (----) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: kleung@cisco.com, haseebak@nortel.com, alpesh@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, I read the rfc4285bis and have minor comments on it. I have editorials and other comments mixed up.. sorry about that. Anyway, my conclusion is that the I-D needs some more work to be OK.. Quick references to not so editorial issues are in o section 3.1 about SPIs o section 5.1 about key length and auth algorithm ----- Abstract >IPsec is specified as the means of securing signaling messages >between the Mobile Node and Home agent for Mobile IPv6 (MIPv6). o .,$s/Home agent/Home Agent/g There are many places to do the same change throughout the=20 document. So no more further mentions of this. o s/Mobile IPv6 (MIPv6)\./Mobile IPv6\. >MIPv6 signalling messages that are secured include the Binding o s/MIPv6/Mobile IPv6 >Updates and Acknowledgement messages used for managing the bindings >between a Mobile Node and its Home Agent. This document proposes an >alternate method for securing MIPv6 signaling messages between a o s/MIPv6/Mobile IPv6 >Mobile Nodes and Home Agents. The alternate method defined here >conists of a MIPv6-specific authentication option that can be added o s/conist/consists o s/MIPv6/Mobile IPv6 >to MIPv6 signalling messages. o s/MIPv6/Mobile IPv6 1. Introduction >The base Mobile IPv6 specification [RFC3775] specifies the signaling o s/Mobile IPv6/Mobile IPv6 (MIPv6) >between the Mobile Node and Home agent to be secured by the IPsec o s/Mobile Node/Mobile Node (MN) o s/Home agent/Home Agent (HA) >Acknowldegement messages (between MN-HA) are secured with the o MN-HA? what about "between MN and HA" ? 1.1. Applicability Statement >network operator. In cdma network deployments this information can o .,$s/cdma/CDMA o Expand CDMA on the first use >- Network deployments in which not all mobile nodes and home agents o .,$s/mobile node/Mobile Node/g there are same change many times throughout the documents so it is mentioned only here. >have IKEv2 implementations and support for the integration of IKEv2 o Reference to IKEv2.. and maybe expand on the first use. >commercial deployments on a large scale. At the time of this writing >[IKEv2-REF] is yet to be published as an RFC. Hence from a practical >perspective that operators face, IKEv2 is not yet capable of >addressing the immediate need for MIP6 deployment. o The above statement is not really true anymore -- ref RFC4306 and I would also reference to RFC4877 >between the mobile node and the authentication server (AAA Home) is o what about changing "AAA Home" to "home AAA server" ? >mechanisms to renew the security association (between MN and AAA >Home) when needed. o Same about the AAA than above. Or then define it as AAAH already in this paragraph >signaling messages sent over such interfaces. MIP6 signaling which o s/MIP6/MIPv6 or just use Mobile IPv6 Whatever is used it should ne consistent throughout the document. Now MIP6, MIPv6 and Mobile IPv6 are used in a nice mixture >an authentication option carried in the BU/BAck messages. o s/Back/BA 2. Overview >guarantee such protection (for instance, like in 3gpp2 networks), o s/3gpp2/3GPP2 Section 3.1 o Mobility SPI -- can this be different from MN to HA and from HA to MN? It is not stated/defined anywhere.. From the current text one gets the impression that the SPI is the same on both directions o The reserved SPI range should be described here as well o Expand SPI here on the first use. Section 4. =20 >(BU) and Binding Acknowledgement (BA) messages are used in the o BU & BA are already defined.. o Figure 1 -- MN-ID is not defined nor used anywhere else in the document. Why not replacing it with MN-NAI as it is what the figure is trying to say.. >security associations). to index between multiple mobility security >associations. o Remove the "to index between multiple mobility security associations." 5. Mobility message authentication option >If both MN-HA and MN-AAA authentication options are present, MN-HA o Expand MN-HA and MN-AAA on the first use. >the Sub-type, mobility Security Parameter Index (SPI) and >Authentication Data fields. o s/mobility Security Parameter Index (SPI)/mobility SPI 5.1. MN-HA authentication mobility option >[0-4294967296], where the range [0-255] is reserved. The key o rather "shared-key" than just "key"? >consists of an arbitrary value and is 20 octets in length. The >authentication algorithm is HMAC_SHA1. The replay protection o MN-HA option has Mobility SPI, so why the key length and the used algorithm are hardcoded here? Should those be selected & defined based on the SPI rather than hardcoding them here? >mechanism may use the Sequence number as specified in [RFC3775] or o s/Sequence/sequence ? >the option as defined in Section 6. If the Timestamp option is used o s/option/Timestamp option >This MUST be the last option in a message with mobility header if it o s/This/The MN-HA authentication option >Authentication Data =3D First (96, HMAC_SHA1(MN-HA Shared key, = Mobility >Data)) o The same what was stated above.. Why not use SPI to select key lengths and algorithms? >The first 96 bits from the MAC result are used as the Authentication >Data field. o This is stated already earlier. o Rather define Mobility Header(MH) as message data starting from the mobility header upto and including the Mobility SPI value of the Mobility message authentication option 5.2. MN-AAA authentication mobility option >corresponding response MUST include the Mobile-Home Authentication >option, and MUST NOT include the Mobile-AAA Authentication option. o s/Mobile-Home Authentication/MN-HA authentication o s/Mobile-AAA Authenticatio/MN-AAA authentication >MAC_Mobility Data =3D SHA1(care-of address | home address | MH Data) o Earlier MH Data was expressed as Mobility Header(MH) >mobility SPI field of this option. o s/this/the Mobility message authentication 5.3. Authentication Failure Detection at the Mobile Node >there is no shared-key based mobility security association, HA drops o s/drops/MUST silently discard 6. Mobility message replay protection option >after the binding entry has been removed. The Home Agent does the =20 o s/binding/binding cache Section 10: o [MN_Ident] -> RFC4283 o [IKEv2-REF] -> RFC4306 o [whyauth] -> -04.txt Cheers, Jouni > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Monday, August 20, 2007 11:20 PM > To: Mobile IPv6 Mailing List > Cc: alpesh@cisco.com; Kent Leung (kleung); haseebak@nortel.com > Subject: [Mip6] WG LC: I-D draft-ietf-mip6-rfc4285bis-00.txt >=20 >=20 >=20 > Hello, >=20 > This is a WG last call for the I-D: Authentication Protocol for Mobile > IPv6 >=20 > This I-D revises RFC4285 and corrects the key-length issue=20 > which has been discussed in the past. >=20 > Please send your comments by Sept 5th, 07 to the mailing list=20 > or the authors.=20 >=20 > -Raj >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 04:04:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQIX3-0006Lw-LA; Wed, 29 Aug 2007 04:04:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQIX3-0006Lq-4K for mip6@ietf.org; Wed, 29 Aug 2007 04:04:09 -0400 Received: from cluster-e.mailcontrol.com ([217.79.216.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQIX2-0000aI-E3 for mip6@ietf.org; Wed, 29 Aug 2007 04:04:09 -0400 Received: from rly22e.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly22e.srv.mailcontrol.com (MailControl) with ESMTP id l7T83qss007615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Aug 2007 09:04:02 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly22e.srv.mailcontrol.com (MailControl) id l7T83Qts006187 for mip6@ietf.org; Wed, 29 Aug 2007 09:03:26 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly22e-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l7T83O5M005981; Wed, 29 Aug 2007 09:03:26 +0100 (BST) Received: from eundadmi01.pan.eu(10.109.33.22) by hhe500-02.hbg.de.pan.eu via smtp id 54dd_5c2ceca6_5605_11dc_9b1a_0030482aac25; Wed, 29 Aug 2007 09:56:33 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007082910032060-16702 ; Wed, 29 Aug 2007 10:03:20 +0200 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: 0.112,BAYES_00: -1.665,TOTAL_SCORE: -1.553 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 29 Aug 2007 10:04:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Subject: RE: [Mip6] I-D ACTION:draft-ietf-mip6-hiopt-06.txt In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] I-D ACTION:draft-ietf-mip6-hiopt-06.txt Thread-Index: Acfpp/QUVLsvgehkT0K69e0IiHX0OQAaFTdg References: To: Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB48A27C@lan-ex-02.panasonic.de> Date: Wed, 29 Aug 2007 10:03:04 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-07-08-00 (www.mailcontrol.com) on 10.69.1.132 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hee Jin Jang, I have a question about this draft: Does this draft require the mobile node to send a DHCP Information Request with Home Network Identifier Option just after network authentication is completed? Or may the mobile node send the DHCP Information Request to obtain home network information at any time after network authentication?=20 For instance, the mobile node may want to bootstrap MIPv6 only when it starts an application that requires session continuity, which may be long after network authentication has been completed.=20 I think this should be clarified in the draft. Regards, Kilian =20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Dienstag, 28. August 2007 21:15 > To: i-d-announce@ietf.org > Cc: mip6@ietf.org > Subject: [Mip6] I-D ACTION:draft-ietf-mip6-hiopt-06.txt=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Mobility for IPv6 Working=20 > Group of the IETF. >=20 > Title : DHCP Option for Home Information=20 > Discovery in MIPv6 > Author(s) : H. Jang, et al. > Filename : draft-ietf-mip6-hiopt-06.txt > Pages : 23 > Date : 2007-8-28 > =09 > This draft defines a DHCP-based scheme to enable dynamic discovery of > Mobile IPv6 home network information. New DHCP options are defined > which allow a mobile node to request the home agent IP=20 > address, FQDN, > or home subnet prefix and obtain it via the DHCP response. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-06.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > the message.=20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-mip6-hiopt-06.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mip6-hiopt-06.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 05:31:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQJtf-0004fW-0m; Wed, 29 Aug 2007 05:31:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQJtc-0004fQ-PK for mip6@ietf.org; Wed, 29 Aug 2007 05:31:32 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQJtb-0001Sn-Ax for mip6@ietf.org; Wed, 29 Aug 2007 05:31:32 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D751619865B; Wed, 29 Aug 2007 12:31:29 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5D8F4198639; Wed, 29 Aug 2007 12:31:28 +0300 (EEST) Message-ID: <46D53CF0.80702@piuha.net> Date: Wed, 29 Aug 2007 12:31:28 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Mobile IPv6 Mailing List , Vijay Devarapalli Subject: [Mip6] Re: Request to progress I-Ds: 1. draft-ietf-mip6-experimental-messages-01.txt AND 2. draft-ietf-mip6-vsm-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I have made my AD review on the mip6-experimental-messages specification, and found no issues. Last Call has been initiated for this. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 05:39:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQK1G-0004Go-Tz; Wed, 29 Aug 2007 05:39:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQK1F-0004DX-6Q for mip6@ietf.org; Wed, 29 Aug 2007 05:39:25 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQK1D-0001av-Vu for mip6@ietf.org; Wed, 29 Aug 2007 05:39:25 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2B98919865F; Wed, 29 Aug 2007 12:39:23 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C991B19865B; Wed, 29 Aug 2007 12:39:22 +0300 (EEST) Message-ID: <46D53ECA.4080206@piuha.net> Date: Wed, 29 Aug 2007 12:39:22 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Mobile IPv6 Mailing List , draft-ietf-mip6-vsm@tools.ietf.org Subject: [Mip6] Re: Request to progress I-Ds: 1. draft-ietf-mip6-experimental-messages-01.txt AND 2. draft-ietf-mip6-vsm-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I have made my AD review on the mip6-vsm specification, and found no issues. Last Call has been initiated for this. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 07:05:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQLMs-00029I-N3; Wed, 29 Aug 2007 07:05:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQLMq-000288-Cb for mip6@ietf.org; Wed, 29 Aug 2007 07:05:48 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQLMp-0004oW-3S for mip6@ietf.org; Wed, 29 Aug 2007 07:05:48 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7TB5Tv14558; Wed, 29 Aug 2007 11:05:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) Date: Wed, 29 Aug 2007 06:05:23 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371166FD922@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgAES6mwAAGAyOQAAS76tAACpN4cA== References: <6FC4416DDE56C44DA0AEE67BC7CA4371166B8800@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Narayanan, Vidya" , "Basavaraj Patil" , "Mobile IPv6 Mailing List" , "Jonne Soininen" X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Cc: Gopal Dommety , Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vidya, Ok. I did not realize that you meant sending Disconnect message to the NAS. I assume that Disconnect message is originated from the H-AAA and in that case it makes a lot of sense to be sent to the HA which keeps a record of the MN binding and can communicate the revocation to the MN via a revocation message. In case that H-AAA sends the Disconnect to the NAS ONLY, then this revocation style would fit option 1 discussed earlier:-( On the question of real world deployment, I do not claim that I have a record of all deployments out there, but I, very well, remember that including the option of notifying the MN with FA-CoA and the support of Co-CoA mode were based on a long discussion and requests from vendors and operators which, IMO, is still valid and is very well reflected by the interest of the people who already have supported the adoption of this draft thus far. Regards, Ahmad =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Wednesday, August 29, 2007 1:54 AM > To: Muhanna, Ahmad (RICH1:2H10); Basavaraj Patil; Mobile IPv6=20 > Mailing List; Jonne Soininen > Cc: Gopal Dommety > Subject: RE: Need for revocation in MIP6 (RE: [Mip6]=20 > Consensus call: Adopting I-D) >=20 > Hi Ahmad, > The point I was making is that the AAA disconnect messages=20 > are sent to the NAS, not the HA - that causes network access=20 > being terminated for the MN. The MN won't even get the MIP6=20 > revocation message once network access is revoked. =20 >=20 > I realize that the MIP4 revocation is also supported in the=20 > spec for MNs in CCoA mode - but, I'm not aware of any real=20 > world use of that. =20 >=20 > Regards, > Vidya=20 >=20 > > -----Original Message----- > > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > Sent: Tuesday, August 28, 2007 8:52 PM > > To: Narayanan, Vidya; Basavaraj Patil; Mobile IPv6 Mailing=20 > List; Jonne=20 > > Soininen > > Cc: Gopal Dommety > > Subject: RE: Need for revocation in MIP6 (RE: [Mip6]=20 > Consensus call:=20 > > Adopting I-D) > >=20 > > Hi Vidya, > >=20 > > Thanks Vidya for the question. I actually was planning to=20 > check with=20 > > you and Jonnie on this topic but I had been very busy here at 3GPP2=20 > > meeting and I had to go out to eat:-( > >=20 > > I believe that we, earlier, had quite good amount of discussion on=20 > > this topic, however, I must admit it was mixed with revocation=20 > > applicability to PMIPv6 too. > >=20 > > Now, let me try to address your MIPv6 specific question.=20 > > There is one scenario when the HA would like to revoke the=20 > MN session,=20 > > for example: > > administrative reasons. As you said, Disconnect message=20 > could be sent=20 > > to the HA for that purpose. Now: I, at least, think of two options=20 > > here: > >=20 > > Option 1. The HA deletes the binding cache entry and forget=20 > about the=20 > > mobile node and the HA starts dropping the MN=20 > packets/traffic, I would=20 > > call this "a bad customer service and a bad example that operators=20 > > would like to avoid such a non-graceful revocation mechanism" > >=20 > > Option 2. As soon as the HA receives the Disconnect message, for=20 > > example, the HA sends a revocation message and informs the=20 > MN that its=20 > > binding has been revoked with the proper code which should indicate=20 > > the reason behind revoking the MN binding. In that case, MN=20 > probably=20 > > can delete its binding with other CN or, at least, gives the MN a=20 > > chance to start a simple IP session, for example, etc. > >=20 > > Now since you mentioned MIPv4 Revocation, I would like to=20 > mention that=20 > > long time ago, early 2002, there has been a lot of discussion during > > RFC3543 development which was translated into allowing the MN to=20 > > clearly indicate if it (the MN) needs to be informed when=20 > its session=20 > > is revoked or NOT. There is an "I" bit in the revocation extension.=20 > > That is similar to the case in MIPv6. > > Not only that, but RFC3543, Registration Revocation in Mobile IPv4,=20 > > also addresses MIPv4 registration in the case of Co-CoA=20 > sessions. This=20 > > is exactly the same as in MIPv6. > >=20 > > Having said the above, I believe that revocation mechanism=20 > is needed=20 > > in multiple scenarios which were presented in Chicago meeting as=20 > > follows: > >=20 > > 1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg) 2. Revoking a > > PMIPv6 session. (PMIPv6 - Netlmm wg) 3. Revoking a specific=20 > > Care-of-Address for a multiple care-of-addresses sessions=20 > (Monami6 wg) > >=20 > > The common thing for all of these scenarios is that all of=20 > them use an=20 > > extension of MIPv6 protocol. Since one simple mechanism can address=20 > > all of these scenarios, then one draft would be the best=20 > choice. As I=20 > > said earlier there is already a precedent at IETF with=20 > DS-MIPv6. IMHO,=20 > > it does make a lot of sense to address all of these scenarios which=20 > > happen to extend across several wgs in a single draft using=20 > one simple=20 > > and generic mechanism. > >=20 > > Finally, in fairness to all the fine people who thus far supported=20 > > this draft as MIP6 wg document, I believe their support was=20 > based on=20 > > the applicability of this draft to MIPv6 and PMIPv6 and I=20 > am sure some=20 > > of them also have Monami6 applicability in mind. > >=20 > >=20 > > Best Regards, > > Ahmad > > =20 > >=20 > > > -----Original Message----- > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > Sent: Tuesday, August 28, 2007 8:43 PM > > > To: Basavaraj Patil; Mobile IPv6 Mailing List; Jonne Soininen > > > Cc: Gopal Dommety > > > Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus > > > call: Adopting I-D) > > >=20 > > > Raj, all, > > > I'd like to understand the need for revocation in MIP6 better. I=20 > > > think we've had a discussion on how to do revocation, but,=20 > > not so much=20 > > > on why we would need it for MIP6. Please note that this is not a=20 > > > discussion on > > > PMIPv6 - I'm trying to specifically understand this in the=20 > > context of=20 > > > MIP6. > > >=20 > > > A revocation mechanism was developed for MIP4 to allow a=20 > > clean up of=20 > > > resources at the mobility agents (FA/HA). The philosphy of=20 > > revocation=20 > > > applies to managed networks and in such networks, a AAA=20 > disconnect=20 > > > message (or equivalent) is likely to first cut off any=20 > > network access=20 > > > to the MNs before even MIP6 has a chance to revocate=20 > anything - so,=20 > > > I'm not sure I understand why we need revocation. Note that the > > > non-MIP6 mechanism is needed regardless so that network=20 > > access can be=20 > > > revoked for nodes not using MIP6 as well. > > >=20 > > > I've seen a number of people support adoption of this draft - so,=20 > > > perhaps there is a good reason for it that I'm just not=20 > > seeing. I'd=20 > > > appreciate a clarification. > > >=20 > > > Thanks, > > > Viday > > >=20 > > > > -----Original Message----- > > > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > Sent: Tuesday, August 28, 2007 9:25 AM > > > > To: Narayanan, Vidya; Mobile IPv6 Mailing List; Jonne Soininen > > > > Cc: Gopal Dommety > > > > Subject: Re: [Mip6] Consensus call: Adopting I-D > > > >=20 > > > >=20 > > > > Hi Vidya, > > > >=20 > > > > In the context of the MIP6 charter: > > > > " > > > > The primary goal of the MIP6 working group will be to=20 > enhance base > > > > IPv6 mobility by continuing work on developments that are > > > required for > > > > wide-scale deployments. > > > > " > > > >=20 > > > > Binding revocation is a feature that is required from=20 > deployments=20 > > > > perspective and hence it fits into the current charter. > > > >=20 > > > > Since MEXT is essentially a consolidation of multiple=20 > > MIP6 related=20 > > > > WGs, I believe this work item would be a carryover from > > > MIP6 to MEXT. > > > >=20 > > > > Having said that, I do however have some questions about > > > this document > > > > scope that is related to Netlmm. > > > >=20 > > > > This I-D is specifying a binding revocation mechanism that is=20 > > > > applicable to > > > > MIP6 and PMIP6. The consensus call is in the MIP6 WG. I=20 > > think that=20 > > > > given the > > > > PMIP6 aspects included in this I-D, it would make sense=20 > > to consult=20 > > > > with you and Jonne (Netlmm chairs) about opinions on this I-D. > > > >=20 > > > > The MIP6 WG charter and scope is focused on extensions to the > > > > MIP6 protocol > > > > (RFC3775) and issues related to base MIP6. From a charter=20 > > and scope=20 > > > > perspective, this I-D oversteps the boundaries of MIP6 and > > > is treading > > > > in Netlmm waters. > > > > It is possible that the feature which addresses MIP6 and > > > > PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm).=20 > > > > But I want to make sure that Netlmm is aware of it and > > > supports it as > > > > well. > > > >=20 > > > > If the binding revocation feature were to be done only as a > > > > MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would=20 > > have to be=20 > > > > removed and any enhancements needed to make binding > > > revocation work in > > > > the case of PMIP6 would have to be done in Netlmm. > > > >=20 > > > > -Raj > > > > =20 > > > >=20 > > > >=20 > > > > On 8/27/07 8:13 PM, "ext Narayanan, Vidya"=20 > > > > wrote: > > > >=20 > > > > > A meta question concerning this draft - how does it fit=20 > > into the=20 > > > > > current > > > > > MIP6 or proposed MEXT charter? > > > > >=20 > > > > > Thanks, > > > > > Vidya > > > > >=20 > > > > >> -----Original Message----- > > > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > >> Sent: Thursday, August 23, 2007 10:16 AM > > > > >> To: Mobile IPv6 Mailing List > > > > >> Cc: Gopal Dommety > > > > >> Subject: [Mip6] Consensus call: Adopting I-D > > > > >>=20 > > > > >>=20 > > > > >> Hello, > > > > >>=20 > > > > >> This is a consensus call for adopting I-D: Binding=20 > > Revocation for > > > > >> IPv6 Mobility=20 > > as a > > > > >> MIP6 WG document. > > > > >>=20 > > > > >> The I-D has been discussed on the ML in the past and=20 > was also=20 > > > > >> presented at > > > > >> IETF69 in Chicago. > > > > >>=20 > > > > >> So please opine on the following statement: > > > > >>=20 > > > > >> The binding revocation feature specified in I-D=20 > > > > >> draft-muhanna-mip6-binding-revocation-01.txt is essential for > > > > >> MIP6 deployments and hence should be made a MIP6 WG=20 > > document and=20 > > > > >> progressed as a standards track doc. > > > > >>=20 > > > > >> Yes [ ] > > > > >> No [ ] > > > > >>=20 > > > > >> -Raj > > > > >>=20 > > > > >>=20 > > > > >> _______________________________________________ > > > > >> Mip6 mailing list > > > > >> Mip6@ietf.org > > > > >> https://www1.ietf.org/mailman/listinfo/mip6 > > > > >>=20 > > > >=20 > > > >=20 > > >=20 > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > >=20 > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 11:38:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQPcG-00055o-Ii; Wed, 29 Aug 2007 11:38:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQPcC-00055N-MR; Wed, 29 Aug 2007 11:37:56 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQPcC-0005b8-EK; Wed, 29 Aug 2007 11:37:56 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 1E499175A4; Wed, 29 Aug 2007 15:37:26 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQPbh-0001bb-Kz; Wed, 29 Aug 2007 11:37:25 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 29 Aug 2007 11:37:25 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip6@ietf.org Subject: [Mip6] Last Call: draft-ietf-mip6-experimental-messages (Mobile IPv6 Experimental Messages) to Proposed Standard X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The IESG has received a request from the Mobility for IPv6 WG (mip6) to consider the following document: - 'Mobile IPv6 Experimental Messages ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-09-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mip6-experimental-messages-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15546&rfc_flag=0 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 11:39:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQPdH-0006W9-NH; Wed, 29 Aug 2007 11:39:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQPdE-0006Ry-D3; Wed, 29 Aug 2007 11:39:00 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQPdE-0003za-55; Wed, 29 Aug 2007 11:39:00 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 0C7A326E65; Wed, 29 Aug 2007 15:39:00 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQPdD-0001dj-UD; Wed, 29 Aug 2007 11:38:59 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 29 Aug 2007 11:38:59 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip6@ietf.org Subject: [Mip6] Last Call: draft-ietf-mip6-ha-switch (Mobility Header Home Agent Switch Message) to Proposed Standard X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The IESG has received a request from the Mobility for IPv6 WG (mip6) to consider the following document: - 'Mobility Header Home Agent Switch Message ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-09-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mip6-ha-switch-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14786&rfc_flag=0 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 11:39:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQPdx-0006xp-Qd; Wed, 29 Aug 2007 11:39:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQPdu-0006sY-Fb; Wed, 29 Aug 2007 11:39:42 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQPdt-00041d-Bk; Wed, 29 Aug 2007 11:39:42 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 518D93289D; Wed, 29 Aug 2007 15:39:41 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQPdt-0001fV-7l; Wed, 29 Aug 2007 11:39:41 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 29 Aug 2007 11:39:41 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip6@ietf.org Subject: [Mip6] Last Call: draft-ietf-mip6-vsm (Mobile IPv6 Vendor Specific Option) to Proposed Standard X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The IESG has received a request from the Mobility for IPv6 WG (mip6) to consider the following document: - 'Mobile IPv6 Vendor Specific Option ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-09-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mip6-vsm-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15547&rfc_flag=0 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 12:21:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQQIk-0002LD-O7; Wed, 29 Aug 2007 12:21:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQQIj-0002L5-JQ for mip6@ietf.org; Wed, 29 Aug 2007 12:21:53 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQQIi-0007lZ-O0 for mip6@ietf.org; Wed, 29 Aug 2007 12:21:53 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7TGLVYe014850; Wed, 29 Aug 2007 19:21:48 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 19:21:15 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 11:21:12 -0500 Received: from 172.19.244.133 ([172.19.244.133]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 29 Aug 2007 16:21:12 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 29 Aug 2007 11:21:31 -0500 Subject: Re: [Mip6] Consensus call: Adopting I-D From: Basavaraj Patil To: ext Ahmad Muhanna , "ext Narayanan, Vidya" , Mobile IPv6 Mailing List , Jonne Soininen Message-ID: Thread-Topic: [Mip6] Consensus call: Adopting I-D Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgACTzG8AAo7HTb In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371166B83F1@zrc2hxm2.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Aug 2007 16:21:12.0102 (UTC) FILETIME=[9D55DC60:01C7EA58] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: Gopal Dommety , Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Ahmad, DS-MIP6 is not really a precedent. Work on DS-MIP6 has been ongoing for quite a while now (couple of years at least). The DS-MIP6 I-D has been developed as a solution for MIP6 and the design considerations in the document precede any PMIP6 discussion in the IETF. DS-MIP6 is a joint MIP6/NEMO WGs effort. If the binding revocation mechanism for MIP6 and PMIP6 were to be specified in a single I-D, it would have to be a joint WG item (MIP6/Netlmm). Else, scope of I-D will need to change. -Raj On 8/28/07 4:22 PM, "ext Ahmad Muhanna" wrote: > Hi Raj, > > I agree; the scope of the work extends to Mobile IPv6 and Proxy > Mobile IPv6. As we stated in our presentation in Chicago meeting, > the semantics and the messaging we are defining for supporting > Binding Revocation should address the requirements of both MIP6 and > Netlmm WG's. > It is exactly the same as how the work of DS-MIP6 is being leveraged by > NETLMM and > NEMO WG's. > > IMHO, Revocation should fall in the same category. That is the reason > why we titled the draft Binding Revocation for IPv6 mobility:-) The > purpose of the messages, the formats and the actions can all be > captured in a common document. Defining multiple documents for > this simple messaging is not a good idea, I hope we as a group will > take the best decision on this, especially, as I just said that there is > already > a precedent in the case of DS-MIPv6 draft. > > We will be happy to work with the NETLMM chairs and the AD to get this > adopted as a joint WG document. > > Best Regards, > Ahmad > > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Tuesday, August 28, 2007 12:25 PM >> To: ext Narayanan, Vidya; Mobile IPv6 Mailing List; Jonne Soininen >> Cc: Gopal Dommety >> Subject: Re: [Mip6] Consensus call: Adopting I-D >> >> >> Hi Vidya, >> >> In the context of the MIP6 charter: >> " >> The primary goal of the MIP6 working group will be to enhance base >> IPv6 mobility by continuing work on developments that are >> required for wide-scale deployments. >> " >> >> Binding revocation is a feature that is required from >> deployments perspective and hence it fits into the current charter. >> >> Since MEXT is essentially a consolidation of multiple MIP6 >> related WGs, I believe this work item would be a carryover >> from MIP6 to MEXT. >> >> Having said that, I do however have some questions about this >> document scope that is related to Netlmm. >> >> This I-D is specifying a binding revocation mechanism that is >> applicable to >> MIP6 and PMIP6. The consensus call is in the MIP6 WG. I think >> that given the >> PMIP6 aspects included in this I-D, it would make sense to >> consult with you and Jonne (Netlmm chairs) about opinions on this I-D. >> >> The MIP6 WG charter and scope is focused on extensions to the >> MIP6 protocol >> (RFC3775) and issues related to base MIP6. From a charter and >> scope perspective, this I-D oversteps the boundaries of MIP6 >> and is treading in Netlmm waters. >> It is possible that the feature which addresses MIP6 and >> PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm). >> But I want to make sure that Netlmm is aware of it and >> supports it as well. >> >> If the binding revocation feature were to be done only as a >> MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would have >> to be removed and any enhancements needed to make binding >> revocation work in the case of PMIP6 would have to be done in Netlmm. >> >> -Raj >> >> >> >> On 8/27/07 8:13 PM, "ext Narayanan, Vidya" >> wrote: >> >>> A meta question concerning this draft - how does it fit into the >>> current >>> MIP6 or proposed MEXT charter? >>> >>> Thanks, >>> Vidya >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>> Sent: Thursday, August 23, 2007 10:16 AM >>>> To: Mobile IPv6 Mailing List >>>> Cc: Gopal Dommety >>>> Subject: [Mip6] Consensus call: Adopting I-D >>>> >>>> >>>> Hello, >>>> >>>> This is a consensus call for adopting I-D: Binding Revocation for >>>> IPv6 Mobility as a >>>> MIP6 WG document. >>>> >>>> The I-D has been discussed on the ML in the past and was also >>>> presented at >>>> IETF69 in Chicago. >>>> >>>> So please opine on the following statement: >>>> >>>> The binding revocation feature specified in I-D >>>> draft-muhanna-mip6-binding-revocation-01.txt is essential for >>>> MIP6 deployments and hence should be made a MIP6 WG document and >>>> progressed as a standards track doc. >>>> >>>> Yes [ ] >>>> No [ ] >>>> >>>> -Raj >>>> >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 12:56:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQQqE-00062q-LX; Wed, 29 Aug 2007 12:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQQqE-00062d-9T for mip6@ietf.org; Wed, 29 Aug 2007 12:56:30 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQQqC-0007Ds-Be for mip6@ietf.org; Wed, 29 Aug 2007 12:56:30 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7TGuMmZ009889; Wed, 29 Aug 2007 19:56:23 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 19:56:12 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 11:55:46 -0500 Received: from 172.19.244.133 ([172.19.244.133]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 29 Aug 2007 16:55:47 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 29 Aug 2007 11:56:05 -0500 Subject: Re: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) From: Basavaraj Patil To: "ext Narayanan, Vidya" , Ahmad Muhanna , Mobile IPv6 Mailing List , Jonne Soininen Message-ID: Thread-Topic: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgAES6mwAAGAyOQAAS76tAAF3CTIQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Aug 2007 16:55:46.0983 (UTC) FILETIME=[720F9370:01C7EA5D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vidya, But the AAA could notify the HA (via the HA-AAA interface for which we are specifying requirements in MIP6) about the Disconnect prior to sending the Disconnect to the NAS. And this would allow a graceful detach from the HA?? -Raj On 8/29/07 12:53 AM, "ext Narayanan, Vidya" wrote: > Hi Ahmad, > The point I was making is that the AAA disconnect messages are sent to > the NAS, not the HA - that causes network access being terminated for > the MN. The MN won't even get the MIP6 revocation message once network > access is revoked. > > I realize that the MIP4 revocation is also supported in the spec for MNs > in CCoA mode - but, I'm not aware of any real world use of that. > > Regards, > Vidya > >> -----Original Message----- >> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] >> Sent: Tuesday, August 28, 2007 8:52 PM >> To: Narayanan, Vidya; Basavaraj Patil; Mobile IPv6 Mailing >> List; Jonne Soininen >> Cc: Gopal Dommety >> Subject: RE: Need for revocation in MIP6 (RE: [Mip6] >> Consensus call: Adopting I-D) >> >> Hi Vidya, >> >> Thanks Vidya for the question. I actually was planning to >> check with you and Jonnie on this topic but I had been very >> busy here at 3GPP2 meeting and I had to go out to eat:-( >> >> I believe that we, earlier, had quite good amount of >> discussion on this topic, however, I must admit it was mixed >> with revocation applicability to PMIPv6 too. >> >> Now, let me try to address your MIPv6 specific question. >> There is one scenario when the HA would like to revoke the MN >> session, for example: >> administrative reasons. As you said, Disconnect message could >> be sent to the HA for that purpose. Now: I, at least, think >> of two options here: >> >> Option 1. The HA deletes the binding cache entry and forget >> about the mobile node and the HA starts dropping the MN >> packets/traffic, I would call this "a bad customer service >> and a bad example that operators would like to avoid such a >> non-graceful revocation mechanism" >> >> Option 2. As soon as the HA receives the Disconnect message, >> for example, the HA sends a revocation message and informs >> the MN that its binding has been revoked with the proper code >> which should indicate the reason behind revoking the MN >> binding. In that case, MN probably can delete its binding >> with other CN or, at least, gives the MN a chance to start a >> simple IP session, for example, etc. >> >> Now since you mentioned MIPv4 Revocation, I would like to >> mention that long time ago, early 2002, there has been a lot >> of discussion during >> RFC3543 development which was translated into allowing the MN >> to clearly indicate if it (the MN) needs to be informed when >> its session is revoked or NOT. There is an "I" bit in the >> revocation extension. That is similar to the case in MIPv6. >> Not only that, but RFC3543, Registration Revocation in Mobile >> IPv4, also addresses MIPv4 registration in the case of Co-CoA >> sessions. This is exactly the same as in MIPv6. >> >> Having said the above, I believe that revocation mechanism is >> needed in multiple scenarios which were presented in Chicago >> meeting as follows: >> >> 1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg) 2. Revoking a >> PMIPv6 session. (PMIPv6 - Netlmm wg) 3. Revoking a specific >> Care-of-Address for a multiple care-of-addresses sessions (Monami6 wg) >> >> The common thing for all of these scenarios is that all of >> them use an extension of MIPv6 protocol. Since one simple >> mechanism can address all of these scenarios, then one draft >> would be the best choice. As I said earlier there is already >> a precedent at IETF with DS-MIPv6. IMHO, it does make a lot >> of sense to address all of these scenarios which happen to >> extend across several wgs in a single draft using one simple >> and generic mechanism. >> >> Finally, in fairness to all the fine people who thus far >> supported this draft as MIP6 wg document, I believe their >> support was based on the applicability of this draft to MIPv6 >> and PMIPv6 and I am sure some of them also have Monami6 >> applicability in mind. >> >> >> Best Regards, >> Ahmad >> >> >>> -----Original Message----- >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>> Sent: Tuesday, August 28, 2007 8:43 PM >>> To: Basavaraj Patil; Mobile IPv6 Mailing List; Jonne Soininen >>> Cc: Gopal Dommety >>> Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus >>> call: Adopting I-D) >>> >>> Raj, all, >>> I'd like to understand the need for revocation in MIP6 better. I >>> think we've had a discussion on how to do revocation, but, >> not so much >>> on why we would need it for MIP6. Please note that this is not a >>> discussion on >>> PMIPv6 - I'm trying to specifically understand this in the >> context of >>> MIP6. >>> >>> A revocation mechanism was developed for MIP4 to allow a >> clean up of >>> resources at the mobility agents (FA/HA). The philosphy of >> revocation >>> applies to managed networks and in such networks, a AAA disconnect >>> message (or equivalent) is likely to first cut off any >> network access >>> to the MNs before even MIP6 has a chance to revocate anything - so, >>> I'm not sure I understand why we need revocation. Note that the >>> non-MIP6 mechanism is needed regardless so that network >> access can be >>> revoked for nodes not using MIP6 as well. >>> >>> I've seen a number of people support adoption of this draft - so, >>> perhaps there is a good reason for it that I'm just not >> seeing. I'd >>> appreciate a clarification. >>> >>> Thanks, >>> Viday >>> >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>> Sent: Tuesday, August 28, 2007 9:25 AM >>>> To: Narayanan, Vidya; Mobile IPv6 Mailing List; Jonne Soininen >>>> Cc: Gopal Dommety >>>> Subject: Re: [Mip6] Consensus call: Adopting I-D >>>> >>>> >>>> Hi Vidya, >>>> >>>> In the context of the MIP6 charter: >>>> " >>>> The primary goal of the MIP6 working group will be to enhance base >>>> IPv6 mobility by continuing work on developments that are >>> required for >>>> wide-scale deployments. >>>> " >>>> >>>> Binding revocation is a feature that is required from deployments >>>> perspective and hence it fits into the current charter. >>>> >>>> Since MEXT is essentially a consolidation of multiple >> MIP6 related >>>> WGs, I believe this work item would be a carryover from >>> MIP6 to MEXT. >>>> >>>> Having said that, I do however have some questions about >>> this document >>>> scope that is related to Netlmm. >>>> >>>> This I-D is specifying a binding revocation mechanism that is >>>> applicable to >>>> MIP6 and PMIP6. The consensus call is in the MIP6 WG. I >> think that >>>> given the >>>> PMIP6 aspects included in this I-D, it would make sense >> to consult >>>> with you and Jonne (Netlmm chairs) about opinions on this I-D. >>>> >>>> The MIP6 WG charter and scope is focused on extensions to the >>>> MIP6 protocol >>>> (RFC3775) and issues related to base MIP6. From a charter >> and scope >>>> perspective, this I-D oversteps the boundaries of MIP6 and >>> is treading >>>> in Netlmm waters. >>>> It is possible that the feature which addresses MIP6 and >>>> PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm). >>>> But I want to make sure that Netlmm is aware of it and >>> supports it as >>>> well. >>>> >>>> If the binding revocation feature were to be done only as a >>>> MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would >> have to be >>>> removed and any enhancements needed to make binding >>> revocation work in >>>> the case of PMIP6 would have to be done in Netlmm. >>>> >>>> -Raj >>>> >>>> >>>> >>>> On 8/27/07 8:13 PM, "ext Narayanan, Vidya" >>>> wrote: >>>> >>>>> A meta question concerning this draft - how does it fit >> into the >>>>> current >>>>> MIP6 or proposed MEXT charter? >>>>> >>>>> Thanks, >>>>> Vidya >>>>> >>>>>> -----Original Message----- >>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>>>> Sent: Thursday, August 23, 2007 10:16 AM >>>>>> To: Mobile IPv6 Mailing List >>>>>> Cc: Gopal Dommety >>>>>> Subject: [Mip6] Consensus call: Adopting I-D >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> This is a consensus call for adopting I-D: Binding >> Revocation for >>>>>> IPv6 Mobility >> as a >>>>>> MIP6 WG document. >>>>>> >>>>>> The I-D has been discussed on the ML in the past and was also >>>>>> presented at >>>>>> IETF69 in Chicago. >>>>>> >>>>>> So please opine on the following statement: >>>>>> >>>>>> The binding revocation feature specified in I-D >>>>>> draft-muhanna-mip6-binding-revocation-01.txt is essential for >>>>>> MIP6 deployments and hence should be made a MIP6 WG >> document and >>>>>> progressed as a standards track doc. >>>>>> >>>>>> Yes [ ] >>>>>> No [ ] >>>>>> >>>>>> -Raj >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mip6 mailing list >>>>>> Mip6@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>>>> >>>> >>>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 13:15:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQR8t-0002Aj-5b; Wed, 29 Aug 2007 13:15:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQR8r-0002AI-Bd for mip6@ietf.org; Wed, 29 Aug 2007 13:15:45 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQR8p-0007fo-NJ for mip6@ietf.org; Wed, 29 Aug 2007 13:15:45 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7THFfUT020545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Aug 2007 10:15:42 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7THFfX9023397; Wed, 29 Aug 2007 10:15:41 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Aug 2007 10:15:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) Date: Wed, 29 Aug 2007 10:15:41 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgAES6mwAAGAyOQAAS76tAAF3CTIQAAh2pg References: From: "Narayanan, Vidya" To: "Basavaraj Patil" , "Ahmad Muhanna" , "Mobile IPv6 Mailing List" , "Jonne Soininen" X-OriginalArrivalTime: 29 Aug 2007 17:15:41.0304 (UTC) FILETIME=[39EE7F80:01C7EA60] X-Spam-Score: -4.0 (----) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, Hmmm.. The AAA could certainly notify the HA. But, a AAA that is interested in revoking access to an MN would contact the NAS first, if not in parallel with the HA. After all, the AAA is getting accounting records from the NAS - note that even if the HA is also physically serving as a AAA aggregation point for accounting (which itself cannot be generalized), it is still a logically separate function that will forward on the AAA disconnect messages all the way to the NAS, resulting in MN's access being revoked.=20 So, the AAA notification to the HA would be good to clean up the HA resources, but, I'm still not seeing a practical need for revocation in MIP6 - the MN has likely had its access revoked before the HA sends the MIP6 revocation out. =20 Vidya > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Wednesday, August 29, 2007 9:56 AM > To: Narayanan, Vidya; Ahmad Muhanna; Mobile IPv6 Mailing=20 > List; Jonne Soininen > Cc: Gopal Dommety > Subject: Re: Need for revocation in MIP6 (RE: [Mip6]=20 > Consensus call: Adopting I-D) >=20 >=20 > Hi Vidya, >=20 > But the AAA could notify the HA (via the HA-AAA interface for=20 > which we are specifying requirements in MIP6) about the=20 > Disconnect prior to sending the Disconnect to the NAS. And=20 > this would allow a graceful detach from the HA?? >=20 > -Raj >=20 >=20 > On 8/29/07 12:53 AM, "ext Narayanan, Vidya"=20 > wrote: >=20 > > Hi Ahmad, > > The point I was making is that the AAA disconnect messages=20 > are sent to=20 > > the NAS, not the HA - that causes network access being=20 > terminated for=20 > > the MN. The MN won't even get the MIP6 revocation message once=20 > > network access is revoked. > >=20 > > I realize that the MIP4 revocation is also supported in the=20 > spec for=20 > > MNs in CCoA mode - but, I'm not aware of any real world use of that. > >=20 > > Regards, > > Vidya > >=20 > >> -----Original Message----- > >> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > >> Sent: Tuesday, August 28, 2007 8:52 PM > >> To: Narayanan, Vidya; Basavaraj Patil; Mobile IPv6 Mailing List;=20 > >> Jonne Soininen > >> Cc: Gopal Dommety > >> Subject: RE: Need for revocation in MIP6 (RE: [Mip6]=20 > Consensus call:=20 > >> Adopting I-D) > >>=20 > >> Hi Vidya, > >>=20 > >> Thanks Vidya for the question. I actually was planning to=20 > check with=20 > >> you and Jonnie on this topic but I had been very busy here=20 > at 3GPP2=20 > >> meeting and I had to go out to eat:-( > >>=20 > >> I believe that we, earlier, had quite good amount of discussion on=20 > >> this topic, however, I must admit it was mixed with revocation=20 > >> applicability to PMIPv6 too. > >>=20 > >> Now, let me try to address your MIPv6 specific question. > >> There is one scenario when the HA would like to revoke the MN=20 > >> session, for example: > >> administrative reasons. As you said, Disconnect message=20 > could be sent=20 > >> to the HA for that purpose. Now: I, at least, think of two options=20 > >> here: > >>=20 > >> Option 1. The HA deletes the binding cache entry and=20 > forget about the=20 > >> mobile node and the HA starts dropping the MN packets/traffic, I=20 > >> would call this "a bad customer service and a bad example that=20 > >> operators would like to avoid such a non-graceful revocation=20 > >> mechanism" > >>=20 > >> Option 2. As soon as the HA receives the Disconnect message, for=20 > >> example, the HA sends a revocation message and informs the MN that=20 > >> its binding has been revoked with the proper code which should=20 > >> indicate the reason behind revoking the MN binding. In=20 > that case, MN=20 > >> probably can delete its binding with other CN or, at=20 > least, gives the=20 > >> MN a chance to start a simple IP session, for example, etc. > >>=20 > >> Now since you mentioned MIPv4 Revocation, I would like to mention=20 > >> that long time ago, early 2002, there has been a lot of discussion=20 > >> during > >> RFC3543 development which was translated into allowing the MN to=20 > >> clearly indicate if it (the MN) needs to be informed when=20 > its session=20 > >> is revoked or NOT. There is an "I" bit in the revocation=20 > extension.=20 > >> That is similar to the case in MIPv6. > >> Not only that, but RFC3543, Registration Revocation in=20 > Mobile IPv4,=20 > >> also addresses MIPv4 registration in the case of Co-CoA sessions.=20 > >> This is exactly the same as in MIPv6. > >>=20 > >> Having said the above, I believe that revocation mechanism=20 > is needed=20 > >> in multiple scenarios which were presented in Chicago meeting as=20 > >> follows: > >>=20 > >> 1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg) 2. Revoking a > >> PMIPv6 session. (PMIPv6 - Netlmm wg) 3. Revoking a specific=20 > >> Care-of-Address for a multiple care-of-addresses sessions (Monami6=20 > >> wg) > >>=20 > >> The common thing for all of these scenarios is that all of=20 > them use=20 > >> an extension of MIPv6 protocol. Since one simple mechanism can=20 > >> address all of these scenarios, then one draft would be the best=20 > >> choice. As I said earlier there is already a precedent at=20 > IETF with=20 > >> DS-MIPv6. IMHO, it does make a lot of sense to address all=20 > of these=20 > >> scenarios which happen to extend across several wgs in a=20 > single draft=20 > >> using one simple and generic mechanism. > >>=20 > >> Finally, in fairness to all the fine people who thus far supported=20 > >> this draft as MIP6 wg document, I believe their support=20 > was based on=20 > >> the applicability of this draft to MIPv6 and PMIPv6 and I am sure=20 > >> some of them also have Monami6 applicability in mind. > >>=20 > >>=20 > >> Best Regards, > >> Ahmad > >> =20 > >>=20 > >>> -----Original Message----- > >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >>> Sent: Tuesday, August 28, 2007 8:43 PM > >>> To: Basavaraj Patil; Mobile IPv6 Mailing List; Jonne Soininen > >>> Cc: Gopal Dommety > >>> Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus > >>> call: Adopting I-D) > >>>=20 > >>> Raj, all, > >>> I'd like to understand the need for revocation in MIP6 better. I=20 > >>> think we've had a discussion on how to do revocation, but, > >> not so much > >>> on why we would need it for MIP6. Please note that this is not a=20 > >>> discussion on > >>> PMIPv6 - I'm trying to specifically understand this in the > >> context of > >>> MIP6. > >>>=20 > >>> A revocation mechanism was developed for MIP4 to allow a > >> clean up of > >>> resources at the mobility agents (FA/HA). The philosphy of > >> revocation > >>> applies to managed networks and in such networks, a AAA=20 > disconnect=20 > >>> message (or equivalent) is likely to first cut off any > >> network access > >>> to the MNs before even MIP6 has a chance to revocate=20 > anything - so,=20 > >>> I'm not sure I understand why we need revocation. Note that the > >>> non-MIP6 mechanism is needed regardless so that network > >> access can be > >>> revoked for nodes not using MIP6 as well. > >>>=20 > >>> I've seen a number of people support adoption of this draft - so,=20 > >>> perhaps there is a good reason for it that I'm just not > >> seeing. I'd > >>> appreciate a clarification. > >>>=20 > >>> Thanks, > >>> Viday > >>>=20 > >>>> -----Original Message----- > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >>>> Sent: Tuesday, August 28, 2007 9:25 AM > >>>> To: Narayanan, Vidya; Mobile IPv6 Mailing List; Jonne Soininen > >>>> Cc: Gopal Dommety > >>>> Subject: Re: [Mip6] Consensus call: Adopting I-D > >>>>=20 > >>>>=20 > >>>> Hi Vidya, > >>>>=20 > >>>> In the context of the MIP6 charter: > >>>> " > >>>> The primary goal of the MIP6 working group will be to=20 > enhance base > >>>> IPv6 mobility by continuing work on developments that are > >>> required for > >>>> wide-scale deployments. > >>>> " > >>>>=20 > >>>> Binding revocation is a feature that is required from=20 > deployments=20 > >>>> perspective and hence it fits into the current charter. > >>>>=20 > >>>> Since MEXT is essentially a consolidation of multiple > >> MIP6 related > >>>> WGs, I believe this work item would be a carryover from > >>> MIP6 to MEXT. > >>>>=20 > >>>> Having said that, I do however have some questions about > >>> this document > >>>> scope that is related to Netlmm. > >>>>=20 > >>>> This I-D is specifying a binding revocation mechanism that is=20 > >>>> applicable to > >>>> MIP6 and PMIP6. The consensus call is in the MIP6 WG. I > >> think that > >>>> given the > >>>> PMIP6 aspects included in this I-D, it would make sense > >> to consult > >>>> with you and Jonne (Netlmm chairs) about opinions on this I-D. > >>>>=20 > >>>> The MIP6 WG charter and scope is focused on extensions to the > >>>> MIP6 protocol > >>>> (RFC3775) and issues related to base MIP6. From a charter > >> and scope > >>>> perspective, this I-D oversteps the boundaries of MIP6 and > >>> is treading > >>>> in Netlmm waters. > >>>> It is possible that the feature which addresses MIP6 and > >>>> PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm). > >>>> But I want to make sure that Netlmm is aware of it and > >>> supports it as > >>>> well. > >>>>=20 > >>>> If the binding revocation feature were to be done only as a > >>>> MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would > >> have to be > >>>> removed and any enhancements needed to make binding > >>> revocation work in > >>>> the case of PMIP6 would have to be done in Netlmm. > >>>>=20 > >>>> -Raj > >>>> =20 > >>>>=20 > >>>>=20 > >>>> On 8/27/07 8:13 PM, "ext Narayanan, Vidya" > >>>> wrote: > >>>>=20 > >>>>> A meta question concerning this draft - how does it fit > >> into the > >>>>> current > >>>>> MIP6 or proposed MEXT charter? > >>>>>=20 > >>>>> Thanks, > >>>>> Vidya > >>>>>=20 > >>>>>> -----Original Message----- > >>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >>>>>> Sent: Thursday, August 23, 2007 10:16 AM > >>>>>> To: Mobile IPv6 Mailing List > >>>>>> Cc: Gopal Dommety > >>>>>> Subject: [Mip6] Consensus call: Adopting I-D > >>>>>>=20 > >>>>>>=20 > >>>>>> Hello, > >>>>>>=20 > >>>>>> This is a consensus call for adopting I-D: Binding > >> Revocation for > >>>>>> IPv6 Mobility > >> as a > >>>>>> MIP6 WG document. > >>>>>>=20 > >>>>>> The I-D has been discussed on the ML in the past and was also=20 > >>>>>> presented at > >>>>>> IETF69 in Chicago. > >>>>>>=20 > >>>>>> So please opine on the following statement: > >>>>>>=20 > >>>>>> The binding revocation feature specified in I-D=20 > >>>>>> draft-muhanna-mip6-binding-revocation-01.txt is essential for > >>>>>> MIP6 deployments and hence should be made a MIP6 WG > >> document and > >>>>>> progressed as a standards track doc. > >>>>>>=20 > >>>>>> Yes [ ] > >>>>>> No [ ] > >>>>>>=20 > >>>>>> -Raj > >>>>>>=20 > >>>>>>=20 > >>>>>> _______________________________________________ > >>>>>> Mip6 mailing list > >>>>>> Mip6@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > >>>>>>=20 > >>>>=20 > >>>>=20 > >>>=20 > >>> _______________________________________________ > >>> Mip6 mailing list > >>> Mip6@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mip6 > >>>=20 > >>=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 13:42:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQRYa-0008Kf-Ty; Wed, 29 Aug 2007 13:42:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQRYZ-0008KB-9N for mip6@ietf.org; Wed, 29 Aug 2007 13:42:19 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQRYX-0002B1-K0 for mip6@ietf.org; Wed, 29 Aug 2007 13:42:19 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7THfo7f014251; Wed, 29 Aug 2007 20:42:13 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 20:42:12 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 12:42:01 -0500 Received: from 172.19.244.133 ([172.19.244.133]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 29 Aug 2007 17:42:00 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 29 Aug 2007 12:42:19 -0500 Subject: Re: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) From: Basavaraj Patil To: "ext Narayanan, Vidya" , Ahmad Muhanna , Mobile IPv6 Mailing List , Jonne Soininen Message-ID: Thread-Topic: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgAES6mwAAGAyOQAAS76tAAF3CTIQAAh2pgAAEV8jg= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Aug 2007 17:42:01.0162 (UTC) FILETIME=[E799B2A0:01C7EA63] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vidya, I agree that if the issue is primarily resource clean up, a notification from the AAA to the HA will deprecate the binding. But if the AAA sends a Disconnect to the NAS, I am not sure if there is a graceful mechanism to indicate to the MN that it is being disconnected. Of course there are many different ways to indicate that the MN has been disconnected from the network and these could also be access technology dependent. However if there is no good way to indicate to the MN that it has been disconnected, the MN would continue to believe that it still has MIP6 binding and subsequently may cause a delay in creating a binding with the HA when the MN does attach (for example via another access type). So I think it would still make sense to indicate to the MN that the HA has revoked the binding. There is of course an issue about synchronizing the AAA Disconnect to the NAS and the indication to the HA to ensure that the MN can be notified of the binding revocation prior to pulling the plug at the NAS. But I think this can be dealt with. -Raj On 8/29/07 12:15 PM, "ext Narayanan, Vidya" wrote: > Hi Raj, > Hmmm.. The AAA could certainly notify the HA. But, a AAA that is > interested in revoking access to an MN would contact the NAS first, if > not in parallel with the HA. After all, the AAA is getting accounting > records from the NAS - note that even if the HA is also physically > serving as a AAA aggregation point for accounting (which itself cannot > be generalized), it is still a logically separate function that will > forward on the AAA disconnect messages all the way to the NAS, resulting > in MN's access being revoked. > > So, the AAA notification to the HA would be good to clean up the HA > resources, but, I'm still not seeing a practical need for revocation in > MIP6 - the MN has likely had its access revoked before the HA sends the > MIP6 revocation out. > > Vidya > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >> Sent: Wednesday, August 29, 2007 9:56 AM >> To: Narayanan, Vidya; Ahmad Muhanna; Mobile IPv6 Mailing >> List; Jonne Soininen >> Cc: Gopal Dommety >> Subject: Re: Need for revocation in MIP6 (RE: [Mip6] >> Consensus call: Adopting I-D) >> >> >> Hi Vidya, >> >> But the AAA could notify the HA (via the HA-AAA interface for >> which we are specifying requirements in MIP6) about the >> Disconnect prior to sending the Disconnect to the NAS. And >> this would allow a graceful detach from the HA?? >> >> -Raj >> >> >> On 8/29/07 12:53 AM, "ext Narayanan, Vidya" >> wrote: >> >>> Hi Ahmad, >>> The point I was making is that the AAA disconnect messages >> are sent to >>> the NAS, not the HA - that causes network access being >> terminated for >>> the MN. The MN won't even get the MIP6 revocation message once >>> network access is revoked. >>> >>> I realize that the MIP4 revocation is also supported in the >> spec for >>> MNs in CCoA mode - but, I'm not aware of any real world use of that. >>> >>> Regards, >>> Vidya >>> >>>> -----Original Message----- >>>> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] >>>> Sent: Tuesday, August 28, 2007 8:52 PM >>>> To: Narayanan, Vidya; Basavaraj Patil; Mobile IPv6 Mailing List; >>>> Jonne Soininen >>>> Cc: Gopal Dommety >>>> Subject: RE: Need for revocation in MIP6 (RE: [Mip6] >> Consensus call: >>>> Adopting I-D) >>>> >>>> Hi Vidya, >>>> >>>> Thanks Vidya for the question. I actually was planning to >> check with >>>> you and Jonnie on this topic but I had been very busy here >> at 3GPP2 >>>> meeting and I had to go out to eat:-( >>>> >>>> I believe that we, earlier, had quite good amount of discussion on >>>> this topic, however, I must admit it was mixed with revocation >>>> applicability to PMIPv6 too. >>>> >>>> Now, let me try to address your MIPv6 specific question. >>>> There is one scenario when the HA would like to revoke the MN >>>> session, for example: >>>> administrative reasons. As you said, Disconnect message >> could be sent >>>> to the HA for that purpose. Now: I, at least, think of two options >>>> here: >>>> >>>> Option 1. The HA deletes the binding cache entry and >> forget about the >>>> mobile node and the HA starts dropping the MN packets/traffic, I >>>> would call this "a bad customer service and a bad example that >>>> operators would like to avoid such a non-graceful revocation >>>> mechanism" >>>> >>>> Option 2. As soon as the HA receives the Disconnect message, for >>>> example, the HA sends a revocation message and informs the MN that >>>> its binding has been revoked with the proper code which should >>>> indicate the reason behind revoking the MN binding. In >> that case, MN >>>> probably can delete its binding with other CN or, at >> least, gives the >>>> MN a chance to start a simple IP session, for example, etc. >>>> >>>> Now since you mentioned MIPv4 Revocation, I would like to mention >>>> that long time ago, early 2002, there has been a lot of discussion >>>> during >>>> RFC3543 development which was translated into allowing the MN to >>>> clearly indicate if it (the MN) needs to be informed when >> its session >>>> is revoked or NOT. There is an "I" bit in the revocation >> extension. >>>> That is similar to the case in MIPv6. >>>> Not only that, but RFC3543, Registration Revocation in >> Mobile IPv4, >>>> also addresses MIPv4 registration in the case of Co-CoA sessions. >>>> This is exactly the same as in MIPv6. >>>> >>>> Having said the above, I believe that revocation mechanism >> is needed >>>> in multiple scenarios which were presented in Chicago meeting as >>>> follows: >>>> >>>> 1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg) 2. Revoking a >>>> PMIPv6 session. (PMIPv6 - Netlmm wg) 3. Revoking a specific >>>> Care-of-Address for a multiple care-of-addresses sessions (Monami6 >>>> wg) >>>> >>>> The common thing for all of these scenarios is that all of >> them use >>>> an extension of MIPv6 protocol. Since one simple mechanism can >>>> address all of these scenarios, then one draft would be the best >>>> choice. As I said earlier there is already a precedent at >> IETF with >>>> DS-MIPv6. IMHO, it does make a lot of sense to address all >> of these >>>> scenarios which happen to extend across several wgs in a >> single draft >>>> using one simple and generic mechanism. >>>> >>>> Finally, in fairness to all the fine people who thus far supported >>>> this draft as MIP6 wg document, I believe their support >> was based on >>>> the applicability of this draft to MIPv6 and PMIPv6 and I am sure >>>> some of them also have Monami6 applicability in mind. >>>> >>>> >>>> Best Regards, >>>> Ahmad >>>> >>>> >>>>> -----Original Message----- >>>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>>>> Sent: Tuesday, August 28, 2007 8:43 PM >>>>> To: Basavaraj Patil; Mobile IPv6 Mailing List; Jonne Soininen >>>>> Cc: Gopal Dommety >>>>> Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus >>>>> call: Adopting I-D) >>>>> >>>>> Raj, all, >>>>> I'd like to understand the need for revocation in MIP6 better. I >>>>> think we've had a discussion on how to do revocation, but, >>>> not so much >>>>> on why we would need it for MIP6. Please note that this is not a >>>>> discussion on >>>>> PMIPv6 - I'm trying to specifically understand this in the >>>> context of >>>>> MIP6. >>>>> >>>>> A revocation mechanism was developed for MIP4 to allow a >>>> clean up of >>>>> resources at the mobility agents (FA/HA). The philosphy of >>>> revocation >>>>> applies to managed networks and in such networks, a AAA >> disconnect >>>>> message (or equivalent) is likely to first cut off any >>>> network access >>>>> to the MNs before even MIP6 has a chance to revocate >> anything - so, >>>>> I'm not sure I understand why we need revocation. Note that the >>>>> non-MIP6 mechanism is needed regardless so that network >>>> access can be >>>>> revoked for nodes not using MIP6 as well. >>>>> >>>>> I've seen a number of people support adoption of this draft - so, >>>>> perhaps there is a good reason for it that I'm just not >>>> seeing. I'd >>>>> appreciate a clarification. >>>>> >>>>> Thanks, >>>>> Viday >>>>> >>>>>> -----Original Message----- >>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>>>> Sent: Tuesday, August 28, 2007 9:25 AM >>>>>> To: Narayanan, Vidya; Mobile IPv6 Mailing List; Jonne Soininen >>>>>> Cc: Gopal Dommety >>>>>> Subject: Re: [Mip6] Consensus call: Adopting I-D >>>>>> >>>>>> >>>>>> Hi Vidya, >>>>>> >>>>>> In the context of the MIP6 charter: >>>>>> " >>>>>> The primary goal of the MIP6 working group will be to >> enhance base >>>>>> IPv6 mobility by continuing work on developments that are >>>>> required for >>>>>> wide-scale deployments. >>>>>> " >>>>>> >>>>>> Binding revocation is a feature that is required from >> deployments >>>>>> perspective and hence it fits into the current charter. >>>>>> >>>>>> Since MEXT is essentially a consolidation of multiple >>>> MIP6 related >>>>>> WGs, I believe this work item would be a carryover from >>>>> MIP6 to MEXT. >>>>>> >>>>>> Having said that, I do however have some questions about >>>>> this document >>>>>> scope that is related to Netlmm. >>>>>> >>>>>> This I-D is specifying a binding revocation mechanism that is >>>>>> applicable to >>>>>> MIP6 and PMIP6. The consensus call is in the MIP6 WG. I >>>> think that >>>>>> given the >>>>>> PMIP6 aspects included in this I-D, it would make sense >>>> to consult >>>>>> with you and Jonne (Netlmm chairs) about opinions on this I-D. >>>>>> >>>>>> The MIP6 WG charter and scope is focused on extensions to the >>>>>> MIP6 protocol >>>>>> (RFC3775) and issues related to base MIP6. From a charter >>>> and scope >>>>>> perspective, this I-D oversteps the boundaries of MIP6 and >>>>> is treading >>>>>> in Netlmm waters. >>>>>> It is possible that the feature which addresses MIP6 and >>>>>> PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm). >>>>>> But I want to make sure that Netlmm is aware of it and >>>>> supports it as >>>>>> well. >>>>>> >>>>>> If the binding revocation feature were to be done only as a >>>>>> MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would >>>> have to be >>>>>> removed and any enhancements needed to make binding >>>>> revocation work in >>>>>> the case of PMIP6 would have to be done in Netlmm. >>>>>> >>>>>> -Raj >>>>>> >>>>>> >>>>>> >>>>>> On 8/27/07 8:13 PM, "ext Narayanan, Vidya" >>>>>> wrote: >>>>>> >>>>>>> A meta question concerning this draft - how does it fit >>>> into the >>>>>>> current >>>>>>> MIP6 or proposed MEXT charter? >>>>>>> >>>>>>> Thanks, >>>>>>> Vidya >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] >>>>>>>> Sent: Thursday, August 23, 2007 10:16 AM >>>>>>>> To: Mobile IPv6 Mailing List >>>>>>>> Cc: Gopal Dommety >>>>>>>> Subject: [Mip6] Consensus call: Adopting I-D >>>>>>>> >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> This is a consensus call for adopting I-D: Binding >>>> Revocation for >>>>>>>> IPv6 Mobility >>>> as a >>>>>>>> MIP6 WG document. >>>>>>>> >>>>>>>> The I-D has been discussed on the ML in the past and was also >>>>>>>> presented at >>>>>>>> IETF69 in Chicago. >>>>>>>> >>>>>>>> So please opine on the following statement: >>>>>>>> >>>>>>>> The binding revocation feature specified in I-D >>>>>>>> draft-muhanna-mip6-binding-revocation-01.txt is essential for >>>>>>>> MIP6 deployments and hence should be made a MIP6 WG >>>> document and >>>>>>>> progressed as a standards track doc. >>>>>>>> >>>>>>>> Yes [ ] >>>>>>>> No [ ] >>>>>>>> >>>>>>>> -Raj >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Mip6 mailing list >>>>>>>> Mip6@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Mip6 mailing list >>>>> Mip6@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>>> >>>> >> >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 13:47:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQRdK-0003zE-Ep; Wed, 29 Aug 2007 13:47:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQRdE-0003wb-36 for mip6@ietf.org; Wed, 29 Aug 2007 13:47:08 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQRdC-0000hT-HD for mip6@ietf.org; Wed, 29 Aug 2007 13:47:08 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 29 Aug 2007 10:47:06 -0700 X-IronPort-AV: i="4.19,322,1183359600"; d="scan'208"; a="518432992:sNHT82709092" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7THl5S0028817; Wed, 29 Aug 2007 10:47:05 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l7THl5Ya028464; Wed, 29 Aug 2007 17:47:05 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 10:47:05 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 10:47:04 -0700 From: "Sri Gundavelli" To: "'Basavaraj Patil'" , "'ext Narayanan, Vidya'" , "'Ahmad Muhanna'" , "'Mobile IPv6 Mailing List'" , "'Jonne Soininen'" References: Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus call:Adopting I-D) Date: Wed, 29 Aug 2007 10:47:03 -0700 Message-ID: <026701c7ea64$9ca64500$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgAES6mwAAGAyOQAAS76tAAF3CTIQABOiKA X-OriginalArrivalTime: 29 Aug 2007 17:47:05.0067 (UTC) FILETIME=[9CBDEBB0:01C7EA64] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12302; t=1188409625; x=1189273625; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20Need=20for=20revocation=20in=20MIP6=20(RE=3A=20[Mip6] =20Consensus=20call=3AAdopting=20I-D) |Sender:=20; bh=CBIHNVz5bP6komYnaHYaImD7nTbcA5M5dfgzcpk+DX8=; b=NF/8G8o0Vjyhvg46NZaVnqMisr2KcBCTpXpICnpNyKtYE65eUBJ2Ik9F/jvOij40HElkP87l zuwk9Hoi2l1HCYgM/76rrwodWVWQKVWyx1kgeSr9+UmDMVEO+61kkC1mGJdMyXLB4rhtbYTjl6 FjIW/sF2e1b0380tV+uYtvit4=; Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Cc: 'Gopal Dommety' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I was not following this thread ... just a comment on this. No time for long discussions. We cannot just assume AAA to be deployed in the network and assume the entire revocation to be activated and managed through AAA. Pretty much all the specs, including "HA Switchover", "Notifications", "HA Reliability" ... every thing could be achieved through AAA. What we need is a mobility messaging and with no assumption on the presence of AAA. 3775 does not assume AAA on the network either. AAA is not mandataroy for mobility to be achieved. That is just one interface most useful for cellular networks. I dont know if any one would apply AAA for enterprise mobility. Now, if the case where AAA interface is not present, if HA wants to revoke the mobile node's binding, it needs a mechanism to notify the mobile node and the spec defines the signaling for that. Regarding the scope of the work, we cannot expect every WG to go and define the same protocol, changing the entity names and by defining a new usecase. If some one goes and defines Revocation for PMIP6, the work is not going to be vastly different. Its the same messaging and with a different title. If we look at this work in the sense of project management, this work should be done once and leveraged by other WG's (That's been Jari's position regarding leveraging work). Again, just as how DSMIP6 work is being leveraged in 10 different places. That really helped and in the same way, this work should be done just in the base MIP6 group and be leveraged by other WG's. Hope, this work will be adopted as a joint WG item across NEMO, MIP6, NETLMM and MONAMI6. Sri > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > Sent: Wednesday, August 29, 2007 9:56 AM > To: ext Narayanan, Vidya; Ahmad Muhanna; Mobile IPv6 Mailing > List; Jonne Soininen > Cc: Gopal Dommety > Subject: Re: Need for revocation in MIP6 (RE: [Mip6] > Consensus call:Adopting I-D) > > > Hi Vidya, > > But the AAA could notify the HA (via the HA-AAA interface for > which we are > specifying requirements in MIP6) about the Disconnect prior > to sending the > Disconnect to the NAS. And this would allow a graceful detach > from the HA?? > > -Raj > > > On 8/29/07 12:53 AM, "ext Narayanan, Vidya" > wrote: > > > Hi Ahmad, > > The point I was making is that the AAA disconnect messages > are sent to > > the NAS, not the HA - that causes network access being > terminated for > > the MN. The MN won't even get the MIP6 revocation message > once network > > access is revoked. > > > > I realize that the MIP4 revocation is also supported in the > spec for MNs > > in CCoA mode - but, I'm not aware of any real world use of that. > > > > Regards, > > Vidya > > > >> -----Original Message----- > >> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > >> Sent: Tuesday, August 28, 2007 8:52 PM > >> To: Narayanan, Vidya; Basavaraj Patil; Mobile IPv6 Mailing > >> List; Jonne Soininen > >> Cc: Gopal Dommety > >> Subject: RE: Need for revocation in MIP6 (RE: [Mip6] > >> Consensus call: Adopting I-D) > >> > >> Hi Vidya, > >> > >> Thanks Vidya for the question. I actually was planning to > >> check with you and Jonnie on this topic but I had been very > >> busy here at 3GPP2 meeting and I had to go out to eat:-( > >> > >> I believe that we, earlier, had quite good amount of > >> discussion on this topic, however, I must admit it was mixed > >> with revocation applicability to PMIPv6 too. > >> > >> Now, let me try to address your MIPv6 specific question. > >> There is one scenario when the HA would like to revoke the MN > >> session, for example: > >> administrative reasons. As you said, Disconnect message could > >> be sent to the HA for that purpose. Now: I, at least, think > >> of two options here: > >> > >> Option 1. The HA deletes the binding cache entry and forget > >> about the mobile node and the HA starts dropping the MN > >> packets/traffic, I would call this "a bad customer service > >> and a bad example that operators would like to avoid such a > >> non-graceful revocation mechanism" > >> > >> Option 2. As soon as the HA receives the Disconnect message, > >> for example, the HA sends a revocation message and informs > >> the MN that its binding has been revoked with the proper code > >> which should indicate the reason behind revoking the MN > >> binding. In that case, MN probably can delete its binding > >> with other CN or, at least, gives the MN a chance to start a > >> simple IP session, for example, etc. > >> > >> Now since you mentioned MIPv4 Revocation, I would like to > >> mention that long time ago, early 2002, there has been a lot > >> of discussion during > >> RFC3543 development which was translated into allowing the MN > >> to clearly indicate if it (the MN) needs to be informed when > >> its session is revoked or NOT. There is an "I" bit in the > >> revocation extension. That is similar to the case in MIPv6. > >> Not only that, but RFC3543, Registration Revocation in Mobile > >> IPv4, also addresses MIPv4 registration in the case of Co-CoA > >> sessions. This is exactly the same as in MIPv6. > >> > >> Having said the above, I believe that revocation mechanism is > >> needed in multiple scenarios which were presented in Chicago > >> meeting as follows: > >> > >> 1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg) 2. Revoking a > >> PMIPv6 session. (PMIPv6 - Netlmm wg) 3. Revoking a specific > >> Care-of-Address for a multiple care-of-addresses sessions > (Monami6 wg) > >> > >> The common thing for all of these scenarios is that all of > >> them use an extension of MIPv6 protocol. Since one simple > >> mechanism can address all of these scenarios, then one draft > >> would be the best choice. As I said earlier there is already > >> a precedent at IETF with DS-MIPv6. IMHO, it does make a lot > >> of sense to address all of these scenarios which happen to > >> extend across several wgs in a single draft using one simple > >> and generic mechanism. > >> > >> Finally, in fairness to all the fine people who thus far > >> supported this draft as MIP6 wg document, I believe their > >> support was based on the applicability of this draft to MIPv6 > >> and PMIPv6 and I am sure some of them also have Monami6 > >> applicability in mind. > >> > >> > >> Best Regards, > >> Ahmad > >> > >> > >>> -----Original Message----- > >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >>> Sent: Tuesday, August 28, 2007 8:43 PM > >>> To: Basavaraj Patil; Mobile IPv6 Mailing List; Jonne Soininen > >>> Cc: Gopal Dommety > >>> Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus > >>> call: Adopting I-D) > >>> > >>> Raj, all, > >>> I'd like to understand the need for revocation in MIP6 better. I > >>> think we've had a discussion on how to do revocation, but, > >> not so much > >>> on why we would need it for MIP6. Please note that this is not a > >>> discussion on > >>> PMIPv6 - I'm trying to specifically understand this in the > >> context of > >>> MIP6. > >>> > >>> A revocation mechanism was developed for MIP4 to allow a > >> clean up of > >>> resources at the mobility agents (FA/HA). The philosphy of > >> revocation > >>> applies to managed networks and in such networks, a AAA disconnect > >>> message (or equivalent) is likely to first cut off any > >> network access > >>> to the MNs before even MIP6 has a chance to revocate > anything - so, > >>> I'm not sure I understand why we need revocation. Note that the > >>> non-MIP6 mechanism is needed regardless so that network > >> access can be > >>> revoked for nodes not using MIP6 as well. > >>> > >>> I've seen a number of people support adoption of this draft - so, > >>> perhaps there is a good reason for it that I'm just not > >> seeing. I'd > >>> appreciate a clarification. > >>> > >>> Thanks, > >>> Viday > >>> > >>>> -----Original Message----- > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >>>> Sent: Tuesday, August 28, 2007 9:25 AM > >>>> To: Narayanan, Vidya; Mobile IPv6 Mailing List; Jonne Soininen > >>>> Cc: Gopal Dommety > >>>> Subject: Re: [Mip6] Consensus call: Adopting I-D > >>>> > >>>> > >>>> Hi Vidya, > >>>> > >>>> In the context of the MIP6 charter: > >>>> " > >>>> The primary goal of the MIP6 working group will be to > enhance base > >>>> IPv6 mobility by continuing work on developments that are > >>> required for > >>>> wide-scale deployments. > >>>> " > >>>> > >>>> Binding revocation is a feature that is required from deployments > >>>> perspective and hence it fits into the current charter. > >>>> > >>>> Since MEXT is essentially a consolidation of multiple > >> MIP6 related > >>>> WGs, I believe this work item would be a carryover from > >>> MIP6 to MEXT. > >>>> > >>>> Having said that, I do however have some questions about > >>> this document > >>>> scope that is related to Netlmm. > >>>> > >>>> This I-D is specifying a binding revocation mechanism that is > >>>> applicable to > >>>> MIP6 and PMIP6. The consensus call is in the MIP6 WG. I > >> think that > >>>> given the > >>>> PMIP6 aspects included in this I-D, it would make sense > >> to consult > >>>> with you and Jonne (Netlmm chairs) about opinions on this I-D. > >>>> > >>>> The MIP6 WG charter and scope is focused on extensions to the > >>>> MIP6 protocol > >>>> (RFC3775) and issues related to base MIP6. From a charter > >> and scope > >>>> perspective, this I-D oversteps the boundaries of MIP6 and > >>> is treading > >>>> in Netlmm waters. > >>>> It is possible that the feature which addresses MIP6 and > >>>> PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm). > >>>> But I want to make sure that Netlmm is aware of it and > >>> supports it as > >>>> well. > >>>> > >>>> If the binding revocation feature were to be done only as a > >>>> MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would > >> have to be > >>>> removed and any enhancements needed to make binding > >>> revocation work in > >>>> the case of PMIP6 would have to be done in Netlmm. > >>>> > >>>> -Raj > >>>> > >>>> > >>>> > >>>> On 8/27/07 8:13 PM, "ext Narayanan, Vidya" > >>>> wrote: > >>>> > >>>>> A meta question concerning this draft - how does it fit > >> into the > >>>>> current > >>>>> MIP6 or proposed MEXT charter? > >>>>> > >>>>> Thanks, > >>>>> Vidya > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >>>>>> Sent: Thursday, August 23, 2007 10:16 AM > >>>>>> To: Mobile IPv6 Mailing List > >>>>>> Cc: Gopal Dommety > >>>>>> Subject: [Mip6] Consensus call: Adopting I-D > >>>>>> > >>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> This is a consensus call for adopting I-D: Binding > >> Revocation for > >>>>>> IPv6 Mobility > >> as a > >>>>>> MIP6 WG document. > >>>>>> > >>>>>> The I-D has been discussed on the ML in the past and was also > >>>>>> presented at > >>>>>> IETF69 in Chicago. > >>>>>> > >>>>>> So please opine on the following statement: > >>>>>> > >>>>>> The binding revocation feature specified in I-D > >>>>>> draft-muhanna-mip6-binding-revocation-01.txt is essential for > >>>>>> MIP6 deployments and hence should be made a MIP6 WG > >> document and > >>>>>> progressed as a standards track doc. > >>>>>> > >>>>>> Yes [ ] > >>>>>> No [ ] > >>>>>> > >>>>>> -Raj > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Mip6 mailing list > >>>>>> Mip6@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > >>>>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Mip6 mailing list > >>> Mip6@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mip6 > >>> > >> > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 14:08:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQRxR-0003zU-3b; Wed, 29 Aug 2007 14:08:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQRxI-0003wu-SR for mip6@ietf.org; Wed, 29 Aug 2007 14:07:55 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQRxG-000190-OS for mip6@ietf.org; Wed, 29 Aug 2007 14:07:52 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7TI7mwN028610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Aug 2007 11:07:48 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7TI7lSM017843; Wed, 29 Aug 2007 11:07:47 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Aug 2007 11:07:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus call:Adopting I-D) Date: Wed, 29 Aug 2007 11:07:44 -0700 Message-ID: In-Reply-To: <026701c7ea64$9ca64500$d4f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for revocation in MIP6 (RE: [Mip6] Consensus call:Adopting I-D) Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgAES6mwAAGAyOQAAS76tAAF3CTIQABOiKAAAEkG9A= References: <026701c7ea64$9ca64500$d4f6200a@amer.cisco.com> From: "Narayanan, Vidya" To: "Sri Gundavelli" , "Basavaraj Patil" , "Ahmad Muhanna" , "Mobile IPv6 Mailing List" , "Jonne Soininen" X-OriginalArrivalTime: 29 Aug 2007 18:07:47.0364 (UTC) FILETIME=[81356640:01C7EA67] X-Spam-Score: -4.0 (----) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Doing "HA switch" or "Notifications" or "HA Reliability" via AAA doesn't make sense - those are functions of MIP6. Revocation is a policy thing and is associated with AAA or an equivalent entity (HSS or whatever other entity). I don't believe we are making the right comparisons here. =20 Of all the items listed, I can perhaps see the need for NETLMM, for cleaning up MAG resources upon revocation of the MN. For NEMO, MIP6 or MONAMI6, I don't see the point. And, I particularly don't want to discuss the NETLMM need here at this time, since we haven't yet discussed it in the NETLMM WG. For the purpose of MEXT, I'm not seeing the practical need for revocation.=20 Vidya > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Wednesday, August 29, 2007 10:47 AM > To: 'Basavaraj Patil'; Narayanan, Vidya; 'Ahmad Muhanna';=20 > 'Mobile IPv6 Mailing List'; 'Jonne Soininen' > Cc: 'Gopal Dommety' > Subject: RE: Need for revocation in MIP6 (RE: [Mip6]=20 > Consensus call:Adopting I-D) >=20 > I was not following this thread ... just a comment on this.=20 > No time for long discussions. >=20 >=20 > We cannot just assume AAA to be deployed in the network and=20 > assume the entire revocation to be activated and managed=20 > through AAA. Pretty much all the specs, including "HA=20 > Switchover", "Notifications", "HA Reliability" ... every=20 > thing could be achieved through AAA. What we need is a=20 > mobility messaging and with no assumption on the presence of=20 > AAA. 3775 does not assume AAA on the network either. AAA is=20 > not mandataroy for mobility to be achieved. > That is just one interface most useful for cellular networks.=20 > I dont know if any one would apply AAA for enterprise mobility.=20 >=20 > Now, if the case where AAA interface is not present, if HA=20 > wants to revoke the mobile node's binding, it needs a=20 > mechanism to notify the mobile node and the spec defines the=20 > signaling for that. >=20 > Regarding the scope of the work, we cannot expect every WG to=20 > go and define the same protocol, changing the entity names=20 > and by defining a new usecase. If some one goes and defines=20 > Revocation for PMIP6, the work is not going to be vastly=20 > different. Its the same messaging and with a different title.=20 > If we look at this work in the sense of project management,=20 > this work should be done once and leveraged by other WG's=20 > (That's been Jari's position regarding leveraging work). > Again, just as how DSMIP6 work is being leveraged in 10=20 > different places. That really helped and in the same way,=20 > this work should be done just in the base MIP6 group and be=20 > leveraged by other WG's. Hope, this work will be adopted as a=20 > joint WG item across NEMO, MIP6, NETLMM and MONAMI6. >=20 > Sri >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > Sent: Wednesday, August 29, 2007 9:56 AM > > To: ext Narayanan, Vidya; Ahmad Muhanna; Mobile IPv6 Mailing List;=20 > > Jonne Soininen > > Cc: Gopal Dommety > > Subject: Re: Need for revocation in MIP6 (RE: [Mip6] Consensus=20 > > call:Adopting I-D) > >=20 > >=20 > > Hi Vidya, > >=20 > > But the AAA could notify the HA (via the HA-AAA interface=20 > for which we=20 > > are specifying requirements in MIP6) about the Disconnect prior to=20 > > sending the Disconnect to the NAS. And this would allow a graceful=20 > > detach from the HA?? > >=20 > > -Raj > >=20 > >=20 > > On 8/29/07 12:53 AM, "ext Narayanan, Vidya"=20 > > wrote: > >=20 > > > Hi Ahmad, > > > The point I was making is that the AAA disconnect messages > > are sent to > > > the NAS, not the HA - that causes network access being > > terminated for > > > the MN. The MN won't even get the MIP6 revocation message > > once network > > > access is revoked. > > >=20 > > > I realize that the MIP4 revocation is also supported in the > > spec for MNs > > > in CCoA mode - but, I'm not aware of any real world use of that. > > >=20 > > > Regards, > > > Vidya > > >=20 > > >> -----Original Message----- > > >> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > >> Sent: Tuesday, August 28, 2007 8:52 PM > > >> To: Narayanan, Vidya; Basavaraj Patil; Mobile IPv6 Mailing List;=20 > > >> Jonne Soininen > > >> Cc: Gopal Dommety > > >> Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus=20 > > >> call: Adopting I-D) > > >>=20 > > >> Hi Vidya, > > >>=20 > > >> Thanks Vidya for the question. I actually was planning to check=20 > > >> with you and Jonnie on this topic but I had been very=20 > busy here at=20 > > >> 3GPP2 meeting and I had to go out to eat:-( > > >>=20 > > >> I believe that we, earlier, had quite good amount of=20 > discussion on=20 > > >> this topic, however, I must admit it was mixed with revocation=20 > > >> applicability to PMIPv6 too. > > >>=20 > > >> Now, let me try to address your MIPv6 specific question. > > >> There is one scenario when the HA would like to revoke the MN=20 > > >> session, for example: > > >> administrative reasons. As you said, Disconnect message could be=20 > > >> sent to the HA for that purpose. Now: I, at least, think of two=20 > > >> options here: > > >>=20 > > >> Option 1. The HA deletes the binding cache entry and=20 > forget about=20 > > >> the mobile node and the HA starts dropping the MN=20 > packets/traffic,=20 > > >> I would call this "a bad customer service and a bad example that=20 > > >> operators would like to avoid such a non-graceful revocation=20 > > >> mechanism" > > >>=20 > > >> Option 2. As soon as the HA receives the Disconnect message, for=20 > > >> example, the HA sends a revocation message and informs=20 > the MN that=20 > > >> its binding has been revoked with the proper code which should=20 > > >> indicate the reason behind revoking the MN binding. In=20 > that case,=20 > > >> MN probably can delete its binding with other CN or, at least,=20 > > >> gives the MN a chance to start a simple IP session, for example,=20 > > >> etc. > > >>=20 > > >> Now since you mentioned MIPv4 Revocation, I would like=20 > to mention=20 > > >> that long time ago, early 2002, there has been a lot of=20 > discussion=20 > > >> during > > >> RFC3543 development which was translated into allowing the MN to=20 > > >> clearly indicate if it (the MN) needs to be informed when its=20 > > >> session is revoked or NOT. There is an "I" bit in the revocation=20 > > >> extension. That is similar to the case in MIPv6. > > >> Not only that, but RFC3543, Registration Revocation in=20 > Mobile IPv4,=20 > > >> also addresses MIPv4 registration in the case of Co-CoA=20 > sessions.=20 > > >> This is exactly the same as in MIPv6. > > >>=20 > > >> Having said the above, I believe that revocation mechanism is=20 > > >> needed in multiple scenarios which were presented in Chicago=20 > > >> meeting as follows: > > >>=20 > > >> 1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg) 2. Revoking a > > >> PMIPv6 session. (PMIPv6 - Netlmm wg) 3. Revoking a specific=20 > > >> Care-of-Address for a multiple care-of-addresses sessions > > (Monami6 wg) > > >>=20 > > >> The common thing for all of these scenarios is that all=20 > of them use=20 > > >> an extension of MIPv6 protocol. Since one simple mechanism can=20 > > >> address all of these scenarios, then one draft would be the best=20 > > >> choice. As I said earlier there is already a precedent=20 > at IETF with=20 > > >> DS-MIPv6. IMHO, it does make a lot of sense to address=20 > all of these=20 > > >> scenarios which happen to extend across several wgs in a single=20 > > >> draft using one simple and generic mechanism. > > >>=20 > > >> Finally, in fairness to all the fine people who thus far=20 > supported=20 > > >> this draft as MIP6 wg document, I believe their support=20 > was based=20 > > >> on the applicability of this draft to MIPv6 and PMIPv6 and I am=20 > > >> sure some of them also have Monami6 applicability in mind. > > >>=20 > > >>=20 > > >> Best Regards, > > >> Ahmad > > >> =20 > > >>=20 > > >>> -----Original Message----- > > >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > >>> Sent: Tuesday, August 28, 2007 8:43 PM > > >>> To: Basavaraj Patil; Mobile IPv6 Mailing List; Jonne Soininen > > >>> Cc: Gopal Dommety > > >>> Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus > > >>> call: Adopting I-D) > > >>>=20 > > >>> Raj, all, > > >>> I'd like to understand the need for revocation in MIP6=20 > better. I=20 > > >>> think we've had a discussion on how to do revocation, but, > > >> not so much > > >>> on why we would need it for MIP6. Please note that=20 > this is not a=20 > > >>> discussion on > > >>> PMIPv6 - I'm trying to specifically understand this in the > > >> context of > > >>> MIP6. > > >>>=20 > > >>> A revocation mechanism was developed for MIP4 to allow a > > >> clean up of > > >>> resources at the mobility agents (FA/HA). The philosphy of > > >> revocation > > >>> applies to managed networks and in such networks, a AAA=20 > disconnect=20 > > >>> message (or equivalent) is likely to first cut off any > > >> network access > > >>> to the MNs before even MIP6 has a chance to revocate > > anything - so, > > >>> I'm not sure I understand why we need revocation. Note that the > > >>> non-MIP6 mechanism is needed regardless so that network > > >> access can be > > >>> revoked for nodes not using MIP6 as well. > > >>>=20 > > >>> I've seen a number of people support adoption of this=20 > draft - so,=20 > > >>> perhaps there is a good reason for it that I'm just not > > >> seeing. I'd > > >>> appreciate a clarification. > > >>>=20 > > >>> Thanks, > > >>> Viday > > >>>=20 > > >>>> -----Original Message----- > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >>>> Sent: Tuesday, August 28, 2007 9:25 AM > > >>>> To: Narayanan, Vidya; Mobile IPv6 Mailing List; Jonne Soininen > > >>>> Cc: Gopal Dommety > > >>>> Subject: Re: [Mip6] Consensus call: Adopting I-D > > >>>>=20 > > >>>>=20 > > >>>> Hi Vidya, > > >>>>=20 > > >>>> In the context of the MIP6 charter: > > >>>> " > > >>>> The primary goal of the MIP6 working group will be to > > enhance base > > >>>> IPv6 mobility by continuing work on developments that are > > >>> required for > > >>>> wide-scale deployments. > > >>>> " > > >>>>=20 > > >>>> Binding revocation is a feature that is required from=20 > deployments=20 > > >>>> perspective and hence it fits into the current charter. > > >>>>=20 > > >>>> Since MEXT is essentially a consolidation of multiple > > >> MIP6 related > > >>>> WGs, I believe this work item would be a carryover from > > >>> MIP6 to MEXT. > > >>>>=20 > > >>>> Having said that, I do however have some questions about > > >>> this document > > >>>> scope that is related to Netlmm. > > >>>>=20 > > >>>> This I-D is specifying a binding revocation mechanism that is=20 > > >>>> applicable to > > >>>> MIP6 and PMIP6. The consensus call is in the MIP6 WG. I > > >> think that > > >>>> given the > > >>>> PMIP6 aspects included in this I-D, it would make sense > > >> to consult > > >>>> with you and Jonne (Netlmm chairs) about opinions on this I-D. > > >>>>=20 > > >>>> The MIP6 WG charter and scope is focused on extensions to the > > >>>> MIP6 protocol > > >>>> (RFC3775) and issues related to base MIP6. From a charter > > >> and scope > > >>>> perspective, this I-D oversteps the boundaries of MIP6 and > > >>> is treading > > >>>> in Netlmm waters. > > >>>> It is possible that the feature which addresses MIP6 and > > >>>> PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm). > > >>>> But I want to make sure that Netlmm is aware of it and > > >>> supports it as > > >>>> well. > > >>>>=20 > > >>>> If the binding revocation feature were to be done only as a > > >>>> MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would > > >> have to be > > >>>> removed and any enhancements needed to make binding > > >>> revocation work in > > >>>> the case of PMIP6 would have to be done in Netlmm. > > >>>>=20 > > >>>> -Raj > > >>>> =20 > > >>>>=20 > > >>>>=20 > > >>>> On 8/27/07 8:13 PM, "ext Narayanan, Vidya" > > >>>> wrote: > > >>>>=20 > > >>>>> A meta question concerning this draft - how does it fit > > >> into the > > >>>>> current > > >>>>> MIP6 or proposed MEXT charter? > > >>>>>=20 > > >>>>> Thanks, > > >>>>> Vidya > > >>>>>=20 > > >>>>>> -----Original Message----- > > >>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >>>>>> Sent: Thursday, August 23, 2007 10:16 AM > > >>>>>> To: Mobile IPv6 Mailing List > > >>>>>> Cc: Gopal Dommety > > >>>>>> Subject: [Mip6] Consensus call: Adopting I-D > > >>>>>>=20 > > >>>>>>=20 > > >>>>>> Hello, > > >>>>>>=20 > > >>>>>> This is a consensus call for adopting I-D: Binding > > >> Revocation for > > >>>>>> IPv6 Mobility > > >> as a > > >>>>>> MIP6 WG document. > > >>>>>>=20 > > >>>>>> The I-D has been discussed on the ML in the past and=20 > was also=20 > > >>>>>> presented at > > >>>>>> IETF69 in Chicago. > > >>>>>>=20 > > >>>>>> So please opine on the following statement: > > >>>>>>=20 > > >>>>>> The binding revocation feature specified in I-D=20 > > >>>>>> draft-muhanna-mip6-binding-revocation-01.txt is essential for > > >>>>>> MIP6 deployments and hence should be made a MIP6 WG > > >> document and > > >>>>>> progressed as a standards track doc. > > >>>>>>=20 > > >>>>>> Yes [ ] > > >>>>>> No [ ] > > >>>>>>=20 > > >>>>>> -Raj > > >>>>>>=20 > > >>>>>>=20 > > >>>>>> _______________________________________________ > > >>>>>> Mip6 mailing list > > >>>>>> Mip6@ietf.org > > >>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > >>>>>>=20 > > >>>>=20 > > >>>>=20 > > >>>=20 > > >>> _______________________________________________ > > >>> Mip6 mailing list > > >>> Mip6@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/mip6 > > >>>=20 > > >>=20 > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 14:15:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQS4e-0002Pr-Fh; Wed, 29 Aug 2007 14:15:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQS4a-0002Pl-TV for mip6@ietf.org; Wed, 29 Aug 2007 14:15:24 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQS4Z-0001Jl-AU for mip6@ietf.org; Wed, 29 Aug 2007 14:15:24 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Aug 2007 11:15:22 -0700 X-IronPort-AV: i="4.19,322,1183359600"; d="scan'208"; a="208786097:sNHT88007211" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7TIFMUo020896; Wed, 29 Aug 2007 11:15:22 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7TIFMl9022454; Wed, 29 Aug 2007 18:15:22 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 11:15:22 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 11:15:21 -0700 From: "Sri Gundavelli" To: "'Narayanan, Vidya'" , "'Basavaraj Patil'" , "'Ahmad Muhanna'" , "'Mobile IPv6 Mailing List'" , "'Jonne Soininen'" References: <026701c7ea64$9ca64500$d4f6200a@amer.cisco.com> Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus call:Adopting I-D) Date: Wed, 29 Aug 2007 11:15:21 -0700 Message-ID: <027e01c7ea68$8fdfb690$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgAES6mwAAGAyOQAAS76tAAF3CTIQABOiKAAAEkG9AAADDq0A== X-OriginalArrivalTime: 29 Aug 2007 18:15:21.0609 (UTC) FILETIME=[8FF5AF90:01C7EA68] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15917; t=1188411322; x=1189275322; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20Need=20for=20revocation=20in=20MIP6=20(RE=3A=20[Mip6] =20Consensus=20call=3AAdopting=20I-D) |Sender:=20; bh=GTVLtytNrgwxakhLTnAEA8TnHtW6TbKhKxGOooIOSpo=; b=D5/i0DDpjVxM2r+JWx8OaS1sw8NigKgnxd6kNl4IarNPWvYSbfrrTb0cdEPTjIf05CWMwF47 FMwyxp7ie+baEEJqE003T3BL3pl8dIFW3jOM+Zk2X4mzByep4ySKBVGX; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e Cc: 'Gopal Dommety' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org HA reboot is not a policy event. HA is rebooting, it wants to send a graceful event to the mobile. I dont see why AAA function should be involved here. This is one usecase. Again, 3775 does not assume AAA entity in the mobility infrastructure and so the signaling has to be based on MIP6 signaling. Extending this further, offering mobility service involves some policy aspect. So, it is possible to get rid of MIP6 signaling and let AAA notify both HA and MN to setup the binding state. Sure, no need to bring NETLMM usecases for this discussion. Sri > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Wednesday, August 29, 2007 11:08 AM > To: Sri Gundavelli; Basavaraj Patil; Ahmad Muhanna; Mobile > IPv6 Mailing List; Jonne Soininen > Cc: Gopal Dommety > Subject: RE: Need for revocation in MIP6 (RE: [Mip6] > Consensus call:Adopting I-D) > > > Doing "HA switch" or "Notifications" or "HA Reliability" via > AAA doesn't > make sense - those are functions of MIP6. Revocation is a > policy thing > and is associated with AAA or an equivalent entity (HSS or whatever > other entity). I don't believe we are making the right comparisons > here. > > Of all the items listed, I can perhaps see the need for NETLMM, for > cleaning up MAG resources upon revocation of the MN. For > NEMO, MIP6 or > MONAMI6, I don't see the point. And, I particularly don't want to > discuss the NETLMM need here at this time, since we haven't yet > discussed it in the NETLMM WG. For the purpose of MEXT, I'm > not seeing > the practical need for revocation. > > Vidya > > > -----Original Message----- > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > Sent: Wednesday, August 29, 2007 10:47 AM > > To: 'Basavaraj Patil'; Narayanan, Vidya; 'Ahmad Muhanna'; > > 'Mobile IPv6 Mailing List'; 'Jonne Soininen' > > Cc: 'Gopal Dommety' > > Subject: RE: Need for revocation in MIP6 (RE: [Mip6] > > Consensus call:Adopting I-D) > > > > I was not following this thread ... just a comment on this. > > No time for long discussions. > > > > > > We cannot just assume AAA to be deployed in the network and > > assume the entire revocation to be activated and managed > > through AAA. Pretty much all the specs, including "HA > > Switchover", "Notifications", "HA Reliability" ... every > > thing could be achieved through AAA. What we need is a > > mobility messaging and with no assumption on the presence of > > AAA. 3775 does not assume AAA on the network either. AAA is > > not mandataroy for mobility to be achieved. > > That is just one interface most useful for cellular networks. > > I dont know if any one would apply AAA for enterprise mobility. > > > > Now, if the case where AAA interface is not present, if HA > > wants to revoke the mobile node's binding, it needs a > > mechanism to notify the mobile node and the spec defines the > > signaling for that. > > > > Regarding the scope of the work, we cannot expect every WG to > > go and define the same protocol, changing the entity names > > and by defining a new usecase. If some one goes and defines > > Revocation for PMIP6, the work is not going to be vastly > > different. Its the same messaging and with a different title. > > If we look at this work in the sense of project management, > > this work should be done once and leveraged by other WG's > > (That's been Jari's position regarding leveraging work). > > Again, just as how DSMIP6 work is being leveraged in 10 > > different places. That really helped and in the same way, > > this work should be done just in the base MIP6 group and be > > leveraged by other WG's. Hope, this work will be adopted as a > > joint WG item across NEMO, MIP6, NETLMM and MONAMI6. > > > > Sri > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > Sent: Wednesday, August 29, 2007 9:56 AM > > > To: ext Narayanan, Vidya; Ahmad Muhanna; Mobile IPv6 > Mailing List; > > > Jonne Soininen > > > Cc: Gopal Dommety > > > Subject: Re: Need for revocation in MIP6 (RE: [Mip6] Consensus > > > call:Adopting I-D) > > > > > > > > > Hi Vidya, > > > > > > But the AAA could notify the HA (via the HA-AAA interface > > for which we > > > are specifying requirements in MIP6) about the Disconnect > prior to > > > sending the Disconnect to the NAS. And this would allow a > graceful > > > detach from the HA?? > > > > > > -Raj > > > > > > > > > On 8/29/07 12:53 AM, "ext Narayanan, Vidya" > > > wrote: > > > > > > > Hi Ahmad, > > > > The point I was making is that the AAA disconnect messages > > > are sent to > > > > the NAS, not the HA - that causes network access being > > > terminated for > > > > the MN. The MN won't even get the MIP6 revocation message > > > once network > > > > access is revoked. > > > > > > > > I realize that the MIP4 revocation is also supported in the > > > spec for MNs > > > > in CCoA mode - but, I'm not aware of any real world use of that. > > > > > > > > Regards, > > > > Vidya > > > > > > > >> -----Original Message----- > > > >> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > >> Sent: Tuesday, August 28, 2007 8:52 PM > > > >> To: Narayanan, Vidya; Basavaraj Patil; Mobile IPv6 > Mailing List; > > > >> Jonne Soininen > > > >> Cc: Gopal Dommety > > > >> Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus > > > >> call: Adopting I-D) > > > >> > > > >> Hi Vidya, > > > >> > > > >> Thanks Vidya for the question. I actually was planning > to check > > > >> with you and Jonnie on this topic but I had been very > > busy here at > > > >> 3GPP2 meeting and I had to go out to eat:-( > > > >> > > > >> I believe that we, earlier, had quite good amount of > > discussion on > > > >> this topic, however, I must admit it was mixed with revocation > > > >> applicability to PMIPv6 too. > > > >> > > > >> Now, let me try to address your MIPv6 specific question. > > > >> There is one scenario when the HA would like to revoke the MN > > > >> session, for example: > > > >> administrative reasons. As you said, Disconnect > message could be > > > >> sent to the HA for that purpose. Now: I, at least, > think of two > > > >> options here: > > > >> > > > >> Option 1. The HA deletes the binding cache entry and > > forget about > > > >> the mobile node and the HA starts dropping the MN > > packets/traffic, > > > >> I would call this "a bad customer service and a bad > example that > > > >> operators would like to avoid such a non-graceful revocation > > > >> mechanism" > > > >> > > > >> Option 2. As soon as the HA receives the Disconnect > message, for > > > >> example, the HA sends a revocation message and informs > > the MN that > > > >> its binding has been revoked with the proper code which should > > > >> indicate the reason behind revoking the MN binding. In > > that case, > > > >> MN probably can delete its binding with other CN or, at least, > > > >> gives the MN a chance to start a simple IP session, > for example, > > > >> etc. > > > >> > > > >> Now since you mentioned MIPv4 Revocation, I would like > > to mention > > > >> that long time ago, early 2002, there has been a lot of > > discussion > > > >> during > > > >> RFC3543 development which was translated into allowing > the MN to > > > >> clearly indicate if it (the MN) needs to be informed when its > > > >> session is revoked or NOT. There is an "I" bit in the > revocation > > > >> extension. That is similar to the case in MIPv6. > > > >> Not only that, but RFC3543, Registration Revocation in > > Mobile IPv4, > > > >> also addresses MIPv4 registration in the case of Co-CoA > > sessions. > > > >> This is exactly the same as in MIPv6. > > > >> > > > >> Having said the above, I believe that revocation mechanism is > > > >> needed in multiple scenarios which were presented in Chicago > > > >> meeting as follows: > > > >> > > > >> 1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg) 2. Revoking a > > > >> PMIPv6 session. (PMIPv6 - Netlmm wg) 3. Revoking a specific > > > >> Care-of-Address for a multiple care-of-addresses sessions > > > (Monami6 wg) > > > >> > > > >> The common thing for all of these scenarios is that all > > of them use > > > >> an extension of MIPv6 protocol. Since one simple mechanism can > > > >> address all of these scenarios, then one draft would > be the best > > > >> choice. As I said earlier there is already a precedent > > at IETF with > > > >> DS-MIPv6. IMHO, it does make a lot of sense to address > > all of these > > > >> scenarios which happen to extend across several wgs in > a single > > > >> draft using one simple and generic mechanism. > > > >> > > > >> Finally, in fairness to all the fine people who thus far > > supported > > > >> this draft as MIP6 wg document, I believe their support > > was based > > > >> on the applicability of this draft to MIPv6 and PMIPv6 > and I am > > > >> sure some of them also have Monami6 applicability in mind. > > > >> > > > >> > > > >> Best Regards, > > > >> Ahmad > > > >> > > > >> > > > >>> -----Original Message----- > > > >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > >>> Sent: Tuesday, August 28, 2007 8:43 PM > > > >>> To: Basavaraj Patil; Mobile IPv6 Mailing List; Jonne Soininen > > > >>> Cc: Gopal Dommety > > > >>> Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus > > > >>> call: Adopting I-D) > > > >>> > > > >>> Raj, all, > > > >>> I'd like to understand the need for revocation in MIP6 > > better. I > > > >>> think we've had a discussion on how to do revocation, but, > > > >> not so much > > > >>> on why we would need it for MIP6. Please note that > > this is not a > > > >>> discussion on > > > >>> PMIPv6 - I'm trying to specifically understand this in the > > > >> context of > > > >>> MIP6. > > > >>> > > > >>> A revocation mechanism was developed for MIP4 to allow a > > > >> clean up of > > > >>> resources at the mobility agents (FA/HA). The philosphy of > > > >> revocation > > > >>> applies to managed networks and in such networks, a AAA > > disconnect > > > >>> message (or equivalent) is likely to first cut off any > > > >> network access > > > >>> to the MNs before even MIP6 has a chance to revocate > > > anything - so, > > > >>> I'm not sure I understand why we need revocation. > Note that the > > > >>> non-MIP6 mechanism is needed regardless so that network > > > >> access can be > > > >>> revoked for nodes not using MIP6 as well. > > > >>> > > > >>> I've seen a number of people support adoption of this > > draft - so, > > > >>> perhaps there is a good reason for it that I'm just not > > > >> seeing. I'd > > > >>> appreciate a clarification. > > > >>> > > > >>> Thanks, > > > >>> Viday > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > >>>> Sent: Tuesday, August 28, 2007 9:25 AM > > > >>>> To: Narayanan, Vidya; Mobile IPv6 Mailing List; > Jonne Soininen > > > >>>> Cc: Gopal Dommety > > > >>>> Subject: Re: [Mip6] Consensus call: Adopting I-D > > > >>>> > > > >>>> > > > >>>> Hi Vidya, > > > >>>> > > > >>>> In the context of the MIP6 charter: > > > >>>> " > > > >>>> The primary goal of the MIP6 working group will be to > > > enhance base > > > >>>> IPv6 mobility by continuing work on developments that are > > > >>> required for > > > >>>> wide-scale deployments. > > > >>>> " > > > >>>> > > > >>>> Binding revocation is a feature that is required from > > deployments > > > >>>> perspective and hence it fits into the current charter. > > > >>>> > > > >>>> Since MEXT is essentially a consolidation of multiple > > > >> MIP6 related > > > >>>> WGs, I believe this work item would be a carryover from > > > >>> MIP6 to MEXT. > > > >>>> > > > >>>> Having said that, I do however have some questions about > > > >>> this document > > > >>>> scope that is related to Netlmm. > > > >>>> > > > >>>> This I-D is specifying a binding revocation > mechanism that is > > > >>>> applicable to > > > >>>> MIP6 and PMIP6. The consensus call is in the MIP6 WG. I > > > >> think that > > > >>>> given the > > > >>>> PMIP6 aspects included in this I-D, it would make sense > > > >> to consult > > > >>>> with you and Jonne (Netlmm chairs) about opinions on > this I-D. > > > >>>> > > > >>>> The MIP6 WG charter and scope is focused on extensions to the > > > >>>> MIP6 protocol > > > >>>> (RFC3775) and issues related to base MIP6. From a charter > > > >> and scope > > > >>>> perspective, this I-D oversteps the boundaries of MIP6 and > > > >>> is treading > > > >>>> in Netlmm waters. > > > >>>> It is possible that the feature which addresses MIP6 and > > > >>>> PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm). > > > >>>> But I want to make sure that Netlmm is aware of it and > > > >>> supports it as > > > >>>> well. > > > >>>> > > > >>>> If the binding revocation feature were to be done only as a > > > >>>> MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would > > > >> have to be > > > >>>> removed and any enhancements needed to make binding > > > >>> revocation work in > > > >>>> the case of PMIP6 would have to be done in Netlmm. > > > >>>> > > > >>>> -Raj > > > >>>> > > > >>>> > > > >>>> > > > >>>> On 8/27/07 8:13 PM, "ext Narayanan, Vidya" > > > >>>> wrote: > > > >>>> > > > >>>>> A meta question concerning this draft - how does it fit > > > >> into the > > > >>>>> current > > > >>>>> MIP6 or proposed MEXT charter? > > > >>>>> > > > >>>>> Thanks, > > > >>>>> Vidya > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > >>>>>> Sent: Thursday, August 23, 2007 10:16 AM > > > >>>>>> To: Mobile IPv6 Mailing List > > > >>>>>> Cc: Gopal Dommety > > > >>>>>> Subject: [Mip6] Consensus call: Adopting I-D > > > >>>>>> > > > >>>>>> > > > >>>>>> Hello, > > > >>>>>> > > > >>>>>> This is a consensus call for adopting I-D: Binding > > > >> Revocation for > > > >>>>>> IPv6 Mobility > > > >> as a > > > >>>>>> MIP6 WG document. > > > >>>>>> > > > >>>>>> The I-D has been discussed on the ML in the past and > > was also > > > >>>>>> presented at > > > >>>>>> IETF69 in Chicago. > > > >>>>>> > > > >>>>>> So please opine on the following statement: > > > >>>>>> > > > >>>>>> The binding revocation feature specified in I-D > > > >>>>>> draft-muhanna-mip6-binding-revocation-01.txt is > essential for > > > >>>>>> MIP6 deployments and hence should be made a MIP6 WG > > > >> document and > > > >>>>>> progressed as a standards track doc. > > > >>>>>> > > > >>>>>> Yes [ ] > > > >>>>>> No [ ] > > > >>>>>> > > > >>>>>> -Raj > > > >>>>>> > > > >>>>>> > > > >>>>>> _______________________________________________ > > > >>>>>> Mip6 mailing list > > > >>>>>> Mip6@ietf.org > > > >>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > > >>>>>> > > > >>>> > > > >>>> > > > >>> > > > >>> _______________________________________________ > > > >>> Mip6 mailing list > > > >>> Mip6@ietf.org > > > >>> https://www1.ietf.org/mailman/listinfo/mip6 > > > >>> > > > >> > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 14:39:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSRh-0003iz-5H; Wed, 29 Aug 2007 14:39:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSRY-0003iV-2K for mip6@ietf.org; Wed, 29 Aug 2007 14:39:09 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQSRW-0003pb-FH for mip6@ietf.org; Wed, 29 Aug 2007 14:39:07 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7TId4ut000376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Aug 2007 11:39:04 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7TId3UK025154; Wed, 29 Aug 2007 11:39:03 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Aug 2007 11:39:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) Date: Wed, 29 Aug 2007 11:38:55 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgAES6mwAAGAyOQAAS76tAAF3CTIQAAh2pgAAEV8jgAAdmGkA== References: From: "Narayanan, Vidya" To: "Basavaraj Patil" , "Ahmad Muhanna" , "Mobile IPv6 Mailing List" , "Jonne Soininen" X-OriginalArrivalTime: 29 Aug 2007 18:39:03.0218 (UTC) FILETIME=[DF4E0120:01C7EA6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I'll make a final point and stop here. Most managed networks that are considering the use of MIP6 today allow a mix of MIP6 and non-MIP6 capable nodes to exist on the network. A mechanism of revoking access is needed for both MIP6 and non-MIP6 capable endpoints and they don't need to be different. =20 When the NAS receives a disconnect, it stops accepting packets sourced from that IP address (the CoA, in the MIP6 case) and also won't forward anything to that IP address - surely, we are not saying that the NAS understand MIP6 signaling and forward that alone on to the MN. Good mobile implementations should automatically blow any state associated with that IP address (including MIP6 state), when access is revoked. =20 Vidya > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Wednesday, August 29, 2007 10:42 AM > To: Narayanan, Vidya; Ahmad Muhanna; Mobile IPv6 Mailing=20 > List; Jonne Soininen > Cc: Gopal Dommety > Subject: Re: Need for revocation in MIP6 (RE: [Mip6]=20 > Consensus call: Adopting I-D) >=20 >=20 > Hi Vidya, >=20 > I agree that if the issue is primarily resource clean up, a=20 > notification from the AAA to the HA will deprecate the binding. >=20 > But if the AAA sends a Disconnect to the NAS, I am not sure=20 > if there is a graceful mechanism to indicate to the MN that=20 > it is being disconnected. Of course there are many different=20 > ways to indicate that the MN has been disconnected from the=20 > network and these could also be access technology dependent.=20 > However if there is no good way to indicate to the MN that it=20 > has been disconnected, the MN would continue to believe that=20 > it still has MIP6 binding and subsequently may cause a delay=20 > in creating a binding with the HA when the MN does attach=20 > (for example via another access type). So I think it would=20 > still make sense to indicate to the MN that the HA has=20 > revoked the binding.=20 > There is of course an issue about synchronizing the AAA=20 > Disconnect to the NAS and the indication to the HA to ensure=20 > that the MN can be notified of the binding revocation prior=20 > to pulling the plug at the NAS. But I think this can be dealt with. >=20 > -Raj >=20 >=20 > On 8/29/07 12:15 PM, "ext Narayanan, Vidya"=20 > wrote: >=20 > > Hi Raj, > > Hmmm.. The AAA could certainly notify the HA. But, a AAA that is=20 > > interested in revoking access to an MN would contact the=20 > NAS first, if=20 > > not in parallel with the HA. After all, the AAA is getting=20 > accounting=20 > > records from the NAS - note that even if the HA is also physically=20 > > serving as a AAA aggregation point for accounting (which=20 > itself cannot=20 > > be generalized), it is still a logically separate function=20 > that will=20 > > forward on the AAA disconnect messages all the way to the NAS,=20 > > resulting in MN's access being revoked. > >=20 > > So, the AAA notification to the HA would be good to clean up the HA=20 > > resources, but, I'm still not seeing a practical need for=20 > revocation=20 > > in > > MIP6 - the MN has likely had its access revoked before the HA sends=20 > > the > > MIP6 revocation out. > >=20 > > Vidya > >=20 > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >> Sent: Wednesday, August 29, 2007 9:56 AM > >> To: Narayanan, Vidya; Ahmad Muhanna; Mobile IPv6 Mailing=20 > List; Jonne=20 > >> Soininen > >> Cc: Gopal Dommety > >> Subject: Re: Need for revocation in MIP6 (RE: [Mip6]=20 > Consensus call:=20 > >> Adopting I-D) > >>=20 > >>=20 > >> Hi Vidya, > >>=20 > >> But the AAA could notify the HA (via the HA-AAA interface=20 > for which=20 > >> we are specifying requirements in MIP6) about the=20 > Disconnect prior to=20 > >> sending the Disconnect to the NAS. And this would allow a graceful=20 > >> detach from the HA?? > >>=20 > >> -Raj > >>=20 > >>=20 > >> On 8/29/07 12:53 AM, "ext Narayanan, Vidya" > >> wrote: > >>=20 > >>> Hi Ahmad, > >>> The point I was making is that the AAA disconnect messages > >> are sent to > >>> the NAS, not the HA - that causes network access being > >> terminated for > >>> the MN. The MN won't even get the MIP6 revocation message once=20 > >>> network access is revoked. > >>>=20 > >>> I realize that the MIP4 revocation is also supported in the > >> spec for > >>> MNs in CCoA mode - but, I'm not aware of any real world=20 > use of that. > >>>=20 > >>> Regards, > >>> Vidya > >>>=20 > >>>> -----Original Message----- > >>>> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > >>>> Sent: Tuesday, August 28, 2007 8:52 PM > >>>> To: Narayanan, Vidya; Basavaraj Patil; Mobile IPv6 Mailing List;=20 > >>>> Jonne Soininen > >>>> Cc: Gopal Dommety > >>>> Subject: RE: Need for revocation in MIP6 (RE: [Mip6] > >> Consensus call:=20 > >>>> Adopting I-D) > >>>>=20 > >>>> Hi Vidya, > >>>>=20 > >>>> Thanks Vidya for the question. I actually was planning to > >> check with > >>>> you and Jonnie on this topic but I had been very busy here > >> at 3GPP2 > >>>> meeting and I had to go out to eat:-( > >>>>=20 > >>>> I believe that we, earlier, had quite good amount of=20 > discussion on=20 > >>>> this topic, however, I must admit it was mixed with revocation=20 > >>>> applicability to PMIPv6 too. > >>>>=20 > >>>> Now, let me try to address your MIPv6 specific question. > >>>> There is one scenario when the HA would like to revoke the MN=20 > >>>> session, for example: > >>>> administrative reasons. As you said, Disconnect message > >> could be sent > >>>> to the HA for that purpose. Now: I, at least, think of=20 > two options > >>>> here: > >>>>=20 > >>>> Option 1. The HA deletes the binding cache entry and > >> forget about the > >>>> mobile node and the HA starts dropping the MN packets/traffic, I=20 > >>>> would call this "a bad customer service and a bad example that=20 > >>>> operators would like to avoid such a non-graceful revocation=20 > >>>> mechanism" > >>>>=20 > >>>> Option 2. As soon as the HA receives the Disconnect message, for=20 > >>>> example, the HA sends a revocation message and informs=20 > the MN that=20 > >>>> its binding has been revoked with the proper code which should=20 > >>>> indicate the reason behind revoking the MN binding. In > >> that case, MN > >>>> probably can delete its binding with other CN or, at > >> least, gives the > >>>> MN a chance to start a simple IP session, for example, etc. > >>>>=20 > >>>> Now since you mentioned MIPv4 Revocation, I would like=20 > to mention=20 > >>>> that long time ago, early 2002, there has been a lot of=20 > discussion=20 > >>>> during > >>>> RFC3543 development which was translated into allowing the MN to=20 > >>>> clearly indicate if it (the MN) needs to be informed when > >> its session > >>>> is revoked or NOT. There is an "I" bit in the revocation > >> extension.=20 > >>>> That is similar to the case in MIPv6. > >>>> Not only that, but RFC3543, Registration Revocation in > >> Mobile IPv4, > >>>> also addresses MIPv4 registration in the case of Co-CoA sessions. > >>>> This is exactly the same as in MIPv6. > >>>>=20 > >>>> Having said the above, I believe that revocation mechanism > >> is needed > >>>> in multiple scenarios which were presented in Chicago meeting as > >>>> follows: > >>>>=20 > >>>> 1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg) 2. Revoking a > >>>> PMIPv6 session. (PMIPv6 - Netlmm wg) 3. Revoking a specific=20 > >>>> Care-of-Address for a multiple care-of-addresses=20 > sessions (Monami6 > >>>> wg) > >>>>=20 > >>>> The common thing for all of these scenarios is that all of > >> them use > >>>> an extension of MIPv6 protocol. Since one simple mechanism can=20 > >>>> address all of these scenarios, then one draft would be the best=20 > >>>> choice. As I said earlier there is already a precedent at > >> IETF with > >>>> DS-MIPv6. IMHO, it does make a lot of sense to address all > >> of these > >>>> scenarios which happen to extend across several wgs in a > >> single draft > >>>> using one simple and generic mechanism. > >>>>=20 > >>>> Finally, in fairness to all the fine people who thus far=20 > supported=20 > >>>> this draft as MIP6 wg document, I believe their support > >> was based on > >>>> the applicability of this draft to MIPv6 and PMIPv6 and=20 > I am sure=20 > >>>> some of them also have Monami6 applicability in mind. > >>>>=20 > >>>>=20 > >>>> Best Regards, > >>>> Ahmad > >>>> =20 > >>>>=20 > >>>>> -----Original Message----- > >>>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >>>>> Sent: Tuesday, August 28, 2007 8:43 PM > >>>>> To: Basavaraj Patil; Mobile IPv6 Mailing List; Jonne Soininen > >>>>> Cc: Gopal Dommety > >>>>> Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus > >>>>> call: Adopting I-D) > >>>>>=20 > >>>>> Raj, all, > >>>>> I'd like to understand the need for revocation in MIP6=20 > better. I=20 > >>>>> think we've had a discussion on how to do revocation, but, > >>>> not so much > >>>>> on why we would need it for MIP6. Please note that=20 > this is not a=20 > >>>>> discussion on > >>>>> PMIPv6 - I'm trying to specifically understand this in the > >>>> context of > >>>>> MIP6. > >>>>>=20 > >>>>> A revocation mechanism was developed for MIP4 to allow a > >>>> clean up of > >>>>> resources at the mobility agents (FA/HA). The philosphy of > >>>> revocation > >>>>> applies to managed networks and in such networks, a AAA > >> disconnect > >>>>> message (or equivalent) is likely to first cut off any > >>>> network access > >>>>> to the MNs before even MIP6 has a chance to revocate > >> anything - so, > >>>>> I'm not sure I understand why we need revocation. Note that the > >>>>> non-MIP6 mechanism is needed regardless so that network > >>>> access can be > >>>>> revoked for nodes not using MIP6 as well. > >>>>>=20 > >>>>> I've seen a number of people support adoption of this=20 > draft - so,=20 > >>>>> perhaps there is a good reason for it that I'm just not > >>>> seeing. I'd > >>>>> appreciate a clarification. > >>>>>=20 > >>>>> Thanks, > >>>>> Viday > >>>>>=20 > >>>>>> -----Original Message----- > >>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >>>>>> Sent: Tuesday, August 28, 2007 9:25 AM > >>>>>> To: Narayanan, Vidya; Mobile IPv6 Mailing List; Jonne Soininen > >>>>>> Cc: Gopal Dommety > >>>>>> Subject: Re: [Mip6] Consensus call: Adopting I-D > >>>>>>=20 > >>>>>>=20 > >>>>>> Hi Vidya, > >>>>>>=20 > >>>>>> In the context of the MIP6 charter: > >>>>>> " > >>>>>> The primary goal of the MIP6 working group will be to > >> enhance base > >>>>>> IPv6 mobility by continuing work on developments that are > >>>>> required for > >>>>>> wide-scale deployments. > >>>>>> " > >>>>>>=20 > >>>>>> Binding revocation is a feature that is required from > >> deployments > >>>>>> perspective and hence it fits into the current charter. > >>>>>>=20 > >>>>>> Since MEXT is essentially a consolidation of multiple > >>>> MIP6 related > >>>>>> WGs, I believe this work item would be a carryover from > >>>>> MIP6 to MEXT. > >>>>>>=20 > >>>>>> Having said that, I do however have some questions about > >>>>> this document > >>>>>> scope that is related to Netlmm. > >>>>>>=20 > >>>>>> This I-D is specifying a binding revocation mechanism that is=20 > >>>>>> applicable to > >>>>>> MIP6 and PMIP6. The consensus call is in the MIP6 WG. I > >>>> think that > >>>>>> given the > >>>>>> PMIP6 aspects included in this I-D, it would make sense > >>>> to consult > >>>>>> with you and Jonne (Netlmm chairs) about opinions on this I-D. > >>>>>>=20 > >>>>>> The MIP6 WG charter and scope is focused on extensions to the > >>>>>> MIP6 protocol > >>>>>> (RFC3775) and issues related to base MIP6. From a charter > >>>> and scope > >>>>>> perspective, this I-D oversteps the boundaries of MIP6 and > >>>>> is treading > >>>>>> in Netlmm waters. > >>>>>> It is possible that the feature which addresses MIP6 and > >>>>>> PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm). > >>>>>> But I want to make sure that Netlmm is aware of it and > >>>>> supports it as > >>>>>> well. > >>>>>>=20 > >>>>>> If the binding revocation feature were to be done only as a > >>>>>> MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would > >>>> have to be > >>>>>> removed and any enhancements needed to make binding > >>>>> revocation work in > >>>>>> the case of PMIP6 would have to be done in Netlmm. > >>>>>>=20 > >>>>>> -Raj > >>>>>> =20 > >>>>>>=20 > >>>>>>=20 > >>>>>> On 8/27/07 8:13 PM, "ext Narayanan, Vidya" > >>>>>> wrote: > >>>>>>=20 > >>>>>>> A meta question concerning this draft - how does it fit > >>>> into the > >>>>>>> current > >>>>>>> MIP6 or proposed MEXT charter? > >>>>>>>=20 > >>>>>>> Thanks, > >>>>>>> Vidya > >>>>>>>=20 > >>>>>>>> -----Original Message----- > >>>>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >>>>>>>> Sent: Thursday, August 23, 2007 10:16 AM > >>>>>>>> To: Mobile IPv6 Mailing List > >>>>>>>> Cc: Gopal Dommety > >>>>>>>> Subject: [Mip6] Consensus call: Adopting I-D > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> Hello, > >>>>>>>>=20 > >>>>>>>> This is a consensus call for adopting I-D: Binding > >>>> Revocation for > >>>>>>>> IPv6 Mobility > >>>> as a > >>>>>>>> MIP6 WG document. > >>>>>>>>=20 > >>>>>>>> The I-D has been discussed on the ML in the past and=20 > was also=20 > >>>>>>>> presented at > >>>>>>>> IETF69 in Chicago. > >>>>>>>>=20 > >>>>>>>> So please opine on the following statement: > >>>>>>>>=20 > >>>>>>>> The binding revocation feature specified in I-D=20 > >>>>>>>> draft-muhanna-mip6-binding-revocation-01.txt is essential for > >>>>>>>> MIP6 deployments and hence should be made a MIP6 WG > >>>> document and > >>>>>>>> progressed as a standards track doc. > >>>>>>>>=20 > >>>>>>>> Yes [ ] > >>>>>>>> No [ ] > >>>>>>>>=20 > >>>>>>>> -Raj > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> _______________________________________________ > >>>>>>>> Mip6 mailing list > >>>>>>>> Mip6@ietf.org > >>>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > >>>>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>>=20 > >>>>> _______________________________________________ > >>>>> Mip6 mailing list > >>>>> Mip6@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/mip6 > >>>>>=20 > >>>>=20 > >>=20 > >>=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 14:55:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQShM-0001VQ-Ra; Wed, 29 Aug 2007 14:55:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQShA-0001Th-5P for mip6@ietf.org; Wed, 29 Aug 2007 14:55:16 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQSh8-0004UC-5W for mip6@ietf.org; Wed, 29 Aug 2007 14:55:16 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 29 Aug 2007 11:55:14 -0700 X-IronPort-AV: i="4.19,322,1183359600"; d="scan'208"; a="518466221:sNHT79959736" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7TItDJE000928; Wed, 29 Aug 2007 11:55:13 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7TIt5l7001307; Wed, 29 Aug 2007 18:55:05 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 11:55:05 -0700 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 11:55:03 -0700 From: "Sri Gundavelli" To: "'Sri Gundavelli'" , "'Narayanan, Vidya'" , "'Basavaraj Patil'" , "'Ahmad Muhanna'" , "'Mobile IPv6 Mailing List'" , "'Jonne Soininen'" References: <026701c7ea64$9ca64500$d4f6200a@amer.cisco.com> <027e01c7ea68$8fdfb690$d4f6200a@amer.cisco.com> Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus call:AdoptingI-D) Date: Wed, 29 Aug 2007 11:55:03 -0700 Message-ID: <029b01c7ea6e$1c0c0380$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <027e01c7ea68$8fdfb690$d4f6200a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgAES6mwAAGAyOQAAS76tAAF3CTIQABOiKAAAEkG9AAADDq0AABLeBQ X-OriginalArrivalTime: 29 Aug 2007 18:55:04.0250 (UTC) FILETIME=[1C1FD9A0:01C7EA6E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=18151; t=1188413713; x=1189277713; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20Need=20for=20revocation=20in=20MIP6=20(RE=3A=20[Mip6] =20Consensus=20call=3AAdoptingI-D) |Sender:=20; bh=ruP4nNxTWxUxbtT0ZbbH3bW7ufe7fCkwA3v+TspNVAc=; b=WseOz6YWySePuVjPf32DViwtLboLm5YQPZtOApJoKYFlgvJOYKuVWKtAEiXKG6Tex1cx7Gwz x9Q+IfmvbnSRJBjxBS+xVek9GT+angTawJe6iUaKM9QPw7op3phDs6dI; Authentication-Results: sj-dkim-4; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d094b18a574860cb9e2fe5fedfbcc179 Cc: 'Gopal Dommety' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Adding a final comment to close this discussion from my end as well. If an operator goes to the Home Agent and clears a specific binding for what ever reasons, that revocation event needs to be propagated by the use MIP6 signaling. AAA is not the only source for activating revocation events and AAA may or may not even be there in a given architecture. It is also possible the AAA server in an access network MAY not have a relation to the AAA server in the home network. The base protocol should have the required hooks for proper mobility management. Assuming AAA (a non mobility function) to exist in a given architecture, is just one solution and leaves the base protocol incomplete. Hope this discussion helps in adopting this work across all WG's, leveraging MIP6 protocol. Thanks Regards Sri > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Wednesday, August 29, 2007 11:15 AM > To: 'Narayanan, Vidya'; 'Basavaraj Patil'; 'Ahmad Muhanna'; > 'Mobile IPv6 Mailing List'; 'Jonne Soininen' > Cc: 'Gopal Dommety' > Subject: RE: Need for revocation in MIP6 (RE: [Mip6] > Consensus call:AdoptingI-D) > > > HA reboot is not a policy event. HA is rebooting, it wants to > send a graceful event to the mobile. I dont see why AAA function > should be involved here. This is one usecase. Again, 3775 does > not assume AAA entity in the mobility infrastructure and so > the signaling has to be based on MIP6 signaling. > > Extending this further, offering mobility service involves > some policy aspect. So, it is possible to get rid of MIP6 > signaling and let AAA notify both HA and MN to setup the > binding state. > > Sure, no need to bring NETLMM usecases for this discussion. > > Sri > > > > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Wednesday, August 29, 2007 11:08 AM > > To: Sri Gundavelli; Basavaraj Patil; Ahmad Muhanna; Mobile > > IPv6 Mailing List; Jonne Soininen > > Cc: Gopal Dommety > > Subject: RE: Need for revocation in MIP6 (RE: [Mip6] > > Consensus call:Adopting I-D) > > > > > > Doing "HA switch" or "Notifications" or "HA Reliability" via > > AAA doesn't > > make sense - those are functions of MIP6. Revocation is a > > policy thing > > and is associated with AAA or an equivalent entity (HSS or whatever > > other entity). I don't believe we are making the right comparisons > > here. > > > > Of all the items listed, I can perhaps see the need for NETLMM, for > > cleaning up MAG resources upon revocation of the MN. For > > NEMO, MIP6 or > > MONAMI6, I don't see the point. And, I particularly don't want to > > discuss the NETLMM need here at this time, since we haven't yet > > discussed it in the NETLMM WG. For the purpose of MEXT, I'm > > not seeing > > the practical need for revocation. > > > > Vidya > > > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > Sent: Wednesday, August 29, 2007 10:47 AM > > > To: 'Basavaraj Patil'; Narayanan, Vidya; 'Ahmad Muhanna'; > > > 'Mobile IPv6 Mailing List'; 'Jonne Soininen' > > > Cc: 'Gopal Dommety' > > > Subject: RE: Need for revocation in MIP6 (RE: [Mip6] > > > Consensus call:Adopting I-D) > > > > > > I was not following this thread ... just a comment on this. > > > No time for long discussions. > > > > > > > > > We cannot just assume AAA to be deployed in the network and > > > assume the entire revocation to be activated and managed > > > through AAA. Pretty much all the specs, including "HA > > > Switchover", "Notifications", "HA Reliability" ... every > > > thing could be achieved through AAA. What we need is a > > > mobility messaging and with no assumption on the presence of > > > AAA. 3775 does not assume AAA on the network either. AAA is > > > not mandataroy for mobility to be achieved. > > > That is just one interface most useful for cellular networks. > > > I dont know if any one would apply AAA for enterprise mobility. > > > > > > Now, if the case where AAA interface is not present, if HA > > > wants to revoke the mobile node's binding, it needs a > > > mechanism to notify the mobile node and the spec defines the > > > signaling for that. > > > > > > Regarding the scope of the work, we cannot expect every WG to > > > go and define the same protocol, changing the entity names > > > and by defining a new usecase. If some one goes and defines > > > Revocation for PMIP6, the work is not going to be vastly > > > different. Its the same messaging and with a different title. > > > If we look at this work in the sense of project management, > > > this work should be done once and leveraged by other WG's > > > (That's been Jari's position regarding leveraging work). > > > Again, just as how DSMIP6 work is being leveraged in 10 > > > different places. That really helped and in the same way, > > > this work should be done just in the base MIP6 group and be > > > leveraged by other WG's. Hope, this work will be adopted as a > > > joint WG item across NEMO, MIP6, NETLMM and MONAMI6. > > > > > > Sri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > Sent: Wednesday, August 29, 2007 9:56 AM > > > > To: ext Narayanan, Vidya; Ahmad Muhanna; Mobile IPv6 > > Mailing List; > > > > Jonne Soininen > > > > Cc: Gopal Dommety > > > > Subject: Re: Need for revocation in MIP6 (RE: [Mip6] Consensus > > > > call:Adopting I-D) > > > > > > > > > > > > Hi Vidya, > > > > > > > > But the AAA could notify the HA (via the HA-AAA interface > > > for which we > > > > are specifying requirements in MIP6) about the Disconnect > > prior to > > > > sending the Disconnect to the NAS. And this would allow a > > graceful > > > > detach from the HA?? > > > > > > > > -Raj > > > > > > > > > > > > On 8/29/07 12:53 AM, "ext Narayanan, Vidya" > > > > wrote: > > > > > > > > > Hi Ahmad, > > > > > The point I was making is that the AAA disconnect messages > > > > are sent to > > > > > the NAS, not the HA - that causes network access being > > > > terminated for > > > > > the MN. The MN won't even get the MIP6 revocation message > > > > once network > > > > > access is revoked. > > > > > > > > > > I realize that the MIP4 revocation is also supported in the > > > > spec for MNs > > > > > in CCoA mode - but, I'm not aware of any real world > use of that. > > > > > > > > > > Regards, > > > > > Vidya > > > > > > > > > >> -----Original Message----- > > > > >> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > > >> Sent: Tuesday, August 28, 2007 8:52 PM > > > > >> To: Narayanan, Vidya; Basavaraj Patil; Mobile IPv6 > > Mailing List; > > > > >> Jonne Soininen > > > > >> Cc: Gopal Dommety > > > > >> Subject: RE: Need for revocation in MIP6 (RE: [Mip6] > Consensus > > > > >> call: Adopting I-D) > > > > >> > > > > >> Hi Vidya, > > > > >> > > > > >> Thanks Vidya for the question. I actually was planning > > to check > > > > >> with you and Jonnie on this topic but I had been very > > > busy here at > > > > >> 3GPP2 meeting and I had to go out to eat:-( > > > > >> > > > > >> I believe that we, earlier, had quite good amount of > > > discussion on > > > > >> this topic, however, I must admit it was mixed with > revocation > > > > >> applicability to PMIPv6 too. > > > > >> > > > > >> Now, let me try to address your MIPv6 specific question. > > > > >> There is one scenario when the HA would like to > revoke the MN > > > > >> session, for example: > > > > >> administrative reasons. As you said, Disconnect > > message could be > > > > >> sent to the HA for that purpose. Now: I, at least, > > think of two > > > > >> options here: > > > > >> > > > > >> Option 1. The HA deletes the binding cache entry and > > > forget about > > > > >> the mobile node and the HA starts dropping the MN > > > packets/traffic, > > > > >> I would call this "a bad customer service and a bad > > example that > > > > >> operators would like to avoid such a non-graceful revocation > > > > >> mechanism" > > > > >> > > > > >> Option 2. As soon as the HA receives the Disconnect > > message, for > > > > >> example, the HA sends a revocation message and informs > > > the MN that > > > > >> its binding has been revoked with the proper code > which should > > > > >> indicate the reason behind revoking the MN binding. In > > > that case, > > > > >> MN probably can delete its binding with other CN or, > at least, > > > > >> gives the MN a chance to start a simple IP session, > > for example, > > > > >> etc. > > > > >> > > > > >> Now since you mentioned MIPv4 Revocation, I would like > > > to mention > > > > >> that long time ago, early 2002, there has been a lot of > > > discussion > > > > >> during > > > > >> RFC3543 development which was translated into allowing > > the MN to > > > > >> clearly indicate if it (the MN) needs to be informed > when its > > > > >> session is revoked or NOT. There is an "I" bit in the > > revocation > > > > >> extension. That is similar to the case in MIPv6. > > > > >> Not only that, but RFC3543, Registration Revocation in > > > Mobile IPv4, > > > > >> also addresses MIPv4 registration in the case of Co-CoA > > > sessions. > > > > >> This is exactly the same as in MIPv6. > > > > >> > > > > >> Having said the above, I believe that revocation > mechanism is > > > > >> needed in multiple scenarios which were presented in Chicago > > > > >> meeting as follows: > > > > >> > > > > >> 1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg) 2. Revoking a > > > > >> PMIPv6 session. (PMIPv6 - Netlmm wg) 3. Revoking a specific > > > > >> Care-of-Address for a multiple care-of-addresses sessions > > > > (Monami6 wg) > > > > >> > > > > >> The common thing for all of these scenarios is that all > > > of them use > > > > >> an extension of MIPv6 protocol. Since one simple > mechanism can > > > > >> address all of these scenarios, then one draft would > > be the best > > > > >> choice. As I said earlier there is already a precedent > > > at IETF with > > > > >> DS-MIPv6. IMHO, it does make a lot of sense to address > > > all of these > > > > >> scenarios which happen to extend across several wgs in > > a single > > > > >> draft using one simple and generic mechanism. > > > > >> > > > > >> Finally, in fairness to all the fine people who thus far > > > supported > > > > >> this draft as MIP6 wg document, I believe their support > > > was based > > > > >> on the applicability of this draft to MIPv6 and PMIPv6 > > and I am > > > > >> sure some of them also have Monami6 applicability in mind. > > > > >> > > > > >> > > > > >> Best Regards, > > > > >> Ahmad > > > > >> > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > >>> Sent: Tuesday, August 28, 2007 8:43 PM > > > > >>> To: Basavaraj Patil; Mobile IPv6 Mailing List; > Jonne Soininen > > > > >>> Cc: Gopal Dommety > > > > >>> Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus > > > > >>> call: Adopting I-D) > > > > >>> > > > > >>> Raj, all, > > > > >>> I'd like to understand the need for revocation in MIP6 > > > better. I > > > > >>> think we've had a discussion on how to do revocation, but, > > > > >> not so much > > > > >>> on why we would need it for MIP6. Please note that > > > this is not a > > > > >>> discussion on > > > > >>> PMIPv6 - I'm trying to specifically understand this in the > > > > >> context of > > > > >>> MIP6. > > > > >>> > > > > >>> A revocation mechanism was developed for MIP4 to allow a > > > > >> clean up of > > > > >>> resources at the mobility agents (FA/HA). The philosphy of > > > > >> revocation > > > > >>> applies to managed networks and in such networks, a AAA > > > disconnect > > > > >>> message (or equivalent) is likely to first cut off any > > > > >> network access > > > > >>> to the MNs before even MIP6 has a chance to revocate > > > > anything - so, > > > > >>> I'm not sure I understand why we need revocation. > > Note that the > > > > >>> non-MIP6 mechanism is needed regardless so that network > > > > >> access can be > > > > >>> revoked for nodes not using MIP6 as well. > > > > >>> > > > > >>> I've seen a number of people support adoption of this > > > draft - so, > > > > >>> perhaps there is a good reason for it that I'm just not > > > > >> seeing. I'd > > > > >>> appreciate a clarification. > > > > >>> > > > > >>> Thanks, > > > > >>> Viday > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > >>>> Sent: Tuesday, August 28, 2007 9:25 AM > > > > >>>> To: Narayanan, Vidya; Mobile IPv6 Mailing List; > > Jonne Soininen > > > > >>>> Cc: Gopal Dommety > > > > >>>> Subject: Re: [Mip6] Consensus call: Adopting I-D > > > > >>>> > > > > >>>> > > > > >>>> Hi Vidya, > > > > >>>> > > > > >>>> In the context of the MIP6 charter: > > > > >>>> " > > > > >>>> The primary goal of the MIP6 working group will be to > > > > enhance base > > > > >>>> IPv6 mobility by continuing work on developments that are > > > > >>> required for > > > > >>>> wide-scale deployments. > > > > >>>> " > > > > >>>> > > > > >>>> Binding revocation is a feature that is required from > > > deployments > > > > >>>> perspective and hence it fits into the current charter. > > > > >>>> > > > > >>>> Since MEXT is essentially a consolidation of multiple > > > > >> MIP6 related > > > > >>>> WGs, I believe this work item would be a carryover from > > > > >>> MIP6 to MEXT. > > > > >>>> > > > > >>>> Having said that, I do however have some questions about > > > > >>> this document > > > > >>>> scope that is related to Netlmm. > > > > >>>> > > > > >>>> This I-D is specifying a binding revocation > > mechanism that is > > > > >>>> applicable to > > > > >>>> MIP6 and PMIP6. The consensus call is in the MIP6 WG. I > > > > >> think that > > > > >>>> given the > > > > >>>> PMIP6 aspects included in this I-D, it would make sense > > > > >> to consult > > > > >>>> with you and Jonne (Netlmm chairs) about opinions on > > this I-D. > > > > >>>> > > > > >>>> The MIP6 WG charter and scope is focused on > extensions to the > > > > >>>> MIP6 protocol > > > > >>>> (RFC3775) and issues related to base MIP6. From a charter > > > > >> and scope > > > > >>>> perspective, this I-D oversteps the boundaries of MIP6 and > > > > >>> is treading > > > > >>>> in Netlmm waters. > > > > >>>> It is possible that the feature which addresses MIP6 and > > > > >>>> PMIP6 can be done as a joint WG item (MIP6/MEXT > and Netlmm). > > > > >>>> But I want to make sure that Netlmm is aware of it and > > > > >>> supports it as > > > > >>>> well. > > > > >>>> > > > > >>>> If the binding revocation feature were to be done only as a > > > > >>>> MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would > > > > >> have to be > > > > >>>> removed and any enhancements needed to make binding > > > > >>> revocation work in > > > > >>>> the case of PMIP6 would have to be done in Netlmm. > > > > >>>> > > > > >>>> -Raj > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> On 8/27/07 8:13 PM, "ext Narayanan, Vidya" > > > > >>>> wrote: > > > > >>>> > > > > >>>>> A meta question concerning this draft - how does it fit > > > > >> into the > > > > >>>>> current > > > > >>>>> MIP6 or proposed MEXT charter? > > > > >>>>> > > > > >>>>> Thanks, > > > > >>>>> Vidya > > > > >>>>> > > > > >>>>>> -----Original Message----- > > > > >>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > >>>>>> Sent: Thursday, August 23, 2007 10:16 AM > > > > >>>>>> To: Mobile IPv6 Mailing List > > > > >>>>>> Cc: Gopal Dommety > > > > >>>>>> Subject: [Mip6] Consensus call: Adopting I-D > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Hello, > > > > >>>>>> > > > > >>>>>> This is a consensus call for adopting I-D: Binding > > > > >> Revocation for > > > > >>>>>> IPv6 Mobility > > > > >> as a > > > > >>>>>> MIP6 WG document. > > > > >>>>>> > > > > >>>>>> The I-D has been discussed on the ML in the past and > > > was also > > > > >>>>>> presented at > > > > >>>>>> IETF69 in Chicago. > > > > >>>>>> > > > > >>>>>> So please opine on the following statement: > > > > >>>>>> > > > > >>>>>> The binding revocation feature specified in I-D > > > > >>>>>> draft-muhanna-mip6-binding-revocation-01.txt is > > essential for > > > > >>>>>> MIP6 deployments and hence should be made a MIP6 WG > > > > >> document and > > > > >>>>>> progressed as a standards track doc. > > > > >>>>>> > > > > >>>>>> Yes [ ] > > > > >>>>>> No [ ] > > > > >>>>>> > > > > >>>>>> -Raj > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> _______________________________________________ > > > > >>>>>> Mip6 mailing list > > > > >>>>>> Mip6@ietf.org > > > > >>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > >>>>>> > > > > >>>> > > > > >>>> > > > > >>> > > > > >>> _______________________________________________ > > > > >>> Mip6 mailing list > > > > >>> Mip6@ietf.org > > > > >>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > >>> > > > > >> > > > > > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 15:05:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSr3-0008AV-5F; Wed, 29 Aug 2007 15:05:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSqv-00087k-71 for mip6@ietf.org; Wed, 29 Aug 2007 15:05:21 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQSqu-00055C-Fy for mip6@ietf.org; Wed, 29 Aug 2007 15:05:21 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7TJ50n00397; Wed, 29 Aug 2007 19:05:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call: Adopting I-D Date: Wed, 29 Aug 2007 14:04:52 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371166FE6DF@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Consensus call: Adopting I-D Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgACTzG8AAo7HTbAAV0dtA= References: <6FC4416DDE56C44DA0AEE67BC7CA4371166B83F1@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Basavaraj Patil" , "ext Narayanan, Vidya" , "Mobile IPv6 Mailing List" , "Jonne Soininen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: Gopal Dommety , Sri Gundavelli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Raj, I agree.=20 All what I am saying is: addressing revocation for all related MIP6 protocols in one document is the best option. However, as you said, in that case, it needs to be a joint draft. Regards, Ahmad =20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com]=20 > Sent: Wednesday, August 29, 2007 12:22 PM > To: Muhanna, Ahmad (RICH1:2H10); ext Narayanan, Vidya; Mobile=20 > IPv6 Mailing List; Jonne Soininen > Cc: Gopal Dommety; Sri Gundavelli > Subject: Re: [Mip6] Consensus call: Adopting I-D >=20 >=20 > Ahmad, >=20 > DS-MIP6 is not really a precedent. Work on DS-MIP6 has been=20 > ongoing for quite a while now (couple of years at least). The=20 > DS-MIP6 I-D has been developed as a solution for MIP6 and the=20 > design considerations in the document precede any PMIP6=20 > discussion in the IETF. DS-MIP6 is a joint MIP6/NEMO WGs effort. >=20 > If the binding revocation mechanism for MIP6 and PMIP6 were=20 > to be specified in a single I-D, it would have to be a joint=20 > WG item (MIP6/Netlmm). > Else, scope of I-D will need to change. >=20 > -Raj >=20 >=20 > On 8/28/07 4:22 PM, "ext Ahmad Muhanna" wrote: >=20 > > Hi Raj, > >=20 > > I agree; the scope of the work extends to Mobile IPv6 and=20 > Proxy Mobile=20 > > IPv6. As we stated in our presentation in Chicago meeting, the=20 > > semantics and the messaging we are defining for supporting Binding=20 > > Revocation should address the requirements of both MIP6 and Netlmm=20 > > WG's. > > It is exactly the same as how the work of DS-MIP6 is being=20 > leveraged=20 > > by NETLMM and NEMO WG's. > >=20 > > IMHO, Revocation should fall in the same category. That is=20 > the reason=20 > > why we titled the draft Binding Revocation for IPv6 mobility:-) The=20 > > purpose of the messages, the formats and the actions can all be=20 > > captured in a common document. Defining multiple documents for this=20 > > simple messaging is not a good idea, I hope we as a group will take=20 > > the best decision on this, especially, as I just said that there is=20 > > already a precedent in the case of DS-MIPv6 draft. > >=20 > > We will be happy to work with the NETLMM chairs and the AD=20 > to get this=20 > > adopted as a joint WG document. > >=20 > > Best Regards, > > Ahmad > > =20 > >=20 > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >> Sent: Tuesday, August 28, 2007 12:25 PM > >> To: ext Narayanan, Vidya; Mobile IPv6 Mailing List; Jonne Soininen > >> Cc: Gopal Dommety > >> Subject: Re: [Mip6] Consensus call: Adopting I-D > >>=20 > >>=20 > >> Hi Vidya, > >>=20 > >> In the context of the MIP6 charter: > >> " > >> The primary goal of the MIP6 working group will be to enhance base > >> IPv6 mobility by continuing work on developments that are required=20 > >> for wide-scale deployments. > >> " > >>=20 > >> Binding revocation is a feature that is required from deployments=20 > >> perspective and hence it fits into the current charter. > >>=20 > >> Since MEXT is essentially a consolidation of multiple MIP6 related=20 > >> WGs, I believe this work item would be a carryover from=20 > MIP6 to MEXT. > >>=20 > >> Having said that, I do however have some questions about this=20 > >> document scope that is related to Netlmm. > >>=20 > >> This I-D is specifying a binding revocation mechanism that is=20 > >> applicable to > >> MIP6 and PMIP6. The consensus call is in the MIP6 WG. I think that=20 > >> given the > >> PMIP6 aspects included in this I-D, it would make sense to consult=20 > >> with you and Jonne (Netlmm chairs) about opinions on this I-D. > >>=20 > >> The MIP6 WG charter and scope is focused on extensions to the > >> MIP6 protocol > >> (RFC3775) and issues related to base MIP6. From a charter=20 > and scope=20 > >> perspective, this I-D oversteps the boundaries of MIP6 and is=20 > >> treading in Netlmm waters. > >> It is possible that the feature which addresses MIP6 and > >> PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm). > >> But I want to make sure that Netlmm is aware of it and=20 > supports it as=20 > >> well. > >>=20 > >> If the binding revocation feature were to be done only as a > >> MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would=20 > have to be=20 > >> removed and any enhancements needed to make binding=20 > revocation work=20 > >> in the case of PMIP6 would have to be done in Netlmm. > >>=20 > >> -Raj > >> =20 > >>=20 > >>=20 > >> On 8/27/07 8:13 PM, "ext Narayanan, Vidya" > >> wrote: > >>=20 > >>> A meta question concerning this draft - how does it fit into the=20 > >>> current > >>> MIP6 or proposed MEXT charter? > >>>=20 > >>> Thanks, > >>> Vidya > >>>=20 > >>>> -----Original Message----- > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > >>>> Sent: Thursday, August 23, 2007 10:16 AM > >>>> To: Mobile IPv6 Mailing List > >>>> Cc: Gopal Dommety > >>>> Subject: [Mip6] Consensus call: Adopting I-D > >>>>=20 > >>>>=20 > >>>> Hello, > >>>>=20 > >>>> This is a consensus call for adopting I-D: Binding Revocation for > >>>> IPv6 Mobility as a > >>>> MIP6 WG document. > >>>>=20 > >>>> The I-D has been discussed on the ML in the past and was also=20 > >>>> presented at > >>>> IETF69 in Chicago. > >>>>=20 > >>>> So please opine on the following statement: > >>>>=20 > >>>> The binding revocation feature specified in I-D=20 > >>>> draft-muhanna-mip6-binding-revocation-01.txt is essential for > >>>> MIP6 deployments and hence should be made a MIP6 WG document and=20 > >>>> progressed as a standards track doc. > >>>>=20 > >>>> Yes [ ] > >>>> No [ ] > >>>>=20 > >>>> -Raj > >>>>=20 > >>>>=20 > >>>> _______________________________________________ > >>>> Mip6 mailing list > >>>> Mip6@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/mip6 > >>>>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 15:44:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQTSZ-0003te-36; Wed, 29 Aug 2007 15:44:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQTSS-0003cy-M7 for mip6@ietf.org; Wed, 29 Aug 2007 15:44:10 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQTSS-0007Cs-9v for mip6@ietf.org; Wed, 29 Aug 2007 15:44:08 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CD61A19865F; Wed, 29 Aug 2007 22:44:06 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7B96C19865B; Wed, 29 Aug 2007 22:44:06 +0300 (EEST) Message-ID: <46D5B494.3060600@piuha.net> Date: Wed, 29 Aug 2007 21:01:56 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Mobile IPv6 Mailing List , draft-ietf-mip6-ha-switch@tools.ietf.org Subject: [Mip6] draft-ietf-mip6-ha-switch AD review X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I have made my AD review on this draft. The draft is OK and has been sent for IETF Last Call. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 16:24:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQU5f-0008LC-Do; Wed, 29 Aug 2007 16:24:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQU5Y-0008KX-Vu for mip6@ietf.org; Wed, 29 Aug 2007 16:24:33 -0400 Received: from atlrel9.hp.com ([156.153.255.214]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQU5Y-000226-Fv for mip6@ietf.org; Wed, 29 Aug 2007 16:24:32 -0400 Received: from smtp1.fc.hp.com (smtp.cnd.hp.com [15.15.136.127]) by atlrel9.hp.com (Postfix) with ESMTP id BA5A839292; Wed, 29 Aug 2007 16:24:06 -0400 (EDT) Received: from [16.116.96.52] (wrx.zko.hp.com [16.116.96.52]) by smtp1.fc.hp.com (Postfix) with ESMTP id 32DF51B3F6B; Wed, 29 Aug 2007 20:24:06 +0000 (UTC) Message-ID: <46D5D5E5.40000@hp.com> Date: Wed, 29 Aug 2007 16:24:05 -0400 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Consensus call: Adopting I-D References: <46D30D7C.8040508@azairenet.com> In-Reply-To: <46D30D7C.8040508@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Gopal Dommety , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, Vijay Devarapalli wrote: > Hi Raj, > > I do agree that we need to standardize a binding revocation mechanism. > But I am not sure about adopting > draft-muhanna-mip6-binding-revocation-01.txt. If we are adopting this > document, we need substantial changes. My comments at a high level > > 1. I had argued for using mobility options in the generic mobility > header signaling message to carry the revocation information. Those > changes haven't been done yet. Also, I don't believe we have consensus > on changing the format of the generic mobility header signaling message > to include a sub-type. I guess that is the current assumption. I am in the process of doing these changes, I'm just incorporating some feedback now. As far as consensus, I sent email to the list back on 6/4 and had very little feedback. In short, there were only two "votes": Ryuji: Yes Vijay: No Since the three authors (Sri, Ahmad and myself) came to agreement on the changes I'm going to make them. If the WG doesn't like them when it's posted I'll be happy to revisit them to make everyone happy, but supporting the revocation work with the mechanism was a driver for the changes. -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 16:49:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQUTZ-0002rV-QT; Wed, 29 Aug 2007 16:49:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQUTV-0002mH-Gh for mip6@ietf.org; Wed, 29 Aug 2007 16:49:17 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQUTU-0001K3-Ai for mip6@ietf.org; Wed, 29 Aug 2007 16:49:17 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7TKn8n01459; Wed, 29 Aug 2007 20:49:08 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call: Adopting I-D Date: Wed, 29 Aug 2007 15:48:12 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116741855@zrc2hxm2.corp.nortel.com> In-Reply-To: <46D5D5E5.40000@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Consensus call: Adopting I-D Thread-Index: Acfqeqfkl4AEFsVHQPivVBoXrzLDtAAAJqkQ References: <46D30D7C.8040508@azairenet.com> <46D5D5E5.40000@hp.com> From: "Ahmad Muhanna" To: "Brian Haley" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Gopal Dommety , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Brian, Thanks for making the changes.=20 I may also add that I presented the revocation draft during Chicago IETF MIP6 meeting using the same format that we agreed on and you proposed on the mailing list on 6/4 and there was no objection to the proposed format. Regards, Ahmad =20 > -----Original Message----- > From: Brian Haley [mailto:brian.haley@hp.com]=20 > Sent: Wednesday, August 29, 2007 4:24 PM > To: Vijay Devarapalli > Cc: Gopal Dommety; Mobile IPv6 Mailing List > Subject: Re: [Mip6] Consensus call: Adopting I-D >=20 > Hi Vijay, >=20 > Vijay Devarapalli wrote: > > Hi Raj, > >=20 > > I do agree that we need to standardize a binding revocation=20 > mechanism.=20 > > But I am not sure about adopting > > draft-muhanna-mip6-binding-revocation-01.txt. If we are=20 > adopting this=20 > > document, we need substantial changes. My comments at a high level > >=20 > > 1. I had argued for using mobility options in the generic mobility=20 > > header signaling message to carry the revocation information. Those=20 > > changes haven't been done yet. Also, I don't believe we=20 > have consensus=20 > > on changing the format of the generic mobility header signaling=20 > > message to include a sub-type. I guess that is the current=20 > assumption. >=20 > I am in the process of doing these changes, I'm just=20 > incorporating some feedback now. >=20 > As far as consensus, I sent email to the list back on 6/4 and=20 > had very little feedback. In short, there were only two "votes": >=20 > Ryuji: Yes > Vijay: No >=20 > Since the three authors (Sri, Ahmad and myself) came to=20 > agreement on the changes I'm going to make them. If the WG=20 > doesn't like them when it's posted I'll be happy to revisit=20 > them to make everyone happy, but supporting the revocation=20 > work with the mechanism was a driver for the changes. >=20 > -Brian >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 17:11:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQUoy-0004iw-F5; Wed, 29 Aug 2007 17:11:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQUop-0004ch-R2; Wed, 29 Aug 2007 17:11:20 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQUoo-00023T-K4; Wed, 29 Aug 2007 17:11:19 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id EDF44E0445; Wed, 29 Aug 2007 14:09:26 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20070829210926.EDF44E0445@bosco.isi.edu> Date: Wed, 29 Aug 2007 14:09:26 -0700 (PDT) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: mip6@ietf.org, rfc-editor@rfc-editor.org Subject: [Mip6] RFC 4977 on Problem Statement: Dual Stack Mobility X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4977 Title: Problem Statement: Dual Stack Mobility Author: G. Tsirtsis, H. Soliman Status: Informational Date: August 2007 Mailbox: tsirtsis@qualcomm.com, hesham@elevatemobile.com Pages: 8 Characters: 16758 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mip6-dsmip-problem-03.txt URL: http://www.rfc-editor.org/rfc/rfc4977.txt This document discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of problems. Deployment and operational issues motivate the use of a single mobility management protocol. This document discusses such motivations. The document also discusses requirements for the Mobile IPv4 (MIPv4) and Mobile IPv6 (MIPv6) protocol so that they can support mobility management for a dual stack node. This memo provides information for the Internet community. This document is a product of the Mobility for IPv6 Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Aug 29 17:24:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQV1V-0006Ih-CF; Wed, 29 Aug 2007 17:24:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQUwt-0004As-J2 for mip6@ietf.org; Wed, 29 Aug 2007 17:19:39 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQUty-0002cE-8n for mip6@ietf.org; Wed, 29 Aug 2007 17:16:39 -0400 Received: from [127.0.0.1] ([192.130.163.105]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 14:16:36 -0700 Message-ID: <46D5E22E.5030403@azairenet.com> Date: Wed, 29 Aug 2007 14:16:30 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Haley Subject: Re: [Mip6] Consensus call: Adopting I-D References: <46D30D7C.8040508@azairenet.com> <46D5D5E5.40000@hp.com> In-Reply-To: <46D5D5E5.40000@hp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2007 21:16:36.0844 (UTC) FILETIME=[E21ADAC0:01C7EA81] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Gopal Dommety , Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Brian, The Mobility Header signaling message is still an individual draft. The authors are free to make any changes they want to the document. I know there was a consensus call run to adopt this draft as a WG document, but the one presented to the WG was the one with previous format. Not the new one. Vijay Brian Haley wrote: > Hi Vijay, > > Vijay Devarapalli wrote: >> Hi Raj, >> >> I do agree that we need to standardize a binding revocation mechanism. >> But I am not sure about adopting >> draft-muhanna-mip6-binding-revocation-01.txt. If we are adopting this >> document, we need substantial changes. My comments at a high level >> >> 1. I had argued for using mobility options in the generic mobility >> header signaling message to carry the revocation information. Those >> changes haven't been done yet. Also, I don't believe we have consensus >> on changing the format of the generic mobility header signaling >> message to include a sub-type. I guess that is the current assumption. > > I am in the process of doing these changes, I'm just incorporating some > feedback now. > > As far as consensus, I sent email to the list back on 6/4 and had very > little feedback. In short, there were only two "votes": > > Ryuji: Yes > Vijay: No > > Since the three authors (Sri, Ahmad and myself) came to agreement on the > changes I'm going to make them. If the WG doesn't like them when it's > posted I'll be happy to revisit them to make everyone happy, but > supporting the revocation work with the mechanism was a driver for the > changes. > > -Brian _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Aug 30 02:43:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQdk6-0000JT-2n; Thu, 30 Aug 2007 02:43:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQdk4-0000JJ-LS for mip6@ietf.org; Thu, 30 Aug 2007 02:43:00 -0400 Received: from [2001:200:601:12:230:48ff:fe22:3a84] (helo=mandala.kddilabs.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQdk4-0000bn-9n for mip6@ietf.org; Thu, 30 Aug 2007 02:43:00 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 9614EEC9E9 for ; Thu, 30 Aug 2007 15:42:58 +0900 (JST) Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [2001:200:601:402::145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 5A135EC9E3 for ; Thu, 30 Aug 2007 15:42:58 +0900 (JST) Received: from [172.19.87.30] (c030.vpn.kddilabs.jp [172.19.87.30]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 50D721BA74 for ; Thu, 30 Aug 2007 15:38:39 +0900 (JST) Message-ID: <46D666E9.7020403@kddilabs.jp> Date: Thu, 30 Aug 2007 15:42:49 +0900 From: Hidetoshi Yokota User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mip6@ietf.org Subject: Re: [Mip6] Consensus call: Adopting I-D Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: -1.4 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj and all, Sorry for this late support. There seems to be a couple of issues raised on this I-D, but I believe this deserves the WG draft. Hence: The binding revocation feature specified in I-D draft-muhanna-mip6-binding-revocation-01.txt is essential for MIP6 deployments and hence should be made a MIP6 WG document and progressed as a standards track doc. Yes [X] No [ ] -- Hidetoshi _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Aug 30 05:59:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQgoO-00025i-JV; Thu, 30 Aug 2007 05:59:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQgoN-00023t-DO for mip6@ietf.org; Thu, 30 Aug 2007 05:59:39 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQgoL-0001C7-Ji for mip6@ietf.org; Thu, 30 Aug 2007 05:59:39 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7U9xZ8H016450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Aug 2007 02:59:35 -0700 Received: from SANEXCAS03.na.qualcomm.com (sanexcas03.qualcomm.com [172.30.32.65]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7U9xYoD016902; Thu, 30 Aug 2007 02:59:35 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Aug 2007 02:59:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus call:AdoptingI-D) Date: Thu, 30 Aug 2007 02:59:32 -0700 Message-ID: In-Reply-To: <027e01c7ea68$8fdfb690$d4f6200a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for revocation in MIP6 (RE: [Mip6] Consensus call:AdoptingI-D) Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgAES6mwAAGAyOQAAS76tAAF3CTIQABOiKAAAEkG9AAADDq0AAg9WvQ From: "Giaretta, Gerardo" To: "Sri Gundavelli" , "Narayanan, Vidya" , "Basavaraj Patil" , "Ahmad Muhanna" , "Mobile IPv6 Mailing List" , "Jonne Soininen" X-OriginalArrivalTime: 30 Aug 2007 09:59:34.0851 (UTC) FILETIME=[77EC6130:01C7EAEC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d9aaf4f837d0910b987cb9188300fdd Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Sri, >=20 > HA reboot is not a policy event. HA is rebooting, it wants to > send a graceful event to the mobile. I dont see why AAA function > should be involved here. This is one usecase. Again, 3775 does > not assume AAA entity in the mobility infrastructure and so > the signaling has to be based on MIP6 signaling. >=20 HA rebooting/maintenance was one of the motivations to define the HA switch message as explained in section 2.3 of draft-ietf-mip6-ha-switch-03.txt I think the operator will switch the user to another HA in case of reboot of HA and prefer not to break the mobility service.=20 Therefore I don't think this is a valid use case for this draft.=20 > Extending this further, offering mobility service involves > some policy aspect. So, it is possible to get rid of MIP6 > signaling and let AAA notify both HA and MN to setup the > binding state. >=20 Again, can you clarify the different use cases for the HA switch message and the revocation message?=20 Sorry, I may be missing something as I did not attend the Chicago presentation and proceedings are not available yet. Thanks Gerardo > Sure, no need to bring NETLMM usecases for this discussion. >=20 > Sri >=20 >=20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Wednesday, August 29, 2007 11:08 AM > > To: Sri Gundavelli; Basavaraj Patil; Ahmad Muhanna; Mobile > > IPv6 Mailing List; Jonne Soininen > > Cc: Gopal Dommety > > Subject: RE: Need for revocation in MIP6 (RE: [Mip6] > > Consensus call:Adopting I-D) > > > > > > Doing "HA switch" or "Notifications" or "HA Reliability" via > > AAA doesn't > > make sense - those are functions of MIP6. Revocation is a > > policy thing > > and is associated with AAA or an equivalent entity (HSS or whatever > > other entity). I don't believe we are making the right comparisons > > here. > > > > Of all the items listed, I can perhaps see the need for NETLMM, for > > cleaning up MAG resources upon revocation of the MN. For > > NEMO, MIP6 or > > MONAMI6, I don't see the point. And, I particularly don't want to > > discuss the NETLMM need here at this time, since we haven't yet > > discussed it in the NETLMM WG. For the purpose of MEXT, I'm > > not seeing > > the practical need for revocation. > > > > Vidya > > > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > Sent: Wednesday, August 29, 2007 10:47 AM > > > To: 'Basavaraj Patil'; Narayanan, Vidya; 'Ahmad Muhanna'; > > > 'Mobile IPv6 Mailing List'; 'Jonne Soininen' > > > Cc: 'Gopal Dommety' > > > Subject: RE: Need for revocation in MIP6 (RE: [Mip6] > > > Consensus call:Adopting I-D) > > > > > > I was not following this thread ... just a comment on this. > > > No time for long discussions. > > > > > > > > > We cannot just assume AAA to be deployed in the network and > > > assume the entire revocation to be activated and managed > > > through AAA. Pretty much all the specs, including "HA > > > Switchover", "Notifications", "HA Reliability" ... every > > > thing could be achieved through AAA. What we need is a > > > mobility messaging and with no assumption on the presence of > > > AAA. 3775 does not assume AAA on the network either. AAA is > > > not mandataroy for mobility to be achieved. > > > That is just one interface most useful for cellular networks. > > > I dont know if any one would apply AAA for enterprise mobility. > > > > > > Now, if the case where AAA interface is not present, if HA > > > wants to revoke the mobile node's binding, it needs a > > > mechanism to notify the mobile node and the spec defines the > > > signaling for that. > > > > > > Regarding the scope of the work, we cannot expect every WG to > > > go and define the same protocol, changing the entity names > > > and by defining a new usecase. If some one goes and defines > > > Revocation for PMIP6, the work is not going to be vastly > > > different. Its the same messaging and with a different title. > > > If we look at this work in the sense of project management, > > > this work should be done once and leveraged by other WG's > > > (That's been Jari's position regarding leveraging work). > > > Again, just as how DSMIP6 work is being leveraged in 10 > > > different places. That really helped and in the same way, > > > this work should be done just in the base MIP6 group and be > > > leveraged by other WG's. Hope, this work will be adopted as a > > > joint WG item across NEMO, MIP6, NETLMM and MONAMI6. > > > > > > Sri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > Sent: Wednesday, August 29, 2007 9:56 AM > > > > To: ext Narayanan, Vidya; Ahmad Muhanna; Mobile IPv6 > > Mailing List; > > > > Jonne Soininen > > > > Cc: Gopal Dommety > > > > Subject: Re: Need for revocation in MIP6 (RE: [Mip6] Consensus > > > > call:Adopting I-D) > > > > > > > > > > > > Hi Vidya, > > > > > > > > But the AAA could notify the HA (via the HA-AAA interface > > > for which we > > > > are specifying requirements in MIP6) about the Disconnect > > prior to > > > > sending the Disconnect to the NAS. And this would allow a > > graceful > > > > detach from the HA?? > > > > > > > > -Raj > > > > > > > > > > > > On 8/29/07 12:53 AM, "ext Narayanan, Vidya" > > > > wrote: > > > > > > > > > Hi Ahmad, > > > > > The point I was making is that the AAA disconnect messages > > > > are sent to > > > > > the NAS, not the HA - that causes network access being > > > > terminated for > > > > > the MN. The MN won't even get the MIP6 revocation message > > > > once network > > > > > access is revoked. > > > > > > > > > > I realize that the MIP4 revocation is also supported in the > > > > spec for MNs > > > > > in CCoA mode - but, I'm not aware of any real world use of that. > > > > > > > > > > Regards, > > > > > Vidya > > > > > > > > > >> -----Original Message----- > > > > >> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > > >> Sent: Tuesday, August 28, 2007 8:52 PM > > > > >> To: Narayanan, Vidya; Basavaraj Patil; Mobile IPv6 > > Mailing List; > > > > >> Jonne Soininen > > > > >> Cc: Gopal Dommety > > > > >> Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus > > > > >> call: Adopting I-D) > > > > >> > > > > >> Hi Vidya, > > > > >> > > > > >> Thanks Vidya for the question. I actually was planning > > to check > > > > >> with you and Jonnie on this topic but I had been very > > > busy here at > > > > >> 3GPP2 meeting and I had to go out to eat:-( > > > > >> > > > > >> I believe that we, earlier, had quite good amount of > > > discussion on > > > > >> this topic, however, I must admit it was mixed with revocation > > > > >> applicability to PMIPv6 too. > > > > >> > > > > >> Now, let me try to address your MIPv6 specific question. > > > > >> There is one scenario when the HA would like to revoke the MN > > > > >> session, for example: > > > > >> administrative reasons. As you said, Disconnect > > message could be > > > > >> sent to the HA for that purpose. Now: I, at least, > > think of two > > > > >> options here: > > > > >> > > > > >> Option 1. The HA deletes the binding cache entry and > > > forget about > > > > >> the mobile node and the HA starts dropping the MN > > > packets/traffic, > > > > >> I would call this "a bad customer service and a bad > > example that > > > > >> operators would like to avoid such a non-graceful revocation > > > > >> mechanism" > > > > >> > > > > >> Option 2. As soon as the HA receives the Disconnect > > message, for > > > > >> example, the HA sends a revocation message and informs > > > the MN that > > > > >> its binding has been revoked with the proper code which should > > > > >> indicate the reason behind revoking the MN binding. In > > > that case, > > > > >> MN probably can delete its binding with other CN or, at least, > > > > >> gives the MN a chance to start a simple IP session, > > for example, > > > > >> etc. > > > > >> > > > > >> Now since you mentioned MIPv4 Revocation, I would like > > > to mention > > > > >> that long time ago, early 2002, there has been a lot of > > > discussion > > > > >> during > > > > >> RFC3543 development which was translated into allowing > > the MN to > > > > >> clearly indicate if it (the MN) needs to be informed when its > > > > >> session is revoked or NOT. There is an "I" bit in the > > revocation > > > > >> extension. That is similar to the case in MIPv6. > > > > >> Not only that, but RFC3543, Registration Revocation in > > > Mobile IPv4, > > > > >> also addresses MIPv4 registration in the case of Co-CoA > > > sessions. > > > > >> This is exactly the same as in MIPv6. > > > > >> > > > > >> Having said the above, I believe that revocation mechanism is > > > > >> needed in multiple scenarios which were presented in Chicago > > > > >> meeting as follows: > > > > >> > > > > >> 1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg) 2. Revoking a > > > > >> PMIPv6 session. (PMIPv6 - Netlmm wg) 3. Revoking a specific > > > > >> Care-of-Address for a multiple care-of-addresses sessions > > > > (Monami6 wg) > > > > >> > > > > >> The common thing for all of these scenarios is that all > > > of them use > > > > >> an extension of MIPv6 protocol. Since one simple mechanism can > > > > >> address all of these scenarios, then one draft would > > be the best > > > > >> choice. As I said earlier there is already a precedent > > > at IETF with > > > > >> DS-MIPv6. IMHO, it does make a lot of sense to address > > > all of these > > > > >> scenarios which happen to extend across several wgs in > > a single > > > > >> draft using one simple and generic mechanism. > > > > >> > > > > >> Finally, in fairness to all the fine people who thus far > > > supported > > > > >> this draft as MIP6 wg document, I believe their support > > > was based > > > > >> on the applicability of this draft to MIPv6 and PMIPv6 > > and I am > > > > >> sure some of them also have Monami6 applicability in mind. > > > > >> > > > > >> > > > > >> Best Regards, > > > > >> Ahmad > > > > >> > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > >>> Sent: Tuesday, August 28, 2007 8:43 PM > > > > >>> To: Basavaraj Patil; Mobile IPv6 Mailing List; Jonne Soininen > > > > >>> Cc: Gopal Dommety > > > > >>> Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus > > > > >>> call: Adopting I-D) > > > > >>> > > > > >>> Raj, all, > > > > >>> I'd like to understand the need for revocation in MIP6 > > > better. I > > > > >>> think we've had a discussion on how to do revocation, but, > > > > >> not so much > > > > >>> on why we would need it for MIP6. Please note that > > > this is not a > > > > >>> discussion on > > > > >>> PMIPv6 - I'm trying to specifically understand this in the > > > > >> context of > > > > >>> MIP6. > > > > >>> > > > > >>> A revocation mechanism was developed for MIP4 to allow a > > > > >> clean up of > > > > >>> resources at the mobility agents (FA/HA). The philosphy of > > > > >> revocation > > > > >>> applies to managed networks and in such networks, a AAA > > > disconnect > > > > >>> message (or equivalent) is likely to first cut off any > > > > >> network access > > > > >>> to the MNs before even MIP6 has a chance to revocate > > > > anything - so, > > > > >>> I'm not sure I understand why we need revocation. > > Note that the > > > > >>> non-MIP6 mechanism is needed regardless so that network > > > > >> access can be > > > > >>> revoked for nodes not using MIP6 as well. > > > > >>> > > > > >>> I've seen a number of people support adoption of this > > > draft - so, > > > > >>> perhaps there is a good reason for it that I'm just not > > > > >> seeing. I'd > > > > >>> appreciate a clarification. > > > > >>> > > > > >>> Thanks, > > > > >>> Viday > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > >>>> Sent: Tuesday, August 28, 2007 9:25 AM > > > > >>>> To: Narayanan, Vidya; Mobile IPv6 Mailing List; > > Jonne Soininen > > > > >>>> Cc: Gopal Dommety > > > > >>>> Subject: Re: [Mip6] Consensus call: Adopting I-D > > > > >>>> > > > > >>>> > > > > >>>> Hi Vidya, > > > > >>>> > > > > >>>> In the context of the MIP6 charter: > > > > >>>> " > > > > >>>> The primary goal of the MIP6 working group will be to > > > > enhance base > > > > >>>> IPv6 mobility by continuing work on developments that are > > > > >>> required for > > > > >>>> wide-scale deployments. > > > > >>>> " > > > > >>>> > > > > >>>> Binding revocation is a feature that is required from > > > deployments > > > > >>>> perspective and hence it fits into the current charter. > > > > >>>> > > > > >>>> Since MEXT is essentially a consolidation of multiple > > > > >> MIP6 related > > > > >>>> WGs, I believe this work item would be a carryover from > > > > >>> MIP6 to MEXT. > > > > >>>> > > > > >>>> Having said that, I do however have some questions about > > > > >>> this document > > > > >>>> scope that is related to Netlmm. > > > > >>>> > > > > >>>> This I-D is specifying a binding revocation > > mechanism that is > > > > >>>> applicable to > > > > >>>> MIP6 and PMIP6. The consensus call is in the MIP6 WG. I > > > > >> think that > > > > >>>> given the > > > > >>>> PMIP6 aspects included in this I-D, it would make sense > > > > >> to consult > > > > >>>> with you and Jonne (Netlmm chairs) about opinions on > > this I-D. > > > > >>>> > > > > >>>> The MIP6 WG charter and scope is focused on extensions to the > > > > >>>> MIP6 protocol > > > > >>>> (RFC3775) and issues related to base MIP6. From a charter > > > > >> and scope > > > > >>>> perspective, this I-D oversteps the boundaries of MIP6 and > > > > >>> is treading > > > > >>>> in Netlmm waters. > > > > >>>> It is possible that the feature which addresses MIP6 and > > > > >>>> PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm). > > > > >>>> But I want to make sure that Netlmm is aware of it and > > > > >>> supports it as > > > > >>>> well. > > > > >>>> > > > > >>>> If the binding revocation feature were to be done only as a > > > > >>>> MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would > > > > >> have to be > > > > >>>> removed and any enhancements needed to make binding > > > > >>> revocation work in > > > > >>>> the case of PMIP6 would have to be done in Netlmm. > > > > >>>> > > > > >>>> -Raj > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> On 8/27/07 8:13 PM, "ext Narayanan, Vidya" > > > > >>>> wrote: > > > > >>>> > > > > >>>>> A meta question concerning this draft - how does it fit > > > > >> into the > > > > >>>>> current > > > > >>>>> MIP6 or proposed MEXT charter? > > > > >>>>> > > > > >>>>> Thanks, > > > > >>>>> Vidya > > > > >>>>> > > > > >>>>>> -----Original Message----- > > > > >>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > >>>>>> Sent: Thursday, August 23, 2007 10:16 AM > > > > >>>>>> To: Mobile IPv6 Mailing List > > > > >>>>>> Cc: Gopal Dommety > > > > >>>>>> Subject: [Mip6] Consensus call: Adopting I-D > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Hello, > > > > >>>>>> > > > > >>>>>> This is a consensus call for adopting I-D: Binding > > > > >> Revocation for > > > > >>>>>> IPv6 Mobility > > > > >> as a > > > > >>>>>> MIP6 WG document. > > > > >>>>>> > > > > >>>>>> The I-D has been discussed on the ML in the past and > > > was also > > > > >>>>>> presented at > > > > >>>>>> IETF69 in Chicago. > > > > >>>>>> > > > > >>>>>> So please opine on the following statement: > > > > >>>>>> > > > > >>>>>> The binding revocation feature specified in I-D > > > > >>>>>> draft-muhanna-mip6-binding-revocation-01.txt is > > essential for > > > > >>>>>> MIP6 deployments and hence should be made a MIP6 WG > > > > >> document and > > > > >>>>>> progressed as a standards track doc. > > > > >>>>>> > > > > >>>>>> Yes [ ] > > > > >>>>>> No [ ] > > > > >>>>>> > > > > >>>>>> -Raj > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> _______________________________________________ > > > > >>>>>> Mip6 mailing list > > > > >>>>>> Mip6@ietf.org > > > > >>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > >>>>>> > > > > >>>> > > > > >>>> > > > > >>> > > > > >>> _______________________________________________ > > > > >>> Mip6 mailing list > > > > >>> Mip6@ietf.org > > > > >>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > >>> > > > > >> > > > > > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Aug 30 06:33:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQhL0-0007XW-KR; Thu, 30 Aug 2007 06:33:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQhKz-0007QD-8A for mip6@ietf.org; Thu, 30 Aug 2007 06:33:21 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQhKx-0002qm-5Q for mip6@ietf.org; Thu, 30 Aug 2007 06:33:20 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l7UAUN518865; Thu, 30 Aug 2007 10:30:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus call:AdoptingI-D) Date: Thu, 30 Aug 2007 05:32:23 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116741DD5@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for revocation in MIP6 (RE: [Mip6] Consensus call:AdoptingI-D) Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgAES6mwAAGAyOQAAS76tAAF3CTIQABOiKAAAEkG9AAADDq0AAg9WvQAAEEF4A= References: <027e01c7ea68$8fdfb690$d4f6200a@amer.cisco.com> From: "Ahmad Muhanna" To: "Giaretta, Gerardo" , "Sri Gundavelli" , "Narayanan, Vidya" , "Basavaraj Patil" , "Mobile IPv6 Mailing List" , "Jonne Soininen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 57b3d456dc4730784e7070d5c6b7d14f Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Gerardo, Please visit the below link for binding revocation presentation and the minutes was provided sometime back on the mailing list. http://www3.ietf.org/proceedings/07jul/slides/mip6-3/sld1.htm Regards, Ahmad =20 > -----Original Message----- > From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com]=20 > Sent: Thursday, August 30, 2007 6:00 AM > To: Sri Gundavelli; Narayanan, Vidya; Basavaraj Patil;=20 > Muhanna, Ahmad (RICH1:2H10); Mobile IPv6 Mailing List; Jonne Soininen > Cc: Gopal Dommety > Subject: RE: Need for revocation in MIP6 (RE: [Mip6]=20 > Consensus call:AdoptingI-D) >=20 > Hi Sri, >=20 > >=20 > > HA reboot is not a policy event. HA is rebooting, it wants=20 > to send a=20 > > graceful event to the mobile. I dont see why AAA function should be=20 > > involved here. This is one usecase. Again, 3775 does not assume AAA=20 > > entity in the mobility infrastructure and so the signaling=20 > has to be=20 > > based on MIP6 signaling. > >=20 >=20 > HA rebooting/maintenance was one of the motivations to define=20 > the HA switch message as explained in section 2.3 of=20 > draft-ietf-mip6-ha-switch-03.txt I think the operator will=20 > switch the user to another HA in case of reboot of HA and=20 > prefer not to break the mobility service.=20 >=20 > Therefore I don't think this is a valid use case for this draft.=20 >=20 > > Extending this further, offering mobility service involves=20 > some policy=20 > > aspect. So, it is possible to get rid of MIP6 signaling and let AAA=20 > > notify both HA and MN to setup the binding state. > >=20 >=20 > Again, can you clarify the different use cases for the HA=20 > switch message and the revocation message?=20 >=20 > Sorry, I may be missing something as I did not attend the=20 > Chicago presentation and proceedings are not available yet. >=20 > Thanks > Gerardo >=20 > > Sure, no need to bring NETLMM usecases for this discussion. > >=20 > > Sri > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > Sent: Wednesday, August 29, 2007 11:08 AM > > > To: Sri Gundavelli; Basavaraj Patil; Ahmad Muhanna; Mobile > > > IPv6 Mailing List; Jonne Soininen > > > Cc: Gopal Dommety > > > Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus=20 > > > call:Adopting I-D) > > > > > > > > > Doing "HA switch" or "Notifications" or "HA Reliability" via AAA=20 > > > doesn't make sense - those are functions of MIP6. =20 > Revocation is a=20 > > > policy thing and is associated with AAA or an equivalent=20 > entity (HSS=20 > > > or whatever other entity). I don't believe we are making=20 > the right=20 > > > comparisons here. > > > > > > Of all the items listed, I can perhaps see the need for=20 > NETLMM, for=20 > > > cleaning up MAG resources upon revocation of the MN. For=20 > NEMO, MIP6=20 > > > or MONAMI6, I don't see the point. And, I particularly=20 > don't want=20 > > > to discuss the NETLMM need here at this time, since we=20 > haven't yet=20 > > > discussed it in the NETLMM WG. For the purpose of MEXT, I'm not=20 > > > seeing the practical need for revocation. > > > > > > Vidya > > > > > > > -----Original Message----- > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > Sent: Wednesday, August 29, 2007 10:47 AM > > > > To: 'Basavaraj Patil'; Narayanan, Vidya; 'Ahmad=20 > Muhanna'; 'Mobile=20 > > > > IPv6 Mailing List'; 'Jonne Soininen' > > > > Cc: 'Gopal Dommety' > > > > Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus=20 > > > > call:Adopting I-D) > > > > > > > > I was not following this thread ... just a comment on this. > > > > No time for long discussions. > > > > > > > > > > > > We cannot just assume AAA to be deployed in the network=20 > and assume=20 > > > > the entire revocation to be activated and managed through AAA.=20 > > > > Pretty much all the specs, including "HA Switchover",=20 > > > > "Notifications", "HA Reliability" ... every thing could be=20 > > > > achieved through AAA. What we need is a mobility messaging and=20 > > > > with no assumption on the presence of AAA. 3775 does not assume=20 > > > > AAA on the network either. AAA is not mandataroy for=20 > mobility to=20 > > > > be achieved. > > > > That is just one interface most useful for cellular networks. > > > > I dont know if any one would apply AAA for enterprise mobility. > > > > > > > > Now, if the case where AAA interface is not present, if=20 > HA wants=20 > > > > to revoke the mobile node's binding, it needs a mechanism to=20 > > > > notify the mobile node and the spec defines the signaling for=20 > > > > that. > > > > > > > > Regarding the scope of the work, we cannot expect every=20 > WG to go=20 > > > > and define the same protocol, changing the entity names and by=20 > > > > defining a new usecase. If some one goes and defines Revocation=20 > > > > for PMIP6, the work is not going to be vastly=20 > different. Its the=20 > > > > same messaging and with a different title. > > > > If we look at this work in the sense of project=20 > management, this=20 > > > > work should be done once and leveraged by other WG's=20 > (That's been=20 > > > > Jari's position regarding leveraging work). > > > > Again, just as how DSMIP6 work is being leveraged in 10=20 > different=20 > > > > places. That really helped and in the same way, this=20 > work should=20 > > > > be done just in the base MIP6 group and be leveraged by other=20 > > > > WG's. Hope, this work will be adopted as a joint WG item across=20 > > > > NEMO, MIP6, NETLMM and MONAMI6. > > > > > > > > Sri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > > Sent: Wednesday, August 29, 2007 9:56 AM > > > > > To: ext Narayanan, Vidya; Ahmad Muhanna; Mobile IPv6 > > > Mailing List; > > > > > Jonne Soininen > > > > > Cc: Gopal Dommety > > > > > Subject: Re: Need for revocation in MIP6 (RE: [Mip6]=20 > Consensus=20 > > > > > call:Adopting I-D) > > > > > > > > > > > > > > > Hi Vidya, > > > > > > > > > > But the AAA could notify the HA (via the HA-AAA interface > > > > for which we > > > > > are specifying requirements in MIP6) about the Disconnect > > > prior to > > > > > sending the Disconnect to the NAS. And this would allow a > > > graceful > > > > > detach from the HA?? > > > > > > > > > > -Raj > > > > > > > > > > > > > > > On 8/29/07 12:53 AM, "ext Narayanan, Vidya" > > > > > wrote: > > > > > > > > > > > Hi Ahmad, > > > > > > The point I was making is that the AAA disconnect messages > > > > > are sent to > > > > > > the NAS, not the HA - that causes network access being > > > > > terminated for > > > > > > the MN. The MN won't even get the MIP6 revocation message > > > > > once network > > > > > > access is revoked. > > > > > > > > > > > > I realize that the MIP4 revocation is also supported in the > > > > > spec for MNs > > > > > > in CCoA mode - but, I'm not aware of any real world use of > that. > > > > > > > > > > > > Regards, > > > > > > Vidya > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > > > >> Sent: Tuesday, August 28, 2007 8:52 PM > > > > > >> To: Narayanan, Vidya; Basavaraj Patil; Mobile IPv6 > > > Mailing List; > > > > > >> Jonne Soininen > > > > > >> Cc: Gopal Dommety > > > > > >> Subject: RE: Need for revocation in MIP6 (RE: [Mip6] > Consensus > > > > > >> call: Adopting I-D) > > > > > >> > > > > > >> Hi Vidya, > > > > > >> > > > > > >> Thanks Vidya for the question. I actually was planning > > > to check > > > > > >> with you and Jonnie on this topic but I had been very > > > > busy here at > > > > > >> 3GPP2 meeting and I had to go out to eat:-( > > > > > >> > > > > > >> I believe that we, earlier, had quite good amount of > > > > discussion on > > > > > >> this topic, however, I must admit it was mixed with > revocation > > > > > >> applicability to PMIPv6 too. > > > > > >> > > > > > >> Now, let me try to address your MIPv6 specific question. > > > > > >> There is one scenario when the HA would like to=20 > revoke the MN=20 > > > > > >> session, for example: > > > > > >> administrative reasons. As you said, Disconnect > > > message could be > > > > > >> sent to the HA for that purpose. Now: I, at least, > > > think of two > > > > > >> options here: > > > > > >> > > > > > >> Option 1. The HA deletes the binding cache entry and > > > > forget about > > > > > >> the mobile node and the HA starts dropping the MN > > > > packets/traffic, > > > > > >> I would call this "a bad customer service and a bad > > > example that > > > > > >> operators would like to avoid such a non-graceful=20 > revocation=20 > > > > > >> mechanism" > > > > > >> > > > > > >> Option 2. As soon as the HA receives the Disconnect > > > message, for > > > > > >> example, the HA sends a revocation message and informs > > > > the MN that > > > > > >> its binding has been revoked with the proper code which > should > > > > > >> indicate the reason behind revoking the MN binding. In > > > > that case, > > > > > >> MN probably can delete its binding with other CN or, at > least, > > > > > >> gives the MN a chance to start a simple IP session, > > > for example, > > > > > >> etc. > > > > > >> > > > > > >> Now since you mentioned MIPv4 Revocation, I would like > > > > to mention > > > > > >> that long time ago, early 2002, there has been a lot of > > > > discussion > > > > > >> during > > > > > >> RFC3543 development which was translated into allowing > > > the MN to > > > > > >> clearly indicate if it (the MN) needs to be=20 > informed when its=20 > > > > > >> session is revoked or NOT. There is an "I" bit in the > > > revocation > > > > > >> extension. That is similar to the case in MIPv6. > > > > > >> Not only that, but RFC3543, Registration Revocation in > > > > Mobile IPv4, > > > > > >> also addresses MIPv4 registration in the case of Co-CoA > > > > sessions. > > > > > >> This is exactly the same as in MIPv6. > > > > > >> > > > > > >> Having said the above, I believe that revocation=20 > mechanism is=20 > > > > > >> needed in multiple scenarios which were presented=20 > in Chicago=20 > > > > > >> meeting as follows: > > > > > >> > > > > > >> 1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg) 2.=20 > Revoking a > > > > > >> PMIPv6 session. (PMIPv6 - Netlmm wg) 3. Revoking a=20 > specific=20 > > > > > >> Care-of-Address for a multiple care-of-addresses sessions > > > > > (Monami6 wg) > > > > > >> > > > > > >> The common thing for all of these scenarios is that all > > > > of them use > > > > > >> an extension of MIPv6 protocol. Since one simple mechanism > can > > > > > >> address all of these scenarios, then one draft would > > > be the best > > > > > >> choice. As I said earlier there is already a precedent > > > > at IETF with > > > > > >> DS-MIPv6. IMHO, it does make a lot of sense to address > > > > all of these > > > > > >> scenarios which happen to extend across several wgs in > > > a single > > > > > >> draft using one simple and generic mechanism. > > > > > >> > > > > > >> Finally, in fairness to all the fine people who thus far > > > > supported > > > > > >> this draft as MIP6 wg document, I believe their support > > > > was based > > > > > >> on the applicability of this draft to MIPv6 and PMIPv6 > > > and I am > > > > > >> sure some of them also have Monami6 applicability in mind. > > > > > >> > > > > > >> > > > > > >> Best Regards, > > > > > >> Ahmad > > > > > >> > > > > > >> > > > > > >>> -----Original Message----- > > > > > >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > > >>> Sent: Tuesday, August 28, 2007 8:43 PM > > > > > >>> To: Basavaraj Patil; Mobile IPv6 Mailing List; Jonne > Soininen > > > > > >>> Cc: Gopal Dommety > > > > > >>> Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus > > > > > >>> call: Adopting I-D) > > > > > >>> > > > > > >>> Raj, all, > > > > > >>> I'd like to understand the need for revocation in MIP6 > > > > better. I > > > > > >>> think we've had a discussion on how to do revocation, but, > > > > > >> not so much > > > > > >>> on why we would need it for MIP6. Please note that > > > > this is not a > > > > > >>> discussion on > > > > > >>> PMIPv6 - I'm trying to specifically understand this in the > > > > > >> context of > > > > > >>> MIP6. > > > > > >>> > > > > > >>> A revocation mechanism was developed for MIP4 to allow a > > > > > >> clean up of > > > > > >>> resources at the mobility agents (FA/HA). The=20 > philosphy of > > > > > >> revocation > > > > > >>> applies to managed networks and in such networks, a AAA > > > > disconnect > > > > > >>> message (or equivalent) is likely to first cut off any > > > > > >> network access > > > > > >>> to the MNs before even MIP6 has a chance to revocate > > > > > anything - so, > > > > > >>> I'm not sure I understand why we need revocation. > > > Note that the > > > > > >>> non-MIP6 mechanism is needed regardless so that network > > > > > >> access can be > > > > > >>> revoked for nodes not using MIP6 as well. > > > > > >>> > > > > > >>> I've seen a number of people support adoption of this > > > > draft - so, > > > > > >>> perhaps there is a good reason for it that I'm just not > > > > > >> seeing. I'd > > > > > >>> appreciate a clarification. > > > > > >>> > > > > > >>> Thanks, > > > > > >>> Viday > > > > > >>> > > > > > >>>> -----Original Message----- > > > > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > > >>>> Sent: Tuesday, August 28, 2007 9:25 AM > > > > > >>>> To: Narayanan, Vidya; Mobile IPv6 Mailing List; > > > Jonne Soininen > > > > > >>>> Cc: Gopal Dommety > > > > > >>>> Subject: Re: [Mip6] Consensus call: Adopting I-D > > > > > >>>> > > > > > >>>> > > > > > >>>> Hi Vidya, > > > > > >>>> > > > > > >>>> In the context of the MIP6 charter: > > > > > >>>> " > > > > > >>>> The primary goal of the MIP6 working group will be to > > > > > enhance base > > > > > >>>> IPv6 mobility by continuing work on developments that are > > > > > >>> required for > > > > > >>>> wide-scale deployments. > > > > > >>>> " > > > > > >>>> > > > > > >>>> Binding revocation is a feature that is required from > > > > deployments > > > > > >>>> perspective and hence it fits into the current charter. > > > > > >>>> > > > > > >>>> Since MEXT is essentially a consolidation of multiple > > > > > >> MIP6 related > > > > > >>>> WGs, I believe this work item would be a carryover from > > > > > >>> MIP6 to MEXT. > > > > > >>>> > > > > > >>>> Having said that, I do however have some questions about > > > > > >>> this document > > > > > >>>> scope that is related to Netlmm. > > > > > >>>> > > > > > >>>> This I-D is specifying a binding revocation > > > mechanism that is > > > > > >>>> applicable to > > > > > >>>> MIP6 and PMIP6. The consensus call is in the MIP6 WG. I > > > > > >> think that > > > > > >>>> given the > > > > > >>>> PMIP6 aspects included in this I-D, it would make sense > > > > > >> to consult > > > > > >>>> with you and Jonne (Netlmm chairs) about opinions on > > > this I-D. > > > > > >>>> > > > > > >>>> The MIP6 WG charter and scope is focused on extensions to > the > > > > > >>>> MIP6 protocol > > > > > >>>> (RFC3775) and issues related to base MIP6. From a charter > > > > > >> and scope > > > > > >>>> perspective, this I-D oversteps the boundaries=20 > of MIP6 and > > > > > >>> is treading > > > > > >>>> in Netlmm waters. > > > > > >>>> It is possible that the feature which addresses MIP6 and > > > > > >>>> PMIP6 can be done as a joint WG item (MIP6/MEXT and > Netlmm). > > > > > >>>> But I want to make sure that Netlmm is aware of it and > > > > > >>> supports it as > > > > > >>>> well. > > > > > >>>> > > > > > >>>> If the binding revocation feature were to be=20 > done only as a > > > > > >>>> MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would > > > > > >> have to be > > > > > >>>> removed and any enhancements needed to make binding > > > > > >>> revocation work in > > > > > >>>> the case of PMIP6 would have to be done in Netlmm. > > > > > >>>> > > > > > >>>> -Raj > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> On 8/27/07 8:13 PM, "ext Narayanan, Vidya" > > > > > >>>> wrote: > > > > > >>>> > > > > > >>>>> A meta question concerning this draft - how does it fit > > > > > >> into the > > > > > >>>>> current > > > > > >>>>> MIP6 or proposed MEXT charter? > > > > > >>>>> > > > > > >>>>> Thanks, > > > > > >>>>> Vidya > > > > > >>>>> > > > > > >>>>>> -----Original Message----- > > > > > >>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > > >>>>>> Sent: Thursday, August 23, 2007 10:16 AM > > > > > >>>>>> To: Mobile IPv6 Mailing List > > > > > >>>>>> Cc: Gopal Dommety > > > > > >>>>>> Subject: [Mip6] Consensus call: Adopting I-D > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> Hello, > > > > > >>>>>> > > > > > >>>>>> This is a consensus call for adopting I-D: Binding > > > > > >> Revocation for > > > > > >>>>>> IPv6 Mobility > > > > > >> as a > > > > > >>>>>> MIP6 WG document. > > > > > >>>>>> > > > > > >>>>>> The I-D has been discussed on the ML in the past and > > > > was also > > > > > >>>>>> presented at > > > > > >>>>>> IETF69 in Chicago. > > > > > >>>>>> > > > > > >>>>>> So please opine on the following statement: > > > > > >>>>>> > > > > > >>>>>> The binding revocation feature specified in I-D=20 > > > > > >>>>>> draft-muhanna-mip6-binding-revocation-01.txt is > > > essential for > > > > > >>>>>> MIP6 deployments and hence should be made a MIP6 WG > > > > > >> document and > > > > > >>>>>> progressed as a standards track doc. > > > > > >>>>>> > > > > > >>>>>> Yes [ ] > > > > > >>>>>> No [ ] > > > > > >>>>>> > > > > > >>>>>> -Raj > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> _______________________________________________ > > > > > >>>>>> Mip6 mailing list > > > > > >>>>>> Mip6@ietf.org > > > > > >>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > > >>>>>> > > > > > >>>> > > > > > >>>> > > > > > >>> > > > > > >>> _______________________________________________ > > > > > >>> Mip6 mailing list > > > > > >>> Mip6@ietf.org > > > > > >>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > _______________________________________________ > > > > > Mip6 mailing list > > > > > Mip6@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Aug 30 06:44:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQhW0-0000Of-7W; Thu, 30 Aug 2007 06:44:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQhVz-0000MN-78 for mip6@ietf.org; Thu, 30 Aug 2007 06:44:43 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQhVx-00039a-QG for mip6@ietf.org; Thu, 30 Aug 2007 06:44:43 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7UAiHi14083; Thu, 30 Aug 2007 10:44:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) Date: Thu, 30 Aug 2007 05:44:12 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116741DD7@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for revocation in MIP6 (RE: [Mip6] Consensus call: Adopting I-D) Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgAES6mwAAGAyOQAAS76tAAF3CTIQAAh2pgAAEV8jgAAdmGkAAht2Ww References: From: "Ahmad Muhanna" To: "Narayanan, Vidya" , "Basavaraj Patil" , "Mobile IPv6 Mailing List" , "Jonne Soininen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org >=20 >=20 > I'll make a final point and stop here. Most managed networks=20 > that are considering the use of MIP6 today allow a mix of=20 > MIP6 and non-MIP6 capable nodes to exist on the network. A=20 > mechanism of revoking access is needed for both MIP6 and=20 > non-MIP6 capable endpoints and they don't need to be different. =20 >=20 > When the NAS receives a disconnect, it stops accepting=20 > packets sourced from that IP address (the CoA, in the MIP6=20 > case) and also won't forward anything to that IP address -=20 > surely, we are not saying that the NAS understand MIP6=20 > signaling and forward that alone on to the MN. Good mobile=20 > implementations should automatically blow any state=20 > associated with that IP address (including MIP6 state), when=20 > access is revoked. [Ahmad] Hmmm It is scary. I did not know that even Good MIP6 enabled MN is getting into the blow up business:-) But do you still qualify that smart implementation as graceful? =20 >=20 > Vidya >=20 > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > Sent: Wednesday, August 29, 2007 10:42 AM > > To: Narayanan, Vidya; Ahmad Muhanna; Mobile IPv6 Mailing=20 > List; Jonne=20 > > Soininen > > Cc: Gopal Dommety > > Subject: Re: Need for revocation in MIP6 (RE: [Mip6]=20 > Consensus call:=20 > > Adopting I-D) > >=20 > >=20 > > Hi Vidya, > >=20 > > I agree that if the issue is primarily resource clean up, a=20 > > notification from the AAA to the HA will deprecate the binding. > >=20 > > But if the AAA sends a Disconnect to the NAS, I am not sure=20 > if there=20 > > is a graceful mechanism to indicate to the MN that it is being=20 > > disconnected. Of course there are many different ways to=20 > indicate that=20 > > the MN has been disconnected from the network and these=20 > could also be=20 > > access technology dependent. > > However if there is no good way to indicate to the MN that=20 > it has been=20 > > disconnected, the MN would continue to believe that it=20 > still has MIP6=20 > > binding and subsequently may cause a delay in creating a=20 > binding with=20 > > the HA when the MN does attach (for example via another=20 > access type).=20 > > So I think it would still make sense to indicate to the MN=20 > that the HA=20 > > has revoked the binding. > > There is of course an issue about synchronizing the AAA=20 > Disconnect to=20 > > the NAS and the indication to the HA to ensure that the MN can be=20 > > notified of the binding revocation prior to pulling the plug at the=20 > > NAS. But I think this can be dealt with. > >=20 > > -Raj > >=20 > >=20 > > On 8/29/07 12:15 PM, "ext Narayanan, Vidya"=20 > > wrote: > >=20 > > > Hi Raj, > > > Hmmm.. The AAA could certainly notify the HA. But, a AAA that is=20 > > > interested in revoking access to an MN would contact the > > NAS first, if > > > not in parallel with the HA. After all, the AAA is getting > > accounting > > > records from the NAS - note that even if the HA is also=20 > physically=20 > > > serving as a AAA aggregation point for accounting (which > > itself cannot > > > be generalized), it is still a logically separate function > > that will > > > forward on the AAA disconnect messages all the way to the NAS,=20 > > > resulting in MN's access being revoked. > > >=20 > > > So, the AAA notification to the HA would be good to clean=20 > up the HA=20 > > > resources, but, I'm still not seeing a practical need for > > revocation > > > in > > > MIP6 - the MN has likely had its access revoked before=20 > the HA sends=20 > > > the > > > MIP6 revocation out. > > >=20 > > > Vidya > > >=20 > > >> -----Original Message----- > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >> Sent: Wednesday, August 29, 2007 9:56 AM > > >> To: Narayanan, Vidya; Ahmad Muhanna; Mobile IPv6 Mailing > > List; Jonne > > >> Soininen > > >> Cc: Gopal Dommety > > >> Subject: Re: Need for revocation in MIP6 (RE: [Mip6] > > Consensus call:=20 > > >> Adopting I-D) > > >>=20 > > >>=20 > > >> Hi Vidya, > > >>=20 > > >> But the AAA could notify the HA (via the HA-AAA interface > > for which > > >> we are specifying requirements in MIP6) about the > > Disconnect prior to > > >> sending the Disconnect to the NAS. And this would allow=20 > a graceful=20 > > >> detach from the HA?? > > >>=20 > > >> -Raj > > >>=20 > > >>=20 > > >> On 8/29/07 12:53 AM, "ext Narayanan, Vidya" > > >> wrote: > > >>=20 > > >>> Hi Ahmad, > > >>> The point I was making is that the AAA disconnect messages > > >> are sent to > > >>> the NAS, not the HA - that causes network access being > > >> terminated for > > >>> the MN. The MN won't even get the MIP6 revocation message once=20 > > >>> network access is revoked. > > >>>=20 > > >>> I realize that the MIP4 revocation is also supported in the > > >> spec for > > >>> MNs in CCoA mode - but, I'm not aware of any real world > > use of that. > > >>>=20 > > >>> Regards, > > >>> Vidya > > >>>=20 > > >>>> -----Original Message----- > > >>>> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > >>>> Sent: Tuesday, August 28, 2007 8:52 PM > > >>>> To: Narayanan, Vidya; Basavaraj Patil; Mobile IPv6=20 > Mailing List;=20 > > >>>> Jonne Soininen > > >>>> Cc: Gopal Dommety > > >>>> Subject: RE: Need for revocation in MIP6 (RE: [Mip6] > > >> Consensus call:=20 > > >>>> Adopting I-D) > > >>>>=20 > > >>>> Hi Vidya, > > >>>>=20 > > >>>> Thanks Vidya for the question. I actually was planning to > > >> check with > > >>>> you and Jonnie on this topic but I had been very busy here > > >> at 3GPP2 > > >>>> meeting and I had to go out to eat:-( > > >>>>=20 > > >>>> I believe that we, earlier, had quite good amount of > > discussion on > > >>>> this topic, however, I must admit it was mixed with revocation=20 > > >>>> applicability to PMIPv6 too. > > >>>>=20 > > >>>> Now, let me try to address your MIPv6 specific question. > > >>>> There is one scenario when the HA would like to revoke the MN=20 > > >>>> session, for example: > > >>>> administrative reasons. As you said, Disconnect message > > >> could be sent > > >>>> to the HA for that purpose. Now: I, at least, think of > > two options > > >>>> here: > > >>>>=20 > > >>>> Option 1. The HA deletes the binding cache entry and > > >> forget about the > > >>>> mobile node and the HA starts dropping the MN=20 > packets/traffic, I=20 > > >>>> would call this "a bad customer service and a bad example that=20 > > >>>> operators would like to avoid such a non-graceful revocation=20 > > >>>> mechanism" > > >>>>=20 > > >>>> Option 2. As soon as the HA receives the Disconnect=20 > message, for=20 > > >>>> example, the HA sends a revocation message and informs > > the MN that > > >>>> its binding has been revoked with the proper code which should=20 > > >>>> indicate the reason behind revoking the MN binding. In > > >> that case, MN > > >>>> probably can delete its binding with other CN or, at > > >> least, gives the > > >>>> MN a chance to start a simple IP session, for example, etc. > > >>>>=20 > > >>>> Now since you mentioned MIPv4 Revocation, I would like > > to mention > > >>>> that long time ago, early 2002, there has been a lot of > > discussion > > >>>> during > > >>>> RFC3543 development which was translated into allowing=20 > the MN to=20 > > >>>> clearly indicate if it (the MN) needs to be informed when > > >> its session > > >>>> is revoked or NOT. There is an "I" bit in the revocation > > >> extension.=20 > > >>>> That is similar to the case in MIPv6. > > >>>> Not only that, but RFC3543, Registration Revocation in > > >> Mobile IPv4, > > >>>> also addresses MIPv4 registration in the case of=20 > Co-CoA sessions. > > >>>> This is exactly the same as in MIPv6. > > >>>>=20 > > >>>> Having said the above, I believe that revocation mechanism > > >> is needed > > >>>> in multiple scenarios which were presented in Chicago=20 > meeting as > > >>>> follows: > > >>>>=20 > > >>>> 1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg) 2. Revoking a > > >>>> PMIPv6 session. (PMIPv6 - Netlmm wg) 3. Revoking a specific=20 > > >>>> Care-of-Address for a multiple care-of-addresses > > sessions (Monami6 > > >>>> wg) > > >>>>=20 > > >>>> The common thing for all of these scenarios is that all of > > >> them use > > >>>> an extension of MIPv6 protocol. Since one simple mechanism can=20 > > >>>> address all of these scenarios, then one draft would=20 > be the best=20 > > >>>> choice. As I said earlier there is already a precedent at > > >> IETF with > > >>>> DS-MIPv6. IMHO, it does make a lot of sense to address all > > >> of these > > >>>> scenarios which happen to extend across several wgs in a > > >> single draft > > >>>> using one simple and generic mechanism. > > >>>>=20 > > >>>> Finally, in fairness to all the fine people who thus far > > supported > > >>>> this draft as MIP6 wg document, I believe their support > > >> was based on > > >>>> the applicability of this draft to MIPv6 and PMIPv6 and > > I am sure > > >>>> some of them also have Monami6 applicability in mind. > > >>>>=20 > > >>>>=20 > > >>>> Best Regards, > > >>>> Ahmad > > >>>> =20 > > >>>>=20 > > >>>>> -----Original Message----- > > >>>>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > >>>>> Sent: Tuesday, August 28, 2007 8:43 PM > > >>>>> To: Basavaraj Patil; Mobile IPv6 Mailing List; Jonne Soininen > > >>>>> Cc: Gopal Dommety > > >>>>> Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus > > >>>>> call: Adopting I-D) > > >>>>>=20 > > >>>>> Raj, all, > > >>>>> I'd like to understand the need for revocation in MIP6 > > better. I > > >>>>> think we've had a discussion on how to do revocation, but, > > >>>> not so much > > >>>>> on why we would need it for MIP6. Please note that > > this is not a > > >>>>> discussion on > > >>>>> PMIPv6 - I'm trying to specifically understand this in the > > >>>> context of > > >>>>> MIP6. > > >>>>>=20 > > >>>>> A revocation mechanism was developed for MIP4 to allow a > > >>>> clean up of > > >>>>> resources at the mobility agents (FA/HA). The philosphy of > > >>>> revocation > > >>>>> applies to managed networks and in such networks, a AAA > > >> disconnect > > >>>>> message (or equivalent) is likely to first cut off any > > >>>> network access > > >>>>> to the MNs before even MIP6 has a chance to revocate > > >> anything - so, > > >>>>> I'm not sure I understand why we need revocation.=20 > Note that the > > >>>>> non-MIP6 mechanism is needed regardless so that network > > >>>> access can be > > >>>>> revoked for nodes not using MIP6 as well. > > >>>>>=20 > > >>>>> I've seen a number of people support adoption of this > > draft - so, > > >>>>> perhaps there is a good reason for it that I'm just not > > >>>> seeing. I'd > > >>>>> appreciate a clarification. > > >>>>>=20 > > >>>>> Thanks, > > >>>>> Viday > > >>>>>=20 > > >>>>>> -----Original Message----- > > >>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >>>>>> Sent: Tuesday, August 28, 2007 9:25 AM > > >>>>>> To: Narayanan, Vidya; Mobile IPv6 Mailing List;=20 > Jonne Soininen > > >>>>>> Cc: Gopal Dommety > > >>>>>> Subject: Re: [Mip6] Consensus call: Adopting I-D > > >>>>>>=20 > > >>>>>>=20 > > >>>>>> Hi Vidya, > > >>>>>>=20 > > >>>>>> In the context of the MIP6 charter: > > >>>>>> " > > >>>>>> The primary goal of the MIP6 working group will be to > > >> enhance base > > >>>>>> IPv6 mobility by continuing work on developments that are > > >>>>> required for > > >>>>>> wide-scale deployments. > > >>>>>> " > > >>>>>>=20 > > >>>>>> Binding revocation is a feature that is required from > > >> deployments > > >>>>>> perspective and hence it fits into the current charter. > > >>>>>>=20 > > >>>>>> Since MEXT is essentially a consolidation of multiple > > >>>> MIP6 related > > >>>>>> WGs, I believe this work item would be a carryover from > > >>>>> MIP6 to MEXT. > > >>>>>>=20 > > >>>>>> Having said that, I do however have some questions about > > >>>>> this document > > >>>>>> scope that is related to Netlmm. > > >>>>>>=20 > > >>>>>> This I-D is specifying a binding revocation=20 > mechanism that is=20 > > >>>>>> applicable to > > >>>>>> MIP6 and PMIP6. The consensus call is in the MIP6 WG. I > > >>>> think that > > >>>>>> given the > > >>>>>> PMIP6 aspects included in this I-D, it would make sense > > >>>> to consult > > >>>>>> with you and Jonne (Netlmm chairs) about opinions on=20 > this I-D. > > >>>>>>=20 > > >>>>>> The MIP6 WG charter and scope is focused on extensions to the > > >>>>>> MIP6 protocol > > >>>>>> (RFC3775) and issues related to base MIP6. From a charter > > >>>> and scope > > >>>>>> perspective, this I-D oversteps the boundaries of MIP6 and > > >>>>> is treading > > >>>>>> in Netlmm waters. > > >>>>>> It is possible that the feature which addresses MIP6 and > > >>>>>> PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm). > > >>>>>> But I want to make sure that Netlmm is aware of it and > > >>>>> supports it as > > >>>>>> well. > > >>>>>>=20 > > >>>>>> If the binding revocation feature were to be done only as a > > >>>>>> MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would > > >>>> have to be > > >>>>>> removed and any enhancements needed to make binding > > >>>>> revocation work in > > >>>>>> the case of PMIP6 would have to be done in Netlmm. > > >>>>>>=20 > > >>>>>> -Raj > > >>>>>> =20 > > >>>>>>=20 > > >>>>>>=20 > > >>>>>> On 8/27/07 8:13 PM, "ext Narayanan, Vidya" > > >>>>>> wrote: > > >>>>>>=20 > > >>>>>>> A meta question concerning this draft - how does it fit > > >>>> into the > > >>>>>>> current > > >>>>>>> MIP6 or proposed MEXT charter? > > >>>>>>>=20 > > >>>>>>> Thanks, > > >>>>>>> Vidya > > >>>>>>>=20 > > >>>>>>>> -----Original Message----- > > >>>>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > >>>>>>>> Sent: Thursday, August 23, 2007 10:16 AM > > >>>>>>>> To: Mobile IPv6 Mailing List > > >>>>>>>> Cc: Gopal Dommety > > >>>>>>>> Subject: [Mip6] Consensus call: Adopting I-D > > >>>>>>>>=20 > > >>>>>>>>=20 > > >>>>>>>> Hello, > > >>>>>>>>=20 > > >>>>>>>> This is a consensus call for adopting I-D: Binding > > >>>> Revocation for > > >>>>>>>> IPv6 Mobility > > >>>> as a > > >>>>>>>> MIP6 WG document. > > >>>>>>>>=20 > > >>>>>>>> The I-D has been discussed on the ML in the past and > > was also > > >>>>>>>> presented at > > >>>>>>>> IETF69 in Chicago. > > >>>>>>>>=20 > > >>>>>>>> So please opine on the following statement: > > >>>>>>>>=20 > > >>>>>>>> The binding revocation feature specified in I-D=20 > > >>>>>>>> draft-muhanna-mip6-binding-revocation-01.txt is=20 > essential for > > >>>>>>>> MIP6 deployments and hence should be made a MIP6 WG > > >>>> document and > > >>>>>>>> progressed as a standards track doc. > > >>>>>>>>=20 > > >>>>>>>> Yes [ ] > > >>>>>>>> No [ ] > > >>>>>>>>=20 > > >>>>>>>> -Raj > > >>>>>>>>=20 > > >>>>>>>>=20 > > >>>>>>>> _______________________________________________ > > >>>>>>>> Mip6 mailing list > > >>>>>>>> Mip6@ietf.org > > >>>>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > >>>>>>>>=20 > > >>>>>>=20 > > >>>>>>=20 > > >>>>>=20 > > >>>>> _______________________________________________ > > >>>>> Mip6 mailing list > > >>>>> Mip6@ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > >>>>>=20 > > >>>>=20 > > >>=20 > > >>=20 > >=20 > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Aug 30 17:04:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQrBp-0004OD-3H; Thu, 30 Aug 2007 17:04:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQrBo-0004O8-2g for mip6@ietf.org; Thu, 30 Aug 2007 17:04:32 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQrBl-0005BD-TM for mip6@ietf.org; Thu, 30 Aug 2007 17:04:31 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7UL4RuD011196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Aug 2007 14:04:27 -0700 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7UL4QWq003371; Thu, 30 Aug 2007 14:04:27 -0700 Received: from NAEX12.na.qualcomm.com ([129.46.51.246]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Aug 2007 14:04:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus call:AdoptingI-D) Date: Thu, 30 Aug 2007 14:04:23 -0700 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116741DD5@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for revocation in MIP6 (RE: [Mip6] Consensus call:AdoptingI-D) Thread-Index: AcflqUMFgdAYGlGcEdyuUQARJNUNiADZ1ArgAB/cIRgAES6mwAAGAyOQAAS76tAAF3CTIQABOiKAAAEkG9AAADDq0AAg9WvQAAEEF4AAFi3MQA== From: "Giaretta, Gerardo" To: "Ahmad Muhanna" , "Sri Gundavelli" , "Narayanan, Vidya" , "Basavaraj Patil" , "Mobile IPv6 Mailing List" , "Jonne Soininen" X-OriginalArrivalTime: 30 Aug 2007 21:04:26.0494 (UTC) FILETIME=[593209E0:01C7EB49] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3d1fcc6feccbcc611b6c309986f05f7 Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ahmad, Thanks for the pointer.=20 I went through the slides and still I partially miss the motivations of this work for MIPv6. In slide 3 the following motivations are mentioned: - Home Agent Revokes Mobile Node's binding for Administrative Reasons - Network Resource Optimization - Gracefully Revoke multiple sessions before scheduled or emergency system maintenance - Avoid out of sync state between MN and mobility entities In slide 4 two scenarios are mentioned, but these are technical scenarios rather than use cases.=20 Looking at the HA switch I-D, in section 2 there are the use cases listed: - overloaded HA - (functional) load balancing - maintenance - HA renumbering It seems to me that the motivations and use cases are definitely overlapping. So which are the reasons we should define yet another mechanism in MIP6? Thanks Gerardo > -----Original Message----- > From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > Sent: Thursday, August 30, 2007 12:32 PM > To: Giaretta, Gerardo; Sri Gundavelli; Narayanan, Vidya; Basavaraj Patil; > Mobile IPv6 Mailing List; Jonne Soininen > Cc: Gopal Dommety > Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus > call:AdoptingI-D) >=20 > Gerardo, >=20 > Please visit the below link for binding revocation presentation and the > minutes was provided sometime back on the mailing list. >=20 > http://www3.ietf.org/proceedings/07jul/slides/mip6-3/sld1.htm >=20 >=20 > Regards, > Ahmad >=20 >=20 > > -----Original Message----- > > From: Giaretta, Gerardo [mailto:gerardog@qualcomm.com] > > Sent: Thursday, August 30, 2007 6:00 AM > > To: Sri Gundavelli; Narayanan, Vidya; Basavaraj Patil; > > Muhanna, Ahmad (RICH1:2H10); Mobile IPv6 Mailing List; Jonne Soininen > > Cc: Gopal Dommety > > Subject: RE: Need for revocation in MIP6 (RE: [Mip6] > > Consensus call:AdoptingI-D) > > > > Hi Sri, > > > > > > > > HA reboot is not a policy event. HA is rebooting, it wants > > to send a > > > graceful event to the mobile. I dont see why AAA function should be > > > involved here. This is one usecase. Again, 3775 does not assume AAA > > > entity in the mobility infrastructure and so the signaling > > has to be > > > based on MIP6 signaling. > > > > > > > HA rebooting/maintenance was one of the motivations to define > > the HA switch message as explained in section 2.3 of > > draft-ietf-mip6-ha-switch-03.txt I think the operator will > > switch the user to another HA in case of reboot of HA and > > prefer not to break the mobility service. > > > > Therefore I don't think this is a valid use case for this draft. > > > > > Extending this further, offering mobility service involves > > some policy > > > aspect. So, it is possible to get rid of MIP6 signaling and let AAA > > > notify both HA and MN to setup the binding state. > > > > > > > Again, can you clarify the different use cases for the HA > > switch message and the revocation message? > > > > Sorry, I may be missing something as I did not attend the > > Chicago presentation and proceedings are not available yet. > > > > Thanks > > Gerardo > > > > > Sure, no need to bring NETLMM usecases for this discussion. > > > > > > Sri > > > > > > > > > > > > > -----Original Message----- > > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > Sent: Wednesday, August 29, 2007 11:08 AM > > > > To: Sri Gundavelli; Basavaraj Patil; Ahmad Muhanna; Mobile > > > > IPv6 Mailing List; Jonne Soininen > > > > Cc: Gopal Dommety > > > > Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus > > > > call:Adopting I-D) > > > > > > > > > > > > Doing "HA switch" or "Notifications" or "HA Reliability" via AAA > > > > doesn't make sense - those are functions of MIP6. > > Revocation is a > > > > policy thing and is associated with AAA or an equivalent > > entity (HSS > > > > or whatever other entity). I don't believe we are making > > the right > > > > comparisons here. > > > > > > > > Of all the items listed, I can perhaps see the need for > > NETLMM, for > > > > cleaning up MAG resources upon revocation of the MN. For > > NEMO, MIP6 > > > > or MONAMI6, I don't see the point. And, I particularly > > don't want > > > > to discuss the NETLMM need here at this time, since we > > haven't yet > > > > discussed it in the NETLMM WG. For the purpose of MEXT, I'm not > > > > seeing the practical need for revocation. > > > > > > > > Vidya > > > > > > > > > -----Original Message----- > > > > > From: Sri Gundavelli [mailto:sgundave@cisco.com] > > > > > Sent: Wednesday, August 29, 2007 10:47 AM > > > > > To: 'Basavaraj Patil'; Narayanan, Vidya; 'Ahmad > > Muhanna'; 'Mobile > > > > > IPv6 Mailing List'; 'Jonne Soininen' > > > > > Cc: 'Gopal Dommety' > > > > > Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus > > > > > call:Adopting I-D) > > > > > > > > > > I was not following this thread ... just a comment on this. > > > > > No time for long discussions. > > > > > > > > > > > > > > > We cannot just assume AAA to be deployed in the network > > and assume > > > > > the entire revocation to be activated and managed through AAA. > > > > > Pretty much all the specs, including "HA Switchover", > > > > > "Notifications", "HA Reliability" ... every thing could be > > > > > achieved through AAA. What we need is a mobility messaging and > > > > > with no assumption on the presence of AAA. 3775 does not assume > > > > > AAA on the network either. AAA is not mandataroy for > > mobility to > > > > > be achieved. > > > > > That is just one interface most useful for cellular networks. > > > > > I dont know if any one would apply AAA for enterprise mobility. > > > > > > > > > > Now, if the case where AAA interface is not present, if > > HA wants > > > > > to revoke the mobile node's binding, it needs a mechanism to > > > > > notify the mobile node and the spec defines the signaling for > > > > > that. > > > > > > > > > > Regarding the scope of the work, we cannot expect every > > WG to go > > > > > and define the same protocol, changing the entity names and by > > > > > defining a new usecase. If some one goes and defines Revocation > > > > > for PMIP6, the work is not going to be vastly > > different. Its the > > > > > same messaging and with a different title. > > > > > If we look at this work in the sense of project > > management, this > > > > > work should be done once and leveraged by other WG's > > (That's been > > > > > Jari's position regarding leveraging work). > > > > > Again, just as how DSMIP6 work is being leveraged in 10 > > different > > > > > places. That really helped and in the same way, this > > work should > > > > > be done just in the base MIP6 group and be leveraged by other > > > > > WG's. Hope, this work will be adopted as a joint WG item across > > > > > NEMO, MIP6, NETLMM and MONAMI6. > > > > > > > > > > Sri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > > > Sent: Wednesday, August 29, 2007 9:56 AM > > > > > > To: ext Narayanan, Vidya; Ahmad Muhanna; Mobile IPv6 > > > > Mailing List; > > > > > > Jonne Soininen > > > > > > Cc: Gopal Dommety > > > > > > Subject: Re: Need for revocation in MIP6 (RE: [Mip6] > > Consensus > > > > > > call:Adopting I-D) > > > > > > > > > > > > > > > > > > Hi Vidya, > > > > > > > > > > > > But the AAA could notify the HA (via the HA-AAA interface > > > > > for which we > > > > > > are specifying requirements in MIP6) about the Disconnect > > > > prior to > > > > > > sending the Disconnect to the NAS. And this would allow a > > > > graceful > > > > > > detach from the HA?? > > > > > > > > > > > > -Raj > > > > > > > > > > > > > > > > > > On 8/29/07 12:53 AM, "ext Narayanan, Vidya" > > > > > > wrote: > > > > > > > > > > > > > Hi Ahmad, > > > > > > > The point I was making is that the AAA disconnect messages > > > > > > are sent to > > > > > > > the NAS, not the HA - that causes network access being > > > > > > terminated for > > > > > > > the MN. The MN won't even get the MIP6 revocation message > > > > > > once network > > > > > > > access is revoked. > > > > > > > > > > > > > > I realize that the MIP4 revocation is also supported in the > > > > > > spec for MNs > > > > > > > in CCoA mode - but, I'm not aware of any real world use of > > that. > > > > > > > > > > > > > > Regards, > > > > > > > Vidya > > > > > > > > > > > > > >> -----Original Message----- > > > > > > >> From: Ahmad Muhanna [mailto:amuhanna@nortel.com] > > > > > > >> Sent: Tuesday, August 28, 2007 8:52 PM > > > > > > >> To: Narayanan, Vidya; Basavaraj Patil; Mobile IPv6 > > > > Mailing List; > > > > > > >> Jonne Soininen > > > > > > >> Cc: Gopal Dommety > > > > > > >> Subject: RE: Need for revocation in MIP6 (RE: [Mip6] > > Consensus > > > > > > >> call: Adopting I-D) > > > > > > >> > > > > > > >> Hi Vidya, > > > > > > >> > > > > > > >> Thanks Vidya for the question. I actually was planning > > > > to check > > > > > > >> with you and Jonnie on this topic but I had been very > > > > > busy here at > > > > > > >> 3GPP2 meeting and I had to go out to eat:-( > > > > > > >> > > > > > > >> I believe that we, earlier, had quite good amount of > > > > > discussion on > > > > > > >> this topic, however, I must admit it was mixed with > > revocation > > > > > > >> applicability to PMIPv6 too. > > > > > > >> > > > > > > >> Now, let me try to address your MIPv6 specific question. > > > > > > >> There is one scenario when the HA would like to > > revoke the MN > > > > > > >> session, for example: > > > > > > >> administrative reasons. As you said, Disconnect > > > > message could be > > > > > > >> sent to the HA for that purpose. Now: I, at least, > > > > think of two > > > > > > >> options here: > > > > > > >> > > > > > > >> Option 1. The HA deletes the binding cache entry and > > > > > forget about > > > > > > >> the mobile node and the HA starts dropping the MN > > > > > packets/traffic, > > > > > > >> I would call this "a bad customer service and a bad > > > > example that > > > > > > >> operators would like to avoid such a non-graceful > > revocation > > > > > > >> mechanism" > > > > > > >> > > > > > > >> Option 2. As soon as the HA receives the Disconnect > > > > message, for > > > > > > >> example, the HA sends a revocation message and informs > > > > > the MN that > > > > > > >> its binding has been revoked with the proper code which > > should > > > > > > >> indicate the reason behind revoking the MN binding. In > > > > > that case, > > > > > > >> MN probably can delete its binding with other CN or, at > > least, > > > > > > >> gives the MN a chance to start a simple IP session, > > > > for example, > > > > > > >> etc. > > > > > > >> > > > > > > >> Now since you mentioned MIPv4 Revocation, I would like > > > > > to mention > > > > > > >> that long time ago, early 2002, there has been a lot of > > > > > discussion > > > > > > >> during > > > > > > >> RFC3543 development which was translated into allowing > > > > the MN to > > > > > > >> clearly indicate if it (the MN) needs to be > > informed when its > > > > > > >> session is revoked or NOT. There is an "I" bit in the > > > > revocation > > > > > > >> extension. That is similar to the case in MIPv6. > > > > > > >> Not only that, but RFC3543, Registration Revocation in > > > > > Mobile IPv4, > > > > > > >> also addresses MIPv4 registration in the case of Co-CoA > > > > > sessions. > > > > > > >> This is exactly the same as in MIPv6. > > > > > > >> > > > > > > >> Having said the above, I believe that revocation > > mechanism is > > > > > > >> needed in multiple scenarios which were presented > > in Chicago > > > > > > >> meeting as follows: > > > > > > >> > > > > > > >> 1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg) 2. > > Revoking a > > > > > > >> PMIPv6 session. (PMIPv6 - Netlmm wg) 3. Revoking a > > specific > > > > > > >> Care-of-Address for a multiple care-of-addresses sessions > > > > > > (Monami6 wg) > > > > > > >> > > > > > > >> The common thing for all of these scenarios is that all > > > > > of them use > > > > > > >> an extension of MIPv6 protocol. Since one simple mechanism > > can > > > > > > >> address all of these scenarios, then one draft would > > > > be the best > > > > > > >> choice. As I said earlier there is already a precedent > > > > > at IETF with > > > > > > >> DS-MIPv6. IMHO, it does make a lot of sense to address > > > > > all of these > > > > > > >> scenarios which happen to extend across several wgs in > > > > a single > > > > > > >> draft using one simple and generic mechanism. > > > > > > >> > > > > > > >> Finally, in fairness to all the fine people who thus far > > > > > supported > > > > > > >> this draft as MIP6 wg document, I believe their support > > > > > was based > > > > > > >> on the applicability of this draft to MIPv6 and PMIPv6 > > > > and I am > > > > > > >> sure some of them also have Monami6 applicability in mind. > > > > > > >> > > > > > > >> > > > > > > >> Best Regards, > > > > > > >> Ahmad > > > > > > >> > > > > > > >> > > > > > > >>> -----Original Message----- > > > > > > >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > > > >>> Sent: Tuesday, August 28, 2007 8:43 PM > > > > > > >>> To: Basavaraj Patil; Mobile IPv6 Mailing List; Jonne > > Soininen > > > > > > >>> Cc: Gopal Dommety > > > > > > >>> Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus > > > > > > >>> call: Adopting I-D) > > > > > > >>> > > > > > > >>> Raj, all, > > > > > > >>> I'd like to understand the need for revocation in MIP6 > > > > > better. I > > > > > > >>> think we've had a discussion on how to do revocation, but, > > > > > > >> not so much > > > > > > >>> on why we would need it for MIP6. Please note that > > > > > this is not a > > > > > > >>> discussion on > > > > > > >>> PMIPv6 - I'm trying to specifically understand this in the > > > > > > >> context of > > > > > > >>> MIP6. > > > > > > >>> > > > > > > >>> A revocation mechanism was developed for MIP4 to allow a > > > > > > >> clean up of > > > > > > >>> resources at the mobility agents (FA/HA). The > > philosphy of > > > > > > >> revocation > > > > > > >>> applies to managed networks and in such networks, a AAA > > > > > disconnect > > > > > > >>> message (or equivalent) is likely to first cut off any > > > > > > >> network access > > > > > > >>> to the MNs before even MIP6 has a chance to revocate > > > > > > anything - so, > > > > > > >>> I'm not sure I understand why we need revocation. > > > > Note that the > > > > > > >>> non-MIP6 mechanism is needed regardless so that network > > > > > > >> access can be > > > > > > >>> revoked for nodes not using MIP6 as well. > > > > > > >>> > > > > > > >>> I've seen a number of people support adoption of this > > > > > draft - so, > > > > > > >>> perhaps there is a good reason for it that I'm just not > > > > > > >> seeing. I'd > > > > > > >>> appreciate a clarification. > > > > > > >>> > > > > > > >>> Thanks, > > > > > > >>> Viday > > > > > > >>> > > > > > > >>>> -----Original Message----- > > > > > > >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > > > >>>> Sent: Tuesday, August 28, 2007 9:25 AM > > > > > > >>>> To: Narayanan, Vidya; Mobile IPv6 Mailing List; > > > > Jonne Soininen > > > > > > >>>> Cc: Gopal Dommety > > > > > > >>>> Subject: Re: [Mip6] Consensus call: Adopting I-D > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> Hi Vidya, > > > > > > >>>> > > > > > > >>>> In the context of the MIP6 charter: > > > > > > >>>> " > > > > > > >>>> The primary goal of the MIP6 working group will be to > > > > > > enhance base > > > > > > >>>> IPv6 mobility by continuing work on developments that are > > > > > > >>> required for > > > > > > >>>> wide-scale deployments. > > > > > > >>>> " > > > > > > >>>> > > > > > > >>>> Binding revocation is a feature that is required from > > > > > deployments > > > > > > >>>> perspective and hence it fits into the current charter. > > > > > > >>>> > > > > > > >>>> Since MEXT is essentially a consolidation of multiple > > > > > > >> MIP6 related > > > > > > >>>> WGs, I believe this work item would be a carryover from > > > > > > >>> MIP6 to MEXT. > > > > > > >>>> > > > > > > >>>> Having said that, I do however have some questions about > > > > > > >>> this document > > > > > > >>>> scope that is related to Netlmm. > > > > > > >>>> > > > > > > >>>> This I-D is specifying a binding revocation > > > > mechanism that is > > > > > > >>>> applicable to > > > > > > >>>> MIP6 and PMIP6. The consensus call is in the MIP6 WG. I > > > > > > >> think that > > > > > > >>>> given the > > > > > > >>>> PMIP6 aspects included in this I-D, it would make sense > > > > > > >> to consult > > > > > > >>>> with you and Jonne (Netlmm chairs) about opinions on > > > > this I-D. > > > > > > >>>> > > > > > > >>>> The MIP6 WG charter and scope is focused on extensions to > > the > > > > > > >>>> MIP6 protocol > > > > > > >>>> (RFC3775) and issues related to base MIP6. From a charter > > > > > > >> and scope > > > > > > >>>> perspective, this I-D oversteps the boundaries > > of MIP6 and > > > > > > >>> is treading > > > > > > >>>> in Netlmm waters. > > > > > > >>>> It is possible that the feature which addresses MIP6 and > > > > > > >>>> PMIP6 can be done as a joint WG item (MIP6/MEXT and > > Netlmm). > > > > > > >>>> But I want to make sure that Netlmm is aware of it and > > > > > > >>> supports it as > > > > > > >>>> well. > > > > > > >>>> > > > > > > >>>> If the binding revocation feature were to be > > done only as a > > > > > > >>>> MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would > > > > > > >> have to be > > > > > > >>>> removed and any enhancements needed to make binding > > > > > > >>> revocation work in > > > > > > >>>> the case of PMIP6 would have to be done in Netlmm. > > > > > > >>>> > > > > > > >>>> -Raj > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> On 8/27/07 8:13 PM, "ext Narayanan, Vidya" > > > > > > >>>> wrote: > > > > > > >>>> > > > > > > >>>>> A meta question concerning this draft - how does it fit > > > > > > >> into the > > > > > > >>>>> current > > > > > > >>>>> MIP6 or proposed MEXT charter? > > > > > > >>>>> > > > > > > >>>>> Thanks, > > > > > > >>>>> Vidya > > > > > > >>>>> > > > > > > >>>>>> -----Original Message----- > > > > > > >>>>>> From: Basavaraj Patil [mailto:basavaraj.patil@nsn.com] > > > > > > >>>>>> Sent: Thursday, August 23, 2007 10:16 AM > > > > > > >>>>>> To: Mobile IPv6 Mailing List > > > > > > >>>>>> Cc: Gopal Dommety > > > > > > >>>>>> Subject: [Mip6] Consensus call: Adopting I-D > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>>> Hello, > > > > > > >>>>>> > > > > > > >>>>>> This is a consensus call for adopting I-D: Binding > > > > > > >> Revocation for > > > > > > >>>>>> IPv6 Mobility > > > > > > >> as a > > > > > > >>>>>> MIP6 WG document. > > > > > > >>>>>> > > > > > > >>>>>> The I-D has been discussed on the ML in the past and > > > > > was also > > > > > > >>>>>> presented at > > > > > > >>>>>> IETF69 in Chicago. > > > > > > >>>>>> > > > > > > >>>>>> So please opine on the following statement: > > > > > > >>>>>> > > > > > > >>>>>> The binding revocation feature specified in I-D > > > > > > >>>>>> draft-muhanna-mip6-binding-revocation-01.txt is > > > > essential for > > > > > > >>>>>> MIP6 deployments and hence should be made a MIP6 WG > > > > > > >> document and > > > > > > >>>>>> progressed as a standards track doc. > > > > > > >>>>>> > > > > > > >>>>>> Yes [ ] > > > > > > >>>>>> No [ ] > > > > > > >>>>>> > > > > > > >>>>>> -Raj > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>>> _______________________________________________ > > > > > > >>>>>> Mip6 mailing list > > > > > > >>>>>> Mip6@ietf.org > > > > > > >>>>>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > >>>>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>> > > > > > > >>> _______________________________________________ > > > > > > >>> Mip6 mailing list > > > > > > >>> Mip6@ietf.org > > > > > > >>> https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Mip6 mailing list > > > > > > Mip6@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6