From mip4-bounces@ietf.org Wed Aug 01 11:36:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGGEu-0001qe-8O; Wed, 01 Aug 2007 11:35:56 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IG0Ok-0005S2-P1 for mip4-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 18:41:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG0Oj-0005LV-SO; Tue, 31 Jul 2007 18:41:01 -0400 Received: from gremlin.ics.uci.edu ([128.195.1.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IG0Oi-0001Dz-KY; Tue, 31 Jul 2007 18:41:01 -0400 Received: from gremlin.ics.uci.edu (localhost [127.0.0.1]) by gremlin.ics.uci.edu (8.13.6/8.13.5) with ESMTP id l6VMckTf027204; Tue, 31 Jul 2007 15:39:52 -0700 (PDT) Received: from oogie-boogie.ics.uci.edu (oogie-boogie.ics.uci.edu [128.195.1.41]) by gremlin.ics.uci.edu (8.13.6/8.13.5) with ESMTP id l6VLO3ax019505 for ; Tue, 31 Jul 2007 14:24:03 -0700 (PDT) Received: from [128.195.201.208] (dhcp-x201-208.calit2.uci.edu [128.195.201.208]) by oogie-boogie.ics.uci.edu (8.13.6/8.13.6) with ESMTP id l6VLNuot013917; Tue, 31 Jul 2007 14:23:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9DBF5521-1999-4284-B301-1BF3938C8ED8@ics.uci.edu> Content-Transfer-Encoding: 7bit From: Seguti Gutierrez-Nolasco Date: Tue, 31 Jul 2007 14:23:55 -0700 To: middleware2007@ics.uci.edu X-Mailer: Apple Mail (2.752.2) X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.164, required 5, autolearn=disabled, ALL_TRUSTED -1.44, MAILTO_TO_SPAM_ADDR 0.28) X-ICS-MailScanner-From: seguti@ics.uci.edu X-Mailman-Approved-At: Tue, 31 Jul 2007 15:38:42 -0700 X-BeenThere: middleware2007@mailman.ics.uci.edu X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 X-Mailman-Approved-At: Wed, 01 Aug 2007 11:35:55 -0400 Cc: Subject: [Mip4] [ACM Middleware2007] CFP: 6th Workshop on Adaptive and Reflective Middleware (ARM2007) -- EXTENDED DEADLINE August 12, 2007 X-BeenThere: mip4@ietf.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org (Apologies if you receive multiple messages from us.) Please forward to interested colleagues. ------------------------------------------------------------------------ The 6th Workshop on Adaptive and Reflective Middleware (ARM2007) Monday November 26, 2007 Newport Beach, CA, USA CALL FOR PAPERS UPDATE: Submission deadline has been extended Overview -------- It is now widely acknowledged that middleware systems of the future must flexibly adapt to increasing heterogeneity of devices and access networks, and deal with highly dynamic change at different levels of the system architecture. The prior workshops in this series (RMW00, RMW03, RMW04, ARM05, ARM06) have explored a range of techniques to support such adaptivity, and have also focused strongly on approaches to self-adaptivity. In the early days of the workshop series, much of the focus was on the application of reflective techniques. However, as reflection became mainstream, the scope of the workshop has increasingly diversified to encompass a wider range of adaptivity approaches and techniques. In the 2007 edition we plan to continue this trend by considering a broad range of relevant techniques including software componentization, design patterns in support of adaptation, software architecture, aspect-orientation, and control theory. We also want to acknowledge strong trends towards diversification in middleware environments leading to such areas peer-to-peer middleware, network-centric middleware, grid environments, sensor networks, and pervasive and mobile environments. This essentially implies considering domain-specific adaptation approaches (e.g. generalized fault-tolerance in peer-to-peer middleware). Finally, we want to recognize that developing comprehensively-adaptive middleware requires us to consider the nuances of system layers (e.g. devices, OSs, networks, applications) other than the middleware 'layer' itself. Goal and Contributions ---------------------- Following the success of the past workshops in this series, ARM07 aims to provide researchers with a leading-edge view on the state of the art in adaptive middleware. The goal of the workshop is to gather active researchers in the field to pool insight, and to share and develop new approaches to middleware adaptivity. As indicated above, our aim is to also bring in researchers involved in designing adaptive software at the architectural, OS and network layers. We believe that a forum that includes experts from these various communities will be extremely useful in fostering a more holistic approach to future research in adaptive middleware. Workshop Format --------------- The workshop will be organized as a series of sessions, each devoted to the presentation of papers on a common theme. Each session will end with a mini-panel involving the presenters and driven by a pre-selected "devil's advocate". In past years this format has been found to lead to lively and productive discussion. The workshop will include a special session for the presentation of posters and demos of ongoing research efforts and prototypes. The workshop will conclude with a wrap-up panel, moderated by one of the organizers, with the aim of discussing and summarising key contributions, research issues and trends. Submission Guidelines --------------------- Attendance is based on the submission of a position paper, poster or demo. (In addition, other participants may be invited by the organizing committee.) Position papers should not exceed 6 pages of text on letter/A4 paper in ACM format without page numbers. Document templates for most popular document processing tools can be found at http://www.acm.org/sigs/pubs/proceed/template.html. All papers and abstracts should be submitted in either PS or PDF format. Poster and demo submissions should be accompanied with a 2-page abstract. Papers and abstracts should be submitted through the ARM07 EasyChair online submissions website: http://www.easychair.org/ARM07/. All accepted papers will be published via the ACM's Digital Library as part of the "ACM International Conference Proceeding Series" (AICPS). A few selected papers may additionally be invited to submit an extended version to IEEE Distributed Systems Online. Topics of interest to this workshop include, but are not limited to, the following: * Design and performance of adaptive and self-adaptive middleware platforms * Application of adaptive and reflective middleware techniques to achieve reconfigurability and/or adaptability * Application of techniques to achieve separation of concerns in middleware environments * Design of Meta Object Protocols (MOP) for reflective middleware * Cross-layer interactions and adaptation mechanisms including network, OS and device level techniques * Adaptation and reflection in execution environments such as P2P networks, ad-hoc networks, and network-centric computing * Incorporation of non-functional properties such as real-time, fault-tolerance, security, etc. into middleware * Incorporation of adaptation into middleware-related software development techniques, such as design patterns, component frameworks or software architectures * Experiences with adaptive middleware technologies in specific application domains; e.g., sensor networks, ubiquitous and pervasive computing, mobile computing, grid computing etc. * Fundamental developments in the theory and practice of adaptation and reflection, as it relates to middleware * Examination of how complementary techniques, such as aspect- oriented programming, can solve problems in the design, implementation and use of adaptive middleware * Techniques to improve the performance and/or scalability of adaptive middleware techniques * Design and programming abstractions to manage the complexity of adaptive middleware * Approaches to maintain the integrity of adaptive middleware * Tools for adaptive middleware to support areas such as development, deployment, debugging or modeling * Hardware reconfigurability as it relates to middleware Important Dates --------------- Paper, poster and demo submissions.......August 12th, 2007 Acceptance notificati..............................September 1st, 2007 Camera-ready papers due.........................October 1st, 2007 Workshop...............................................November 26th, 2007 Program Chairs -------------- Fabio Costa.........................Federal University of Goias, Brazil Publicity Chair --------------- Sebastian Gutierrez-Nolasco.....University of California at Irvine, USA Poster/Demo Chair ----------------- t.b.d. Publications Chair ------------------ t.b.d. Technical Program Committee --------------------------- Anders Andersen....................................University of Tromso, Norway Gordon Blair.....................................................Lancaster University, UK Roy Campbell..................University of Illinois at U. Champaign, USA Renato Cerqueira...........................................................PUC- Rio, Brazil Yvonne Coady.............................................University Victoria, Canada Angelo Corsaro..........................................Alenia Marconi System, Italy Fabio Costa......................................Federal University of Goias, Brazil Geoff Coulson...................................................Lancaster University, UK Edward Curry..............................National University of Ireland, Ireland Frank Eliassen................................................University of Oslo, Norway Christopher Gill......................Washington University in St. Louis, USA Sebastian Gutierrez-Nolasco....University of California at Irvine, USA Jadwiga Indulska...........................University of Queensland, Australia Fabio Kon................................................University of Sao Paulo, Brazil Joseph Loyall.....................................................BBN Technologies, USA Priya Narasimhan..............................Carnegie Mellon University, USA Manish Parashar................................................Rutgers University, USA Omer F. Rana...........................................................Cardiff U niversity, UK Corrado Santoro.............................................University of Catania, Italy Douglas Schmidt...........................................Vanderbilt University, USA Francisco Silva e Silva............Federal University of Maranhao, Brazil Richard Staehli...................................Independent Consultant, Norway Alexandre Sztajnberg..........State University of Rio de Janeiro, Brazil Carolyn Talcott.......................................................SRI International, USA Gerry Tesauro.................................................IBM T.J.Watson Labs, USA Nalini Venkatasubramanian......University of California at Irvine, USA Nanbor Wang....................................................Tech-X Corporation, USA Mazin Yousif.....................................................Intel Research Labs, USA Organizing Committee -------------------- Renato Cerqueira.............................................................PU C-Rio, Brazil Fabio Costa.......................................Federal University of Goias, Brazil Geoff Coulson.....................................................Lancaster University, UK Sebastian Gutierrez-Nolasco.....University of California at Irvine, USA Omer F. Rana............................................................Cardiff University, UK Nalini Venkatasubramanian.......University of California at Irvine, USA Contact Info: arm07@easychair.org _______________________________________________ Middleware2007 mailing list Middleware2007@mailman.ics.uci.edu https://mailman.ics.uci.edu/mailman/listinfo/middleware2007 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 01 11:37: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 1IGGGk-0003Mg-RZ; Wed, 01 Aug 2007 11:37:50 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IAhlL-0005xf-Qa for mip4-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 03:46:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAhlL-0005uc-Bv; Tue, 17 Jul 2007 03:46:27 -0400 Received: from mx2.univ-lille1.fr ([193.49.225.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAhlK-0005e7-VU; Tue, 17 Jul 2007 03:46:27 -0400 Received: from malonne.lifl.fr (malonne.lifl.fr [134.206.10.29]) by mx2.univ-lille1.fr (8.14.0/8.14.0) with ESMTP id l6H7fuK0003881; Tue, 17 Jul 2007 09:41:56 +0200 Received: from [127.0.0.1] (romy.lifl.fr [134.206.11.216]) by malonne.lifl.fr with ESMTP id l6H7fnU28818 ; Tue, 17 Jul 2007 09:41:52 +0200 (MEST) Message-ID: <469C72CC.1000207@inria.fr> Date: Tue, 17 Jul 2007 09:42:04 +0200 From: Nathalie MITTON User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7.13) Gecko/20060414 X-Accept-Language: fr, en MIME-Version: 1.0 To: mycolleagues@grid.lrg.ufsc.br, ActiveNets_Wire@ittc.ukans.edu, aaa-wg@merit.edu, tcos-announce@tcos.org, cfp@mmlab.snu.ac.kr, comm-theory@ieee.org, commsoft@ieee.org, ecoop-info@ecoop.org, netnomics@listserver.tue.nl, reres@laas.fr, tcgn@ieee.org, wg2@wireless-world-research.org, wg3@wireless-world-research.org, mip6@ietf.org, mip4@ietf.org, mobisys@acm.org, announce@tcos.org, tccc@cs.columbia.edu, tci-announce@computer.org, MOBICOM@acm.org, wg7_3@cs.umass.edu, ifip-tc6@informatik.rwth-aachen.de, itc@i-teletraffic.org, types@cis.upenn.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000757-2, 16/07/2007), Outbound message X-Antivirus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (mx2.univ-lille1.fr [193.49.225.20]); Tue, 17 Jul 2007 09:42:00 +0200 (CEST) X-USTL-MailScanner-Information: Please contact the ISP for more information X-USTL-MailScanner: Found to be clean X-USTL-MailScanner-From: nathalie.mitton@inria.fr X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Wed, 01 Aug 2007 11:37:50 -0400 Cc: Subject: [Mip4] IMAGINE 2007 - Call For Participation X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org *** Apologies for multiple copies *** ______________________________________________________________________ CALL FOR PARTICIPATION IMAGINE 2007 1st International workshop on Mobility, Algorithms and Graph theory In dynamic NEtworks September 26-27, 2007 Lemesos, Cyprus http://www.lifl.fr/IMAGINE2007/ Collocated with DISC 2007 ______________________________________________________________________ We cordially invite you to attend the IMAGINE 2007 workshop to be held in conjunction with DISC 2007, in Lemesos, Cyprus, which will bring together researchers from academia and industry. By attending IMAGINE, you will be given talks by talented junior researchers from the dynamic graphs research area. Indeed, the scientific program of the workshop consists of 5 invited lectures given by 5 junior speakers selected by a strong PC committee with respect to the quality of their research. This workshop aims at letting junior researchers around the world have a larger view of the recent results of their peers, in order to favor future collaboration. IMAGINE also aims at providing a supportive setting for feedback on junior researchers' current research and guidance on future research directions by offering them comments and fresh perspectives on their work from peers outside their own institution and/or field. Full details are on the conference Web site: http://www.lifl.fr/IMAGINE2007/ Invited speakers ================ Doina Bein (University of Texas at Dallas, USA) Augustin Chaintreau (Thomson Paris Research Lab, France) Hannes Frey (University of Southern Denmark, Denmark) Emmanuelle Lebhar (CNRS, LIAFA, France) Thomas Moscibroda (Microsoft Research, USA) Contact ================ David Ilcinkas (david.ilcinkas@lri.fr) Nathalie Mitton (nathalie.mitton@inria.fr) Nicolas Nisse (nicolas.nisse@lri.fr) Co-sponsored by ================ IEEE Cyprus INRIA Futurs -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 01 11:38: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 1IGGH1-0003YB-CV; Wed, 01 Aug 2007 11:38:07 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1I82xe-0007C9-0e for mip4-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 19:48:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I82xd-0007C0-NB for mip4@ietf.org; Mon, 09 Jul 2007 19:48:09 -0400 Received: from kronos.cti.gr ([150.140.1.25]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I82xZ-0002FU-2p for mip4@ietf.org; Mon, 09 Jul 2007 19:48:09 -0400 Received: (qmail 20727 invoked from network); 9 Jul 2007 23:35:14 -0000 Received: from hermes.cti.gr (150.140.1.34) by kronos.cti.gr with SMTP; 9 Jul 2007 23:35:14 -0000 Received: (qmail 17767 invoked by uid 41021); 9 Jul 2007 23:35:11 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Jul 2007 23:35:11 -0000 Date: Tue, 10 Jul 2007 02:35:11 +0300 (EEST) From: Ioannis Chatzigiannakis To: Ioannis Chatzigiannakis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 X-Mailman-Approved-At: Wed, 01 Aug 2007 11:38:06 -0400 Cc: Subject: [Mip4] ALGOSENSORS 2007 -- Call for Participation X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org ************************************************************************** Third International Workshop on Algorithmic Aspects of Wireless Sensor Networks A L G O S E N S O R S 2 0 0 7 July 14, 2006, Wroclaw, Poland To be held in conjunction with ICALP 2007. http://algosensors2007.im.pwr.wroc.pl ************************************************************************** C A L L F O R P A R T I C I P A T I O N ************************************************************************** SCOPE Wireless ad-hoc sensor networks have recently become a very active research subject due to their high potential of providing diverse services to numerous important applications, including remote monitoring and tracking in environmental applications and low maintenance ambient intelligence in everyday life. The effective and efficient realization of such large scale, complex ad-hoc networking environments requires intensive, coordinated technical research and development efforts, especially in power aware, scalable, robust wireless distributed protocols, due to the unusual application requirements and the severe resource constraints of the sensor devices. On the other hand, a solid foundational background seems necessary for sensor networks to achieve their full potential. It is a challenge for abstract modeling, algorithmic design and analysis to achieve provably efficient, scalable and fault-tolerant realizations of such huge, highly-dynamic, complex, non-conventional networks. Features including the extremely large number of sensor devices in the network, the severe power, computing and memory limitations, their dense, random deployment and frequent failures, pose new interesting abstract modeling, algorithmic design, analysis and implementation challenges of great practical impact. This Workshop aims to bring together research contributions related to diverse algorithmic and complexity theoretic aspects of wireless sensor networks. This is the third event in the series. ALGOSENSORS 2004 was held in Turku, Finland, ALGOSENSORS 2006 was held in Venice, Italy. Since its beginning ALGOSENSORS is collocated with ICALP. ************************************************************************** KEYNOTE SPEACHES Sandor Fekete Topology and Routing in Sensor Networks (Keynote Speech) Joao Barros Codes for Sensors: An Algorithmic Perspective (Keynote Speech) ************************************************************************** ACCEPTED PAPERS * Sotiris Nikoletseas, Paul G. Spirakis Efficient Sensor Network Design for Continuous Monitoring of Moving Objects * Beat Gfeller, Matus Mihalak, Subhash Suri, Elias Vicari, Peter Widmayer Counting Targets with Mobile Sensors in an Unknown Environment * F. Barsi, A.A. Bertossi, F. Betti Sorbelli, R. Ciotti, S. Olariu, M.C. Pinotti Asynchronous Training in Wireless Sensor Networks * Luzi Anderegg, Stephan Eidenbenz, Leon Peeters, Peter Widmayer Optimal Placement of Ad-Hoc Devices under a VCG-style Routing Protocol * Marcin Zawada Analysis of the Bounded-Hops Converge-Cast Distributed Protocol in Ad-Hoc Networks * Samar Agnihotri, Pavan Nuggehalli, and H.S. Jamadagni Correlation, Coding, and Cooperation in Wireless Sensor Networks * Patrik Floreen, Petteri Kaski, Topi Musto, Jukka Suomela Local Approximation Algorithms for Scheduling Problems in Sensor Networks * Amotz Bar-Noy, Theodore Brown, Matthew P. Johnson, Thomas La Porta, Ou Liu, Hosam Rowaihy Assigning Sensors to Missions with Demands * Anirvan DuttaGupta, Arijit Bishnu, Indranil Sengupta Maximal Breach in Wireless Sensor Networks: Geometric Characterization and Algorithms * Maciej Gebala, Marcin Kik Counting-sort and Routing in a Single Hop Radio Network * Ioannis Krontiris, Tassos Dimitriou, Thanassis Giannetsos, Marios Mpasoukos Intrusion Detection of Sinkhole Attacks in Wireless Sensor Networks ************************************************************************** PROGRAM COMMITTEE CHAIR * Miroslaw Kutylowski, Wroclaw University of Technology, Poland STEERING COMMITTEE * Josep Diaz, Technical University of Catalonia, Spain * Jan van Leeuwen, Utrecht University, The Netherlands * Sotiris Nikoletseas (Chair), University of Patras and CTI, Greece * Jose Rolim, University of Geneva, Switzerland * Paul Spirakis, University of Patras and CTI, Greece ************************************************************************** PROCEEDINGS Accepted papers will be published in full text in a hardcopy Proceedings by the Lecture Notes in Computer Science (LNCS) Series of Springer Verlag. We are going to have post-proceedings i.e. authors will have the opportunity to revise their papers in the light of the discussion at the event and then submit their camera ready files by the end of August. Pre-proceedings will be available during the workshop for the participants. TCS JOURNAL SPECIAL ISSUE Selected high quality papers will be considered for publication in a Special Issue on Algorithmic Aspects of Wireless Sensor Networks of the Theoretical Computer Science (TCS) Journal. ************************************************************************** SPONSORS * Polish Ministry Of Science and Higher Education * Wroclaw University of Technology ************************************************************************** CONTACT * web: http://algosensors.im.pwr.wroc.pl * email: algosensors2007@im.pwr.wroc.pl * fax: +4871 320 2109 ************************************************************************** -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 02 17:33:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGiIx-00033I-8l; Thu, 02 Aug 2007 17:33:59 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IGiIw-00033A-CA for mip4-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 17:33:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGiIw-000332-0r; Thu, 02 Aug 2007 17:33:58 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGiIu-0003jC-RR; Thu, 02 Aug 2007 17:33:57 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l72LXqiI028189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Aug 2007 14:33:52 -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 l72LXpi3025577; Thu, 2 Aug 2007 14:33:51 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 14:33:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] draft-ietf-mip4-gen-ext-03.txt Date: Thu, 2 Aug 2007 14:33:50 -0700 Message-ID: In-Reply-To: <46AF6F1C.3000408@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] draft-ietf-mip4-gen-ext-03.txt Thread-Index: AcfTvAclFMBTioe/QlqnQGKyrM5mqwBjCdRg References: <46AF6F1C.3000408@azairenet.com> From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "Jayshree Bharatia" X-OriginalArrivalTime: 02 Aug 2007 21:33:51.0167 (UTC) FILETIME=[D174C4F0:01C7D54C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: dhcwg@ietf.org, mip4@ietf.org, McCann Peter-A001034 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org I think this is an overdue discussion (I'm also guilty of not having participated in this discussion earlier). There may be some clarifications needed for getting the DHCP configuration options using DHCP over the MIP tunnel and I think it is necessary to have that discussion and document it appropriately. Personally, I'd prefer clearly documenting that instead of allowing the use of all the DHCP options in MIP again.=20 Further, in draft-ietf-mip4-gen-ext, the scenario of the DHCP server being independent of the HA is not handled. In order to support that, it seems like the HA will need to act as a proxy DHCP client, when the MN is requesting configuration information. So, the draft currently only seems to support the case where the relevant information is available at the HA itself, which I don't think can be a universal assumption. And, as far as I know, a proxy DHCP client is not a standard entity, although, there seem to be proprietary implementations of it.=20 On the other hand, if DHCP from the MN was tunneled through the MIP tunnel, the HA may need to act as a DHCP Relay Agent, with a separate DHCP server. =20 Further, I'll note that this isn't a unique issue to MIP4 and would be applicable to MIP6 as well. There may be some further considerations for MIP4 when using foreign agents.=20 Vidya > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Tuesday, July 31, 2007 10:19 AM > To: Jayshree Bharatia > Cc: dhcwg@ietf.org; mip4@ietf.org; McCann Peter-A001034 > Subject: Re: [Mip4] draft-ietf-mip4-gen-ext-03.txt >=20 > Well, the statement is still valid. There is no document that=20 > describes how to run DHCP over the Mobile IPv4 tunnel. (it=20 > may be obvious to some folks but not to all). >=20 > I guess what we need to decide is whether we want a document=20 > that describes how to run DHCP over the Mobile IPv4 tunnel or=20 > still go with the mechanism described in draft-ietf-mip4-gen-ext. >=20 > Vijay >=20 > Jayshree Bharatia wrote: > > Hi Pete, > >=20 > > The proposal in this draft was always considered as an alternative=20 > > over DHCP. There was never an intent saying that the mechanism=20 > > discussed in this draft is the only way to exchange configuration=20 > > information between two Mobile IP entities. This draft has=20 > been there=20 > > for a long time and honestly, I have lost track of who=20 > provided which=20 > > comment which resulted in the statement you quoted. > >=20 > > We have already gone through multiple WGLC on this draft=20 > and I don't=20 > > necessary agree on the change of status at this time. > >=20 > > Regards, > > Jayshree > >=20 > > -----Original Message----- > > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > > Sent: Tuesday, July 31, 2007 9:01 AM > > To: mip4@ietf.org; dhcwg@ietf.org > > Subject: [Mip4] draft-ietf-mip4-gen-ext-03.txt > >=20 > >=20 > > A question has arisen during the last call for=20 > > draft-ietf-mip4-gen-ext-03.txt. > >=20 > > The draft includes the following text: > >=20 > > There are mechanisms > > such as DHCP for the mobile node to configure=20 > information from the > > foreign network, but not from the home network when the=20 > mobile node > > is not attached to the home network. > >=20 > > However, this may not be strictly true. In particular, it might be=20 > > possible to use a DHCPINFORM message through the tunnel that was=20 > > established with Mobile IP, thus eliminating the need to=20 > encode DHCP=20 > > options inside Mobile IP messages. This would allow for a single=20 > > configuration protocol to be used whether the MN is at home or=20 > > visiting. > >=20 > > I think we may have touched on this question during our last=20 > > chartering discussion but we might not have explored all=20 > the ramifications. > > Please, if you have an opinion either way express it now=20 > and give some=20 > > background as to why you think so. It is possible that we=20 > might turn=20 > > this draft into a BCP-like document for how to configure=20 > and run DHCP=20 > > over the tunnel to the home network. > >=20 > > -Pete > >=20 > >=20 >=20 >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 02 19:00: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 1IGjf3-0001sc-NV; Thu, 02 Aug 2007 19:00:53 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IGjf1-0001s4-LQ for mip4-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 19:00:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGjf1-0001rq-8f; Thu, 02 Aug 2007 19:00:51 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGjf0-0005Ae-Ew; Thu, 02 Aug 2007 19:00:50 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id B0A3A900FB; Thu, 2 Aug 2007 19:00:46 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04566-15; Thu, 2 Aug 2007 19:00:43 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP; Thu, 2 Aug 2007 19:00:43 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Aug 2007 19:01:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] draft-ietf-mip4-gen-ext-03.txt Date: Thu, 2 Aug 2007 19:00:17 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024DA3E6@exchtewks2.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] draft-ietf-mip4-gen-ext-03.txt Thread-Index: AcfTe0Ke/BKsgd15SyWMrcjFTjhBOwB2i4TA From: "Chowdhury, Kuntal" To: "McCann Peter-A001034" , , X-OriginalArrivalTime: 02 Aug 2007 23:01:07.0976 (UTC) FILETIME=[02D66880:01C7D559] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Pete, I think the source of the confusion is the use of DHCP options. The initial version of this I-D did not propose to use DHCP options at all. The proposal contained a few possible host config parameters that we would have defined. However, someone saw the light, and suggested that instead of redesigning the host config options from scratch, why not we used the options and the format of the options carrying config info as defined in DHCP. It made sense; hence we decided to accept that approach. Now, I see that people are mixing the use of DHCP protocol with MIP4 host config options. I think this is a digression that we should avoid. We need to understand the scope of the I-D. It does not rule out other ways to do host configuration when the MN is using MIP4. It defines _a_ way that is Mobile IP specific. It is also the most efficient one from the number of round trips point of view. When you say that running DHCP inside MIP4 tunnel allows for a single protocol to be used whether the MN is at home or visiting, I have a question. How is it possible for the MN to fetch config info from the visited network when RT is negotiated and enforced at the FA?=20 BTW, the approach specified in the draft-ietf-mip4-gen-ext-03.txt allows the use of a single protocol i.e. MIP4 to be used to fetch config info from home and visited networks, not to mention with fewer number of messages. Another issue that we need to think about the use of DHCP inside MIP4 tunnel is security. We cannot prohibit the MN to run DHCPINFORM only, right? The MN may start doing IP address config (lease and release). How to secure these DHCP messages? If we intend to only allow the MN to send DHCPINFORM, how do we prevent it from sending other DHCP messages? AFAIK, RFC 3118 is not widely implemented and used. Even if it is, we can't expect the MIP4 implementations to start implementing RFC 3118 just to get a few config info from the home domain. Regards, Kuntal > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Tuesday, July 31, 2007 9:01 AM > To: mip4@ietf.org; dhcwg@ietf.org > Subject: [Mip4] draft-ietf-mip4-gen-ext-03.txt >=20 > A question has arisen during the last call for > draft-ietf-mip4-gen-ext-03.txt. >=20 > The draft includes the following text: >=20 > There are mechanisms > such as DHCP for the mobile node to configure information from the > foreign network, but not from the home network when the mobile node > is not attached to the home network. >=20 > However, this may not be strictly true. In particular, > it might be possible to use a DHCPINFORM message through > the tunnel that was established with Mobile IP, thus eliminating > the need to encode DHCP options inside Mobile IP messages. > This would allow for a single configuration protocol to be > used whether the MN is at home or visiting. >=20 > I think we may have touched on this question during our last > chartering discussion but we might not have explored all the > ramifications. Please, if you have an opinion either way > express it now and give some background as to why you think so. > It is possible that we might turn this draft into a BCP-like > document for how to configure and run DHCP over the tunnel > to the home network. >=20 > -Pete >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 06 18:00: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 1IIAd4-00014v-9T; Mon, 06 Aug 2007 18:00:46 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IIAd3-00014n-1e for mip4-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 18:00:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIAd2-00014f-K3 for mip4@ietf.org; Mon, 06 Aug 2007 18:00:44 -0400 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIAd1-00075D-Se for mip4@ietf.org; Mon, 06 Aug 2007 18:00:44 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1C8F7491E8F for ; Mon, 6 Aug 2007 15:00:43 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05590-08 for ; Mon, 6 Aug 2007 15:00:42 -0700 (PDT) Received: from [JC??O??IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id AF9F7491E8C for ; Mon, 6 Aug 2007 15:00:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) To: mip4@ietf.org Message-Id: From: Acee Lindem Date: Mon, 6 Aug 2007 17:59:28 -0400 X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 1.8 (+) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Subject: [Mip4] RFC 3344 and draft-ietf-mip4-rfc3344bis-05.txt IANA Considerations X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1037352418==" Errors-To: mip4-bounces@ietf.org --===============1037352418== Content-Type: multipart/alternative; boundary=Apple-Mail-63--175544764 --Apple-Mail-63--175544764 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Charlie, Why is the type 0 for one-byte pad listed in section 6.3 under the "Extensions for Mobile IP Registrations"? 6.3. Extensions to Mobile IP Registration Messages The Mobile IP messages, specified within this document, and listed in Section 1.8 and Section 6.1, may have extensions. Mobile IP message extensions all share the same number space, even if they are to be applied to different Mobile IP messages. The number space for Mobile IP message extensions is specified within this document. Approval of new extension numbers is subject to Expert Review, and a specification is required [14]. Type Name Reference ---- -------------------------------------------- --------- 0 One-byte Padding ~~~~~~~~~~~~~~~~~~~~ 32 Mobile-Home Authentication 3.5.2 33 Mobile-Foreign Authentication 3.5.3 34 Foreign-Home Authentication 3.5.4 Clearly, that is not the intent nor what IANA has reserved: http://www.iana.org/assignments/mobileip-numbers Thanks, Acee --Apple-Mail-63--175544764 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Hi Charlie,

Why is the type 0 for one-byte = pad listed in section 6.3 under the "Extensions for Mobile IP = Registrations"?=A0

6.3.=A0 Extensions to Mobile IP Registration = Messages

=A0= =A0 The = Mobile IP messages, specified within this document, and listed = in
=A0=A0 Section 1.8 and Section 6.1, may have = extensions.=A0 = Mobile IP = message
=A0=A0 extensions all share the same number space, even if = they are to be
=A0=A0 applied to different = Mobile IP messages.=A0 The number space for Mobile
=A0= =A0 IP = message extensions is specified within this document.=A0 Approval = of
=A0=A0 new extension numbers is subject to Expert Review, = and a
=A0=A0 specification is required [14].

=A0=A0 =A0 =A0 = Type=A0 Name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Reference
=A0=A0 =A0 =A0 = ----=A0 -------------------------------------------- = =A0 =A0 = ---------
=A0=A0 =A0 =A0 = 0 = =A0 =A0 = One-byte = Padding
~~~~~~~~~~~~~~~~~~~~
=A0= =A0 =A0 =A0 32=A0 =A0 Mobile-Home Authentication =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 3.5.2
=A0=A0 =A0 =A0 = 33=A0 =A0 Mobile-Foreign = Authentication=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3.5.3
=A0= =A0 =A0 =A0 34=A0 =A0 Foreign-Home Authentication=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 3.5.4


Clearly, that is not the = intent nor what IANA has reserved:


Thanks,
Acee=
= --Apple-Mail-63--175544764-- --===============1037352418== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1037352418==-- From mip4-bounces@ietf.org Tue Aug 07 10:35: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 1IIQ9g-00067O-PD; Tue, 07 Aug 2007 10:35:28 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IIQ9e-00066Z-Tg for mip4-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 10:35:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQ9e-00065w-Ae; Tue, 07 Aug 2007 10:35:26 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIQ9d-0001ON-Un; Tue, 07 Aug 2007 10:35:26 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 3EED6175D8; Tue, 7 Aug 2007 14:15:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IIPpu-0003y7-QO; Tue, 07 Aug 2007 10: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, 07 Aug 2007 10:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-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 IPv4 Working Group of the IETF. Title : Dual Stack Mobile IPv4 Author(s) : G. Tsirtsis, et al. Filename : draft-ietf-mip4-dsmipv4-03.txt Pages : 25 Date : 2007-8-7 This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual stack node to use IPv4 and IPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-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-mip4-dsmipv4-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-mip4-dsmipv4-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-7094637.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-dsmipv4-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-dsmipv4-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-7094637.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Tue Aug 07 10:48: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 1IIQM6-0007uU-TZ; Tue, 07 Aug 2007 10:48:18 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IIQM5-0007uA-KC for mip4-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 10:48:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQM5-0007tt-8m for mip4@ietf.org; Tue, 07 Aug 2007 10:48:17 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IIQM5-0002Zy-09 for mip4@ietf.org; Tue, 07 Aug 2007 10:48:17 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1186498095!25907986!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 24467 invoked from network); 7 Aug 2007 14:48:15 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-14.tower-119.messagelabs.com with SMTP; 7 Aug 2007 14:48:15 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l77EmFVr024976 for ; Tue, 7 Aug 2007 07:48:15 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l77EmEis007009 for ; Tue, 7 Aug 2007 09:48:14 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l77EmCgw006984 for ; Tue, 7 Aug 2007 09:48:13 -0500 (CDT) 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: Tue, 7 Aug 2007 10:48:10 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minutes from IETF 69 Thread-Index: AcfZAfkVxDebyHeuScaDCV+vFx4wIQ== From: "McCann Peter-A001034" To: X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Levkowetz Henrik Subject: [Mip4] Minutes from IETF 69 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org The minutes from our meeting at IETF 69 have been uploaded here: http://www3.ietf.org/proceedings/07jul/minutes/mip4.txt Please send any comments or corrections to the list as soon as possible. -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 07 10:52:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQPh-0001qS-Ts; Tue, 07 Aug 2007 10:52:01 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IIQPV-0001YY-Qd for mip4-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 10:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQPV-0001Xw-6M for mip4@ietf.org; Tue, 07 Aug 2007 10:51:49 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IIQPT-0006QD-TI for mip4@ietf.org; Tue, 07 Aug 2007 10:51:49 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1186498306!5426927!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 2288 invoked from network); 7 Aug 2007 14:51:46 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-11.tower-153.messagelabs.com with SMTP; 7 Aug 2007 14:51:46 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l77EpkT5029183 for ; Tue, 7 Aug 2007 09:51:46 -0500 (CDT) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l77EpjB0022335 for ; Tue, 7 Aug 2007 09:51:45 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l77EphIZ022312 for ; Tue, 7 Aug 2007 09:51:44 -0500 (CDT) 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: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Date: Tue, 7 Aug 2007 10:51:44 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Thread-Index: AcfZASuebTA/LzLbRKKYQS2wK8BHwQAARSZg References: From: "McCann Peter-A001034" To: , X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Thanks George for submitting the updated version. Kent, you said during the meeting that you had some comments on this draft. Could you send them to the list, so that we can move ahead with this document? Thanks, -Pete Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories.=20 > This draft is a work item of the Mobility for IPv4 Working Group of > the IETF.=20 >=20 > Title : Dual Stack Mobile IPv4 > Author(s) : G. Tsirtsis, et al. > Filename : draft-ietf-mip4-dsmipv4-03.txt > Pages : 25 > Date : 2007-8-7 >=20 > This specification provides IPv6 extensions to the Mobile IPv4 > protocol. The extensions allow a dual stack node to use IPv4 and > IPv6 home addresses as well as to move between IPv4 and dual stack > network infrastructures. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-03.txt >=20 > 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. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > 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-mip4-dsmipv4-03.txt". =20 >=20 > 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 =20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mip4-dsmipv4-03.txt". >=20 > 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. >=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 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 07 11:10: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 1IIQhJ-0007Ic-8u; Tue, 07 Aug 2007 11:10:13 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IIQhH-0007Hn-Vv for mip4-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 11:10:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQhH-0007Ha-M4 for mip4@ietf.org; Tue, 07 Aug 2007 11:10:11 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIQhG-0006x5-7G for mip4@ietf.org; Tue, 07 Aug 2007 11:10:11 -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 l77FA8pa017190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 7 Aug 2007 08:10:08 -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 l77FA7c2000595; Tue, 7 Aug 2007 08:10:07 -0700 (PDT) Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 08:09:07 -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: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Date: Tue, 7 Aug 2007 08:09:30 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF4871A94@NAEX16.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Thread-Index: AcfZASuebTA/LzLbRKKYQS2wK8BHwQAARSZgAABr6aA= References: From: "Tsirtsis, George" To: "McCann Peter-A001034" , , X-OriginalArrivalTime: 07 Aug 2007 15:09:07.0996 (UTC) FILETIME=[E6E125C0:01C7D904] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Peter, Kent sent me his comments offline and I have incorporated them in the draft. His main comment was about clarifying that implicit mode is entirely transparent to the FA, which I did. He is now, I think, on vacation so I could not check the changes with him. In any case I am sure he will check the document next week when he will be back. Regards George -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 Sent: Tuesday, August 07, 2007 3:52 PM To: mip4@ietf.org; kleung@cisco.com Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt=20 Thanks George for submitting the updated version. Kent, you said during the meeting that you had some comments on this draft. Could you send them to the list, so that we can move ahead with this document? Thanks, -Pete Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories.=20 > This draft is a work item of the Mobility for IPv4 Working Group of > the IETF.=20 >=20 > Title : Dual Stack Mobile IPv4 > Author(s) : G. Tsirtsis, et al. > Filename : draft-ietf-mip4-dsmipv4-03.txt > Pages : 25 > Date : 2007-8-7 >=20 > This specification provides IPv6 extensions to the Mobile IPv4 > protocol. The extensions allow a dual stack node to use IPv4 and > IPv6 home addresses as well as to move between IPv4 and dual stack > network infrastructures. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-03.txt >=20 > 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. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > 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-mip4-dsmipv4-03.txt". =20 >=20 > 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 =20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mip4-dsmipv4-03.txt". >=20 > 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. >=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 --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 07 11:13: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 1IIQks-00049p-0v; Tue, 07 Aug 2007 11:13:54 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IIQkp-00049c-Pi for mip4-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 11:13:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIQkp-00049Q-G5 for mip4@ietf.org; Tue, 07 Aug 2007 11:13:51 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IIQko-00074H-TU for mip4@ietf.org; Tue, 07 Aug 2007 11:13:51 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1186499629!5295655!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 19848 invoked from network); 7 Aug 2007 15:13:49 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-7.tower-153.messagelabs.com with SMTP; 7 Aug 2007 15:13:49 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l77FDnF1004002 for ; Tue, 7 Aug 2007 10:13:49 -0500 (CDT) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l77FDmeP029262 for ; Tue, 7 Aug 2007 10:13:48 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l77FDkhV029248 for ; Tue, 7 Aug 2007 10:13:47 -0500 (CDT) 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: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Date: Tue, 7 Aug 2007 11:13:46 -0400 Message-ID: In-Reply-To: <2309978910A6A6478C2C7585692B0AF4871A94@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Thread-Index: AcfZASuebTA/LzLbRKKYQS2wK8BHwQAARSZgAABr6aAAAF7rcA== References: <2309978910A6A6478C2C7585692B0AF4871A94@NAEX16.na.qualcomm.com> From: "McCann Peter-A001034" To: "Tsirtsis, George" , , X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Ok, thanks George. We'll wait for word from Kent and then proceed from there. -Pete Tsirtsis, George wrote: > Hi Peter, >=20 > Kent sent me his comments offline and I have incorporated them in the > draft. His main comment was about clarifying that implicit mode is > entirely transparent to the FA, which I did. =20 >=20 > He is now, I think, on vacation so I could not check the changes with > him. In any case I am sure he will check the document next week when > he will be back. =20 >=20 > Regards > George >=20 >=20 > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Tuesday, August 07, 2007 3:52 PM > To: mip4@ietf.org; kleung@cisco.com > Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt >=20 > Thanks George for submitting the updated version. >=20 > Kent, you said during the meeting that you had some comments on this > draft. Could you send them to the list, so that we can move ahead > with this document? =20 >=20 > Thanks, >=20 > -Pete >=20 > Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Mobility for IPv4 >> Working Group of the IETF.=20 >>=20 >> Title : Dual Stack Mobile IPv4 >> Author(s) : G. Tsirtsis, et al. >> Filename : draft-ietf-mip4-dsmipv4-03.txt >> Pages : 25 >> Date : 2007-8-7 >>=20 >> This specification provides IPv6 extensions to the Mobile IPv4 >> protocol. The extensions allow a dual stack node to use IPv4 and >> IPv6 home addresses as well as to move between IPv4 and dual >> stack network infrastructures.=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-03.txt >>=20 >> 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.=20 >>=20 >> 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-mip4-dsmipv4-03.txt". >>=20 >> 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 >>=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-mip4-dsmipv4-03.txt". >>=20 >> 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. >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 07 11:34: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 1IIR4a-0002ns-Cy; Tue, 07 Aug 2007 11:34:16 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IIR4Z-0002nh-PY for mip4-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 11:34:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIR4Z-0002nM-F8; Tue, 07 Aug 2007 11:34:15 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIR4Z-0004IG-3F; Tue, 07 Aug 2007 11:34:15 -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 l77FYCq14350; Tue, 7 Aug 2007 15:34:12 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 Date: Tue, 7 Aug 2007 10:34:06 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711601FED4@zrc2hxm2.corp.nortel.com> In-Reply-To: <46B04CEB.5010407@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 1: Field Data supporting the use case per: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0A References: <46B04CEB.5010407@gmx.net> From: "Ahmad Muhanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mip4@ietf.org, Hannes Tschofenig Subject: [Mip4] Issue 1: Field Data supporting the use case per: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi All, During the DIME meeting at IETF-69, there was a question raised if there is any field data which support the case that it may takes the MN more than one second to receive the initial RRP message and the MN had to retransmit the initial RRQ. First of all, IMO, I would like to say that it is very possible and realistic to assume that under certain conditions the initial MIPv4 RRP message may take more than one second to arrive at the Mobile Node. As far as getting the field data, I will continue to try to find some real data on this. On the other hand, I really appreciate it if any of the handset, AAA vendors or any of the operators can share or comment on this field data record. =20 Regards, Ahmad =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Wednesday, August 01, 2007 4:06 AM > To: dime@ietf.org > Cc: Muhanna, Ahmad (RICH1:2H10) > Subject: MIPv4 Authentication Performance Using RADIUS and=20 > Diameter MIPv4 >=20 > Hi Ahmad, >=20 > you raised some interesting discussions during the DIME=20 > working group meeting. Unfortunately, there was not enough=20 > time to address all questions. >=20 > I would be great if you could > * summarize your presentation, and > * address some of the raised questions > on the mailing list. >=20 > Ciao > Hannes >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 07 11:39:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIR98-0007Cu-0g; Tue, 07 Aug 2007 11:38:58 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IIR96-00077A-Uh for mip4-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 11:38:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIR96-00070Q-FK; Tue, 07 Aug 2007 11:38:56 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIR96-0004SW-4G; Tue, 07 Aug 2007 11:38:56 -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 l77Fcrq15003; Tue, 7 Aug 2007 15:38:53 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 Date: Tue, 7 Aug 2007 10:38:52 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eA= From: "Ahmad Muhanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Hannes Tschofenig , mip4@ietf.org, McCann Peter-A001034 Subject: [Mip4] Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org =20 All, During DIME meeting at IETF-69, Pete raised the point that when RADIUS relay the re-transmitted RRQ without going to AAA, Pete thinks that there possibly a security concern. I would like to start this thread but I would like to let Pete summarize his concern and we then can discuss it. Hi Pete, Could you please summarize the security concern that you raised during DIME meeting? Many thanks in advance. =20 Regards, Ahmad =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, August 01, 2007 4:06 AM > To: dime@ietf.org > Cc: Muhanna, Ahmad (RICH1:2H10) > Subject: MIPv4 Authentication Performance Using RADIUS and Diameter=20 > MIPv4 >=20 > Hi Ahmad, >=20 > you raised some interesting discussions during the DIME working group=20 > meeting. Unfortunately, there was not enough time to address all=20 > questions. >=20 > I would be great if you could > * summarize your presentation, and > * address some of the raised questions on the mailing list. >=20 > Ciao > Hannes >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 07 16:45: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 1IIVwD-0008Ip-B1; Tue, 07 Aug 2007 16:45:57 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IIVwC-0008Id-4f for mip4-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 16:45:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIVwB-0008IT-Q0; Tue, 07 Aug 2007 16:45:55 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IIVwB-0008Kr-9J; Tue, 07 Aug 2007 16:45:55 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1186519553!3901118!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25976 invoked from network); 7 Aug 2007 20:45:53 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 7 Aug 2007 20:45:53 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l77Kjpri026363; Tue, 7 Aug 2007 13:45:53 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l77Kjovc020691; Tue, 7 Aug 2007 15:45:51 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l77KjneP020672; Tue, 7 Aug 2007 15:45:50 -0500 (CDT) 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: Tue, 7 Aug 2007 16:45:48 -0400 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMA== References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> From: "McCann Peter-A001034" To: "Ahmad Muhanna" , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: mip4@ietf.org, Hannes Tschofenig Subject: [Mip4] RE: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi, Ahmad, Maybe this is not so big an issue, but one thing that might happen is that the MN can use a different HA address in the re-transmitted RRQ. If there is network policy in place that only allows registering on specific HAs, this policy might be skirted by the retransmission unless the HA address is sent to the RADIUS/Diameter server with every RRQ. I am also concerned about increasing the overall registration time by going from one round-trip to two round-trips. The nice thing about the existing Diameter application is that it can do both authentication/authorization and MIP registration in one round-trip to the home network. One question: why couldn't we fix the problem by adjusting the retransmission timers upwards? If we know that AAA adds some additional delay, we could wait a bit longer before retransmitting the request. This seems to fix the problem.=20 -Pete Ahmad Muhanna wrote: > All, > During DIME meeting at IETF-69, Pete raised the point that when > RADIUS relay the re-transmitted RRQ without going to AAA, Pete thinks > that there possibly a security concern. =20 >=20 > I would like to start this thread but I would like to let Pete > summarize his concern and we then can discuss it.=20 >=20 > Hi Pete, >=20 > Could you please summarize the security concern that you raised > during DIME meeting?=20 > Many thanks in advance. >=20 > Regards, > Ahmad >=20 >=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, August 01, 2007 4:06 AM >> To: dime@ietf.org >> Cc: Muhanna, Ahmad (RICH1:2H10) >> Subject: MIPv4 Authentication Performance Using RADIUS and Diameter >> MIPv4=20 >>=20 >> Hi Ahmad, >>=20 >> you raised some interesting discussions during the DIME working group >> meeting. Unfortunately, there was not enough time to address all >> questions.=20 >>=20 >> I would be great if you could >> * summarize your presentation, and >> * address some of the raised questions on the mailing list. >>=20 >> Ciao >> Hannes -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 07 17:23: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 1IIWWR-00010Y-Ny; Tue, 07 Aug 2007 17:23:23 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IIWWQ-00010T-U7 for mip4-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 17:23:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIWWQ-00010L-Fy for mip4@ietf.org; Tue, 07 Aug 2007 17:23:22 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIWWP-0000r2-Q4 for mip4@ietf.org; Tue, 07 Aug 2007 17:23:22 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l77LNICi023321; Wed, 8 Aug 2007 00:23:18 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 00:23:17 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 16:23:15 -0500 Received: from [172.18.141.131] ([172.18.141.131]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 16:23:14 -0500 Message-ID: <46B8E2BE.7090208@nokia.com> Date: Tue, 07 Aug 2007 14:23:10 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Acee Lindem Subject: Re: [Mip4] RFC 3344 and draft-ietf-mip4-rfc3344bis-05.txt IANA Considerations References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Aug 2007 21:23:14.0992 (UTC) FILETIME=[2A54EB00:01C7D939] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hello Acee, The first, best answer I can give is that I don't know why that padding extension is listed there. Since it would be for UDP payloads, I don't immediately see why it should be needed. I don't remember hearing anyone express a need for it. There is not any text in the body of the specification describing such an extension. I don't remember asking IANA to put it in there, but I did not comb through all my emails with IANA to be sure. I seem to have some very hazy memory of a discussion about whether such a padding extension would be needed, but I can't resolve when or where or in what context. I think the simplest thing would be to just remove it, but if there are implementations out there relying on the existing of the padding extension, we should respect that. If more detail is needed, I could make a diff between each previous version of the Internet Drafts of the specification, but I'd prefer to avoid having to do that. Regards, Charlie P. ext Acee Lindem wrote: > Hi Charlie, > > Why is the type 0 for one-byte pad listed in section 6.3 under the > "Extensions for Mobile IP Registrations"? > > 6.3. Extensions to Mobile IP Registration Messages > > The Mobile IP messages, specified within this document, and listed in > Section 1.8 and Section 6.1, may have extensions. Mobile IP message > extensions all share the same number space, even if they are to be > applied to different Mobile IP messages. The number space for Mobile > IP message extensions is specified within this document. Approval of > new extension numbers is subject to Expert Review, and a > specification is required [14]. > > Type Name Reference > ---- -------------------------------------------- --------- > 0 One-byte Padding > ~~~~~~~~~~~~~~~~~~~~ > 32 Mobile-Home Authentication 3.5.2 > 33 Mobile-Foreign Authentication 3.5.3 > 34 Foreign-Home Authentication 3.5.4 > > > Clearly, that is not the intent nor what IANA has reserved: > > http://www.iana.org/assignments/mobileip-numbers > > Thanks, > Acee -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 07 18:02:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIX80-00028t-A7; Tue, 07 Aug 2007 18:02:12 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IIX7z-00028h-FI for mip4-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 18:02:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIX7z-00028Y-45; Tue, 07 Aug 2007 18:02:11 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIX7y-0001jX-Ia; Tue, 07 Aug 2007 18:02:11 -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 l77M0Dd29510; Tue, 7 Aug 2007 22:00:13 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 Date: Tue, 7 Aug 2007 17:02:04 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOw References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: mip4@ietf.org, Hannes Tschofenig Subject: [Mip4] RE: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Pete, Please see response inline. Regards, Ahmad =20 > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 > Sent: Tuesday, August 07, 2007 3:46 PM > To: Muhanna, Ahmad (RICH1:2H10); dime@ietf.org > Cc: mip4@ietf.org; Hannes Tschofenig > Subject: RE: Issue 2: Security Concern in RADIUS Mode: MIPv4=20 > Auth Performance Using RADIUS and Diameter MIPv4 Application draft >=20 > Hi, Ahmad, >=20 > Maybe this is not so big an issue, but one thing that might=20 > happen is that the MN can use a different HA address in the=20 > re-transmitted RRQ. If there is network policy in place that=20 > only allows registering on specific HAs, this policy might be=20 > skirted by the retransmission unless the HA address is sent=20 > to the RADIUS/Diameter server with every RRQ. [Ahmad] We can look at this special case later, but for the sake of this simple analysis, we need to address the most common simple scenario first. With the following in mind: "What would the impact be when using Diameter MIPv4 Application in place of RADIUS model." Also, usually the MN does not try to register with another HA until the registration process is timeout. In our case, we are focusing on the first retransmitted RRQ which usually done after one second. >=20 > I am also concerned about increasing the overall registration=20 > time by going from one round-trip to two round-trips. The=20 > nice thing about the existing Diameter application is that it=20 > can do both authentication/authorization and MIP registration=20 > in one round-trip to the home network. [Ahmad] I am sorry I missed this point here. Could you please elaborate a little further. >=20 > One question: why couldn't we fix the problem by adjusting=20 > the retransmission timers upwards? If we know that AAA adds=20 > some additional delay, we could wait a bit longer before=20 > retransmitting the request. This seems to fix the problem.=20 [Ahmad] I agree with you here. It is anticipated that Diameter MIPv4 Application will take a longer time to complete MIPv4 initial registration. Two questions:=20 1. Why the MN and possibly the network configurations need to change just for using Diameter MIPv4 Application in place of RADIUS. 2. On the other hand, even if we increase the initial timer a little, we still do not solve the issue, all what we do is delaying it.=20 >=20 > -Pete >=20 > Ahmad Muhanna wrote: > > All, > > During DIME meeting at IETF-69, Pete raised the point that=20 > when RADIUS=20 > > relay the re-transmitted RRQ without going to AAA, Pete thinks that=20 > > there possibly a security concern. > >=20 > > I would like to start this thread but I would like to let Pete=20 > > summarize his concern and we then can discuss it. > >=20 > > Hi Pete, > >=20 > > Could you please summarize the security concern that you=20 > raised during=20 > > DIME meeting? > > Many thanks in advance. > >=20 > > Regards, > > Ahmad > >=20 > >=20 > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Wednesday, August 01, 2007 4:06 AM > >> To: dime@ietf.org > >> Cc: Muhanna, Ahmad (RICH1:2H10) > >> Subject: MIPv4 Authentication Performance Using RADIUS and Diameter > >> MIPv4 > >>=20 > >> Hi Ahmad, > >>=20 > >> you raised some interesting discussions during the DIME=20 > working group=20 > >> meeting. Unfortunately, there was not enough time to address all=20 > >> questions. > >>=20 > >> I would be great if you could > >> * summarize your presentation, and > >> * address some of the raised questions on the mailing list. > >>=20 > >> Ciao > >> Hannes >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 07 18:04:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIX9k-0002wV-3h; Tue, 07 Aug 2007 18:04:00 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IIX9i-0002wQ-Sa for mip4-confirm+ok@megatron.ietf.org; Tue, 07 Aug 2007 18:03:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIX9i-0002wF-J7 for mip4@ietf.org; Tue, 07 Aug 2007 18:03:58 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIX9h-0004U3-U4 for mip4@ietf.org; Tue, 07 Aug 2007 18:03:58 -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 l77M22d29610 for ; Tue, 7 Aug 2007 22:02: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 Date: Tue, 7 Aug 2007 17:03:54 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711606FEFA@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIPv4 Authentication Performance Using RADIUS and Diameter MIPv4 Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGKopgAAB2vqABQkfZgA== From: "Ahmad Muhanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Subject: [Mip4] FW: MIPv4 Authentication Performance Using RADIUS and Diameter MIPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org =20 fyi Regards, Ahmad -----Original Message----- From: Muhanna, Ahmad (RICH1:2H10)=20 Sent: Wednesday, August 01, 2007 7:57 AM To: 'Hannes Tschofenig'; 'dime@ietf.org' Cc: 'Madjid Nakhjiri'; 'McCann Peter-A001034'; 'jouni.korhonen@teliasonera.com'; Khalil, Mohamed (RICH2:2S20); 'Avi Lior' Subject: RE: MIPv4 Authentication Performance Using RADIUS and Diameter MIPv4 Hi Hannes, Sorry, I forgot to summarize my presentation. Here is the summary: The basic idea of this draft is the following: =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 Since some SDO's is considering the full deployment of Diameter for MIP4 Authentication, Authorization, and possibly MSA allocation, the following question presents itself: What is the anticipated impact of Diameter Mobile IPv4 Application for MIPv4 Authentication, Authorization, and possibly MSA dynamic allocation on the MIPv4 session setup in comparison of RADIUS-Model MIPv4 Authentication and Authorization, etc. High Level Summary of Diameter Mobile IPv4 Application: =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=3D=3D=3D 1. The main functionality of the Diameter MIP4 Application is to Authenticate, Authorize, and optionally allocate Mobility Security Association of MN-HA and FA-HA. 2. In order for Diameter MIP4 Application to achieve step 1, Diameter MIP4 Application uses the AAA infrastructure and Diameter protocol not only to exchange Authentication and Authorization related parameters, BUT it also, include the MIPv4 RRQ and RRP. 3. In other words, the Foreign Agent does not directly relay the RRQ received from the MN to the Home Agent as per RFC3344, it includes the RRQ in the Diameter message AMA and receives the RRP in the Diameter message AMR. Criteria used for Comparison: =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. RFC3344 mandates; when the MN uses timestamp for replay protection, the MN must not retransmit a RRQ before 1 second. 2. In wireless networks, most MIPv4 clients sets the first retransmit timer to 1 second. This is important in order to get the session setup quickly and not waste air resources. 3. Then, what happens if due to some network condition the Mobile Node does not receive MIPv4 RRP within 1 second? How retransmitted initial MIPv4 RRQ message in handled in both models? ---------------------------------------------------------------------- RADIUS-Model MIP4 Auth Case: =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. In the case of RADIUS Model MIPv4 Authentication, AAA infrastructure is used for Authentication, Authorization, etc. BUT NOT used for exchanging MIP4 RRQ and RRP between FA and HA. 2. Only in one condition (FA state), RADIUS-model will reauthenticate the MIPv4 user by contacting AAA server, it is the case when FA receives a retransmitted initial RRQ while waiting for AAA response. 3. In all other states, waiting for RRP, Received RRP, or Relayed RRP, the FA considers the user has been authenticated and relays the retransmitted RRQ directly to the HA without going through AAA infrastructure. Diameter MIP4 Application Case: =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. In the case of Diameter MIPv4 Application,. AAA infrastructure is used for Authentication, Authorization, etc. AND is USED for exchanging MIP4 RRQ and RRP between FA and HA. 2. In all conditions (FA states), Diameter MIPv4 Application will reauthenticate the MIPv4 user by contacting AAA server. 3. Let us also remember that re-authentication of the user in the case of Diameter MIP4 Application is far more complicated and time consuming than in the case of RADIUS-Model. Conclusion: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In case the network condition creates a situation that the Mobile Node does not receive initial MIPv4 RRP within one second, Diameter MIPv4 Application will worsen the network condition by unnecessarily relaying the retransmitted RRQ via AAA (Diameter) infrastructure and re-authenticating the user instead of relaying the retransmitted RRQ DIRECTLY to the Home Agent. Best Regards, Ahmad =20 > -----Original Message----- > From: Muhanna, Ahmad (RICH1:2H10) > Sent: Wednesday, August 01, 2007 7:11 AM > To: 'Hannes Tschofenig'; 'dime@ietf.org' > Cc: 'Madjid Nakhjiri'; 'McCann Peter-A001034';=20 > 'jouni.korhonen@teliasonera.com'; Khalil, Mohamed (RICH2:2S20); 'Avi=20 > Lior' > Subject: RE: MIPv4 Authentication Performance Using RADIUS and=20 > Diameter MIPv4 >=20 > Hi Hannes, >=20 > Thanks a lot for giving me the chance. I really Appreciate it. >=20 > As far as the raised issues I can summarize them as follows and I will > have separate threads (probably end of day or early tomorrow) for each > one of them. >=20 > 1. Is there any field data which support the use case that the draft=20 > is trying to address. (Issue raised by: Madjid and > Jouni) 2. Is there any security issue when the FA relay the=20 > retransmitted initial RRQ without consulting AAA in the case of=20 > RADIUS-Mode. (Issue raised by: Pete McCann) >=20 > Based on the discussion, I would like to update the draft and submit a > new revision and possibly discuss the next steps. >=20 > All, > Please, let me know if there is any issue that was raised and I=20 > missed. >=20 > Best Regards, > Ahmad > =20 >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Wednesday, August 01, 2007 4:06 AM > > To: dime@ietf.org > > Cc: Muhanna, Ahmad (RICH1:2H10) > > Subject: MIPv4 Authentication Performance Using RADIUS and Diameter > > MIPv4 > >=20 > > Hi Ahmad, > >=20 > > you raised some interesting discussions during the DIME > working group > > meeting. Unfortunately, there was not enough time to address all=20 > > questions. > >=20 > > I would be great if you could > > * summarize your presentation, and > > * address some of the raised questions on the mailing list. > >=20 > > Ciao > > Hannes > >=20 > >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 08 10:20:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IImMh-0006KJ-Dx; Wed, 08 Aug 2007 10:18:23 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IImMf-0006K9-Mv for mip4-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 10:18:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IImMf-0006Jx-C8; Wed, 08 Aug 2007 10:18:21 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IImMe-0000Gr-Pe; Wed, 08 Aug 2007 10:18:21 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1186582699!18498677!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 17605 invoked from network); 8 Aug 2007 14:18:19 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-119.messagelabs.com with SMTP; 8 Aug 2007 14:18:19 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l78EIJd4029219; Wed, 8 Aug 2007 07:18:19 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l78EIIeP018439; Wed, 8 Aug 2007 09:18:18 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l78EIItZ018427; Wed, 8 Aug 2007 09:18:18 -0500 (CDT) 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, 8 Aug 2007 10:18:16 -0400 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> From: "McCann Peter-A001034" To: "Ahmad Muhanna" , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: mip4@ietf.org, Hannes Tschofenig Subject: [Mip4] RE: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi, Ahmad, Ahmad Muhanna wrote: >> Maybe this is not so big an issue, but one thing that might happen is >> that the MN can use a different HA address in the re-transmitted RRQ. >> If there is network policy in place that only allows registering on >> specific HAs, this policy might be skirted by the retransmission >> unless the HA address is sent to the RADIUS/Diameter server with >> every RRQ. >=20 > [Ahmad] > We can look at this special case later, but for the sake of this > simple analysis, we need to address the most common simple scenario > first. With the following in mind: "What would the impact be when > using Diameter MIPv4 Application in place of RADIUS model." =20 I think the main impact would be a shorter overall registration time, because the AMR/AMA can carry the registration along with the authentication credentials, which means only one round-trip to the home network instead of 2. =20 > Also, usually the MN does not try to register with another HA until > the registration process is timeout. In our case, we are focusing on > the first retransmitted RRQ which usually done after one second. =20 Why can't we just increase the recommended timeout value? >> I am also concerned about increasing the overall registration time by >> going from one round-trip to two round-trips. The nice thing about >> the existing Diameter application is that it can do both >> authentication/authorization and MIP registration in one round-trip >> to the home network. >=20 > [Ahmad] > I am sorry I missed this point here. Could you please elaborate a > little further.=20 The Diameter MIP4 application was designed to minimize the number of round-trips needed to complete the authentication and registration process. Because the RRQ is carried inside the AMR, there is only one round trip to carry out the two operations: authentication and registration. >> One question: why couldn't we fix the problem by adjusting the >> retransmission timers upwards? If we know that AAA adds some >> additional delay, we could wait a bit longer before retransmitting >> the request. This seems to fix the problem. >=20 > [Ahmad] > I agree with you here. It is anticipated that Diameter MIPv4 > Application will take a longer time to complete MIPv4 initial > registration.=20 On the contrary, I think it will be faster. > Two =20 > questions: >=20 > 1. Why the MN and possibly the network configurations need to change > just for using Diameter MIPv4 Application in place of RADIUS. If we have encountered deployment situations in which a 1 second retransmission is too fast, then we should adjust the recommended minimum value of the timer. =20 > 2. On the other hand, even if we increase the initial timer a little, > we still do not solve the issue, all what we do is delaying it.=20 If we can increase the timer so that 99% of the time the registration completes (or fails) within the new timeout value, then we will have the initial RRP back to the MN before it retransmits (or, in the case of failure, the retransmission will be really necessary). This seems to solve the issue. I don't think we should go re-architecting the MIP4 Diameter application because of a mismatched timeout value. -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 08 10:34: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 1IImaB-0007ul-6g; Wed, 08 Aug 2007 10:32:19 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IIma6-0007uQ-K6 for mip4-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 10:32:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIma6-0007uE-AJ; Wed, 08 Aug 2007 10:32:14 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIma5-0001n9-1Y; Wed, 08 Aug 2007 10:32:14 -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 l78EWA612400; Wed, 8 Aug 2007 14:32:10 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 Date: Wed, 8 Aug 2007 09:31:49 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116070558@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAAJHXAA== References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: mip4@ietf.org, Hannes Tschofenig Subject: [Mip4] RE: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Pete, >From this discussion, it is apparent that there is no security issue that you are concerned with. Please confirm? If that is true, then we can change the subject of this thread to the performance issue and continue discussion. Is that acceptable? Regards, Ahmad =20 >=20 > Hi, Ahmad, >=20 > Ahmad Muhanna wrote: > >> Maybe this is not so big an issue, but one thing that=20 > might happen is=20 > >> that the MN can use a different HA address in the=20 > re-transmitted RRQ. > >> If there is network policy in place that only allows=20 > registering on=20 > >> specific HAs, this policy might be skirted by the retransmission=20 > >> unless the HA address is sent to the RADIUS/Diameter server with=20 > >> every RRQ. > >=20 > > [Ahmad] > > We can look at this special case later, but for the sake of this=20 > > simple analysis, we need to address the most common simple scenario=20 > > first. With the following in mind: "What would the impact be when=20 > > using Diameter MIPv4 Application in place of RADIUS model." >=20 > I think the main impact would be a shorter overall=20 > registration time, because the AMR/AMA can carry the=20 > registration along with the authentication credentials, which=20 > means only one round-trip to the home network instead of 2. > =20 > > Also, usually the MN does not try to register with another HA until=20 > > the registration process is timeout. In our case, we are=20 > focusing on=20 > > the first retransmitted RRQ which usually done after one second. >=20 > Why can't we just increase the recommended timeout value? >=20 > >> I am also concerned about increasing the overall=20 > registration time by=20 > >> going from one round-trip to two round-trips. The nice=20 > thing about=20 > >> the existing Diameter application is that it can do both=20 > >> authentication/authorization and MIP registration in one=20 > round-trip=20 > >> to the home network. > >=20 > > [Ahmad] > > I am sorry I missed this point here. Could you please elaborate a=20 > > little further. >=20 > The Diameter MIP4 application was designed to minimize the=20 > number of round-trips needed to complete the authentication=20 > and registration process. Because the RRQ is carried inside=20 > the AMR, there is only one round trip to carry out the two=20 > operations: authentication and registration. >=20 > >> One question: why couldn't we fix the problem by adjusting the=20 > >> retransmission timers upwards? If we know that AAA adds some=20 > >> additional delay, we could wait a bit longer before retransmitting=20 > >> the request. This seems to fix the problem. > >=20 > > [Ahmad] > > I agree with you here. It is anticipated that Diameter MIPv4=20 > > Application will take a longer time to complete MIPv4 initial=20 > > registration. >=20 > On the contrary, I think it will be faster. >=20 > > Two > > questions: > >=20 > > 1. Why the MN and possibly the network configurations need=20 > to change=20 > > just for using Diameter MIPv4 Application in place of RADIUS. >=20 > If we have encountered deployment situations in which a 1=20 > second retransmission is too fast, then we should adjust the=20 > recommended minimum value of the timer. > =20 > > 2. On the other hand, even if we increase the initial timer=20 > a little,=20 > > we still do not solve the issue, all what we do is delaying it. >=20 > If we can increase the timer so that 99% of the time the=20 > registration completes (or fails) within the new timeout=20 > value, then we will have the initial RRP back to the MN=20 > before it retransmits (or, in the case of failure, the=20 > retransmission will be really necessary). This seems to=20 > solve the issue. I don't think we should go re-architecting=20 > the MIP4 Diameter application because of a mismatched timeout value. >=20 > -Pete >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 08 10:52: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 1IIms7-0005pl-5I; Wed, 08 Aug 2007 10:50:51 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IIms6-0005pf-2b for mip4-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 10:50:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIms5-0005pX-PM for mip4@ietf.org; Wed, 08 Aug 2007 10:50:49 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIms4-0002Ia-BT for mip4@ietf.org; Wed, 08 Aug 2007 10:50:49 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E4153C8CEE0; Wed, 8 Aug 2007 07:50:47 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29779-10; Wed, 8 Aug 2007 07:50:47 -0700 (PDT) Received: from [?6??N???p???h??$IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 48C08C8CEDB; Wed, 8 Aug 2007 07:50:47 -0700 (PDT) In-Reply-To: <46B8E2BE.7090208@nokia.com> References: <46B8E2BE.7090208@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <52D163B0-6E11-4350-8FD2-E94D809EB9CB@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: [Mip4] RFC 3344 and draft-ietf-mip4-rfc3344bis-05.txt IANA Considerations Date: Wed, 8 Aug 2007 10:49:29 -0400 To: "Charles E. Perkins" X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hello Charlie, I'd vote to remote it from the revised draft since, as you pointed out, this usage is not described in body of the RFC 3344 (or the revised draft). If there are clients that send this pad byte and need to be supported, I'd think that could be handled outside the specification since it was never intended or really specified that this extension should be used for mobile IP messages. However, I'll leave this to your wisdom and discretion. Thanks, Acee On Aug 7, 2007, at 5:23 PM, Charles E. Perkins wrote: > > Hello Acee, > > The first, best answer I can give is that I don't know why > that padding extension is listed there. > > Since it would be for UDP payloads, I don't immediately > see why it should be needed. I don't remember hearing > anyone express a need for it. There is not any text in the > body of the specification describing such an extension. > I don't remember asking IANA to put it in there, but I did > not comb through all my emails with IANA to be sure. > I seem to have some very hazy memory of a discussion > about whether such a padding extension would be needed, > but I can't resolve when or where or in what context. > > I think the simplest thing would be to just remove it, > but if there are implementations out there relying on the > existing of the padding extension, we should respect that. > If more detail is needed, I could make a diff between each > previous version of the Internet Drafts of the specification, > but I'd prefer to avoid having to do that. > > Regards, > Charlie P. > > > > > ext Acee Lindem wrote: >> Hi Charlie, >> >> Why is the type 0 for one-byte pad listed in section 6.3 under the >> "Extensions for Mobile IP Registrations"? >> 6.3. Extensions to Mobile IP Registration Messages >> >> The Mobile IP messages, specified within this document, and >> listed in >> Section 1.8 and Section 6.1, may have extensions. Mobile IP >> message >> extensions all share the same number space, even if they are to be >> applied to different Mobile IP messages. The number space for >> Mobile >> IP message extensions is specified within this document. >> Approval of >> new extension numbers is subject to Expert Review, and a >> specification is required [14]. >> >> Type Name >> Reference >> ---- -------------------------------------------- >> --------- >> 0 One-byte Padding >> ~~~~~~~~~~~~~~~~~~~~ >> 32 Mobile-Home Authentication 3.5.2 >> 33 Mobile-Foreign Authentication 3.5.3 >> 34 Foreign-Home Authentication 3.5.4 >> >> >> Clearly, that is not the intent nor what IANA has reserved: >> >> http://www.iana.org/assignments/mobileip-numbers >> >> Thanks, >> Acee > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 08 11:26: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 1IInOZ-0006Yp-LT; Wed, 08 Aug 2007 11:24:23 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IInOY-0006Yh-Ur for mip4-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 11:24:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IInOY-0006YX-K2; Wed, 08 Aug 2007 11:24:22 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IInOX-0001xz-H1; Wed, 08 Aug 2007 11:24:22 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1186586659!3192170!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19537 invoked from network); 8 Aug 2007 15:24:19 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-153.messagelabs.com with SMTP; 8 Aug 2007 15:24:19 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l78FOJkD022880; Wed, 8 Aug 2007 08:24:19 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l78FOHFf015111; Wed, 8 Aug 2007 10:24:18 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l78FOGkH015087; Wed, 8 Aug 2007 10:24:17 -0500 (CDT) 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, 8 Aug 2007 11:24:15 -0400 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116070558@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAAJHXAAACBbmA References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116070558@zrc2hxm2.corp.nortel.com> From: "McCann Peter-A001034" To: "Ahmad Muhanna" , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: mip4@ietf.org, Hannes Tschofenig Subject: [Mip4] RE: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi, Ahmad, I would say there is a minor security issue that may or may not be important in some deployments. It is fine with me if you want to change the subject line. -Pete Ahmad Muhanna wrote: > Hi Pete, >=20 > From this discussion, it is apparent that there is no security issue > that you are concerned with. Please confirm? If that is true, then we > can change the subject of this thread to the performance issue and > continue discussion. =20 >=20 > Is that acceptable? >=20 > Regards, > Ahmad >=20 >>=20 >> Hi, Ahmad, >>=20 >> Ahmad Muhanna wrote: >>>> Maybe this is not so big an issue, but one thing that might happen >>>> is that the MN can use a different HA address in the >>>> re-transmitted RRQ. If there is network policy in place that only >>>> allows registering on specific HAs, this policy might be skirted >>>> by the retransmission unless the HA address is sent to the >>>> RADIUS/Diameter server with every RRQ. >>>=20 >>> [Ahmad] >>> We can look at this special case later, but for the sake of this >>> simple analysis, we need to address the most common simple scenario >>> first. With the following in mind: "What would the impact be when >>> using Diameter MIPv4 Application in place of RADIUS model." >>=20 >> I think the main impact would be a shorter overall registration time, >> because the AMR/AMA can carry the registration along with the >> authentication credentials, which means only one round-trip to the >> home network instead of 2. >=20 >>=20 >>> Also, usually the MN does not try to register with another HA until >>> the registration process is timeout. In our case, we are focusing on >>> the first retransmitted RRQ which usually done after one second. >>=20 >> Why can't we just increase the recommended timeout value? >>=20 >>>> I am also concerned about increasing the overall registration time >>>> by going from one round-trip to two round-trips. The nice thing >>>> about the existing Diameter application is that it can do both >>>> authentication/authorization and MIP registration in one round-trip >>>> to the home network. >>>=20 >>> [Ahmad] >>> I am sorry I missed this point here. Could you please elaborate a >>> little further. >>=20 >> The Diameter MIP4 application was designed to minimize the number of >> round-trips needed to complete the authentication and registration >> process. Because the RRQ is carried inside the AMR, there is only >> one round trip to carry out the two >> operations: authentication and registration. >>=20 >>>> One question: why couldn't we fix the problem by adjusting the >>>> retransmission timers upwards? If we know that AAA adds some >>>> additional delay, we could wait a bit longer before retransmitting >>>> the request. This seems to fix the problem. >>>=20 >>> [Ahmad] >>> I agree with you here. It is anticipated that Diameter MIPv4 >>> Application will take a longer time to complete MIPv4 initial >>> registration. >>=20 >> On the contrary, I think it will be faster. >>=20 >>> Two >>> questions: >>>=20 >>> 1. Why the MN and possibly the network configurations need to change >>> just for using Diameter MIPv4 Application in place of RADIUS. >>=20 >> If we have encountered deployment situations in which a 1 second >> retransmission is too fast, then we should adjust the recommended >> minimum value of the timer.=20 >>=20 >>> 2. On the other hand, even if we increase the initial timer a >>> little, we still do not solve the issue, all what we do is delaying >>> it.=20 >>=20 >> If we can increase the timer so that 99% of the time the registration >> completes (or fails) within the new timeout value, then we will have >> the initial RRP back to the MN before it retransmits (or, in the case >> of failure, the retransmission will be really necessary). This seems >> to solve the issue. I don't think we should go re-architecting the >> MIP4 Diameter application because of a mismatched timeout value. >>=20 >> -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 08 11:31:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IInTI-0001ym-GN; Wed, 08 Aug 2007 11:29:16 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IInTG-0001yZ-Al for mip4-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 11:29:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IInTG-0001yR-1E; Wed, 08 Aug 2007 11:29:14 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IInTE-00038c-QD; Wed, 08 Aug 2007 11:29:14 -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 l78FRFk02653; Wed, 8 Aug 2007 15:27:15 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 Date: Wed, 8 Aug 2007 10:29:05 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711607078E@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAAJHXAAACBbmAAAALInA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116070558@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: mip4@ietf.org, Hannes Tschofenig Subject: [Mip4] RE: Issue 2: Security Concern in RADIUS Mode: MIPv4 Auth Performance Using RADIUS and Diameter MIPv4 Application draft X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Thanks Pete. Just a minor note; I have not been able to see what was the minor security issue you are referring to but as you said, we can go ahead and start the new thread. Will follow Performance discussion on the new thread. Regards, Ahmad =20 > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 > Sent: Wednesday, August 08, 2007 10:24 AM > To: Muhanna, Ahmad (RICH1:2H10); dime@ietf.org > Cc: mip4@ietf.org; Hannes Tschofenig > Subject: RE: Issue 2: Security Concern in RADIUS Mode: MIPv4=20 > Auth Performance Using RADIUS and Diameter MIPv4 Application draft >=20 > Hi, Ahmad, >=20 > I would say there is a minor security issue that may or may=20 > not be important in some deployments. >=20 > It is fine with me if you want to change the subject line. >=20 > -Pete >=20 > Ahmad Muhanna wrote: > > Hi Pete, > >=20 > > From this discussion, it is apparent that there is no=20 > security issue=20 > > that you are concerned with. Please confirm? If that is=20 > true, then we=20 > > can change the subject of this thread to the performance issue and=20 > > continue discussion. > >=20 > > Is that acceptable? > >=20 > > Regards, > > Ahmad > >=20 > >>=20 > >> Hi, Ahmad, > >>=20 > >> Ahmad Muhanna wrote: > >>>> Maybe this is not so big an issue, but one thing that=20 > might happen=20 > >>>> is that the MN can use a different HA address in the=20 > re-transmitted=20 > >>>> RRQ. If there is network policy in place that only allows=20 > >>>> registering on specific HAs, this policy might be skirted by the=20 > >>>> retransmission unless the HA address is sent to the=20 > RADIUS/Diameter=20 > >>>> server with every RRQ. > >>>=20 > >>> [Ahmad] > >>> We can look at this special case later, but for the sake of this=20 > >>> simple analysis, we need to address the most common=20 > simple scenario=20 > >>> first. With the following in mind: "What would the impact be when=20 > >>> using Diameter MIPv4 Application in place of RADIUS model." > >>=20 > >> I think the main impact would be a shorter overall=20 > registration time,=20 > >> because the AMR/AMA can carry the registration along with the=20 > >> authentication credentials, which means only one round-trip to the=20 > >> home network instead of 2. > >=20 > >>=20 > >>> Also, usually the MN does not try to register with=20 > another HA until=20 > >>> the registration process is timeout. In our case, we are=20 > focusing on=20 > >>> the first retransmitted RRQ which usually done after one second. > >>=20 > >> Why can't we just increase the recommended timeout value? > >>=20 > >>>> I am also concerned about increasing the overall=20 > registration time=20 > >>>> by going from one round-trip to two round-trips. The nice thing=20 > >>>> about the existing Diameter application is that it can do both=20 > >>>> authentication/authorization and MIP registration in one=20 > round-trip=20 > >>>> to the home network. > >>>=20 > >>> [Ahmad] > >>> I am sorry I missed this point here. Could you please elaborate a=20 > >>> little further. > >>=20 > >> The Diameter MIP4 application was designed to minimize the=20 > number of=20 > >> round-trips needed to complete the authentication and registration=20 > >> process. Because the RRQ is carried inside the AMR, there is only=20 > >> one round trip to carry out the two > >> operations: authentication and registration. > >>=20 > >>>> One question: why couldn't we fix the problem by adjusting the=20 > >>>> retransmission timers upwards? If we know that AAA adds some=20 > >>>> additional delay, we could wait a bit longer before=20 > retransmitting=20 > >>>> the request. This seems to fix the problem. > >>>=20 > >>> [Ahmad] > >>> I agree with you here. It is anticipated that Diameter MIPv4=20 > >>> Application will take a longer time to complete MIPv4 initial=20 > >>> registration. > >>=20 > >> On the contrary, I think it will be faster. > >>=20 > >>> Two > >>> questions: > >>>=20 > >>> 1. Why the MN and possibly the network configurations=20 > need to change=20 > >>> just for using Diameter MIPv4 Application in place of RADIUS. > >>=20 > >> If we have encountered deployment situations in which a 1 second=20 > >> retransmission is too fast, then we should adjust the recommended=20 > >> minimum value of the timer. > >>=20 > >>> 2. On the other hand, even if we increase the initial timer a=20 > >>> little, we still do not solve the issue, all what we do=20 > is delaying=20 > >>> it. > >>=20 > >> If we can increase the timer so that 99% of the time the=20 > registration=20 > >> completes (or fails) within the new timeout value, then we=20 > will have=20 > >> the initial RRP back to the MN before it retransmits (or,=20 > in the case=20 > >> of failure, the retransmission will be really necessary). =20 > This seems=20 > >> to solve the issue. I don't think we should go re-architecting the > >> MIP4 Diameter application because of a mismatched timeout value. > >>=20 > >> -Pete >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 08 12:17: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 1IIoCV-0007db-Rp; Wed, 08 Aug 2007 12:15:59 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IIoCU-0007dT-QQ for mip4-confirm+ok@megatron.ietf.org; Wed, 08 Aug 2007 12:15:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIoCU-0007bG-AL for mip4@ietf.org; Wed, 08 Aug 2007 12:15:58 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIoCT-0003Ll-MD for mip4@ietf.org; Wed, 08 Aug 2007 12:15:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 6DABE90124 for ; Wed, 8 Aug 2007 12:15:51 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30110-15 for ; Wed, 8 Aug 2007 12:15:47 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 8 Aug 2007 12:15:47 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Aug 2007 12:16:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] RFC 3344 and draft-ietf-mip4-rfc3344bis-05.txtIANA Considerations Date: Wed, 8 Aug 2007 12:15:46 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D70360ACD4@exchtewks2.starentnetworks.com> In-Reply-To: <52D163B0-6E11-4350-8FD2-E94D809EB9CB@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] RFC 3344 and draft-ietf-mip4-rfc3344bis-05.txtIANA Considerations Thread-Index: AcfZy3sXO13x0oAcTlmcBjwXWAVHywACvVEw References: <46B8E2BE.7090208@nokia.com> <52D163B0-6E11-4350-8FD2-E94D809EB9CB@redback.com> From: "Marks, Robert" To: "Acee Lindem" , "Charles E. Perkins" X-OriginalArrivalTime: 08 Aug 2007 16:16:13.0835 (UTC) FILETIME=[70E12DB0:01C7D9D7] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Acee and Charlie, The usage (for ICMP messages) is described in section 2.1.3 in the draft. Section 6.3 refers to section 1.8, in which the following text appears: o The second set consists of those extensions which may appear only in ICMP Router Discovery messages [5]. In this document, the following Types are defined for Extensions appearing in ICMP Router Discovery messages: 0 One-byte Padding (encoded with no Length nor Data field) 16 Mobility Agent Advertisement 19 Prefix-Lengths So it seems there is sufficient reason not to remove it. BR, Bob -----Original Message----- From: Acee Lindem [mailto:acee@redback.com]=20 Sent: Wednesday, August 08, 2007 9:49 AM To: Charles E. Perkins Cc: mip4@ietf.org Subject: Re: [Mip4] RFC 3344 and draft-ietf-mip4-rfc3344bis-05.txtIANA Considerations Hello Charlie, I'd vote to remote it from the revised draft since, as you pointed =20 out, this usage is not described in body of the RFC 3344 (or the =20 revised draft). If there are clients that send this pad byte and need =20 to be supported, I'd think that could be handled outside the =20 specification since it was never intended or really specified that =20 this extension should be used for mobile IP messages. However, I'll =20 leave this to your wisdom and discretion. Thanks, Acee On Aug 7, 2007, at 5:23 PM, Charles E. Perkins wrote: > > Hello Acee, > > The first, best answer I can give is that I don't know why > that padding extension is listed there. > > Since it would be for UDP payloads, I don't immediately > see why it should be needed. I don't remember hearing > anyone express a need for it. There is not any text in the > body of the specification describing such an extension. > I don't remember asking IANA to put it in there, but I did > not comb through all my emails with IANA to be sure. > I seem to have some very hazy memory of a discussion > about whether such a padding extension would be needed, > but I can't resolve when or where or in what context. > > I think the simplest thing would be to just remove it, > but if there are implementations out there relying on the > existing of the padding extension, we should respect that. > If more detail is needed, I could make a diff between each > previous version of the Internet Drafts of the specification, > but I'd prefer to avoid having to do that. > > Regards, > Charlie P. > > > > > ext Acee Lindem wrote: >> Hi Charlie, >> >> Why is the type 0 for one-byte pad listed in section 6.3 under the =20 >> "Extensions for Mobile IP Registrations"? >> 6.3. Extensions to Mobile IP Registration Messages >> >> The Mobile IP messages, specified within this document, and =20 >> listed in >> Section 1.8 and Section 6.1, may have extensions. Mobile IP =20 >> message >> extensions all share the same number space, even if they are to be >> applied to different Mobile IP messages. The number space for =20 >> Mobile >> IP message extensions is specified within this document. =20 >> Approval of >> new extension numbers is subject to Expert Review, and a >> specification is required [14]. >> >> Type Name =20 >> Reference >> ---- -------------------------------------------- =20 >> --------- >> 0 One-byte Padding >> ~~~~~~~~~~~~~~~~~~~~ >> 32 Mobile-Home Authentication 3.5.2 >> 33 Mobile-Foreign Authentication 3.5.3 >> 34 Foreign-Home Authentication 3.5.4 >> >> >> Clearly, that is not the intent nor what IANA has reserved: >> >> http://www.iana.org/assignments/mobileip-numbers >> >> Thanks, >> Acee > --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 09 13:17: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 1IJBc3-00049B-2x; Thu, 09 Aug 2007 13:15:55 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IJBc1-00047M-Ui for mip4-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 13:15:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJBc1-00047D-L5; Thu, 09 Aug 2007 13:15:53 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJBc0-000771-85; Thu, 09 Aug 2007 13:15:53 -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 l79HFlS27027; Thu, 9 Aug 2007 17:15:48 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 Date: Thu, 9 Aug 2007 12:15:44 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0A== References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mip4@ietf.org, Hannes Tschofenig Subject: [Mip4] Issue 3: Diameter MIP4 Application vs. RADIUS Architecture X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Pete, My apologies, I almost forgot about opening this thread. However, May I focus on one portion of your reply, specifically your proposals to address the issue. > =20 >=20 > > Two > > questions: > >=20 > > 1. Why the MN and possibly the network configurations need=20 > to change=20 > > just for using Diameter MIPv4 Application in place of RADIUS. >=20 > If we have encountered deployment situations in which a 1=20 > second retransmission is too fast, then we should adjust the=20 > recommended minimum value of the timer. [Ahmad] This is a proposal for increasing the initial RRQ retransmission timer. Please see below. > =20 > > 2. On the other hand, even if we increase the initial timer=20 > a little,=20 > > we still do not solve the issue, all what we do is delaying it. >=20 > If we can increase the timer so that 99% of the time the=20 > registration completes (or fails) within the new timeout=20 > value, then we will have the initial RRP back to the MN=20 > before it retransmits (or, in the case of failure, the=20 > retransmission will be really necessary). This seems to=20 > solve the issue. I don't think we should go re-architecting=20 > the MIP4 Diameter application because of a mismatched timeout value. [Ahmad] Ok, I think this is an important step. I think what you are trying to say is that you agree with the analysis that the draft presented and you are trying to propose solutions for the issue without any change to the Diameter Mobile IPv4 Application, RFC4004. Is that a fair statement? >=20 > -Pete >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 09 13:53: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 1IJCAu-0000AC-OQ; Thu, 09 Aug 2007 13:51:56 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IJCAt-00009i-PL for mip4-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 13:51:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCAt-00009a-Fc; Thu, 09 Aug 2007 13:51:55 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IJCAr-0007yQ-DA; Thu, 09 Aug 2007 13:51:55 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1186681910!18461861!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30941 invoked from network); 9 Aug 2007 17:51:50 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 9 Aug 2007 17:51:50 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l79HpoVS024134; Thu, 9 Aug 2007 10:51:50 -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 l79HpnLU021873; Thu, 9 Aug 2007 12:51:49 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l79Hpn9a021860; Thu, 9 Aug 2007 12:51:49 -0500 (CDT) 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: Thu, 9 Aug 2007 13:51:48 -0400 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7Gw References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> From: "McCann Peter-A001034" To: "Ahmad Muhanna" , X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: mip4@ietf.org, Hannes Tschofenig Subject: [Mip4] RE: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi, Ahmad, Ahmad Muhanna wrote: >> If we can increase the timer so that 99% of the time the registration >> completes (or fails) within the new timeout value, then we will have >> the initial RRP back to the MN before it retransmits (or, in the case >> of failure, the retransmission will be really necessary). This seems >> to solve the issue. I don't think we should go re-architecting the >> MIP4 Diameter application because of a mismatched timeout value. >=20 > [Ahmad] > Ok, I think this is an important step. I think what you are trying to > say is that you agree with the analysis that the draft presented and > you are trying to propose solutions for the issue without any change > to the Diameter Mobile IPv4 Application, RFC4004. Is that a fair > statement? =20 I agree that if the Diameter infrastructure takes too long to respond to the MN before it retransmits, this would potentially put a second, uneccessary AMR into the network, causing more traffic. The registration process itself would be delayed a bit because the MN would be waiting for a response to its most recently transmitted RRQ. However, RFC3344 specifies an exponentially increasing timeout value so eventually the MN would get registered. I think that summarizes the problem you raised; it could have been sent to the list in that form rather than writing an entire draft with call flows comparing RADIUS to Diameter. I agree that a Diameter (or RADIUS, for that matter) infrastructure might take more than 1 second to respond to an AMR or an Access-Request. It seems that the solution is to recommend a longer timeout value for the initial retransmission. Another solution would be to allow the MN to complete its registration successfully by receiving an RRP matching a previous RRQ (not just the most recently retransmitted one). I don't think we should turn the MIP4 Diameter application into a 2-round-trips protocol. The goal of RFC4004 is to provide MIP registration in one round-trip. -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 09 14:45: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 1IJCz6-0005W6-LO; Thu, 09 Aug 2007 14:43:48 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IJCym-0004xm-B1 for mip4-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 14:43:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJCyk-0004x9-9A; Thu, 09 Aug 2007 14:43:27 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJCyi-0001Ti-PU; Thu, 09 Aug 2007 14:43:26 -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 l79IhLS19061; Thu, 9 Aug 2007 18:43:21 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 Date: Thu, 9 Aug 2007 13:43:16 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711611482D@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: mip4@ietf.org, Hannes Tschofenig Subject: [Mip4] RE: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Pete, >=20 > Hi, Ahmad, >=20 > Ahmad Muhanna wrote: > >> If we can increase the timer so that 99% of the time the=20 > registration=20 > >> completes (or fails) within the new timeout value, then we=20 > will have=20 > >> the initial RRP back to the MN before it retransmits (or,=20 > in the case=20 > >> of failure, the retransmission will be really necessary). =20 > This seems=20 > >> to solve the issue. I don't think we should go re-architecting the > >> MIP4 Diameter application because of a mismatched timeout value. > >=20 > > [Ahmad] > > Ok, I think this is an important step. I think what you are=20 > trying to=20 > > say is that you agree with the analysis that the draft=20 > presented and=20 > > you are trying to propose solutions for the issue without=20 > any change=20 > > to the Diameter Mobile IPv4 Application, RFC4004. Is that a fair > > statement? =20 >=20 > I agree that if the Diameter infrastructure takes too long to=20 > respond to the MN before it retransmits, this would=20 > potentially put a second, uneccessary AMR into the network,=20 > causing more traffic. The registration process itself would=20 > be delayed a bit because the MN would be waiting for a=20 > response to its most recently transmitted RRQ. However,=20 > RFC3344 specifies an exponentially increasing timeout value=20 > so eventually the MN would get registered. >=20 > I think that summarizes the problem you raised; it could have=20 > been sent to the list in that form rather than writing an=20 > entire draft with call flows comparing RADIUS to Diameter. [Ahmad] I assume you are talking here with MIPv4 chair hat-off, there is no restrictions about writing drafts in IETF and getting two wg to agree to present the idea and generate discussion inside the meeting and on the mailing lists or you are suggesting a new IETF rule here? Having said that, I guess the least which can be said about what you just mentioned is over simplification of what the draft is trying to present. The idea the draft was to highlight and present, IMO and many others, a valid weakness about D-MIPv4 architecture. The draft is trying to compare the performance of the current RADIUS deployment to what to be Diameter Mobile IPv4 Application deployment. Let me try to explain what the draft is trying to highlight one more time: 1. Currently there are certain deployment configuration parameters and the operator probably would like to get better performance in case Diameter is used in place of RADIUS without further studies and analysis to how to tweak the network in order to optimize the expected D-MIP4 performance issue. 2. The point here is not about Diameter as an AAA protocol, however, it is about the concept of coupling the MIPv4 control signaling to AAA signaling. Which many people do not think it is a good idea and believe that it is a deviation from RFC3344 initial MIPv4 registration procedure. Do not you agree? 3. Of course, RFC3344 have a retransmission mechanism, which in most cases should get the MN eventually registered. On the other hand, RFC4004 proposes a Diameter Application and impeded MIPv4 control signaling inside AAA control signaling and the draft never assumed that there could be an impact on the MIPv4 signaling retransmission mechanism or performance. Not to mention coupling of MIPv4 signaling retransmission with AAA signaling retransmission. 4. If the AAA infrastructure have the same load in case of RADIUS and D-MIP4 and the MN had to retransmit the initial MIPv4 RRQ, there is a much much greater chance that D-MIPv4 will cause another round of UNNECESSARY AAA signaling that does not happen in the case of RADIUS. 5. If the AAA infrastructure is slightly loaded and cause a MN to retransmit its MIPv4 initial RRQ, D-MIPv4 as per RFC4004 makes the situation much WORSE by injecting, at least, DOUBLE the number of AAA (Diameter) signaling messages. In the case of RADIUS this is not there. 6. Actually, we are going to publish a new revision of this draft and address the scenario of allocating a HA in the visited network. Have you looked into the difference between the RADIUS and D-MIP4 performance in this scenario and what will happen if the MN happened to retransmit? 7. Finally, I guess all of the above worth writing a draft in order to provide heads up for the industry of what to expect in case D-MIPv4, RFC4004, is deployed in place of RADIUS. >=20 > I agree that a Diameter (or RADIUS, for that matter)=20 > infrastructure might take more than 1 second to respond to an=20 > AMR or an Access-Request. > It seems that the solution is to recommend a longer timeout=20 > value for the initial retransmission. Another solution would=20 > be to allow the MN to complete its registration successfully=20 > by receiving an RRP matching a previous RRQ (not just the=20 > most recently retransmitted one). >=20 > I don't think we should turn the MIP4 Diameter application=20 > into a 2-round-trips protocol. The goal of RFC4004 is to=20 > provide MIP registration in one round-trip. >=20 > -Pete >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 09 15:04: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 1IJDH3-0002A7-Ux; Thu, 09 Aug 2007 15:02:21 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IJDH2-00029O-AK for mip4-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 15:02:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJDGz-00028k-Ms; Thu, 09 Aug 2007 15:02:19 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IJDGy-000284-Ee; Thu, 09 Aug 2007 15:02:17 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1186686135!20222747!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6588 invoked from network); 9 Aug 2007 19:02:15 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with SMTP; 9 Aug 2007 19:02:15 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l79J2E4L018319; Thu, 9 Aug 2007 12:02:14 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l79J2E3I008959; Thu, 9 Aug 2007 14:02:14 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l79J2D8s008950; Thu, 9 Aug 2007 14:02:13 -0500 (CDT) 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: Thu, 9 Aug 2007 15:02:12 -0400 Message-ID: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711611482D@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMA== References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711611482D@zrc2hxm2.corp.nortel.com> From: "McCann Peter-A001034" To: "Ahmad Muhanna" , X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mip4@ietf.org, Hannes Tschofenig Subject: [Mip4] RE: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi, Ahmad, Ahmad Muhanna wrote: > 2. The point here is not about Diameter as an AAA protocol, however, > it is about the concept of coupling the MIPv4 control signaling to > AAA signaling. Which many people do not think it is a good idea and > believe that it is a deviation from RFC3344 initial MIPv4 > registration procedure. Do not you agree? =20 No, I don't. Putting the Registration Request in the AMR is a feature. It allows the registration to happen in one round-trip. =20 > 6. Actually, we are going to publish a new revision of this draft and > address the scenario of allocating a HA in the visited network. Have > you looked into the difference between the RADIUS and D-MIP4 > performance in this scenario and what will happen if the MN happened > to retransmit? =20 Obviously this scenario takes longer to process the RRQ and so the chance of hitting a retransmission is greater. =20 >> I agree that a Diameter (or RADIUS, for that matter) infrastructure >> might take more than 1 second to respond to an AMR or an >> Access-Request. It seems that the solution is to recommend a longer >> timeout value for the initial retransmission. Another solution >> would be to allow the MN to complete its registration successfully >> by receiving an RRP matching a previous RRQ (not just the most >> recently retransmitted one).=20 >>=20 >> I don't think we should turn the MIP4 Diameter application into a >> 2-round-trips protocol. The goal of RFC4004 is to provide MIP >> registration in one round-trip. >>=20 -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 09 15:14:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJDQm-0000mb-CK; Thu, 09 Aug 2007 15:12:24 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IJDQk-0000g6-Rl for mip4-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 15:12:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJDQk-0000bu-20 for mip4@ietf.org; Thu, 09 Aug 2007 15:12:22 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJDQj-00058P-1U for mip4@ietf.org; Thu, 09 Aug 2007 15:12:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id C698F901C8 for ; Thu, 9 Aug 2007 15:12:16 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01871-14 for ; Thu, 9 Aug 2007 15:12:13 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 9 Aug 2007 15:12:13 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([10.2.4.27]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 15:12:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] RFC 3344 and draft-ietf-mip4-rfc3344bis-05.txtIANA Considerations Date: Thu, 9 Aug 2007 15:12:00 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D70360AF9C@exchtewks2.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] RFC 3344 and draft-ietf-mip4-rfc3344bis-05.txtIANA Considerations Thread-Index: AcfZ2kqq+WheCPpbTI2f8mnS5j1bVgA3l4gQ References: <46B8E2BE.7090208@nokia.com> <52D163B0-6E11-4350-8FD2-E94D809EB9CB@redback.com> <7CCD07160348804497EF29E9EA5560D70360ACD4@exchtewks2.starentnetworks.com> From: "Marks, Robert" To: "Acee Lindem" X-OriginalArrivalTime: 09 Aug 2007 19:12:40.0007 (UTC) FILETIME=[41249570:01C7DAB9] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Cc: "Charles E. Perkins" , mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1003297195==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1003297195== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DAB9.20475860" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DAB9.20475860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Acee, =20 I'm afraid I misunderstood your email. I fully agree with removing the extension only from section 6.3. =20 BR, Bob =20 ________________________________ From: Acee Lindem [mailto:acee@redback.com]=20 Sent: Wednesday, August 08, 2007 11:36 AM To: Marks, Robert Cc: Charles E. Perkins; mip4@ietf.org Subject: Re: [Mip4] RFC 3344 and draft-ietf-mip4-rfc3344bis-05.txtIANA Considerations =20 Hi Bob,=20 Since 6.3 documents IANA code-points for "Extensions to Mobile IP Registration Messages" and the referenced text from section 1.8 specifically restricts the listed extensions to ICMP Router Discovery messages, I'd guess that the inclusion of the One-byte Padding in section 6.3 was simply a cut-and-paste error that was never caught.=20 =20 Luckily, IANA never included it or it got caught in the IANA review. See the following excerpt from http://www.iana.org/assignments/mobileip-numbers =20 <<< snip, snip, snip >>> ------_=_NextPart_001_01C7DAB9.20475860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Acee,

 

I’m afraid I misunderstood = your email. I fully agree with removing the extension only from section = 6.3.

 

BR,

Bob

 

From: Acee = Lindem [mailto:acee@redback.com]
Sent: Wednesday, August = 08, 2007 11:36 AM
To: Marks, Robert
Cc: Charles E. Perkins; mip4@ietf.org
Subject: Re: [Mip4] RFC = 3344 and draft-ietf-mip4-rfc3344bis-05.txtIANA = Considerations

 

Hi Bob, 

Since 6.3 documents IANA code-points for "Extensions to = Mobile IP Registration Messages" and the referenced text from section 1.8 specifically restricts the listed extensions to ICMP Router Discovery = messages, I'd guess that the inclusion of the One-byte Padding in section 6.3 was = simply a cut-and-paste error that was never = caught. 

 

Luckily, IANA never included it or it got caught in the IANA = review. See the following excerpt from http://www.iana= .org/assignments/mobileip-numbers

 

=

<<< snip, snip, snip = >>>

------_=_NextPart_001_01C7DAB9.20475860-- --===============1003297195== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1003297195==-- From mip4-bounces@ietf.org Thu Aug 09 15:32:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJDis-0002Cj-AO; Thu, 09 Aug 2007 15:31:06 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IJDio-00025w-Pc for mip4-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 15:31:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJDim-000226-UB; Thu, 09 Aug 2007 15:31:02 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJDim-0005hv-Gn; Thu, 09 Aug 2007 15:31:00 -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 l79JT1D02239; Thu, 9 Aug 2007 19:29: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 Date: Thu, 9 Aug 2007 14:30:55 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116114985@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAAAlpMQ References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711611482D@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: mip4@ietf.org, Hannes Tschofenig Subject: [Mip4] RE: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Pete, >=20 > Ahmad Muhanna wrote: > > 2. The point here is not about Diameter as an AAA protocol,=20 > however,=20 > > it is about the concept of coupling the MIPv4 control=20 > signaling to AAA=20 > > signaling. Which many people do not think it is a good idea and=20 > > believe that it is a deviation from RFC3344 initial MIPv4 > > registration procedure. Do not you agree? =20 >=20 > No, I don't. Putting the Registration Request in the AMR is=20 > a feature. > It allows the registration to happen in one round-trip. [Ahmad] Well, I do not understand what you mean by a feature. Initial RRQ/RRP is coupled with AMR/AMA, as a matter of fact they are carried in attributes. In other words, we can not relay initial RRQ/RRP outside AMR/AMA as per RFC3344. Even if you want to call it a feature, that feature makes D-MIP4 architecture different from RADIUS and at the same time makes AAA infrastructure more vulnerable. > =20 > > 6. Actually, we are going to publish a new revision of this=20 > draft and=20 > > address the scenario of allocating a HA in the visited=20 > network. Have=20 > > you looked into the difference between the RADIUS and D-MIP4=20 > > performance in this scenario and what will happen if the MN happened > > to retransmit? =20 >=20 > Obviously this scenario takes longer to process the RRQ and=20 > so the chance of hitting a retransmission is greater. [Ahmad] Okay.. Then that is bad and has bad consequences on the AAA infrastructure and on the current MIPv4 deployment. Operators, expects the current network infrastructure to work, at least, better when upgrading AAA to Diameter not to degrade their network performance and start spending moneys on studies and tweaking mechanisms here and there to compromise for the D-MIPv4 feature. IMO, that is not a bad feature and we need to fix it. > =20 > >> I agree that a Diameter (or RADIUS, for that matter)=20 > infrastructure=20 > >> might take more than 1 second to respond to an AMR or an=20 > >> Access-Request. It seems that the solution is to recommend=20 > a longer=20 > >> timeout value for the initial retransmission. Another=20 > solution would=20 > >> be to allow the MN to complete its registration successfully by=20 > >> receiving an RRP matching a previous RRQ (not just the=20 > most recently=20 > >> retransmitted one). > >>=20 > >> I don't think we should turn the MIP4 Diameter application into a=20 > >> 2-round-trips protocol. The goal of RFC4004 is to provide MIP=20 > >> registration in one round-trip. > >>=20 >=20 > -Pete >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 09 15:36:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJDmQ-0005vM-IQ; Thu, 09 Aug 2007 15:34:46 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IJDmM-0005vD-Q3 for mip4-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 15:34:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJDmL-0005uy-FJ; Thu, 09 Aug 2007 15:34:42 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJDmI-0002yr-EA; Thu, 09 Aug 2007 15:34:40 -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 l79JYYS05283; Thu, 9 Aug 2007 19:34:34 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 Date: Thu, 9 Aug 2007 14:34:18 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711611499F@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116114985@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAAAlpMQAACZeRA= References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711611482D@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116114985@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "Ahmad Muhanna" , "McCann Peter-A001034" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: mip4@ietf.org Subject: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUS Architecture X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Sorry one correction:) > compromise for the D-MIPv4 feature. IMO, that is **not** a bad=20 > feature and we need to fix it. I meant to say: IMO, that is a bad feature and we need to fix it. Regards, Ahmad =20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 09 16:31: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 1IJEe1-0001bZ-0j; Thu, 09 Aug 2007 16:30:09 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IJEdo-0001OL-2W for mip4-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 16:29:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJEdn-0001OC-Nn for mip4@ietf.org; Thu, 09 Aug 2007 16:29:55 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJEdm-0004PS-9i for mip4@ietf.org; Thu, 09 Aug 2007 16:29:55 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l79KTqFQ009598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Aug 2007 13:29:53 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l79KTqRw015466; Thu, 9 Aug 2007 13:29:52 -0700 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 13:29:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Aug 2007 13:29:51 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification question on RFC3024 Thread-Index: AcfaxAnfS06qkz0rQ/uOacMhoUu9Ng== From: "Narayanan, Vidya" To: "gabriel montenegro" X-OriginalArrivalTime: 09 Aug 2007 20:29:52.0268 (UTC) FILETIME=[0A2F84C0:01C7DAC4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Mobile IPv4 Mailing List Subject: [Mip4] Clarification question on RFC3024 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Gabriel, All, One question regarding RFC3024 - if an MN uses encapsulating style delivery option with a foreign agent, are packets coming back to the MN from the HA supposed to be also encapsulated from the FA to the MN? Section 5.1.2. talks about encapsulation from the MN to the FA, but, doesn't talk about the other direction.=20 It appears that such encapsulation in the FA-to-MN direction would be unnecessary, but, I'm not sure what was intended by the RFC. =20 Thanks, Vidya -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 09 16:53: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 1IJEyf-0006zG-9a; Thu, 09 Aug 2007 16:51:29 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IJEyd-0006zA-84 for mip4-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 16:51:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJEyc-0006z2-UU for mip4@ietf.org; Thu, 09 Aug 2007 16:51:26 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJEyb-00053N-KA for mip4@ietf.org; Thu, 09 Aug 2007 16:51:26 -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 l79Kp4h16918; Thu, 9 Aug 2007 20:51:04 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: [Mip4] Clarification question on RFC3024 Date: Thu, 9 Aug 2007 15:50:43 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116114BDF@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Clarification question on RFC3024 Thread-Index: AcfaxAnfS06qkz0rQ/uOacMhoUu9NgAAga0Q References: From: "Ahmad Muhanna" To: "Narayanan, Vidya" , "gabriel montenegro" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Vidya, Yes, there is no encapsulation for packets from FA to MN.=20 However, if HA needs to deliver broadcast packets to then MN, HA encapsulates the packet first with dst. Address is HoA and then encapsulate it again with src. Address =3D HA addr and dst. Addr. =3D FA-CoA. Hope this helps. Regards, Ahmad =20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Thursday, August 09, 2007 3:30 PM > To: gabriel montenegro > Cc: Mobile IPv4 Mailing List > Subject: [Mip4] Clarification question on RFC3024 >=20 > Gabriel, All, > One question regarding RFC3024 - if an MN uses encapsulating=20 > style delivery option with a foreign agent, are packets=20 > coming back to the MN from the HA supposed to be also=20 > encapsulated from the FA to the MN? > Section 5.1.2. talks about encapsulation from the MN to the=20 > FA, but, doesn't talk about the other direction.=20 >=20 > It appears that such encapsulation in the FA-to-MN direction=20 > would be unnecessary, but, I'm not sure what was intended by=20 > the RFC. =20 >=20 > Thanks, > Vidya >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 10 01:27: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 1IJMzt-0002XW-Ki; Fri, 10 Aug 2007 01:25:17 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IJMzr-0002R9-Qv for mip4-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 01:25:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJMzq-0002Mk-1i for mip4@ietf.org; Fri, 10 Aug 2007 01:25:14 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJMzo-0005Ip-RC for mip4@ietf.org; Fri, 10 Aug 2007 01:25:13 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 09 Aug 2007 22:25:12 -0700 X-IronPort-AV: i="4.19,243,1183359600"; d="scan'208"; a="197667964:sNHT59675670" 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 l7A5PCGj018411; Thu, 9 Aug 2007 22:25:12 -0700 Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7A5PCF5012001; Fri, 10 Aug 2007 05:25:12 GMT Date: Thu, 9 Aug 2007 22:25:12 -0700 (PDT) From: Sri Gundavelli To: McCann Peter-A001034 Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt In-Reply-To: Message-ID: References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.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=8335; t=1186723512; x=1187587512; c=relaxed/simple; s=sjdkim4002; 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[Mip4]=20I-D=20ACTION=3Adraft-ietf-mip4-dsmipv4-03.tx t=20 |Sender:=20; bh=u8AlF+D2BT/WzCBUfXEeHk4vJHXQa3zGpzY3saB89P4=; b=Qh02sdeN2GCvfaeSCpOxOGeLen5ue7JaGXhfZoh+4pdkI2QqXVqINNsiTZUJfwUu0W+dB2Lk 5x7N7G7u1kbB0U1ObSh8Cl5AdyLcrPohH/uOnAFt3KiK68XqntXxiTD1; 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: 32029c790f79bd4a84a26bd2915c54b9 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org I've reviewed this document. It is in a good shape. Few comments on the final version. May want to add some clarifying text. Sri --------------------------------------------------------- Section 2.3 Implicit and Explicit Modes "In this mode of operation all traffic to and from the IPv6 prefixes MUST be encapsulated over the IPv4 tunnel between the mobile node's IPv4 home address and the IPv4 address of the home agent, and as such it is transparent to any foreign agent in the path." The above text is not clear on what the supported encap modes are. The text seems to say the encap mode is I(b) or II(b). Should allow I(a) and II(a) ? If transparency to FA is desired for IPv6 traffic in implicit mode, I(b) must be enforced. But, in CCOA mode, I(b) is an overhead. I). FA-COA Mode: HA========FA-----MN Encapsulation modes for IPv6 traffic: a.) HA-FACOA{IPv6-Pak} b.) HA-FACOA{HA-MNHoA{IPv6-Pak}} II). MN-COA Mode: HA================MN Encapsulation modes for IPv6 traffic: a.) HA-MNCOA{IPv6-Pak} b.) HA-MNCOA{HA-MNHOA{IPv6-PAK}} As well for the explicit mode, the document talks about "tunneling to HoA or CoA". But, its not implicit, if this introduces a new encap modes I(b) or II(b). Because, 3344, uses this style of delivery for broadcast or multicast packets. Few more lines of text will help. =================================================== Section 3.2 IPv6 Code Extension > A new skippable extension to the Mobile IPv4 header Should this be a non-skippable extension ? Its a reply and MN cant ignore this. It is present, because MN asked for it and it understands the format. Is it for supporting older FA's in path and when the packets are tunneled to HoA ? ==================================================== Section 3.2 Code Values > 10 registration rejected, not home subnet > 11 registration rejected, Duplicate Address Detection failed Some of these code values require some explanation. Some are relevant only when the requested address is a prefix and some when the address is a IPv6-HoA. Its not specified where exactly each error code can be used. I understand, it may be implicit, but, few lines will help. ======================================================== Section 4.3 "If the IPv6 home address included in a IPv6 prefix request extension" You mean "IPv6 prefix extension" ?. Its in other places as well... ========================================================= Section 4.3.1. IPv6 Packet Processing Should be mentioned that Proxy ND is required only when the requested IPv6 address is a HoA and not a IPv6 prefix. ========================================================= Section 4.3.2: "Even if the tunnel for IPv4 traffic terminates at a different point than the tunnel for IPv6 traffic (mobile node's CoA vs HoA), both tunnels MUST use the tunneling mechanism negotiated by the Mobile IP header as defined in MIPv4 [RFC3344]. When IPinIP encapsulation is negotiated IPv6 is tunneled over IPv4 according to [RFC4213]. GRE and Minimal Encapsulation techniques also allow tunneling of IPv6 packet by setting the Protocol Type [RFC1701] and Protocol [RFC2004] fields to appropriate payload type defined for IPv6 by IANA." When the packets are tunneled to the HoA, the inner capsulation should be just IPv6-over-IPv4. I wonder, what is the value of using GRE for the inner packets ? This alligns better with the delivery style for broadcast and multicast packets, IMO. ============================================================ Section 4.3.2 " Packets addressed to the mobile node's IPv6 link-local address MUST NOT be tunneled to the mobile node. Instead, these packets MUST be discarded and the home agent SHOULD return an ICMPv6 Destination Unreachable, Code 3, message to the packet's Source Address (unless this Source Address is a multicast address)." The HA will probably never know the link-local address of the mobile node ? The document does not specify the operation of the mobile node using a IPv6 HoA on its home interface and also there is no "Link-Local Address Compatibility (L)" flag to tell the HA that the identifier for IPv6-HoA and the Link-local address is the same. ============================================================== "IPv6 packets received from the mobile client" It should be "mobile node". Some places the MN is referred to as mobile client. This should be consistent with 3344 terminology. ============================================================== Section 4.8: Registration with a private CoA You probably need a new type value for carrrying IPv6 packets in UDP. MIP Tunnel Data Message [3519, Section 3.3]. Or just mention that the IPv6 protocol number should be set when carrying IPv6 packets. =============================================================== Tsirtsis, George wrote: > Hi Peter, > > Kent sent me his comments offline and I have incorporated them in the > draft. His main comment was about clarifying that implicit mode is > entirely transparent to the FA, which I did. > > He is now, I think, on vacation so I could not check the changes with > him. In any case I am sure he will check the document next week when > he will be back. > > Regards > George > > > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann at motorola.com] > Sent: Tuesday, August 07, 2007 3:52 PM > To: mip4 at ietf.org; kleung at cisco.com > Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt > > Thanks George for submitting the updated version. > > Kent, you said during the meeting that you had some comments on this > draft. Could you send them to the list, so that we can move ahead > with this document? > > Thanks, > > -Pete > > Internet-Drafts at ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Mobility for IPv4 >> Working Group of the IETF. >> >> Title : Dual Stack Mobile IPv4 >> Author(s) : G. Tsirtsis, et al. >> Filename : draft-ietf-mip4-dsmipv4-03.txt >> Pages : 25 >> Date : 2007-8-7 >> >> This specification provides IPv6 extensions to the Mobile IPv4 >> protocol. The extensions allow a dual stack node to use IPv4 and >> IPv6 home addresses as well as to move between IPv4 and dual >> stack network infrastructures. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-03.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request at 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-mip4-dsmipv4-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 at ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-mip4-dsmipv4-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. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 10 06: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 1IJRcG-00065D-Ey; Fri, 10 Aug 2007 06:21:12 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IJRcF-000655-3P for mip4-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 06:21:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJRcE-00064t-Ol for mip4@ietf.org; Fri, 10 Aug 2007 06:21:10 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJRcC-0006j2-W9 for mip4@ietf.org; Fri, 10 Aug 2007 06:21:10 -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 l7AAL6LC026378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Aug 2007 03:21:07 -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 l7AAL5Cw004459; Fri, 10 Aug 2007 03:21:06 -0700 (PDT) Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 03:21:05 -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: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Date: Fri, 10 Aug 2007 03:21:00 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF4871D58@NAEX16.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Thread-Index: AcfbD6aHrNwGyHUsTzWiewwmNU3lYgAGjSfg References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> From: "Tsirtsis, George" To: "Sri Gundavelli" , "McCann Peter-A001034" X-OriginalArrivalTime: 10 Aug 2007 10:21:05.0569 (UTC) FILETIME=[28FD5110:01C7DB38] X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Sri, Thanks for you comments. Please see comments inline... -----Original Message----- From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 Sent: Friday, August 10, 2007 6:25 AM To: McCann Peter-A001034 Cc: mip4@ietf.org Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt=20 I've reviewed this document. It is in a good shape. Few comments on the final version. May want to add some clarifying text. Sri --------------------------------------------------------- Section 2.3 Implicit and Explicit Modes "In this mode of operation all traffic to and from the IPv6 prefixes MUST be encapsulated over the IPv4 tunnel between the mobile node's IPv4 home address and the IPv4 address of the home agent, and as such it is transparent to any foreign agent in the path." The above text is not clear on what the supported encap modes are. The text seems to say the encap mode is I(b) or II(b). Should allow I(a) and II(a) ? If transparency to FA is desired for IPv6 traffic in implicit mode, I(b) must be enforced. But, in CCOA mode, I(b) is an overhead. GT> Sri, I(b) and II(b), keep things simple. To allow for I(a) we must be confident that the HA can distinguish between CoA and CCoA registrations in all cases. Are we sure HA implementations can always do that? In other words, in the absence of an FA-HA authenticator is it always possible for an HA to know whether a RRQ is coming from the MN or the FA? I). FA-COA Mode: HA=3D=3D=3D=3D=3D=3D=3D=3DFA-----MN Encapsulation modes for IPv6 traffic: a.) HA-FACOA{IPv6-Pak} b.) HA-FACOA{HA-MNHoA{IPv6-Pak}} II). MN-COA Mode: HA=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DMN Encapsulation modes for IPv6 traffic: a.) HA-MNCOA{IPv6-Pak} b.) HA-MNCOA{HA-MNHOA{IPv6-PAK}} As well for the explicit mode, the document talks about "tunneling to HoA or CoA". But, its not implicit, if this introduces a new encap modes I(b) or II(b). Because, 3344, uses this style of delivery for broadcast or multicast packets. Few more lines of text will help. GT> I am not sure what you call "a new encap mode"? what kind of clarification would you think is necessary for I(b) and II(b)? I would appreciate it if you could provide proposed text. =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 Section 3.2 IPv6 Code Extension > A new skippable extension to the Mobile IPv4 header Should this be a non-skippable extension ? Its a reply and MN cant ignore this. It is present, because MN asked for it and it understands the format. Is it for supporting older FA's in path and when the packets are tunneled to HoA ? GT> I see your point but I think the extension works as skippable too. The defined behavior for the mobile not receiving this extension is to assume encapsulation of IPv6 over the HA-HoA tunnel, which is not harmful (just less efficient). Its existence allows for encapsulation to the MN's CoA but one can always encapsulate on the HA-HoA tunnel. Also by keeping it skippable we save on code space (i.e., use of one skippable code for all DSMIP extensions) which I assume is somewhat limited?=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Section 3.2 Code Values > 10 registration rejected, not home subnet > 11 registration rejected, Duplicate Address Detection failed Some of these code values require some explanation. Some are relevant only when the requested address is a prefix and some when the address is a IPv6-HoA. Its not specified where exactly each error code can be used. I understand, it may be implicit, but, few lines will help. GT> Maybe you missed it but use of these codes is I think well defined in the Home Consideration section 4.3 paragraph 3 and 4. Could you take another look and let me know if it is sufficient? =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=3D=3D=3D=3D Section 4.3 "If the IPv6 home address included in a IPv6 prefix request extension" You mean "IPv6 prefix extension" ?. Its in other places as well... GT> Ah yes, thanks. It in 6 places, I will correct it. =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=3D=3D=3D=3D=3D Section 4.3.1. IPv6 Packet Processing Should be mentioned that Proxy ND is required only when the requested IPv6 address is a HoA and not a IPv6 prefix. GT> Hmmm, yes maybe. Is that simple statement sufficient or should we say anything more? =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=3D=3D=3D=3D=3D Section 4.3.2: "Even if the tunnel for IPv4 traffic terminates at a different point than the tunnel for IPv6 traffic (mobile node's CoA vs HoA), both tunnels MUST use the tunneling mechanism negotiated by the Mobile IP header as defined in MIPv4 [RFC3344]. When IPinIP encapsulation is negotiated IPv6 is tunneled over IPv4 according to [RFC4213]. GRE and Minimal Encapsulation techniques also allow tunneling of IPv6 packet by setting the Protocol Type [RFC1701] and Protocol [RFC2004] fields to appropriate payload type defined for IPv6 by IANA." When the packets are tunneled to the HoA, the inner capsulation should be just IPv6-over-IPv4. I wonder, what is the value of using GRE for the inner packets ? This alligns better with the delivery style for broadcast and multicast packets, IMO. GT> Yes you are right. Should I then say that when IPv6 is encapsulated over the HA-HoA tunnel, RFC4213 should always be used? How is the following?: "When IPv6 traffic is encapsulated over the tunnel between the HA and the mobile node's care-off address, the tunneling mechanism used should be the same with the mechanism negotiated by the Mobile IP header as defined in MIPv4 [RFC3344]. In that case, when IPinIP encapsulation is negotiated, IPv6 is tunneled over IPv4 according to [RFC4213]. GRE and Minimal Encapsulation techniques also allow tunneling of IPv6 packet by setting the Protocol Type [RFC1701] and Protocol [RFC2004] fields to appropriate payload type defined for IPv6 by IANA. When, however, IPv6 traffic is encapsulated over the tunnel between the HA and the mobile node's home address, IPv6 is always tunneled over IPv4 according to [RFC4213], no matter what tunneling mechanism is negotiated in MIPv4 signaling. " =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=3D=3D=3D=3D=3D=3D=3D=3D Section 4.3.2 " Packets addressed to the mobile node's IPv6 link-local address MUST NOT be tunneled to the mobile node. Instead, these packets MUST be discarded and the home agent SHOULD return an ICMPv6 Destination Unreachable, Code 3, message to the packet's Source Address (unless this Source Address is a multicast address)." The HA will probably never know the link-local address of the mobile node ? The document does not specify the operation of the mobile node using a IPv6 HoA on its home interface and also there is no "Link-Local Address Compatibility (L)" flag to tell the HA that the identifier for IPv6-HoA and the Link-local address is the same. GT> Actually I am strangling to remember why or when we wrote this. Should I just remove it or is there something else we should say? =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "IPv6 packets received from the mobile client" It should be "mobile node". Some places the MN is referred to as mobile client. This should be consistent with 3344 terminology. GT> ok, thanks. =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 4.8: Registration with a private CoA You probably need a new type value for carrrying IPv6 packets in UDP. MIP Tunnel Data Message [3519, Section 3.3]. Or just mention that the IPv6 protocol number should be set when carrying IPv6 packets. GT> OK, good point. So would the following text work?: " 4.8. Registration with a private CoA If the care-of address is a private address then Mobile IP NAT Traversal as [RFC3519] MAY be used in combination with the extensions described in this specification. In that case the next header field of the Mobile Tunnel Data message header [RFC3519] MUST be set to the value for IPv6." =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks George Tsirtsis, George wrote: > Hi Peter, > > Kent sent me his comments offline and I have incorporated them in the > draft. His main comment was about clarifying that implicit mode is > entirely transparent to the FA, which I did. > > He is now, I think, on vacation so I could not check the changes with > him. In any case I am sure he will check the document next week when > he will be back. > > Regards > George > > > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann at motorola.com] > Sent: Tuesday, August 07, 2007 3:52 PM > To: mip4 at ietf.org; kleung at cisco.com > Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt > > Thanks George for submitting the updated version. > > Kent, you said during the meeting that you had some comments on this > draft. Could you send them to the list, so that we can move ahead > with this document? > > Thanks, > > -Pete > > Internet-Drafts at ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Mobility for IPv4 >> Working Group of the IETF. >> >> Title : Dual Stack Mobile IPv4 >> Author(s) : G. Tsirtsis, et al. >> Filename : draft-ietf-mip4-dsmipv4-03.txt >> Pages : 25 >> Date : 2007-8-7 >> >> This specification provides IPv6 extensions to the Mobile IPv4 >> protocol. The extensions allow a dual stack node to use IPv4 and >> IPv6 home addresses as well as to move between IPv4 and dual >> stack network infrastructures. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-03.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request at 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-mip4-dsmipv4-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 at ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-mip4-dsmipv4-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. --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 10 08:46: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 1IJTqy-00031N-0s; Fri, 10 Aug 2007 08:44:32 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IJTqw-00031A-9x for mip4-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 08:44:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJTqv-000312-VN for mip4@ietf.org; Fri, 10 Aug 2007 08:44:29 -0400 Received: from omta04ps.mx.bigpond.com ([144.140.83.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJTqs-0004WC-2i for mip4@ietf.org; Fri, 10 Aug 2007 08:44:29 -0400 Received: from oaamta04ps.mx.bigpond.com ([124.190.104.34]) by omta04ps.mx.bigpond.com with ESMTP id <20070810124422.VXSB1991.omta04ps.mx.bigpond.com@oaamta04ps.mx.bigpond.com>; Fri, 10 Aug 2007 12:44:22 +0000 Received: from PC20005 ([124.190.104.34]) by oaamta04ps.mx.bigpond.com with ESMTP id <20070810124422.SHAV29327.oaamta04ps.mx.bigpond.com@PC20005>; Fri, 10 Aug 2007 12:44:22 +0000 From: "Hesham Soliman" To: "'Tsirtsis, George'" , "'Sri Gundavelli'" , "'McCann Peter-A001034'" Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Date: Fri, 10 Aug 2007 22:44:15 +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: <2309978910A6A6478C2C7585692B0AF4871D58@NAEX16.na.qualcomm.com> Thread-Index: AcfbD6aHrNwGyHUsTzWiewwmNU3lYgAGjSfgAAhb+EA= X-Spam-Score: 1.1 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org > ========================================================= > Section 4.3.1. IPv6 Packet Processing > > Should be mentioned that Proxy ND is required only when the requested > IPv6 address is a HoA and not a IPv6 prefix. > > GT> Hmmm, yes maybe. Is that simple statement sufficient or should we > say anything more? => Basically we need to say that the HA will defed the IPv6 address by sending a proxy Neighbour Advertisement message. RFC 3775 talks about resending the message once for reliability. You could refer to that behaviour. > Section 4.3.2 > > " Packets addressed to the mobile node's IPv6 link-local address MUST > NOT be tunneled to the mobile node. Instead, these > packets MUST be > discarded and the home agent SHOULD return an ICMPv6 Destination > Unreachable, Code 3, message to the packet's Source > Address (unless > this Source Address is a multicast address)." > > The HA will probably never know the link-local address of the > mobile node ? The document does not specify the operation of the > mobile node using a IPv6 HoA on its home interface and also > there is no "Link-Local Address Compatibility (L)" flag to tell the > HA that the identifier for IPv6-HoA and the Link-local address is > the same. > > GT> Actually I am strangling to remember why or when we wrote this. > Should I just remove it or is there something else we should say? => I can't remember why we wrote this either. Looks like a bug, but I'm wondering whether we should have the L-flag equivalent here at all. It'd be interesting to see if anyone cares about link-local traffic, e.g. DHCPv6, MLD...etc. Hesham -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 13 00:45:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKRm5-0000pQ-IH; Mon, 13 Aug 2007 00:43:29 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IKRm4-0000pG-Fi for mip4-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 00:43:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKRm4-0000p8-2n for mip4@ietf.org; Mon, 13 Aug 2007 00:43:28 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKRm2-0007as-OB for mip4@ietf.org; Mon, 13 Aug 2007 00:43:28 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 12 Aug 2007 21:43:25 -0700 X-IronPort-AV: i="4.19,252,1183359600"; d="scan'208"; a="8206361:sNHT32285310" 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 l7D4hPNm009477; Sun, 12 Aug 2007 21:43:25 -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 l7D4hHF8027892; Mon, 13 Aug 2007 04:43:25 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); Sun, 12 Aug 2007 21:43:20 -0700 Received: from sgundavewxp ([10.82.217.77]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Aug 2007 21:43:18 -0700 From: "Sri Gundavelli" To: "'Tsirtsis, George'" , "'McCann Peter-A001034'" References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> <2309978910A6A6478C2C7585692B0AF4871D58@NAEX16.na.qualcomm.com> Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Date: Sun, 12 Aug 2007 21:43:11 -0700 Message-ID: <02cd01c7dd64$7b8ced90$4dd9520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <2309978910A6A6478C2C7585692B0AF4871D58@NAEX16.na.qualcomm.com> Thread-Index: AcfbD6aHrNwGyHUsTzWiewwmNU3lYgAGjSfgAI1a5PA= X-OriginalArrivalTime: 13 Aug 2007 04:43:18.0835 (UTC) FILETIME=[78506030:01C7DD64] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10136; t=1186980205; x=1187844205; 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=20[Mip4]=20I-D=20ACTION=3Adraft-ietf-mip4-dsmipv4-03.tx t=20 |Sender:=20; bh=55RaCYCVomDTxkNUqmuqh9cVMxPhIR4lXKSb5fVzlcE=; b=kAyeRETdhM0yXj+U3kcn6xHEpd2o15EAIgMHOtZI7p9BvgC4FRe812eaoatnaNwwToKGl34t G2Br/vPkOlPm6h/NhciFaSA1G0NQhGx5OLgm5FZlKeE1J3XnbRpyygv3; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi George, Inline ... > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > Sent: Friday, August 10, 2007 3:21 AM > To: Sri Gundavelli; McCann Peter-A001034 > Cc: mip4@ietf.org > Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt > > Hi Sri, Thanks for you comments. Please see comments inline... > > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Friday, August 10, 2007 6:25 AM > To: McCann Peter-A001034 > Cc: mip4@ietf.org > Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt > > > I've reviewed this document. It is in a good shape. Few > comments on the final version. May want to add some > clarifying text. > > Sri > > > --------------------------------------------------------- > Section 2.3 Implicit and Explicit Modes > > > > "In this mode of operation all traffic to and from > the IPv6 prefixes MUST be encapsulated over the IPv4 > tunnel between > the mobile node's IPv4 home address and the IPv4 address > of the home > agent, and as such it is transparent to any foreign agent in the > path." > > > The above text is not clear on what the supported encap modes are. The > text seems to say the encap mode is I(b) or II(b). Should > allow I(a) and > > II(a) ? > If transparency to FA is desired for IPv6 traffic in implicit > mode, I(b) > must be enforced. But, in CCOA mode, I(b) is an overhead. > > > GT> Sri, I(b) and II(b), keep things simple. To allow for I(a) we must > be confident that the HA can distinguish between CoA and CCoA > registrations in all cases. Are we sure HA implementations > can always do > that? In other words, in the absence of an FA-HA authenticator is it > always possible for an HA to know whether a RRQ is coming > from the MN or > the FA? > Why will this be an issue just in implicit mode. If the "IPv6 Tunneling Mode Extension" is present, HA can send the IPv6 packets in I(a)/II(a) mode i.e to a care-of address and not to the home address. Now, if the CoA is FA-COA or a CCOA, will that be important ? HA simply wraps the IPv6 packets with the tunnel header. If the packets are received at the FA, it simply forwards them as in for the explicit mode. Also, the presence of "D" bit in the RRQ, specifies if its FA-COA or a CCOA mode of operation. I'm ok either way. I was not sure, why in implicit mode, IPv6 packets cant be sent in I(a)/II(a) modes. > > I). FA-COA Mode: > > HA========FA-----MN > > > Encapsulation modes for IPv6 traffic: > > a.) HA-FACOA{IPv6-Pak} > > b.) HA-FACOA{HA-MNHoA{IPv6-Pak}} > > > > > II). MN-COA Mode: > > HA================MN > > > Encapsulation modes for IPv6 traffic: > > a.) HA-MNCOA{IPv6-Pak} > > b.) HA-MNCOA{HA-MNHOA{IPv6-PAK}} > > > As well for the explicit mode, the document talks about "tunneling > to HoA or CoA". But, its not implicit, if this introduces a new > encap modes I(b) or II(b). Because, 3344, uses this style of > delivery for broadcast or multicast packets. Few more lines of > text will help. > > > GT> I am not sure what you call "a new encap mode"? what kind of > clarification would you think is necessary for I(b) and II(b)? I would > appreciate it if you could provide proposed text. > Typical view of a MIP tunnel, is between FA-COA/CCOA to HAA and there is just one tunnel. Tunneling to HoA introduces some what a new tunnel i.e to the HA-MNCOA{HA-MNHOA{IPv6-PAK}}. I was just saying, few more line of text might be good, that the packet needs to be wrapped first in HAA-HoA and then HAA-COA wrappers. The text from 3344 on how broadcast/multicast packets are sent, can be used here. > =================================================== > > Section 3.2 IPv6 Code Extension > > > A new skippable extension to the Mobile IPv4 header > > > Should this be a non-skippable extension ? Its a reply and > MN cant ignore this. It is present, because MN asked for it > and it understands the format. Is it for supporting older > FA's in path and when the packets are tunneled to HoA ? > > GT> I see your point but I think the extension works as skippable too. > The defined behavior for the mobile not receiving this extension is to > assume encapsulation of IPv6 over the HA-HoA tunnel, which is not > harmful (just less efficient). Its existence allows for > encapsulation to > the MN's CoA but one can always encapsulate on the HA-HoA tunnel. Also > by keeping it skippable we save on code space (i.e., use of one > skippable code for all DSMIP extensions) which I assume is somewhat > limited? > Ok. > ==================================================== > > Section 3.2 Code Values > > > > 10 registration rejected, not home subnet > > > 11 registration rejected, Duplicate Address Detection failed > > Some of these code values require some explanation. Some are > relevant only when the requested address is a prefix and some > when the address is a IPv6-HoA. Its not specified where exactly > each error code can be used. I understand, it may be implicit, > but, few lines will help. > > > GT> Maybe you missed it but use of these codes is I think well defined > in the Home Consideration section 4.3 paragraph 3 and 4. > Could you take > another look and let me know if it is sufficient? > Ok. > ======================================================== > Section 4.3 > > "If the IPv6 home address included in a IPv6 prefix request extension" > > You mean "IPv6 prefix extension" ?. Its in other places as well... > > GT> Ah yes, thanks. It in 6 places, I will correct it. > > ========================================================= > Section 4.3.1. IPv6 Packet Processing > > Should be mentioned that Proxy ND is required only when the requested > IPv6 address is a HoA and not a IPv6 prefix. > > GT> Hmmm, yes maybe. Is that simple statement sufficient or should we > say anything more? > > Fine. > ========================================================= > > Section 4.3.2: > > "Even if the tunnel for IPv4 traffic terminates at a > different point > than the tunnel for IPv6 traffic (mobile node's CoA vs HoA), both > tunnels MUST use the tunneling mechanism negotiated by > the Mobile IP > header as defined in MIPv4 [RFC3344]. When IPinIP > encapsulation is > negotiated IPv6 is tunneled over IPv4 according to [RFC4213]. GRE > and Minimal Encapsulation techniques also allow tunneling of IPv6 > packet by setting the Protocol Type [RFC1701] and > Protocol [RFC2004] > fields to appropriate payload type defined for IPv6 by IANA." > > > When the packets are tunneled to the HoA, the inner capsulation > should be just IPv6-over-IPv4. I wonder, what is the value of using > GRE for the inner packets ? This alligns better with the delivery > style for broadcast and multicast packets, IMO. > > GT> Yes you are right. Should I then say that when IPv6 is > encapsulated > over the HA-HoA tunnel, RFC4213 should always be used? How is the > following?: > > "When IPv6 traffic is encapsulated over the tunnel between the HA and > the mobile node's care-off address, the tunneling mechanism > used should > be the same with the mechanism negotiated by the Mobile IP header as > defined in MIPv4 [RFC3344]. In that case, when IPinIP encapsulation is > negotiated, IPv6 is tunneled over IPv4 according to [RFC4213]. GRE and > Minimal Encapsulation techniques also allow tunneling of IPv6 > packet by > setting the Protocol Type [RFC1701] and Protocol [RFC2004] fields to > appropriate payload type defined for IPv6 by IANA. When, however, IPv6 > traffic is encapsulated over the tunnel between the HA and the mobile > node's home address, IPv6 is always tunneled over IPv4 according to > [RFC4213], no matter what tunneling mechanism is negotiated in MIPv4 > signaling. " > This is fine. > ============================================================ > Section 4.3.2 > > " Packets addressed to the mobile node's IPv6 link-local address MUST > NOT be tunneled to the mobile node. Instead, these > packets MUST be > discarded and the home agent SHOULD return an ICMPv6 Destination > Unreachable, Code 3, message to the packet's Source > Address (unless > this Source Address is a multicast address)." > > The HA will probably never know the link-local address of the > mobile node ? The document does not specify the operation of the > mobile node using a IPv6 HoA on its home interface and also > there is no "Link-Local Address Compatibility (L)" flag to tell the > HA that the identifier for IPv6-HoA and the Link-local address is > the same. > > GT> Actually I am strangling to remember why or when we wrote this. > Should I just remove it or is there something else we should say? > > ============================================================== > > "IPv6 packets received from the mobile client" > > It should be "mobile node". Some places the MN is referred to as > mobile client. This should be consistent with 3344 terminology. > > GT> ok, thanks. > > ============================================================== > Section 4.8: Registration with a private CoA > > > You probably need a new type value for carrrying IPv6 packets in > UDP. MIP Tunnel Data Message [3519, Section 3.3]. Or just mention > that the IPv6 protocol number should be set when carrying IPv6 > packets. > > GT> OK, good point. So would the following text work?: > > " 4.8. Registration with a private CoA > > If the care-of address is a private address then Mobile IP > NAT Traversal > as [RFC3519] MAY be used in combination with the extensions > described in > this specification. In that case the next header field of the Mobile > Tunnel Data message header [RFC3519] MUST be set to the value > for IPv6." > Ok. Sri -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 13 01:21: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 1IKSLZ-0000KR-RE; Mon, 13 Aug 2007 01:20:09 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IKSLY-0000JB-7P for mip4-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 01:20:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKSLX-0000J2-KT for mip4@ietf.org; Mon, 13 Aug 2007 01:20:07 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKSLX-0000KU-3n for mip4@ietf.org; Mon, 13 Aug 2007 01:20:07 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 Aug 2007 22:20:06 -0700 X-IronPort-AV: i="4.19,252,1183359600"; d="scan'208"; a="198918202:sNHT48401685" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7D5K6oW004363; Sun, 12 Aug 2007 22:20:06 -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 l7D5JvVp022976; Mon, 13 Aug 2007 05:19:57 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Aug 2007 22:19:56 -0700 Received: from sgundavewxp ([10.82.217.77]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Aug 2007 22:19:52 -0700 From: "Sri Gundavelli" To: "'Hesham Soliman'" , "'Tsirtsis, George'" , "'McCann Peter-A001034'" References: <2309978910A6A6478C2C7585692B0AF4871D58@NAEX16.na.qualcomm.com> Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Date: Sun, 12 Aug 2007 22:19:21 -0700 Message-ID: <02cf01c7dd69$9b986970$4dd9520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: AcfbD6aHrNwGyHUsTzWiewwmNU3lYgAGjSfgAAhb+EAAhkwvoA== X-OriginalArrivalTime: 13 Aug 2007 05:19:54.0573 (UTC) FILETIME=[951367D0:01C7DD69] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2763; t=1186982406; x=1187846406; 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=20[Mip4]=20I-D=20ACTION=3Adraft-ietf-mip4-dsmipv4-03.tx t=20 |Sender:=20; bh=nCb39A/cEt8vtjXznwh+7qz5aQ46BLJr+vhHpfOxt6g=; b=gxlUu/6S6KFBswWO5VmjW5zmkOGIEQ6i2dLM9W79VP7ovgJKFQjPY/bx6dh79yJ2aZx52xi6 xqsFOpODstm9l933VE1zhMPFD4FgFKcV+TUPLssxHc4bGdJqTfmyDnUD; Authentication-Results: sj-dkim-2; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com] > Sent: Friday, August 10, 2007 5:44 AM > To: 'Tsirtsis, George'; 'Sri Gundavelli'; 'McCann Peter-A001034' > Cc: mip4@ietf.org > Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt > > > > ========================================================= > > Section 4.3.1. IPv6 Packet Processing > > > > Should be mentioned that Proxy ND is required only when > the requested > > IPv6 address is a HoA and not a IPv6 prefix. > > > > GT> Hmmm, yes maybe. Is that simple statement sufficient > or should we > > say anything more? > > => Basically we need to say that the HA will defed the IPv6 address by > sending a proxy Neighbour Advertisement message. RFC 3775 talks about > resending the message once for reliability. You could refer to that > behaviour. > I meant for the case, when the MN requests a prefix. HA need not do any IPv6 ND operations. A simple route for the prefix over the tunnel should be sufficient. > > Section 4.3.2 > > > > " Packets addressed to the mobile node's IPv6 link-local > address MUST > > NOT be tunneled to the mobile node. Instead, these > > packets MUST be > > discarded and the home agent SHOULD return an ICMPv6 > Destination > > Unreachable, Code 3, message to the packet's Source > > Address (unless > > this Source Address is a multicast address)." > > > > The HA will probably never know the link-local address of the > > mobile node ? The document does not specify the operation of the > > mobile node using a IPv6 HoA on its home interface and also > > there is no "Link-Local Address Compatibility (L)" flag to tell the > > HA that the identifier for IPv6-HoA and the Link-local address is > > the same. > > > > GT> Actually I am strangling to remember why or when we wrote this. > > Should I just remove it or is there something else we should say? > > => I can't remember why we wrote this either. Looks like a > bug, but I'm > wondering whether we should have the L-flag equivalent here > at all. It'd be > interesting to see if anyone cares about link-local traffic, > e.g. DHCPv6, > MLD...etc. > The draft did not talk about of the use of IPv6 home address on the home link. If the MN is on a virtual link or never at home, there is no need for the HA to defend the mobile node's link-local address. But, there is no such assumption mentioned in the spec. If the mobile node operates as a normal MIPv6 node on the home link, we need to make sure that address is defended by the HA, else it might loose it. MN might use a link-local source address for DHCPv6 requests. Sri -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 13 06:07:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKWo0-0003yZ-Gm; Mon, 13 Aug 2007 06:05:48 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IKWnz-0003yU-OX for mip4-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 06:05:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKWnz-0003yL-D9 for mip4@ietf.org; Mon, 13 Aug 2007 06:05:47 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKWny-0007TH-OJ for mip4@ietf.org; Mon, 13 Aug 2007 06:05:47 -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 l7DA5fHt014679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Aug 2007 03:05:42 -0700 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l7DA5QwH009779; Mon, 13 Aug 2007 03:05:40 -0700 Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 03:05:29 -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: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Date: Mon, 13 Aug 2007 03:05:22 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF4871E52@NAEX16.na.qualcomm.com> In-Reply-To: <02cf01c7dd69$9b986970$4dd9520a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Thread-Index: AcfbD6aHrNwGyHUsTzWiewwmNU3lYgAGjSfgAAhb+EAAhkwvoAALDlbw References: <2309978910A6A6478C2C7585692B0AF4871D58@NAEX16.na.qualcomm.com> <02cf01c7dd69$9b986970$4dd9520a@amer.cisco.com> From: "Tsirtsis, George" To: "Sri Gundavelli" , "Hesham Soliman" , "McCann Peter-A001034" X-OriginalArrivalTime: 13 Aug 2007 10:05:29.0822 (UTC) FILETIME=[7A7AE7E0:01C7DD91] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org inline -----Original Message----- From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 Sent: Monday, August 13, 2007 6:19 AM To: 'Hesham Soliman'; Tsirtsis, George; 'McCann Peter-A001034' Cc: mip4@ietf.org Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt=20 =20 > -----Original Message----- > From: Hesham Soliman [mailto:Hesham@elevatemobile.com]=20 > Sent: Friday, August 10, 2007 5:44 AM > To: 'Tsirtsis, George'; 'Sri Gundavelli'; 'McCann Peter-A001034' > Cc: mip4@ietf.org > Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt=20 >=20 >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > Section 4.3.1. IPv6 Packet Processing > >=20 > > Should be mentioned that Proxy ND is required only when=20 > the requested > > IPv6 address is a HoA and not a IPv6 prefix. > >=20 > > GT> Hmmm, yes maybe. Is that simple statement sufficient=20 > or should we > > say anything more? >=20 > =3D> Basically we need to say that the HA will defed the IPv6 address = by > sending a proxy Neighbour Advertisement message. RFC 3775 talks about > resending the message once for reliability. You could refer to that > behaviour.=20 >=20 I meant for the case, when the MN requests a prefix. HA need not do any IPv6 ND operations. A simple route for the prefix over the tunnel should be sufficient. GT> Yes, I agree. I am going to edit the text in section 4.3. as follows: " When the IPv6 prefix extension contains a /128 IPv6 address and unless this home agent already has a binding for the given IPv6 address indicated, the home agent MUST perform Duplicate Address Detection on the mobile node's home IPv6 link before returning a registration reply. This ensures that no other node on the home link is using the IPv6 home address. Duplicate address detection is not required when the IPv6 prefix extension contains a prefix." > > Section 4.3.2 > >=20 > > " Packets addressed to the mobile node's IPv6 link-local=20 > address MUST > > NOT be tunneled to the mobile node. Instead, these=20 > > packets MUST be > > discarded and the home agent SHOULD return an ICMPv6=20 > Destination > > Unreachable, Code 3, message to the packet's Source=20 > > Address (unless > > this Source Address is a multicast address)." > >=20 > > The HA will probably never know the link-local address of the > > mobile node ? The document does not specify the operation of the > > mobile node using a IPv6 HoA on its home interface and also > > there is no "Link-Local Address Compatibility (L)" flag to tell the > > HA that the identifier for IPv6-HoA and the Link-local address is > > the same. > >=20 > > GT> Actually I am strangling to remember why or when we wrote this. > > Should I just remove it or is there something else we should say? >=20 > =3D> I can't remember why we wrote this either. Looks like a=20 > bug, but I'm > wondering whether we should have the L-flag equivalent here=20 > at all. It'd be > interesting to see if anyone cares about link-local traffic,=20 > e.g. DHCPv6, > MLD...etc.=20 > The draft did not talk about of the use of IPv6 home address on the home link. If the MN is on a virtual link or never at home, there is no need for the HA to defend the mobile node's link-local address. But, there is no such assumption mentioned in the spec. If the mobile node operates as a normal MIPv6 node on the home link, we need to make sure that address is defended by the HA, else it might loose it. MN might use a link-local source address for DHCPv6 requests. GT> I guess the fundamental question is whether the case of MN "at home" is of interest to the group. I do not see a strong need for this since MIPv4 in the field is typically deployed in "virtual link" mode. If people feel strongly about support for home link operation we have to add some more language around that, otherwise I will just state that this is not supported at this point. Thoughts? George -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 13 06:09: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 1IKWpq-0004D1-2A; Mon, 13 Aug 2007 06:07:42 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IKWpo-0004Cs-2Z for mip4-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 06:07:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKWpn-0004Ck-NT for mip4@ietf.org; Mon, 13 Aug 2007 06:07:39 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKWpl-0007WL-ON for mip4@ietf.org; Mon, 13 Aug 2007 06:07:39 -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 l7DA7auK027984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Aug 2007 03:07:36 -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 l7DA7Zbq009180; Mon, 13 Aug 2007 03:07:35 -0700 (PDT) Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 03:07:35 -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: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Date: Mon, 13 Aug 2007 03:07:27 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF4871E53@NAEX16.na.qualcomm.com> In-Reply-To: <02cd01c7dd64$7b8ced90$4dd9520a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Thread-Index: AcfbD6aHrNwGyHUsTzWiewwmNU3lYgAGjSfgAI1a5PAACvXIIA== References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> <2309978910A6A6478C2C7585692B0AF4871D58@NAEX16.na.qualcomm.com> <02cd01c7dd64$7b8ced90$4dd9520a@amer.cisco.com> From: "Tsirtsis, George" To: "Sri Gundavelli" , "McCann Peter-A001034" X-OriginalArrivalTime: 13 Aug 2007 10:07:35.0286 (UTC) FILETIME=[C5433160:01C7DD91] X-Spam-Score: 0.0 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Sri, thanks...some more comments inline... -----Original Message----- From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 Sent: Monday, August 13, 2007 5:43 AM To: Tsirtsis, George; 'McCann Peter-A001034' Cc: mip4@ietf.org Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt=20 Hi George, Inline ...=20 > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 > Sent: Friday, August 10, 2007 3:21 AM > To: Sri Gundavelli; McCann Peter-A001034 > Cc: mip4@ietf.org > Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt=20 >=20 > Hi Sri, Thanks for you comments. Please see comments inline... >=20 > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 > Sent: Friday, August 10, 2007 6:25 AM > To: McCann Peter-A001034 > Cc: mip4@ietf.org > Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt=20 >=20 >=20 > I've reviewed this document. It is in a good shape. Few > comments on the final version. May want to add some > clarifying text. >=20 > Sri >=20 >=20 > --------------------------------------------------------- > Section 2.3 Implicit and Explicit Modes >=20 >=20 >=20 > "In this mode of operation all traffic to and from > the IPv6 prefixes MUST be encapsulated over the IPv4=20 > tunnel between > the mobile node's IPv4 home address and the IPv4 address=20 > of the home > agent, and as such it is transparent to any foreign agent in the > path." >=20 >=20 > The above text is not clear on what the supported encap modes are. The > text seems to say the encap mode is I(b) or II(b). Should=20 > allow I(a) and >=20 > II(a) ? > If transparency to FA is desired for IPv6 traffic in implicit=20 > mode, I(b) > must be enforced. But, in CCOA mode, I(b) is an overhead. >=20 >=20 > GT> Sri, I(b) and II(b), keep things simple. To allow for I(a) we must > be confident that the HA can distinguish between CoA and CCoA > registrations in all cases. Are we sure HA implementations=20 > can always do > that? In other words, in the absence of an FA-HA authenticator is it > always possible for an HA to know whether a RRQ is coming=20 > from the MN or > the FA? >=20 Why will this be an issue just in implicit mode. If the "IPv6 Tunneling Mode Extension" is present, HA can send the IPv6 packets in I(a)/II(a) mode i.e to a care-of address and not to the home address. Now, if the CoA is FA-COA or a CCOA, will that be important ?=20 GT> It is actually important. The MN can only send the "IPv6 Tunneling Mode Extension" if it works in CCoA mode. See the following quote from section 4.5: "The mobile node SHOULD include exactly one IPv6 tunneling mode extension if it uses the co-located care-of address model and it wants to request that IPv6 packets are tunneled to its co-located care-of address. If the mobile node uses the co-located care-of address model but it does not include the IPv6 tunneling mode extension the home agent will tunnel IPv6 traffic to the mobile client's home address. The mobile node MUST NOT include an IPv6 tunneling mode extension if it uses the care-of address mode of operation. Note that if the mobile includes an IPv6 tunneling mode extension in this case, IPv6 packets could be tunneled to the FA by the HA. The FA is then likely to drop them since it may not have appropriate state to process them." HA simply wraps the IPv6 packets with the tunnel header. If the packets are received at the FA, it simply forwards them as in for the explicit mode. Also, the presence of "D" bit in the RRQ, specifies if its FA-COA or a CCOA mode of operation.=20 I'm ok either way. I was not sure, why in implicit mode, IPv6 packets cant be sent in I(a)/II(a) modes. GT> The problem is that if the HA tunnels IPv6 packets to the FA and the FA does not support IPv6, the packets will be dropped on the floor. In implicit mode (i.e., the absence of an IPv6 tunneling Mode extension), there is no way for the HA to know if the FA supports IPv6 or the behaviors defined in this draft, so tunneling to the MN's IPv4 HoA is always safer. >=20 > I). FA-COA Mode: >=20 > HA=3D=3D=3D=3D=3D=3D=3D=3DFA-----MN >=20 >=20 > Encapsulation modes for IPv6 traffic: >=20 > a.) HA-FACOA{IPv6-Pak} >=20 > b.) HA-FACOA{HA-MNHoA{IPv6-Pak}} >=20 >=20 >=20 >=20 > II). MN-COA Mode: >=20 > HA=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DMN >=20 >=20 > Encapsulation modes for IPv6 traffic: >=20 > a.) HA-MNCOA{IPv6-Pak} >=20 > b.) HA-MNCOA{HA-MNHOA{IPv6-PAK}} >=20 >=20 > As well for the explicit mode, the document talks about "tunneling > to HoA or CoA". But, its not implicit, if this introduces a new > encap modes I(b) or II(b). Because, 3344, uses this style of > delivery for broadcast or multicast packets. Few more lines of > text will help. >=20 >=20 > GT> I am not sure what you call "a new encap mode"? what kind of > clarification would you think is necessary for I(b) and II(b)? I would > appreciate it if you could provide proposed text. >=20 Typical view of a MIP tunnel, is between FA-COA/CCOA to HAA and there is just one tunnel. Tunneling to HoA introduces some what a new tunnel i.e to the HA-MNCOA{HA-MNHOA{IPv6-PAK}}. I was just saying, few more line of text might be good, that the packet needs to be wrapped first in HAA-HoA and then HAA-COA=20 wrappers. The text from 3344 on how broadcast/multicast packets are sent, can be used here. GT> OK, I see. I will modify the appropriate part of section 4.3.2 as follows, based on corresponding text in 3344, so tell me if it works: " 1) Registration request is received with one or more IPv6 prefix extensions. An IPv6 tunneling mode extension is not included. All IPv6 packets destined to the registered IPv6 prefix(es) MUST be tunneled by the home agent to the registered IPv4 home address of the mobile. =3D=3D=3Dstart of new text=3D=3D=3D=3D=3D=3D=3D The home agent first encapsulates the IPv6 packet addressed to the mobile node's IPv4 home address, and then tunnels this encapsulated datagram to the foreign agent. This extra level of encapsulation is required so that IPv6 routing remains transparent to a foreign agent that does not support IPv6. When received by the foreign agent, the unicast encapsulated packet is detunneled and delivered to the mobile node in the same way as any other datagram. The mobile node must decapsulate the received IPv4 packet it receives in order to recover the original IPv6 packet.=20 =3D=3D=3D=3D=3D=3Dend of new text=3D=3D=3D=3D=3D=3D=3D=3D Additionally, the home agent MUST be prepared to accept reverse tunneled packets from the IPv4 home address of the mobile encapsulating IPv6 packets sent by that mobile." > = =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 >=20 > Section 3.2 IPv6 Code Extension >=20 > > A new skippable extension to the Mobile IPv4 header >=20 >=20 > Should this be a non-skippable extension ? Its a reply and > MN cant ignore this. It is present, because MN asked for it > and it understands the format. Is it for supporting older > FA's in path and when the packets are tunneled to HoA ? >=20 > GT> I see your point but I think the extension works as skippable too. > The defined behavior for the mobile not receiving this extension is to > assume encapsulation of IPv6 over the HA-HoA tunnel, which is not > harmful (just less efficient). Its existence allows for=20 > encapsulation to > the MN's CoA but one can always encapsulate on the HA-HoA tunnel. Also > by keeping it skippable we save on code space (i.e., use of one > skippable code for all DSMIP extensions) which I assume is somewhat > limited?=20 >=20 Ok. > = =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 >=20 > Section 3.2 Code Values >=20 >=20 > > 10 registration rejected, not home subnet >=20 > > 11 registration rejected, Duplicate Address Detection failed >=20 > Some of these code values require some explanation. Some are > relevant only when the requested address is a prefix and some > when the address is a IPv6-HoA. Its not specified where exactly > each error code can be used. I understand, it may be implicit, > but, few lines will help. >=20 >=20 > GT> Maybe you missed it but use of these codes is I think well defined > in the Home Consideration section 4.3 paragraph 3 and 4.=20 > Could you take > another look and let me know if it is sufficient? >=20 Ok. > = =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=3D=3D=3D=3D > Section 4.3 >=20 > "If the IPv6 home address included in a IPv6 prefix request extension" >=20 > You mean "IPv6 prefix extension" ?. Its in other places as well... >=20 > GT> Ah yes, thanks. It in 6 places, I will correct it. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Section 4.3.1. IPv6 Packet Processing >=20 > Should be mentioned that Proxy ND is required only when the requested > IPv6 address is a HoA and not a IPv6 prefix. >=20 > GT> Hmmm, yes maybe. Is that simple statement sufficient or should we > say anything more? >=20 >=20 Fine. > = =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=3D=3D=3D=3D=3D >=20 > Section 4.3.2: >=20 > "Even if the tunnel for IPv4 traffic terminates at a=20 > different point > than the tunnel for IPv6 traffic (mobile node's CoA vs HoA), both > tunnels MUST use the tunneling mechanism negotiated by=20 > the Mobile IP > header as defined in MIPv4 [RFC3344]. When IPinIP=20 > encapsulation is > negotiated IPv6 is tunneled over IPv4 according to [RFC4213]. GRE > and Minimal Encapsulation techniques also allow tunneling of IPv6 > packet by setting the Protocol Type [RFC1701] and=20 > Protocol [RFC2004] > fields to appropriate payload type defined for IPv6 by IANA." >=20 >=20 > When the packets are tunneled to the HoA, the inner capsulation > should be just IPv6-over-IPv4. I wonder, what is the value of using > GRE for the inner packets ? This alligns better with the delivery > style for broadcast and multicast packets, IMO. >=20 > GT> Yes you are right. Should I then say that when IPv6 is=20 > encapsulated > over the HA-HoA tunnel, RFC4213 should always be used? How is the > following?: >=20 > "When IPv6 traffic is encapsulated over the tunnel between the HA and > the mobile node's care-off address, the tunneling mechanism=20 > used should > be the same with the mechanism negotiated by the Mobile IP header as > defined in MIPv4 [RFC3344]. In that case, when IPinIP encapsulation is > negotiated, IPv6 is tunneled over IPv4 according to [RFC4213]. GRE and > Minimal Encapsulation techniques also allow tunneling of IPv6=20 > packet by > setting the Protocol Type [RFC1701] and Protocol [RFC2004] fields to > appropriate payload type defined for IPv6 by IANA. When, however, IPv6 > traffic is encapsulated over the tunnel between the HA and the mobile > node's home address, IPv6 is always tunneled over IPv4 according to > [RFC4213], no matter what tunneling mechanism is negotiated in MIPv4 > signaling. " >=20 This is fine. > = =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=3D=3D=3D=3D=3D=3D=3D=3D > Section 4.3.2 >=20 > " Packets addressed to the mobile node's IPv6 link-local address MUST > NOT be tunneled to the mobile node. Instead, these=20 > packets MUST be > discarded and the home agent SHOULD return an ICMPv6 Destination > Unreachable, Code 3, message to the packet's Source=20 > Address (unless > this Source Address is a multicast address)." >=20 > The HA will probably never know the link-local address of the > mobile node ? The document does not specify the operation of the > mobile node using a IPv6 HoA on its home interface and also > there is no "Link-Local Address Compatibility (L)" flag to tell the > HA that the identifier for IPv6-HoA and the Link-local address is > the same. >=20 > GT> Actually I am strangling to remember why or when we wrote this. > Should I just remove it or is there something else we should say? >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > "IPv6 packets received from the mobile client" >=20 > It should be "mobile node". Some places the MN is referred to as > mobile client. This should be consistent with 3344 terminology. >=20 > GT> ok, thanks. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Section 4.8: Registration with a private CoA >=20 >=20 > You probably need a new type value for carrrying IPv6 packets in > UDP. MIP Tunnel Data Message [3519, Section 3.3]. Or just mention > that the IPv6 protocol number should be set when carrying IPv6 > packets. >=20 > GT> OK, good point. So would the following text work?: >=20 > " 4.8. Registration with a private CoA >=20 > If the care-of address is a private address then Mobile IP=20 > NAT Traversal > as [RFC3519] MAY be used in combination with the extensions=20 > described in > this specification. In that case the next header field of the Mobile > Tunnel Data message header [RFC3519] MUST be set to the value=20 > for IPv6." >=20 Ok. Sri -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 13 06:19: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 1IKWzN-0004HY-KB; Mon, 13 Aug 2007 06:17:33 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IKWzN-0004HT-3O for mip4-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 06:17:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKWzM-0004HL-Os for mip4@ietf.org; Mon, 13 Aug 2007 06:17:32 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKWzM-0007lv-Bf for mip4@ietf.org; Mon, 13 Aug 2007 06:17:32 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 13 Aug 2007 03:17:31 -0700 X-IronPort-AV: i="4.19,254,1183359600"; d="scan'208"; a="199030617:sNHT45688554" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7DAHV38011566; Mon, 13 Aug 2007 03:17:31 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l7DAHVa1001356; Mon, 13 Aug 2007 10:17:31 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 03:17:31 -0700 Received: from sgundavewxp ([10.82.217.77]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 03:17:29 -0700 From: "Sri Gundavelli" To: "'Tsirtsis, George'" , "'McCann Peter-A001034'" References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com> <2309978910A6A6478C2C7585692B0AF4871D58@NAEX16.na.qualcomm.com> <02cd01c7dd64$7b8ced90$4dd9520a@amer.cisco.com> <2309978910A6A6478C2C7585692B0AF4871E53@NAEX16.na.qualcomm.com> Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Date: Mon, 13 Aug 2007 03:17:20 -0700 Message-ID: <02d401c7dd93$283bfee0$4dd9520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <2309978910A6A6478C2C7585692B0AF4871E53@NAEX16.na.qualcomm.com> Thread-Index: AcfbD6aHrNwGyHUsTzWiewwmNU3lYgAGjSfgAI1a5PAACvXIIAAB7Oxg X-OriginalArrivalTime: 13 Aug 2007 10:17:30.0421 (UTC) FILETIME=[27FD9650:01C7DD93] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1364; t=1187000251; x=1187864251; 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=20[Mip4]=20I-D=20ACTION=3Adraft-ietf-mip4-dsmipv4-03.tx t=20 |Sender:=20; bh=J2ICx6yQML24gh9JOR8SKfb0AioGZK8i0llrDL2+ioQ=; b=CjiX/6qjAUcgSG9f/uzDp4vZ4sCv1jr4mta+YVFw1CPp1B8mBpj0KQu1X09/GukUu2Tm9ICv EK6LaT0pPgiq5WFPpEWYmfxHdSAa3i5sUWFUrMmJwDdUo2RsW18T2auAwCOL/0R/Q/5i/EKH1v 9ynAmtMAx0S/OSQ30onkBuTO0=; 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi George, > > GT> OK, I see. I will modify the appropriate part of section 4.3.2 as > follows, based on corresponding text in 3344, so tell me if it works: > " 1) Registration request is received with one or more IPv6 prefix > extensions. An IPv6 tunneling mode extension is not included. > > All IPv6 packets destined to the registered IPv6 > prefix(es) MUST be tunneled by the home agent to > the registered IPv4 home address of the mobile. > > ===start of new text======= > The home agent first encapsulates the IPv6 > packet addressed to the mobile node's IPv4 home > address, and then tunnels this encapsulated > datagram to the foreign agent. This extra level > of encapsulation is required so that IPv6 > routing remains transparent to a foreign agent > that does not support IPv6. When received by the > foreign agent, the unicast encapsulated packet is > detunneled and delivered to the mobile node in > the same way as any other datagram. The mobile > node must decapsulate the received IPv4 packet > it receives in order to recover the original > IPv6 packet. > ======end of new text======== > Additionally, the home agent MUST > be prepared to accept reverse tunneled packets > from the IPv4 home address of the mobile > encapsulating IPv6 packets sent by that mobile." > This is good. Thanks Sri -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 13 11:16: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 1IKbdM-0002u0-8O; Mon, 13 Aug 2007 11:15:08 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IKbdL-0002ts-8H for mip4-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 11:15:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbdJ-0002tg-0H; Mon, 13 Aug 2007 11:15:06 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKbdI-0000QO-Hk; Mon, 13 Aug 2007 11:15:04 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1187018098!4657528!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 19560 invoked from network); 13 Aug 2007 15:14:58 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-15.tower-153.messagelabs.com with SMTP; 13 Aug 2007 15:14:58 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l7DFEs3q005519; Mon, 13 Aug 2007 08:14:58 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l7DFEqGE028910; Mon, 13 Aug 2007 10:14:53 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l7DFEpET028877; Mon, 13 Aug 2007 10:14:52 -0500 (CDT) 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: Mon, 13 Aug 2007 11:14:50 -0400 Message-ID: In-Reply-To: <0MKpCa-1IJdSp3z3s-0006TB@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPwAIZ9xkA= References: <0MKpCa-1IJdSp3z3s-0006TB@mrelay.perfora.net> From: "McCann Peter-A001034" To: "Alper Yegin" , "Ahmad Muhanna" , X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip4@ietf.org Subject: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Alper Yegin wrote: > Pete, >> No, I don't. Putting the Registration Request in the AMR is a >> feature. It allows the registration to happen in one round-trip. >=20 > Obviously it is a feature. But don't you think it is a bit of a hack? > I mean, tunneling one protocol inside another for the sake of saving > round-trips? For example, we could further reduce the round-trips by > tunneling MIP4 inside EAP of network access authentication. =20 I don't think it's a hack. When we have Mobile IP being used for access authentication I think it makes sense to carry the RRQ in a Diameter application. EAP is a different case because then we have a separate protocol doing access authentication. > I also understand that having to go to HAAA twice for each MIP RegReq > is bothersome. But then, maybe we should re-consider the necessity of > MN-FA authentication. Given that HA is going to authenticate the MN, > does FA also need to do the same? =20 The FA and HA might be part of different administrative domains. I think the FA has just as much reason to authenticate the MN as the HA. > Alper -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 13 13:43: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 1IKdvY-0008LB-Ai; Mon, 13 Aug 2007 13:42:04 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IKdvW-0008L3-Pe for mip4-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 13:42:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdvW-0008Kv-EG for mip4@ietf.org; Mon, 13 Aug 2007 13:42:02 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKdvV-0006UA-Nl for mip4@ietf.org; Mon, 13 Aug 2007 13:42:02 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 13 Aug 2007 10:42:01 -0700 X-IronPort-AV: i="4.19,255,1183359600"; d="scan'208"; a="199264169:sNHT70179246" 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 l7DHg1D4032669; Mon, 13 Aug 2007 10:42:01 -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 l7DHfnWN020769; Mon, 13 Aug 2007 17:42:01 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, 13 Aug 2007 10:41:53 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Date: Mon, 13 Aug 2007 10:41:50 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5204593831@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF4871A94@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Thread-Index: AcfZASuebTA/LzLbRKKYQS2wK8BHwQAARSZgAABr6aABMwxW8A== From: "Kent Leung \(kleung\)" To: "Tsirtsis, George" , "McCann Peter-A001034" , X-OriginalArrivalTime: 13 Aug 2007 17:41:53.0145 (UTC) FILETIME=[3C366690:01C7DDD1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4073; t=1187026921; x=1187890921; 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[Mip4]=20I-D=20ACTION=3Adraft-ietf-mip4-dsmipv4-03.tx t=20 |Sender:=20; bh=p2OAutnCwwrlSEn7hT5NlZr46DZJKGmOnmjH3hctJDI=; b=LVoiNY7Pre+J3AFbB0GCr2SU8f26t383WtonqhPsGUXfHMoC9OoScaviNM0mJ9AXJDBaf4Vo XKjRydIlcFSLBjEiUeLLqBy6ZQZqHGmTC2zK6FxGcpx+xDWZ3Q3dQWhW; 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: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org The latest version looks good to me. Just one minor nit.=20 Sect 2.3: Additionally, in the explicit mode, the mobile node (when co-located mode of operation is used) or the foreign agent (when present) can indicate whether IPv6 traffic should be tunneled to the care-of address of the home address of the mobile node. <--- typo: first "of" should be "or" Kent -----Original Message----- From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 Sent: Tuesday, August 07, 2007 8:10 AM To: McCann Peter-A001034; mip4@ietf.org; Kent Leung (kleung) Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt=20 Hi Peter, Kent sent me his comments offline and I have incorporated them in the draft. His main comment was about clarifying that implicit mode is entirely transparent to the FA, which I did. He is now, I think, on vacation so I could not check the changes with him. In any case I am sure he will check the document next week when he will be back. Regards George -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] Sent: Tuesday, August 07, 2007 3:52 PM To: mip4@ietf.org; kleung@cisco.com Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt=20 Thanks George for submitting the updated version. Kent, you said during the meeting that you had some comments on this draft. Could you send them to the list, so that we can move ahead with this document? Thanks, -Pete Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Mobility for IPv4 Working Group of=20 > the IETF. >=20 > Title : Dual Stack Mobile IPv4 > Author(s) : G. Tsirtsis, et al. > Filename : draft-ietf-mip4-dsmipv4-03.txt > Pages : 25 > Date : 2007-8-7 >=20 > This specification provides IPv6 extensions to the Mobile IPv4 > protocol. The extensions allow a dual stack node to use IPv4 and > IPv6 home addresses as well as to move between IPv4 and dual stack > network infrastructures. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-03.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 the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > 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 "get > draft-ietf-mip4-dsmipv4-03.txt". =20 >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > 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-mip4-dsmipv4-03.txt". >=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 13 13:48: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 1IKdzo-0004YJ-Bo; Mon, 13 Aug 2007 13:46:28 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IKdzm-0004Y9-TT for mip4-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 13:46:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKdzm-0004Y1-Hy for mip4@ietf.org; Mon, 13 Aug 2007 13:46:26 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKdzl-0006f3-Ja for mip4@ietf.org; Mon, 13 Aug 2007 13:46:26 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 19:46:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Aug 2007 19:46:16 +0200 Message-ID: <14FD20369E52DE478BD9612D63BE21B40BD29973@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mobility using Proxy MIP and Mobike Thread-Index: Acfd0djnVYyl/zJDSvu5pi1aY8N7Vg== From: "ANTOINE Stephane RD-ILAB-LON" To: X-OriginalArrivalTime: 13 Aug 2007 17:46:24.0074 (UTC) FILETIME=[DDB2E2A0:01C7DDD1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Subject: [Mip4] Mobility using Proxy MIP and Mobike X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1255064004==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1255064004== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DDD1.DD91EDDE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DDD1.DD91EDDE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello all, =20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : Mobility using Proxy MIP and Mobike Author(s) : S. Antoine Filename : draft-antoine-mip4-proxymobike-00.txt Pages : 10 Date : 2007-8-10 The simultaneous use of Mobike and Mobile IPv4 has been proposed to provide secure connectivity and session continuity to roaming corporate users. Optimization of this solution have eliminated the tunneling overhead of Mobile IPv4 in the vpn tunnel by having a Foreign Agent co-located to the mobile vpn gateway. This document further proposes an interaction between Mobike and Proxy Mobile IP that simplifies implementation and deployment of the previous methods. The mobile vpn gateway is co-located to the Mobility Proxy Agent and each Access Point in the corporate network is equipped with Proxy Mobile IP. When moving outside the corporate network, the Mobile Node secure connectivity and session continuity is handled by Mobike. Proxy Mobile IP alone is used to handle mobility when the Mobile Node moves within the corporate network. This document introduces an interaction between Internet Key Exchange v2 and Proxy Mobile IP in which the Internet Key Exchange AUTH request triggers the Proxy Mobile IP registration request to the internal Home Agent. This interaction easily allows the Mobile Node's home address to be used as vpn Tunnel Inner Address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-antoine-mip4-proxymobike-00.tx t To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request at ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. 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-antoine-mip4-proxymobike-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-antoine-mip4-proxymobike-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =09 =20 =20 ------_=_NextPart_001_01C7DDD1.DD91EDDE Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hello=20 all,
 
A New Internet-Draft is available from the on-line Internet-Drafts=20
directories.


Title : Mobility using Proxy MIP and=20 Mobike
Author(s) : S. Antoine
Filename :=20 draft-antoine-mip4-proxymobike-00.txt
Pages : 10
Date :=20 2007-8-10

   The simultaneous use of Mobike and Mobile = IPv4=20 has been proposed to
   provide secure connectivity and = session=20 continuity to roaming
   corporate users.  = Optimization of=20 this solution have eliminated the
   tunneling overhead of = Mobile=20 IPv4 in the vpn tunnel by having a
   Foreign Agent = co-located to=20 the mobile vpn gateway.  This document
   further = proposes an=20 interaction between Mobike and Proxy Mobile IP
   that = simplifies=20 implementation and deployment of the previous
   = methods.  The=20 mobile vpn gateway is co-located to the Mobility Proxy
   = Agent and=20 each Access Point in the corporate network is equipped = with
  =20 Proxy Mobile IP.  When moving outside the corporate network,=20 the
   Mobile Node secure connectivity and session = continuity is=20 handled by
   Mobike.  Proxy Mobile IP alone is used = to handle=20 mobility when the
   Mobile Node moves within the corporate = network.  This document
   introduces an interaction = between=20 Internet Key Exchange v2 and Proxy
   Mobile IP in which = the=20 Internet Key Exchange AUTH request triggers
   the Proxy = Mobile IP=20 registration request to the internal Home Agent.
   This=20 interaction easily allows the Mobile Node's home address to = be
  =20 used as vpn Tunnel Inner Address.


A URL for this = Internet-Draft=20 is:
http://www.ietf.org/internet-drafts/draft-antoine-mip4-proxymob= ike-00.txt

To=20 remove yourself from the I-D Announcement list, send a message to=20
i-d-announce-request at ietf.org with the word unsubscribe in the = body of=20
the message.
You can also visit https://www1= .ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.

Internet-Drafts are = also=20 available by anonymous FTP. Login with the
username "anonymous" and = a=20 password of your e-mail address. After
logging in, type "cd = internet-drafts"=20 and then
"get draft-antoine-mip4-proxymobike-00.txt".

A list = of=20 Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html<= /A>=20
or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt

Internet-Drafts=20 can also be obtained by e-mail.

Send a message to:
mailserv = at=20 ietf.org.
In the body type:
"FILE=20 /internet-drafts/draft-antoine-mip4-proxymobike-00.txt".

NOTE: = The mail=20 server at ietf.org can return the document in
MIME-encoded form by = using the=20 "mpack" utility.  To use this
feature, insert the command = "ENCODING=20 mime" before the "FILE"
command.  To decode the response(s), = you will=20 need "munpack" or
a MIME-compliant mail reader.  Different=20 MIME-compliant mail readers
exhibit different behavior, especially = when=20 dealing with
"multipart" MIME messages (i.e. documents which have = been=20 split
up into multiple messages), so check your local documentation=20 on
how to manipulate these messages.

Below is the data which = will=20 enable a MIME compliant mail reader
implementation to automatically = retrieve=20 the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-antoine-mip4-proxym= obike-00.txt>=20
 
------_=_NextPart_001_01C7DDD1.DD91EDDE-- --===============1255064004== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1255064004==-- From mip4-bounces@ietf.org Mon Aug 13 15:40: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 1IKfkT-0003sJ-Kw; Mon, 13 Aug 2007 15:38:45 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IKfkT-0003s9-9E for mip4-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 15:38:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKfkS-0003s0-Vg; Mon, 13 Aug 2007 15:38:44 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKfkR-0002ax-53; Mon, 13 Aug 2007 15:38:44 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 13 Aug 2007 12:38:42 -0700 X-IronPort-AV: i="4.19,256,1183359600"; d="scan'208"; a="13266176:sNHT31918926" 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 l7DJcg9A024837; Mon, 13 Aug 2007 12:38:42 -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 l7DJcOFE018886; Mon, 13 Aug 2007 19:38:42 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 12:38:42 -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: [Mip4] draft-ietf-mip4-gen-ext-03.txt Date: Mon, 13 Aug 2007 12:38:43 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5204593901@xmb-sjc-235.amer.cisco.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA3E6@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] draft-ietf-mip4-gen-ext-03.txt Thread-Index: AcfTe0Ke/BKsgd15SyWMrcjFTjhBOwB2i4TAAiIrCDA= From: "Kent Leung \(kleung\)" To: "Chowdhury, Kuntal" , "McCann Peter-A001034" , , X-OriginalArrivalTime: 13 Aug 2007 19:38:42.0093 (UTC) FILETIME=[8DDEFDD0:01C7DDE1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4733; t=1187033922; x=1187897922; c=relaxed/simple; s=sjdkim2002; 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[Mip4]=20draft-ietf-mip4-gen-ext-03.txt |Sender:=20; bh=aDVmgJRW/719tUDm+aeqGc4Qx+2Rp6djFnfhXE6B4Ec=; b=XGO/TUZtrcZmkqw7P1/s6cdRbyPk3fragvEM5zE8HC84CmjLXw2D1a4ebZHUjbjk3Bwk1Cka fkUyz77DZLO7rcKiDVrRm07FEEIizmhsjGtq3Ej6HMTPZYDcY3hRCYoe; Authentication-Results: sj-dkim-2; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Just adding a few more comments. I agree with Kuntal that this draft is defining the MIP method of configuration. The benefits include 1) configuration info from the FA and/or HA, 2) signaling efficiency, 3) built-in authentication of the configuration, 4) extensible parameters, and 5) support for non-DHCP capable MN. The use case may be obtaining a couple of configuration parameters for the Mobile IP interface on the MN. I believe that this draft should proceed forth. There is no technical solution in the case when either #1 (FA CoA and reverse tunnel enabled) and/or #5 exists. =20 Kent=20 -----Original Message----- From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 Sent: Thursday, August 02, 2007 4:00 PM To: McCann Peter-A001034; mip4@ietf.org; dhcwg@ietf.org Subject: RE: [Mip4] draft-ietf-mip4-gen-ext-03.txt Hi Pete, I think the source of the confusion is the use of DHCP options. The initial version of this I-D did not propose to use DHCP options at all. The proposal contained a few possible host config parameters that we would have defined. However, someone saw the light, and suggested that instead of redesigning the host config options from scratch, why not we used the options and the format of the options carrying config info as defined in DHCP. It made sense; hence we decided to accept that approach. Now, I see that people are mixing the use of DHCP protocol with MIP4 host config options. I think this is a digression that we should avoid. We need to understand the scope of the I-D. It does not rule out other ways to do host configuration when the MN is using MIP4. It defines _a_ way that is Mobile IP specific. It is also the most efficient one from the number of round trips point of view. When you say that running DHCP inside MIP4 tunnel allows for a single protocol to be used whether the MN is at home or visiting, I have a question. How is it possible for the MN to fetch config info from the visited network when RT is negotiated and enforced at the FA?=20 BTW, the approach specified in the draft-ietf-mip4-gen-ext-03.txt allows the use of a single protocol i.e. MIP4 to be used to fetch config info from home and visited networks, not to mention with fewer number of messages. Another issue that we need to think about the use of DHCP inside MIP4 tunnel is security. We cannot prohibit the MN to run DHCPINFORM only, right? The MN may start doing IP address config (lease and release). How to secure these DHCP messages? If we intend to only allow the MN to send DHCPINFORM, how do we prevent it from sending other DHCP messages? AFAIK, RFC 3118 is not widely implemented and used. Even if it is, we can't expect the MIP4 implementations to start implementing RFC 3118 just to get a few config info from the home domain. Regards, Kuntal > -----Original Message----- > From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] > Sent: Tuesday, July 31, 2007 9:01 AM > To: mip4@ietf.org; dhcwg@ietf.org > Subject: [Mip4] draft-ietf-mip4-gen-ext-03.txt >=20 > A question has arisen during the last call for=20 > draft-ietf-mip4-gen-ext-03.txt. >=20 > The draft includes the following text: >=20 > There are mechanisms > such as DHCP for the mobile node to configure information from the > foreign network, but not from the home network when the mobile node > is not attached to the home network. >=20 > However, this may not be strictly true. In particular, it might be=20 > possible to use a DHCPINFORM message through the tunnel that was=20 > established with Mobile IP, thus eliminating the need to encode DHCP=20 > options inside Mobile IP messages. > This would allow for a single configuration protocol to be used=20 > whether the MN is at home or visiting. >=20 > I think we may have touched on this question during our last=20 > chartering discussion but we might not have explored all the=20 > ramifications. Please, if you have an opinion either way express it=20 > now and give some background as to why you think so. > It is possible that we might turn this draft into a BCP-like document=20 > for how to configure and run DHCP over the tunnel to the home network. >=20 > -Pete >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 13 16:34:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKgaV-00035I-2h; Mon, 13 Aug 2007 16:32:31 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IKgaS-00034l-Sn for mip4-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 16:32:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKgaS-00034c-Hq; Mon, 13 Aug 2007 16:32:28 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKgaS-0005qk-0y; Mon, 13 Aug 2007 16:32:28 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-4.tower-153.messagelabs.com!1187037146!5492512!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 1640 invoked from network); 13 Aug 2007 20:32:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-153.messagelabs.com with SMTP; 13 Aug 2007 20:32:26 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l7DKWQMG027167; Mon, 13 Aug 2007 13:32:26 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l7DKWPJl019990; Mon, 13 Aug 2007 15:32:25 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l7DKWOrL019969; Mon, 13 Aug 2007 15:32:25 -0500 (CDT) 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: Mon, 13 Aug 2007 16:32:23 -0400 Message-ID: In-Reply-To: <0MKpCa-1IKgE83oi3-0006T1@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPwAIZ9xkAAClyVwAAA1OQA References: <0MKpCa-1IKgE83oi3-0006T1@mrelay.perfora.net> From: "McCann Peter-A001034" To: "Alper Yegin" , "Ahmad Muhanna" , X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: mip4@ietf.org Subject: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Alper Yegin wrote: > Pete, >> >> I don't think it's a hack. When we have Mobile IP being used for >> access authentication I think it makes sense to carry the RRQ in a >> Diameter application. EAP is a different case because then we have a >> separate protocol doing access authentication. >=20 > Using a mobility protocol's AAA for network access AAA is another > hack, IMHO. These are two separate services. That may explain why one > protocol is tunneled inside another, but it does not justify. =20 Well, this is the road we went down back in 1998. There is at least one SDO that is heavily dependent on the MN-NAI and MN-AAA extensions. =20 > I understand these are all driven by performance improvements. Yes. =20 >> The FA and HA might be part of different administrative domains. >> I think the FA has just as much reason to authenticate the MN as the >> HA. >=20 > MN is authenticated by the same entity (HAAA) whether requested by > the FA or the HA. If HA and FA has some trust relationship (e.g., > using FA-HA AE, or IPsec), then I believe letting the HA authenticate > the MN is sufficient. =20 There is no scalable way to maintain trust relationships between all pairs of (FA, HA). One of the main purposes of the Diameter MIPv4 application is to distribute keys for those (FA, HA) relationships that are necessary based on the MNs that are roaming to a given FA. The FA needs to make sure that the visited resources will be paid for, which is why it needs=20 authorization from the AAA infrastructure. -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 13 17:45: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 1IKhhL-0004Dr-QO; Mon, 13 Aug 2007 17:43:39 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IJdSz-0008Rz-OT for mip4-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 19:00:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJdSy-0008Rq-Pu; Fri, 10 Aug 2007 19:00:24 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJdSx-0001KT-Fm; Fri, 10 Aug 2007 19:00:24 -0400 Received: from [88.233.199.213] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IJdSp3z3s-0006TB; Fri, 10 Aug 2007 19:00:21 -0400 From: "Alper Yegin" To: "'McCann Peter-A001034'" , "'Ahmad Muhanna'" , Date: Sat, 11 Aug 2007 02:00:07 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Message-ID: <0MKpCa-1IJdSp3z3s-0006TB@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/OnfAUvYY9K9xYl0rnh5GqSvkj/NgRYMI09xX ZjhG7mCIydbhyPw4dAKp4c97TCuZBbMZsFTQHxJL4US2FwbBs3 xuElbvzgt5+Zk7xanM0IA== X-Spam-Score: -0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Mon, 13 Aug 2007 17:43:37 -0400 Cc: mip4@ietf.org Subject: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Pete, > > 2. The point here is not about Diameter as an AAA protocol, however, > > it is about the concept of coupling the MIPv4 control signaling to > > AAA signaling. Which many people do not think it is a good idea and > > believe that it is a deviation from RFC3344 initial MIPv4 > > registration procedure. Do not you agree? > > No, I don't. Putting the Registration Request in the AMR is a feature. > It allows the registration to happen in one round-trip. Obviously it is a feature. But don't you think it is a bit of a hack? I mean, tunneling one protocol inside another for the sake of saving round-trips? For example, we could further reduce the round-trips by tunneling MIP4 inside EAP of network access authentication. I also understand that having to go to HAAA twice for each MIP RegReq is bothersome. But then, maybe we should re-consider the necessity of MN-FA authentication. Given that HA is going to authenticate the MN, does FA also need to do the same? Alper -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 13 17:45: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 1IKhhM-0004Dw-0B; Mon, 13 Aug 2007 17:43:40 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IKgEJ-0002DW-Ut for mip4-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 16:09:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKgEJ-0002DN-LO; Mon, 13 Aug 2007 16:09:35 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKgEI-0003v3-Cp; Mon, 13 Aug 2007 16:09:35 -0400 Received: from [88.233.137.79] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IKgE83oi3-0006T1; Mon, 13 Aug 2007 16:09:31 -0400 From: "Alper Yegin" To: "'McCann Peter-A001034'" , "'Ahmad Muhanna'" , Date: Mon, 13 Aug 2007 23:09:12 +0300 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: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPwAIZ9xkAAClyVwA== Message-ID: <0MKpCa-1IKgE83oi3-0006T1@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19fC2x2NKL72qVIdu4/WvhQ2zOcOyYIt7qmcO1 4NBusH9iDo/IaWbxr7pi7854sFkaeZWDmKdk0bHotxxucHT2OK KGwxAG9vneq5FFaVvx8XQ== X-Spam-Score: -0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Mon, 13 Aug 2007 17:43:37 -0400 Cc: mip4@ietf.org Subject: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Pete, > >> No, I don't. Putting the Registration Request in the AMR is a > >> feature. It allows the registration to happen in one round-trip. > > > > Obviously it is a feature. But don't you think it is a bit of a hack? > > I mean, tunneling one protocol inside another for the sake of saving > > round-trips? For example, we could further reduce the round-trips by > > tunneling MIP4 inside EAP of network access authentication. > > I don't think it's a hack. When we have Mobile IP being used > for access authentication I think it makes sense to carry the > RRQ in a Diameter application. EAP is a different case because > then we have a separate protocol doing access authentication. Using a mobility protocol's AAA for network access AAA is another hack, IMHO. These are two separate services. That may explain why one protocol is tunneled inside another, but it does not justify. I understand these are all driven by performance improvements. > > I also understand that having to go to HAAA twice for each MIP RegReq > > is bothersome. But then, maybe we should re-consider the necessity of > > MN-FA authentication. Given that HA is going to authenticate the MN, > > does FA also need to do the same? > > The FA and HA might be part of different administrative domains. > I think the FA has just as much reason to authenticate the MN as > the HA. MN is authenticated by the same entity (HAAA) whether requested by the FA or the HA. If HA and FA has some trust relationship (e.g., using FA-HA AE, or IPsec), then I believe letting the HA authenticate the MN is sufficient. Alper > > > Alper > > -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 13 17:45: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 1IKhhL-0004Dr-QO; Mon, 13 Aug 2007 17:43:39 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IJdSz-0008Rz-OT for mip4-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 19:00:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJdSy-0008Rq-Pu; Fri, 10 Aug 2007 19:00:24 -0400 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJdSx-0001KT-Fm; Fri, 10 Aug 2007 19:00:24 -0400 Received: from [88.233.199.213] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IJdSp3z3s-0006TB; Fri, 10 Aug 2007 19:00:21 -0400 From: "Alper Yegin" To: "'McCann Peter-A001034'" , "'Ahmad Muhanna'" , Date: Sat, 11 Aug 2007 02:00:07 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Message-ID: <0MKpCa-1IJdSp3z3s-0006TB@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/OnfAUvYY9K9xYl0rnh5GqSvkj/NgRYMI09xX ZjhG7mCIydbhyPw4dAKp4c97TCuZBbMZsFTQHxJL4US2FwbBs3 xuElbvzgt5+Zk7xanM0IA== X-Spam-Score: -0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Mon, 13 Aug 2007 17:43:37 -0400 Cc: mip4@ietf.org Subject: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Pete, > > 2. The point here is not about Diameter as an AAA protocol, however, > > it is about the concept of coupling the MIPv4 control signaling to > > AAA signaling. Which many people do not think it is a good idea and > > believe that it is a deviation from RFC3344 initial MIPv4 > > registration procedure. Do not you agree? > > No, I don't. Putting the Registration Request in the AMR is a feature. > It allows the registration to happen in one round-trip. Obviously it is a feature. But don't you think it is a bit of a hack? I mean, tunneling one protocol inside another for the sake of saving round-trips? For example, we could further reduce the round-trips by tunneling MIP4 inside EAP of network access authentication. I also understand that having to go to HAAA twice for each MIP RegReq is bothersome. But then, maybe we should re-consider the necessity of MN-FA authentication. Given that HA is going to authenticate the MN, does FA also need to do the same? Alper -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 13 17:45: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 1IKhhM-0004Dw-0B; Mon, 13 Aug 2007 17:43:40 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IKgEJ-0002DW-Ut for mip4-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 16:09:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKgEJ-0002DN-LO; Mon, 13 Aug 2007 16:09:35 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKgEI-0003v3-Cp; Mon, 13 Aug 2007 16:09:35 -0400 Received: from [88.233.137.79] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IKgE83oi3-0006T1; Mon, 13 Aug 2007 16:09:31 -0400 From: "Alper Yegin" To: "'McCann Peter-A001034'" , "'Ahmad Muhanna'" , Date: Mon, 13 Aug 2007 23:09:12 +0300 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: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPwAIZ9xkAAClyVwA== Message-ID: <0MKpCa-1IKgE83oi3-0006T1@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX19fC2x2NKL72qVIdu4/WvhQ2zOcOyYIt7qmcO1 4NBusH9iDo/IaWbxr7pi7854sFkaeZWDmKdk0bHotxxucHT2OK KGwxAG9vneq5FFaVvx8XQ== X-Spam-Score: -0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Mon, 13 Aug 2007 17:43:37 -0400 Cc: mip4@ietf.org Subject: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Pete, > >> No, I don't. Putting the Registration Request in the AMR is a > >> feature. It allows the registration to happen in one round-trip. > > > > Obviously it is a feature. But don't you think it is a bit of a hack? > > I mean, tunneling one protocol inside another for the sake of saving > > round-trips? For example, we could further reduce the round-trips by > > tunneling MIP4 inside EAP of network access authentication. > > I don't think it's a hack. When we have Mobile IP being used > for access authentication I think it makes sense to carry the > RRQ in a Diameter application. EAP is a different case because > then we have a separate protocol doing access authentication. Using a mobility protocol's AAA for network access AAA is another hack, IMHO. These are two separate services. That may explain why one protocol is tunneled inside another, but it does not justify. I understand these are all driven by performance improvements. > > I also understand that having to go to HAAA twice for each MIP RegReq > > is bothersome. But then, maybe we should re-consider the necessity of > > MN-FA authentication. Given that HA is going to authenticate the MN, > > does FA also need to do the same? > > The FA and HA might be part of different administrative domains. > I think the FA has just as much reason to authenticate the MN as > the HA. MN is authenticated by the same entity (HAAA) whether requested by the FA or the HA. If HA and FA has some trust relationship (e.g., using FA-HA AE, or IPsec), then I believe letting the HA authenticate the MN is sufficient. Alper > > > Alper > > -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 13 17:46:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKhiY-0004kE-M3; Mon, 13 Aug 2007 17:44:54 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IJVC4-0005Ml-Fq for mip4-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 10:10:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJVC4-0005ML-5q for mip4@ietf.org; Fri, 10 Aug 2007 10:10:24 -0400 Received: from xsmtp1.ethz.ch ([82.130.70.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJVC2-0006R6-5C for mip4@ietf.org; Fri, 10 Aug 2007 10:10:23 -0400 Received: from xfe1.d.ethz.ch ([82.130.124.41]) by xsmtp1.ethz.ch with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Aug 2007 16:10:21 +0200 Received: from vs9.inf.ethz.ch ([129.132.130.188]) by xfe1.d.ethz.ch over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Aug 2007 16:10:20 +0200 Received: by vs9.inf.ethz.ch (sSMTP sendmail emulation); Fri, 10 Aug 2007 16:10:17 +0200 Date: Fri, 10 Aug 2007 16:10:17 +0200 From: Marc Langheinrich - IOT 2008 To: mip4@ietf.org Message-ID: <20070810141017.GA19563@inf.ethz.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-OriginalArrivalTime: 10 Aug 2007 14:10:20.0079 (UTC) FILETIME=[2F50FBF0:01C7DB58] X-Spam-Score: -4.0 (----) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-Mailman-Approved-At: Mon, 13 Aug 2007 17:44:53 -0400 Subject: [Mip4] 2nd CFP: Internet of Things 2008 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org dear colleagues, the call below might be of interest to you. apologies if you receive multiple copies. best regards, -m ----------------------------------------------------------------- *************************************************************** * Second Call for Papers - Submission Deadline: Sep. 15, 2007 * *************************************************************** INTERNET OF THINGS 2008 International Conference for Industry and Academia March 26-28, 2008, Zurich (Switzerland) Organized by ETH Zurich, University St.Gallen, and MIT www.internet-of-things-2008.org The term "Internet of Things" has come to describe a number of technologies and research disciplines that enable the Internet to reach out into the real world of physical objects. This fore- shadows an exciting future that closely interlinks the physical world and cyberspace -- a development that is highly relevant to researchers, corporations, and individuals. The conference will be the first that brings leading researchers and practitioners from both academia and industry together to facilitate sharing of applications, research results, and knowledge. A world-class program committee comprised of leading researchers in key areas of the Internet of Things is looking forward to contributions addressing topics such as: * Novel services and applications in an Internet of Things (IOT) * Emerging IOT business models and process changes * Communication systems and network architectures for the IOT * Technologies and concepts for embedding sensing, actuation, communication, and computation into networked things * Experience reports from the introduction and operation of net- worked things in areas such as healthcare, logistics & transport * Security & privacy aspects of IOT infrastructures & applications Scientific contributions will be published in the Springer LNCS series. We are particularly interested in work addressing real- world implementation and deployment issues. For submission in- structions and timelines see www.internet-of-things-2008.org/cfp/ -------------------------------------------------------- - Sep. 15, 2007 Technical papers submissions deadline - - Oct. 20, 2007 Workshop/tutorials/demo proposals due - -------------------------------------------------------- General Chairs: Elgar Fleisch (ETH Zurich & University St.Gallen), Friedemann Mattern (ETH Zurich) and Sanjay Sarma (MIT). For a full list of conference committee members, see: www.iot2008.org -- Questions? Contact us: -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Aug 13 19:00: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 1IKis9-0006iw-7t; Mon, 13 Aug 2007 18:58:53 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IKis8-0006il-Dh for mip4-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 18:58:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKis8-0006ic-4B; Mon, 13 Aug 2007 18:58:52 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKis6-0002Bx-QK; Mon, 13 Aug 2007 18:58:52 -0400 Received: from [88.233.137.79] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IKirz3qBP-0006SO; Mon, 13 Aug 2007 18:58:49 -0400 From: "Alper Yegin" To: "'McCann Peter-A001034'" , "'Ahmad Muhanna'" , Date: Tue, 14 Aug 2007 01:58:32 +0300 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: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPwAIZ9xkAAClyVwAAA1OQAAAUjpAA= Message-ID: <0MKpCa-1IKirz3qBP-0006SO@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1/Gw/cVkVE31tMl447aVzQOIsrP/vexHOJ1iIy 6h4zxh+wD86hEAf5LrJ+xAh/ams981D/G8RzP4m4FSCcNf8JYk XTnR2cKd42sBHr8Sc0aVQ== X-Spam-Score: -0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip4@ietf.org Subject: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org > > MN is authenticated by the same entity (HAAA) whether requested by > > the FA or the HA. If HA and FA has some trust relationship (e.g., > > using FA-HA AE, or IPsec), then I believe letting the HA authenticate > > the MN is sufficient. > > There is no scalable way to maintain trust relationships between > all pairs of (FA, HA). One of the main purposes of the Diameter > MIPv4 application is to distribute keys for those (FA, HA) > relationships that are necessary based on the MNs that are > roaming to a given FA. The FA needs to make sure that the > visited resources will be paid for, which is why it needs > authorization from the AAA infrastructure. FA-HA security association can also be dynamically created during the network access authentication procedure. Alper -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 14 06:56: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 1IKu2Z-0006xn-4i; Tue, 14 Aug 2007 06:54:23 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IKu2Y-0006xi-9p for mip4-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 06:54:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKu2X-0006xZ-Tb for mip4@ietf.org; Tue, 14 Aug 2007 06:54:21 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKu2W-0003YN-FN for mip4@ietf.org; Tue, 14 Aug 2007 06:54:21 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l7EAsIic011158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Aug 2007 03:54:19 -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 l7EAsHcG031548; Tue, 14 Aug 2007 03:54:18 -0700 Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 03:54:17 -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: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Date: Tue, 14 Aug 2007 03:54:15 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF4871FCA@NAEX16.na.qualcomm.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5204593831@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt Thread-Index: AcfZASuebTA/LzLbRKKYQS2wK8BHwQAARSZgAABr6aABMwxW8AAkUaVw References: <2309978910A6A6478C2C7585692B0AF4871A94@NAEX16.na.qualcomm.com> <2979E38DD6FC6544B789C8DAD7BAFC5204593831@xmb-sjc-235.amer.cisco.com> From: "Tsirtsis, George" To: "Kent Leung (kleung)" , "McCann Peter-A001034" , X-OriginalArrivalTime: 14 Aug 2007 10:54:17.0539 (UTC) FILETIME=[75F2D130:01C7DE61] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Yes, will correct it, thanks. -----Original Message----- From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 Sent: Monday, August 13, 2007 6:42 PM To: Tsirtsis, George; McCann Peter-A001034; mip4@ietf.org Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt=20 The latest version looks good to me. Just one minor nit.=20 Sect 2.3: Additionally, in the explicit mode, the mobile node (when co-located mode of operation is used) or the foreign agent (when present) can indicate whether IPv6 traffic should be tunneled to the care-of address of the home address of the mobile node. <--- typo: first "of" should be "or" Kent -----Original Message----- From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 Sent: Tuesday, August 07, 2007 8:10 AM To: McCann Peter-A001034; mip4@ietf.org; Kent Leung (kleung) Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt=20 Hi Peter, Kent sent me his comments offline and I have incorporated them in the draft. His main comment was about clarifying that implicit mode is entirely transparent to the FA, which I did. He is now, I think, on vacation so I could not check the changes with him. In any case I am sure he will check the document next week when he will be back. Regards George -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] Sent: Tuesday, August 07, 2007 3:52 PM To: mip4@ietf.org; kleung@cisco.com Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-dsmipv4-03.txt=20 Thanks George for submitting the updated version. Kent, you said during the meeting that you had some comments on this draft. Could you send them to the list, so that we can move ahead with this document? Thanks, -Pete Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Mobility for IPv4 Working Group of=20 > the IETF. >=20 > Title : Dual Stack Mobile IPv4 > Author(s) : G. Tsirtsis, et al. > Filename : draft-ietf-mip4-dsmipv4-03.txt > Pages : 25 > Date : 2007-8-7 >=20 > This specification provides IPv6 extensions to the Mobile IPv4 > protocol. The extensions allow a dual stack node to use IPv4 and > IPv6 home addresses as well as to move between IPv4 and dual stack > network infrastructures. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip4-dsmipv4-03.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 the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > 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 "get > draft-ietf-mip4-dsmipv4-03.txt". =20 >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > 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-mip4-dsmipv4-03.txt". >=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 14 10:01: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 1IKwvc-00006n-GQ; Tue, 14 Aug 2007 09:59:24 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IKwvc-00006Z-01 for mip4-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 09:59:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwvb-00006P-LQ; Tue, 14 Aug 2007 09:59:23 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IKwvb-0005AS-7P; Tue, 14 Aug 2007 09:59:23 -0400 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-9.tower-153.messagelabs.com!1187099960!5212234!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4364 invoked from network); 14 Aug 2007 13:59:20 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-153.messagelabs.com with SMTP; 14 Aug 2007 13:59:20 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l7EDxGrg012890; Tue, 14 Aug 2007 06:59:20 -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 l7EDxF1l004159; Tue, 14 Aug 2007 08:59:16 -0500 (CDT) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l7EDxF0k004148; Tue, 14 Aug 2007 08:59:15 -0500 (CDT) 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: Tue, 14 Aug 2007 09:59:11 -0400 Message-ID: In-Reply-To: <0MKpCa-1IKirz3qBP-0006SO@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPwAIZ9xkAAClyVwAAA1OQAAAUjpAAAH596IA== References: <0MKpCa-1IKirz3qBP-0006SO@mrelay.perfora.net> From: "McCann Peter-A001034" To: "Alper Yegin" , "Ahmad Muhanna" , X-Vontu: Pass X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: mip4@ietf.org Subject: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Alper Yegin wrote: >> There is no scalable way to maintain trust relationships between all >> pairs of (FA, HA). One of the main purposes of the Diameter >> MIPv4 application is to distribute keys for those (FA, HA) >> relationships that are necessary based on the MNs that are roaming to >> a given FA. The FA needs to make sure that the visited resources >> will be paid for, which is why it needs authorization from the AAA >> infrastructure. >=20 > FA-HA security association can also be dynamically created during the > network access authentication procedure.=20 That's exactly what the Diameter-MIPv4 application does. -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Aug 15 16:34:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPXa-0006zC-Jm; Wed, 15 Aug 2007 16:32:30 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1ILPXZ-0006yt-5D for mip4-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 16:32:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPXY-0006yl-Rs; Wed, 15 Aug 2007 16:32:28 -0400 Received: from mout.perfora.net ([74.208.4.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILPXY-0000jL-9D; Wed, 15 Aug 2007 16:32:28 -0400 Received: from [88.233.137.79] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1ILPXP3mAK-0005Es; Wed, 15 Aug 2007 16:32:27 -0400 From: "Alper Yegin" To: "'Tom Taylor'" Date: Wed, 15 Aug 2007 23:32:15 +0300 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: <46C33772.3010700@rogers.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcffYYbQ12tlM4I5ThmB/BWjLQA+nAAGc2yQ Message-Id: <0MKp8S-1ILPXP3mAK-0005Es@mrelay.perfora.net> X-Provags-ID: V01U2FsdGVkX1+Zaj+tp4mOtqJWNoLMhX3dC6F46mtKnU1bf4q kavtyJsX8SOwSnf+L1ab3ARQsLWSJEXwRjPSVthmvgo2bn0pN2 SmXi6GpYf7ZEZjJxZgVCQ== X-Spam-Score: -0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: dime@ietf.org, mip4@ietf.org, 'McCann Peter-A001034' , 'Ahmad Muhanna' Subject: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Yes, HOKEY has relevance to that. Alper > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor@rogers.com] > Sent: Wednesday, August 15, 2007 8:27 PM > To: Alper Yegin > Cc: 'McCann Peter-A001034'; 'Ahmad Muhanna'; dime@ietf.org; mip4@ietf.org > Subject: Re: [Dime] RE: Issue 3: Diameter MIP4 Application vs. > RADIUSArchitecture > > Isn't this what HOKEY is all about? > > Alper Yegin wrote: > >>> MN is authenticated by the same entity (HAAA) whether requested by > >>> the FA or the HA. If HA and FA has some trust relationship (e.g., > >>> using FA-HA AE, or IPsec), then I believe letting the HA authenticate > >>> the MN is sufficient. > >> There is no scalable way to maintain trust relationships between > >> all pairs of (FA, HA). One of the main purposes of the Diameter > >> MIPv4 application is to distribute keys for those (FA, HA) > >> relationships that are necessary based on the MNs that are > >> roaming to a given FA. The FA needs to make sure that the > >> visited resources will be paid for, which is why it needs > >> authorization from the AAA infrastructure. > > > > FA-HA security association can also be dynamically created during the > > network access authentication procedure. > > > > Alper > > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 16 07:36:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILdd0-0004s5-I8; Thu, 16 Aug 2007 07:35:02 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1ILdcz-0004rv-5R for mip4-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 07:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILdcy-0004rn-Mq; Thu, 16 Aug 2007 07:35:00 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILdcx-0003qj-25; Thu, 16 Aug 2007 07:35:00 -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 l7GBYuVF001565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 Aug 2007 04:34:57 -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 l7GBYuCA010246; Thu, 16 Aug 2007 04:34:56 -0700 (PDT) Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by SANEXCAS03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Aug 2007 04:34:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs.RADIUSArchitecture Date: Thu, 16 Aug 2007 04:34:59 -0700 Message-ID: <2309978910A6A6478C2C7585692B0AF4951568@NAEX16.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs.RADIUSArchitecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPwAIZ9xkAAClyVwAAA1OQAAAUjpAAAH596IABfZtVg References: <0MKpCa-1IKirz3qBP-0006SO@mrelay.perfora.net> From: "Tsirtsis, George" To: "McCann Peter-A001034" , "Alper Yegin" , "Ahmad Muhanna" , X-OriginalArrivalTime: 16 Aug 2007 11:34:55.0815 (UTC) FILETIME=[7819B570:01C7DFF9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Sorry I have not followed this fully but I also think that sending RRQs encapsulated in DIAMETER messages is not always desirable. In fact it links two protocols in a way that is somewhat undesirable. The HA for example, has to be able to accept MIP registrations from two different protocols now (i.e., MIP and DIAMETER). The RADIUS way of doing this is a bit cleaner, but more importantly is widely deployed and current deployments are unlikely to change their model just because they want to upgrade to DIAMETER. My 2c George -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 Sent: Tuesday, August 14, 2007 2:59 PM To: Alper Yegin; Ahmad Muhanna; dime@ietf.org Cc: mip4@ietf.org Subject: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs.RADIUSArchitecture Alper Yegin wrote: >> There is no scalable way to maintain trust relationships between all >> pairs of (FA, HA). One of the main purposes of the Diameter >> MIPv4 application is to distribute keys for those (FA, HA) >> relationships that are necessary based on the MNs that are roaming to >> a given FA. The FA needs to make sure that the visited resources >> will be paid for, which is why it needs authorization from the AAA >> infrastructure. >=20 > FA-HA security association can also be dynamically created during the > network access authentication procedure.=20 That's exactly what the Diameter-MIPv4 application does. -Pete --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 16 08:03: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 1ILe2r-0007oc-4D; Thu, 16 Aug 2007 08:01:45 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1ILe2o-0007o7-4v for mip4-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 08:01:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILe2n-0007nw-QF; Thu, 16 Aug 2007 08:01:41 -0400 Received: from omta02ps.mx.bigpond.com ([144.140.83.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILe2l-0004sx-Sq; Thu, 16 Aug 2007 08:01:41 -0400 Received: from oaamta02ps.mx.bigpond.com ([124.190.104.34]) by omta02ps.mx.bigpond.com with ESMTP id <20070816120136.YGLA14578.omta02ps.mx.bigpond.com@oaamta02ps.mx.bigpond.com>; Thu, 16 Aug 2007 12:01:36 +0000 Received: from PC20005 ([124.190.104.34]) by oaamta02ps.mx.bigpond.com with ESMTP id <20070816120135.MTDZ14534.oaamta02ps.mx.bigpond.com@PC20005>; Thu, 16 Aug 2007 12:01:35 +0000 From: "Hesham Soliman" To: "'Alper Yegin'" , "'McCann Peter-A001034'" , "'Ahmad Muhanna'" , Subject: RE: [Mip4] RE: [Dime] RE: Issue 3: Diameter MIP4 Application vs.RADIUSArchitecture Date: Thu, 16 Aug 2007 22:01:32 +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 Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAA6hsPwAIZ9xkAAClyVwACGBojQ In-Reply-To: <0MKpCa-1IKgE83oi3-0006T1@mrelay.perfora.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org > > > Obviously it is a feature. But don't you think it is a > bit of a hack? > > > I mean, tunneling one protocol inside another for the > sake of saving > > > round-trips? For example, we could further reduce the > round-trips by > > > tunneling MIP4 inside EAP of network access authentication. > > > > I don't think it's a hack. When we have Mobile IP being used > > for access authentication I think it makes sense to carry the > > RRQ in a Diameter application. EAP is a different case because > > then we have a separate protocol doing access authentication. > > Using a mobility protocol's AAA for network access AAA is > another hack, > IMHO. These are two separate services. That may explain why > one protocol is > tunneled inside another, but it does not justify. > > I understand these are all driven by performance improvements. => I agree with Alper about this. I do think we should avoid this type of "performance improvement" :). I don't think it's a good idea for the RRQ or other MIP messages to be encapsulated in Diameter and I actually think the performance benefits are negligible. Hesham > > > > > I also understand that having to go to HAAA twice for > each MIP RegReq > > > is bothersome. But then, maybe we should re-consider the > necessity of > > > MN-FA authentication. Given that HA is going to > authenticate the MN, > > > does FA also need to do the same? > > > > The FA and HA might be part of different administrative domains. > > I think the FA has just as much reason to authenticate the MN as > > the HA. > > MN is authenticated by the same entity (HAAA) whether > requested by the FA or > the HA. If HA and FA has some trust relationship (e.g., > using FA-HA AE, or > IPsec), then I believe letting the HA authenticate the MN is > sufficient. > > Alper > > > > > > > > > > > > > Alper > > > > -Pete > > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: > http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 16 21:43: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 1ILqqp-0007kO-Rn; Thu, 16 Aug 2007 21:42:11 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1ILMeM-00008A-CN for mip4-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 13:27:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILMeM-00005t-0p for mip4@ietf.org; Wed, 15 Aug 2007 13:27:18 -0400 Received: from smtp108.rog.mail.re2.yahoo.com ([68.142.225.206]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ILMeK-0003X3-Qt for mip4@ietf.org; Wed, 15 Aug 2007 13:27:18 -0400 Received: (qmail 19161 invoked from network); 15 Aug 2007 17:27:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=0iirQ9+dQ7/L+VkpWceo2fqUF+UVUoQPfJ9dzws7EH4H1RKOjIIp93y07T2sCGDKY6seahzeiZ6vGdsHk3haL8Wuw3ppW5DIsErHtpMNXoXxSPioODRvsNdWfOf6a9XVtkJNr8Xr4BB49X0OmEuTi5DvZMIVcy/C6j/zKpAwKdE= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp108.rog.mail.re2.yahoo.com with SMTP; 15 Aug 2007 17:27:16 -0000 X-YMail-OSG: fw_Ps6wVM1lIRt0SkRJh1dNPByvtY9.i8Bvn9_NkjE7_BYSmggmk0lt0mVKKybL6Fw-- Message-ID: <46C33772.3010700@rogers.com> Date: Wed, 15 Aug 2007 13:27:14 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alper Yegin References: <0MKpCa-1IKirz3qBP-0006SO@mrelay.perfora.net> In-Reply-To: <0MKpCa-1IKirz3qBP-0006SO@mrelay.perfora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Thu, 16 Aug 2007 21:42:11 -0400 Cc: dime@ietf.org, mip4@ietf.org, 'McCann Peter-A001034' , 'Ahmad Muhanna' Subject: [Mip4] Re: [Dime] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Isn't this what HOKEY is all about? Alper Yegin wrote: >>> MN is authenticated by the same entity (HAAA) whether requested by >>> the FA or the HA. If HA and FA has some trust relationship (e.g., >>> using FA-HA AE, or IPsec), then I believe letting the HA authenticate >>> the MN is sufficient. >> There is no scalable way to maintain trust relationships between >> all pairs of (FA, HA). One of the main purposes of the Diameter >> MIPv4 application is to distribute keys for those (FA, HA) >> relationships that are necessary based on the MNs that are >> roaming to a given FA. The FA needs to make sure that the >> visited resources will be paid for, which is why it needs >> authorization from the AAA infrastructure. > > FA-HA security association can also be dynamically created during the > network access authentication procedure. > > Alper > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Aug 17 11:10: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 1IM3RQ-0004MC-1T; Fri, 17 Aug 2007 11:08:48 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IM3RO-0004Ao-Pz for mip4-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 11:08:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3RO-000491-FG; Fri, 17 Aug 2007 11:08:46 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM3RO-0001tM-5Y; Fri, 17 Aug 2007 11:08:46 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 097D2175A5; Fri, 17 Aug 2007 14:41:08 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IM30d-00037s-Gd; Fri, 17 Aug 2007 10:41:07 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 17 Aug 2007 10:41:07 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mip4 chair , Internet Architecture Board , mip4 mailing list , RFC Editor Subject: [Mip4] Document Action: 'Mobile IPv4 RADIUS requirements' to Informational RFC X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org The IESG has approved the following document: - 'Mobile IPv4 RADIUS requirements ' as an Informational RFC This document is the product of the Mobility for IPv4 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-mip4-radius-requirements-04.txt Technical Summary This document defines a set of goals and a set of non-goals for RADIUS extensions to handle Mobile IPv4 key distribution. Among the goals are the definition of new attributes, backwards compatibility, and turning FAs and HAs into RADIUS clients. Among the non-goals are any RADIUS extensions to support security, transport reliability, or the size of the available message set. Together, the goals and non-goals serve to define and limit the scope of the Mobile IPv4 RADIUS work that will take place when this document is approved. Working Group Summary The document completed last call in the mip4 working group in May, 2007. It was also reviewed by selected members of the RADEXT working group Protocol Quality Jari Arkko has reviewed this specification for the IESG. Note to RFC Editor Section 3.1: In the first and third bullet item, it appears appropriate that the word "required" be upper-cased to denote its use as a normative declaration. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Aug 21 06:30: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 1INQz0-0002HD-O6; Tue, 21 Aug 2007 06:29:10 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1INQyz-0002H3-KR for mip4-confirm+ok@megatron.ietf.org; Tue, 21 Aug 2007 06:29:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INQyz-0002Gv-9i for mip4@ietf.org; Tue, 21 Aug 2007 06:29:09 -0400 Received: from cassius.ee.usyd.edu.au ([129.78.13.49]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INQyx-0000e4-PD for mip4@ietf.org; Tue, 21 Aug 2007 06:29:08 -0400 Received: from ee.usyd.edu.au (localhost [127.0.0.1]) by cassius.ee.usyd.edu.au (8.13.6/8.13.6) with SMTP id l7LAQALu021523 for ; Tue, 21 Aug 2007 20:26:11 +1000 (EST) From: Guo Qiang Mao Received: from 220.233.174.32 (SquirrelMail authenticated user guoqiang) by www.ee.usyd.edu.au with HTTP; Tue, 21 Aug 2007 20:26:11 +1000 (EST) Message-ID: <24269.220.233.174.32.1187691971.squirrel@www.ee.usyd.edu.au> Date: Tue, 21 Aug 2007 20:26:11 +1000 (EST) To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.7) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-ElectricalEngineering-MailScanner-Information: Please contact the ISP for more information X-ElectricalEngineering-MailScanner: Found to be clean X-ElectricalEngineering-MailScanner-From: guoqiang@ee.usyd.edu.au Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cassius.ee.usyd.edu.au id l7LAQALu021523 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [Mip4] =?iso-8859-1?q?Call_for_Chapters_on_Localization_in_Wirel?= =?iso-8859-1?q?ess_Sensor_Networks_=96_Deadline_Approaching?= X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org [Our apologizes if you receive multiple copies of this CFP] [CFC] Call for Chapters on Localization in Wireless Sensor Networks =96 Deadline Approaching Book Title: Localization Algorithms and Strategies for Wireless Sensor Networks: Monitoring and Surveillance Techniques for Target Tracking Book webpage: http://www.ee.usyd.edu.au/~guoqiang/Research/BookOnLocalizationAlgorithms= .htm Editors: Guoqiang Mao and Baris Fidan Publishing Details: This book will be published by IGI Global http://www.igi-pub.com/ in 2008. Introduction Wireless sensor networks (WSNs) constitute a significant technology of today, attracting considerable research interest from various disciplines. Self-localization capability is a highly desirable characteristic of wireless sensor networks. In environmental monitoring applications such a= s bush fire surveillance, water quality monitoring and precision agriculture, the measurement data are meaningless without knowing the location from where the data are obtained. Moreover, location estimation may enable a myriad of applications such as inventory management, intrusion detection, road traffic monitoring, health monitoring, reconnaissance and surveillance. This book intends to cover the fundamental theories, the state-of-the-art research findings, and experimental studies and applications of WSN localization techniques. We expect the book to serve as a valuable and comprehensive reference for students, educators, researchers, and engineers who work in this rapidly evolving field. Recommended topics (not limited to) =95 Measurements techniques used in WSN localization =95 WSN localization algorithms =95 Fundamental theories in WSN localization =95 Graph theoretical analysis of characteristics of WSNs and application= of such analysis to WSN localization =95 Monitoring and surveillance techniques =95 Experimental studies =95 Applications of WSN localization techniques Invitation Prospective chapter authors are invited to submit, initially, a 1-2 page single column, single space proposal describing the proposed chapter in M= S Word or RTF format. The proposal should include the title, the abstract, the chapter organization, number of pages of the final manuscript intende= d to be submitted and contact authors. Each chapter is planned to fit 15-25 letter-size pages (single column, single space, 12 pt font). However, (only) fundamental chapter proposals of comprehensive review/survey style will be allowed to be up to 40 pages. Chapter templates will be provided once the proposals are submitted and acceptance decisions are made. Important Dates =95 Submission of Chapter Proposals: September 15, 2007 =95 Notification of Proposal Acceptance: October 15, 2007 =95 Full Chapter Submission: March 15, 2008 =95 Review Reports Due: May 15, 2008 =95 Final Version Submission: July 15, 2008 Contact =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 Please make correspondence and proposal submissions to: Dr Guoqiang Mao School of Electrical and Information Engineering The University of Sydney NSW 2006, Australia Email: guoqiang@ee.usyd.edu.au Dr Baris Fidan National ICT Australia Locked Bag 8001 Canberra ACT 2601, Australia Email: baris.fidan@nicta.com.au -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 30 08:07: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 1IQim4-0003Kl-9h; Thu, 30 Aug 2007 08:05:24 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IQim3-0003HG-B7 for mip4-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 08:05:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQim3-0003H5-0K; Thu, 30 Aug 2007 08:05:23 -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 1IQim1-0000y2-Gf; Thu, 30 Aug 2007 08:05:22 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l7UC5AcA007655; Thu, 30 Aug 2007 15:05:15 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 15:05:14 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 15:05:14 +0300 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: [Mip4] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture Date: Thu, 30 Aug 2007 15:05:12 +0300 Message-ID: <58357EDC7884E24BAD684C1B2D91F96D0601DBA0@trebe101.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] RE: Issue 3: Diameter MIP4 Application vs. RADIUSArchitecture Thread-Index: AcfUGyjk+uHvSBZCTZChfmfiOho9igAGdW0AATTc4eAACl8zMAABByOwACPqseAAOKQT0AABF7GwAAB0xyAAAjYAMAQRcaCw References: <6FC4416DDE56C44DA0AEE67BC7CA43711601FEFC@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA43711606FEEB@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA437116114603@zrc2hxm2.corp.nortel.com><6FC4416DDE56C44DA0AEE67BC7CA43711611482D@zrc2hxm2.corp.nortel.com> From: To: , , X-OriginalArrivalTime: 30 Aug 2007 12:05:14.0174 (UTC) FILETIME=[05B5C5E0:01C7EAFE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: mip4@ietf.org, Hannes.Tschofenig@gmx.net X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi all, Sorry for jumping in the thread but I fail to understand why we'd need to alter a MIPv4 initial retransmission timer due to a certain deployment model. If MIPv4 is deployed in such a way that the initial retransmission timer would need to be doubled, tripled,... then I'd say it is up to the service provider to provide such parameters. This is how 3GPP2 operators have solved it. Cheers, Markku=20 >-----Original Message----- >From: ext McCann Peter-A001034 [mailto:pete.mccann@motorola.com]=20 >Sent: 09 August, 2007 22:02 >To: Ahmad Muhanna; dime@ietf.org >Cc: mip4@ietf.org; Hannes Tschofenig >Subject: [Mip4] RE: Issue 3: Diameter MIP4 Application vs.=20 >RADIUSArchitecture > >Hi, Ahmad, > >Ahmad Muhanna wrote: >> 2. The point here is not about Diameter as an AAA protocol, however,=20 >> it is about the concept of coupling the MIPv4 control=20 >signaling to AAA=20 >> signaling. Which many people do not think it is a good idea and=20 >> believe that it is a deviation from RFC3344 initial MIPv4 >> registration procedure. Do not you agree? =20 > >No, I don't. Putting the Registration Request in the AMR is a feature. >It allows the registration to happen in one round-trip. >=20 >> 6. Actually, we are going to publish a new revision of this=20 >draft and=20 >> address the scenario of allocating a HA in the visited network. Have=20 >> you looked into the difference between the RADIUS and D-MIP4=20 >> performance in this scenario and what will happen if the MN happened >> to retransmit? =20 > >Obviously this scenario takes longer to process the RRQ and so=20 >the chance of hitting a retransmission is greater. >=20 >>> I agree that a Diameter (or RADIUS, for that matter) infrastructure=20 >>> might take more than 1 second to respond to an AMR or an=20 >>> Access-Request. It seems that the solution is to recommend a longer=20 >>> timeout value for the initial retransmission. Another=20 >solution would=20 >>> be to allow the MN to complete its registration successfully by=20 >>> receiving an RRP matching a previous RRQ (not just the most=20 >recently=20 >>> retransmitted one). >>>=20 >>> I don't think we should turn the MIP4 Diameter application into a=20 >>> 2-round-trips protocol. The goal of RFC4004 is to provide MIP=20 >>> registration in one round-trip. >>>=20 > >-Pete > > > >-- >Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html >Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Aug 30 08:53: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 1IQjUd-0007md-Id; Thu, 30 Aug 2007 08:51:27 -0400 Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1IQjUb-0007mS-Lt for mip4-confirm+ok@megatron.ietf.org; Thu, 30 Aug 2007 08:51:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQjUb-0007mK-AI; Thu, 30 Aug 2007 08:51:25 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQjUa-0007Xl-L9; Thu, 30 Aug 2007 08:51:25 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 30 Aug 2007 05:51:24 -0700 X-IronPort-AV: i="4.19,325,1183359600"; d="scan'208"; a="209326973:sNHT53498844" 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 l7UCpOlK030008; Thu, 30 Aug 2007 05:51:24 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l7UCpE9D010317; Thu, 30 Aug 2007 12:51:23 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 08:51:14 -0400 Received: from [192.168.1.100] ([10.86.242.165]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 08:51:13 -0400 In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024DA3E6@exchtewks2.starentnetworks.com> References: <7CCD07160348804497EF29E9EA5560D7024DA3E6@exchtewks2.starentnetworks.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47B81490-F3AE-4E43-80E7-683126B207F9@cisco.com> Content-Transfer-Encoding: 7bit From: Ralph Droms Subject: Re: [dhcwg] RE: [Mip4] draft-ietf-mip4-gen-ext-03.txt Date: Thu, 30 Aug 2007 08:51:12 -0400 To: "Chowdhury, Kuntal" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 30 Aug 2007 12:51:13.0902 (UTC) FILETIME=[72A2D8E0:01C7EB04] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4176; t=1188478284; x=1189342284; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20RE=3A=20[Mip4]=20draft-ietf-mip4-gen-ext-03 .txt |Sender:=20; bh=O1AkEkn4M4uGv8XefqIXQB4iOTCEiq4x+cnhYt20mN0=; b=Ej1VmU++/PzCYDmfnv5v9RFJ/wb7sfI26KdqFW6Id3CHox7l34rcqOAPOWEjHQ7dzdZC0VJ8 TnTipFL+X8EgzJuRhwOC6aa43l0LFNfWzg2ymdXH7xD1KlHQmG8Q378Md02BUfTHFy5xNUJGSf 1c1Ov4BpJhnk0IpLvHELaB720=; Authentication-Results: sj-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: dhcwg@ietf.org, mip4@ietf.org, McCann Peter-A001034 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Why is the use of DHCP over MIP4 a digression? You mentioned: * more messages * security Sounds to me like these issues would be worth exploring if they haven't been explored already. - Ralph On Aug 2, 2007, at Aug 2, 2007,7:00 PM, Chowdhury, Kuntal wrote: > Hi Pete, > > I think the source of the confusion is the use of DHCP options. The > initial version of this I-D did not propose to use DHCP options at > all. > The proposal contained a few possible host config parameters that we > would have defined. However, someone saw the light, and suggested that > instead of redesigning the host config options from scratch, why > not we > used the options and the format of the options carrying config info as > defined in DHCP. It made sense; hence we decided to accept that > approach. > > Now, I see that people are mixing the use of DHCP protocol with MIP4 > host config options. I think this is a digression that we should > avoid. > We need to understand the scope of the I-D. It does not rule out other > ways to do host configuration when the MN is using MIP4. It defines > _a_ > way that is Mobile IP specific. It is also the most efficient one from > the number of round trips point of view. > > When you say that running DHCP inside MIP4 tunnel allows for a single > protocol to be used whether the MN is at home or visiting, I have a > question. How is it possible for the MN to fetch config info from the > visited network when RT is negotiated and enforced at the FA? > > BTW, the approach specified in the draft-ietf-mip4-gen-ext-03.txt > allows > the use of a single protocol i.e. MIP4 to be used to fetch config info > from home and visited networks, not to mention with fewer number of > messages. > > Another issue that we need to think about the use of DHCP inside MIP4 > tunnel is security. We cannot prohibit the MN to run DHCPINFORM only, > right? The MN may start doing IP address config (lease and > release). How > to secure these DHCP messages? If we intend to only allow the MN to > send > DHCPINFORM, how do we prevent it from sending other DHCP messages? > > AFAIK, RFC 3118 is not widely implemented and used. Even if it is, we > can't expect the MIP4 implementations to start implementing RFC 3118 > just to get a few config info from the home domain. > > Regards, > Kuntal > >> -----Original Message----- >> From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] >> Sent: Tuesday, July 31, 2007 9:01 AM >> To: mip4@ietf.org; dhcwg@ietf.org >> Subject: [Mip4] draft-ietf-mip4-gen-ext-03.txt >> >> A question has arisen during the last call for >> draft-ietf-mip4-gen-ext-03.txt. >> >> The draft includes the following text: >> >> There are mechanisms >> such as DHCP for the mobile node to configure information from >> the >> foreign network, but not from the home network when the mobile > node >> is not attached to the home network. >> >> However, this may not be strictly true. In particular, >> it might be possible to use a DHCPINFORM message through >> the tunnel that was established with Mobile IP, thus eliminating >> the need to encode DHCP options inside Mobile IP messages. >> This would allow for a single configuration protocol to be >> used whether the MN is at home or visiting. >> >> I think we may have touched on this question during our last >> chartering discussion but we might not have explored all the >> ramifications. Please, if you have an opinion either way >> express it now and give some background as to why you think so. >> It is possible that we might turn this draft into a BCP-like >> document for how to configure and run DHCP over the tunnel >> to the home network. >> >> -Pete >> >> >> -- >> Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4- >> charter.html >> Supplemental site: http://www.mip4.org/ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/