From mip6-bounces@ietf.org Thu Feb 01 09:34:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCd0I-0007L0-GT; Thu, 01 Feb 2007 09:33:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCd0H-0007Ku-IE for mip6@ietf.org; Thu, 01 Feb 2007 09:33:33 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCd0B-0003uQ-JT for mip6@ietf.org; Thu, 01 Feb 2007 09:33:33 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1170340406!856426!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2186 invoked from network); 1 Feb 2007 14:33:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-153.messagelabs.com with SMTP; 1 Feb 2007 14:33:26 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l11EXLVf027218; Thu, 1 Feb 2007 07:33:25 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l11EXKYe026416; Thu, 1 Feb 2007 08:33:21 -0600 (CST) Message-ID: <45C1FA30.9050100@motorola.com> Date: Thu, 01 Feb 2007 15:33:20 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA References: <459A295C.5000005@motorola.com> <200701051650.JGI82841.BJLHVUXB@ysknet.co.jp> <45A26BA7.9060102@motorola.com> <200701091652.AAH56236.XJVBUBLH@ysknet.co.jp> <45A39A57.4020801@motorola.com> <200701161433.JBD35485.HLJBVUXB@ysknet.co.jp> <45C11700.4010400@azairenet.com> In-Reply-To: <45C11700.4010400@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Hello Kawaguchi-san, > > Sorry for the late reply. > > K.Kawaguchi wrote: >> The test specification interprets RFC3775 as follows now. >> >> a) Whether HA transmits BRR or not. >> >> => HA doesn't send BRR. > > That is correct. > >> b) How should HA do, when HA receives the packet of Echo Request with >> Home Address destination option from MN where HA has the binding >> cache entry. >> >> => HA replies Echo Reply wtih type2 routing headr. >> When HA sends the packet to MN, the processing of HA is the same >> as CN (10.4.2 refer to 9.3.2 in RFC3775). >> In view of the situation, when HA receives the packet from MN, >> the processing of HA is the same as CN (so 10.4.x seems to have >> missed the reference to 9.3.1.). > >> c) How should HA do, when HA receives the packet of Echo Request with >> Home Address destination option from node where HA hasn't the binding >> cache entry. >> >> => HA replies Binding Error(status 1). >> The reason is the same as b). > > No. If you want to interpret RFC 3775 accurately, the HA > should send a binding error (status 1) only if the home > address in the home address option does not belong to the > home prefix served by the HA. If the HA is the home agent > for that mobile node, the packet should be dropped (no > binding error is sent). No, same RFC says that MH Binding Error should be sent by _any_ node that doesn't understand (not only under the condition you mention above). Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 01 14:45:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HChr5-0002Sz-21; Thu, 01 Feb 2007 14:44:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HChr4-0002Sd-5D for mip6@ietf.org; Thu, 01 Feb 2007 14:44:22 -0500 Received: from 207.47.15.6.static.nextweb.net ([207.47.15.6] helo=mail2.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HChr2-0006l5-Qd for mip6@ietf.org; Thu, 01 Feb 2007 14:44:22 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 11:44:19 -0800 Message-ID: <45C24312.3030903@azairenet.com> Date: Thu, 01 Feb 2007 11:44:18 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "K.Kawaguchi" Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA References: <45A26BA7.9060102@motorola.com> <200701091652.AAH56236.XJVBUBLH@ysknet.co.jp> <45A39A57.4020801@motorola.com> <200701161433.JBD35485.HLJBVUXB@ysknet.co.jp> <45C11700.4010400@azairenet.com> <200702011219.HCC87083.JHBLBUXV@ysknet.co.jp> In-Reply-To: <200702011219.HCC87083.JHBLBUXV@ysknet.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2007 19:44:19.0970 (UTC) FILETIME=[5D892E20:01C74639] X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org K.Kawaguchi wrote: > - There are the home prefix 2001:DB8:1:1::/64 served by the HA. > - The HA has one binding cache entry for the MN-1. I assume the binding cache entry is for the MN's home address - 2001:DB8:1:1::1 > - The MN-1 home address is 2001:DB8:1:1::1. > - The MN-1 primary care-of address is 2001:DB8:100:100::1. > > How should the HA do, if the HA receives the following echo request with > the home address option. > > 1) The "well known" addresses in the echo request. > > Echo request with the home address option > src: MN primary care-of address (2001:DB8:100:100::1) > dst: HA address > home address option, home address: MN home address (2001:DB8:1:1::1) > > It is echo reply with the type2 routing header in my understanding. > src: HA address > dst: MN primary care-of address (2001:DB8:100:100::1) > type2 routing header, home address: MN home address (2001:DB8:1:1::1) Correct. > 2) The unknown address in the source address field. > > Echo request with the home address option > src: unknown address (2001:DB8:100:100::2) > dst: HA address > home address option, home address: MN home address (2001:DB8:1:1::1) > > It is binding error in my understanding. > src: HA address > dst: 2001:DB8:100:100::2 > BE header, status : 1 > home address: 2001:DB8:1:1::1 No. The packet is silently dropped, since the MN is sending a packet with a different CoA. It is not using a CoA that it has registered with the home agent. > 3) The unknown address in the home address field of the home address > option. It is in home prefix. > > Echo request with the home address option > src: MN primary Care-of Address (2001:DB8:100:100::1) > dst: HA Address > Home Address Option, home address: unknown address (2001:DB8:1:1::3) > > It is binding error in my understanding. > src: HA address > dst: 2001:DB8:100:100::1 > BE header, status : 1 > home address: 2001:DB8:1:1::3 Packet is dropped again. Sending a binding error with status 1 would make sense here, but if you want to interpret RFC 3775 accurately (since we are talking about a logo test), the packet should be silently dropped and binding error message should not be sent. > 4) The unknown address in the home address field of the home address > option. It isn't in home prefix. > > Echo request with the home address option > src: MN primary Care-of Address (2001:DB8:100:100::1) > dst: HA Address > Home Address Option, home address: unknown address (2001:DB8:4:4::4) > > It is binding error in my understanding. > src: HA address > dst: 2001:DB8:100:100::1 > BE header, status : 1 > home address: 2001:DB8:4:4::4 Correct. > 5) The unknown address in the source address field. > The unknown address in the home address field of the home address > option. It is in home prefix. > > Echo request with the home address option > src: unknown address (2001:DB8:500:500::5) > dst: HA Address > Home Address Option, home address: unknown address (2001:DB8:1:1::5) > > It is binding error in my understanding. > src: HA Address > dst: 2001:DB8:500:500::5 > BE header, status : 1 > home address: 2001:DB8:1:1::5 Packet is dropped again. Binding Error is not sent. > 6) The unknown address in the source address field. > The unknown address in the home address field of the home address > option. It isn't in home prefix. > > Echo request with the home address option > src: unknown address (2001:DB8:600:600::6) > dst: HA Address > home address in Home Address Option: unknown address (2001:DB8:6:6::6) > > It is binding error in my understanding. > src: HA Address > dst: 2001:DB8:600:600::6 > BE header, status : 1 > home address: 2001:DB8:6:6::6 Correct. Hope this helps. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 05 04:18:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDzyI-0007u1-HK; Mon, 05 Feb 2007 04:17:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDzyH-0007s5-3j for mip6@ietf.org; Mon, 05 Feb 2007 04:17:09 -0500 Received: from an-out-0708.google.com ([209.85.132.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDzyG-00038X-Bd for mip6@ietf.org; Mon, 05 Feb 2007 04:17:09 -0500 Received: by an-out-0708.google.com with SMTP id d30so890011and for ; Mon, 05 Feb 2007 01:17:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lrQGCS2x/zAsXd2E9kQrp7oGe5QyjaKW5SEBYNicAN4WpK6BHYt3txY5Lo6gHRdp50fg9m32b9GcFXBy8F5kV2G//wlr3HsOSNDjjiEtMnQCFhli1cFB8VrCqy5WggEpUKWlzPTVAOhMuTYRXMB7987oSx90BZi5uKXkpryoW2U= Received: by 10.115.51.1 with SMTP id d1mr572260wak.1170667027243; Mon, 05 Feb 2007 01:17:07 -0800 (PST) Received: by 10.114.57.8 with HTTP; Mon, 5 Feb 2007 01:17:07 -0800 (PST) Message-ID: Date: Mon, 5 Feb 2007 01:17:07 -0800 From: "eduardo segura" To: deri.ie-iswc2005@lists.deri.org, ambient-intelligence@lists.andrew.cmu.edu, mip6@ietf.org, mip4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4de5d7f989d6c039c8b887f1940f36ab Cc: Subject: [Mip6] CFP: SPAC 07 - Software Patterns: Addressing Challenges X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org My apologies for duplicates The First IEEE International Workshop on Software Patterns: Addressing Challenges SPAC 2007 Call for Papers Beijing, China, July 24-27, 2007 (in conjunction with COMPSAC 2007) http://conferences.computer.org/compsac/2007/ (COMPSAC 2007 Link) http://conferences.computer.org/compsac/2007/workshops/SPAC (Workshop Link= -1) http://www.engr.sjsu.edu/~fayad/workshops/COMPSAC07 (Workshop Link-2) http://www.vrlsoft.com/workshops/SPAC07 (WorkshopLink-3) THEME OF THE WORKSHOP As software increases in size and becomes more complex and costly, the need for techniques to ease software development is likewise increasing. Over the last decade, pattern community has evolved and received more interest in both academia and industry. Developing software using patterns holds the promise to reduce the cost and condensing the time of developing software systems, while simultaneously maintaining the quality of these systems. However, the potential of using patterns in developing systems is not fully realized and we need to address many challenges. For example, developing pattern repositories and catalogs, from which patterns can be retrieved and reused, still forms a challenge to software engineering, knowledge engineering and information systems communities. In addition, the need for (semi-) automated approaches for patterns mining and integration poses several open research questions to the software engineering community. Many think these challenges and others preclude the realization of the benefit of patterns as a reuse approach. This workshop aims at bringing together researchers and practitioners who are interested in resolving research challenges or who have practical experience with the different issues of patterns reuse and integration to discuss and advance the state-of-the-art and the state-of-the-practice in patterns reuse. Patterns have emerged as a promising reuse technique for both improving the quality and reducing the cost and time of software development. However, there is an immense belief that patterns have not fulfilled the expectations software developers wanted. Nevertheless, this belief does not rebuff the fact that patterns, as a concept, have the potential to play a key role in developing systems in the near future. This near future will never come unless there are serious attempts from both developers and researchers to investigate and provide creative solutions to current challenges that hinder utilizing patterns in practice. Among these challenges, this workshop focuses on investigating how to develop systems using patterns. We are sure that this topic will attract many developers and researchers in the field to participate in this workshop. WORKSHOP CHALLENGES The workshop will address software patterns challenges and debate several issues related to the following questions. We want researchers, framework developers, and application developers to discuss and debate the following questions related to: I. Pattern Creation and Development a. Leaving experience claim on the side, can you show how to create and develop patterns? b. What are the bases of creating patterns? c. Are there guidelines, methodologies, and/or processes for pattern creations and developments? d. Would you show an example or two? II. Patterns Selection Process: a. How does one select analysis and design patterns to build any system? b. What is the basis for selecting these patterns? c. If someone would like to build a system from patterns, how does she select patterns? d. What kind of patterns should one select to build a system from patterns? e. Is there a guideline for the selection process? III. Patterns Composition a. How does one integrate the selected patterns to build any system? or How does one compose any system from patterns? b. What are the various claims related to patterns composition? Are they true? c. Are there guidelines or techniques for patterns composition? Would you illustrate how to use them? IV. System of Patterns and General Reuse a. What do we mean when we say "systems of patterns"? b. Are the various claims related to building any system from patterns reasonable? c. How to develop pattern repositories and catalogs, from which patterns can be retrieved and reused? d. Are there automated approaches for patterns mining and integration? e. What other concepts will help build any system from patter= ns? . V. Impacts a. What is the impact of software stability on the above issu= es? Check any of the following websites for all columns and accepted position papers: http://conferences.computer.org/compsac/2007/workshops/SPAC (Main Link) www.engr.sjsu.edu/~fayad//workshops/COMPSAC07 (Workshop Link 2) www.vrlsoft.com/workshops/SPAC07 (Workshop Link 3 -- Under Construction) PAPER FORMAT AND SUBMISSIONS Detailed instructions for electronic paper submission and review process can be found at http://www.compsac.org/. People interested in participating in the workshop are requested to submit a short position paper (3-5 pages) or regular workshop paper (limited to 6 pages, double spaced, including figures) representing views and experiences relevant to the discussion topic. The title page should include a maximum 150-word abstract, five keywords, full mailing address, e-mail address, phone number, fax number, and a designated contact author. Papers will be selected depending on the originality, quality and relevance to the workshop. All submitted papers will be evaluated according to its originality, significance, correctness, presentation and relevance. Papers should be submitted electronically at: http://compsac.cs.iastate.edu/2007/SPAC/ . Please follow the instructions given by the web page. Camera Ready manuscripts must be submitted following IEEE conference proceedings style and guidelines. We encourage authors to present novel ideas, critique of existing work, and practical studies. Each accepted paper must be presented in person by the author or one of the authors. To foster lively discussions, each author is encouraged to present open questions and one or two main statements that will be discussed at the workshop. Submissions must be either MS-Word or RTF formats (please, DO NOT compress files). Depending on the number and spread of contributions, the scope may be narrowed to ensure effective communication and information sharing. Accepted position papers will be distributed to the participants before the workshop and made generally available through the WWW and FTP. Accepted papers will be published in the Workshop Proceedings of the 31st IEEE Computer Software and Applications Conference (COMPSAC 2007). At least one of the authors of each accepted paper must register as a full participant in the workshop to have the paper published in the COMPSAC 2007 Proceedings. The workshop selected best papers will be published in online Journal of International Journal Of Patterns (IJOP) =96 www.ijop.org WORKSHOP PARTICIPATION Interested in participating in the workshop without submission are requested to fill out the participation form and e-mail to the co-chair Haitham Hamza , Eduardo Segura , or to the workshop chair M.E. Fayad . ------------------------------------------------- PARTICIPATION FORM: Name and Affiliation: Position: Address: E-mail: URL: Areas of interest: Why would you like to participate? ------------------------------------------------- Please note that registration is required in order to participate in the workshop. An early registration discount is available. An overhead projector and a flipchart will be available. For more information please visit any of the following websites: http://conferences.computer.org/compsac/2007/workshops/SPAC (Main Link) www.engr.sjsu.edu/~fayad//workshops/COMPSAC07 (Workshop Link 2) www.vrlsoft.com/workshops/SPAC07 (Workshop Link 3 -- Under Construction) You may also contact the organizers. PROPOSED AGENDA 1. Welcome and introduction of participants. The organizers will first give a short overview of any open issues and of the main arguments arising out of the position papers. (Estimated time: 20-30 minutes) 2. Selected authors (representing the main trends) will be given 20 minutes to explain how their position relates to other positions and what each sees as the three major issues. We expect about 5-10 position papers. (Estimated time: 120-130 minutes) 3. The organizers will propose an identification of the major issues, and the participants will then discuss and select what they think are the hottest issues to be examined. (Estimated time: 10-15 minutes) 4. The participants will work for 70-95 minutes in small groups, with a designated moderator in each group. The groups will each deal with two different hot issues identified and will produce a summary in the form of points and counterpoints, showing either how several views are irreducibly opposed or how they are complementary. The number of groups will depend on the number of participants and number of issues selected; ideally there should be 3-5 p people in each group. (Estimated time: 60-70 minutes) 5. Each group will be given 10-15 minutes to present its findings to the workshop. A closing discussion will follow. The workshop report will be written on the basis of these findings and will include an agenda for future exploration and cooperation; it will be made available through the WWW and FTP. (Estimated time: 50-60 minutes for five teams) (Total estimated time: 285-315 minutes, i.e. about five hours +/- 15 minutes; lunch and breaks are not included.) IMPORTANT DATES We will be updated based on acceptance process Feb. 23, 2007: Full paper and short paper due Mar. 25, 2007: Decision notification (electronic) Apr. 30, 2007: Camera-ready copy and author registration due July 24-27, 2007: The workshop Date ORGANIZERS Chair and Point of Contact: Dr. M.E. Fayad Professor of Computer Engineering Computer Engineering Dept., College of Engineering San Jos=E9 State University One Washington Square, San Jos=E9, CA 95192-0180 Ph: (408) 924-7364, Fax: (408) 924-4153 E-mail: m.fayad@sjsu.edu, me fayad@gmail.com http://www.engr.sjsu.edu/fayad Co-Chairs: Dr. H.S. Hamza (Co-Chair) Faculty of Computers and Informatics, Information Technology Department Cairo University, Orman, Giza 12613 - Egypt Ph: (02) 335-8355 (office) E-mail: hshamza@gmail.com Eduardo M. Segura vrlSoft, Inc. 2065 Martin Ave., Suite 103 Santa Clara, CA 95050-2707 Phone/Fax: (408) 654-8972 E-mail: esegura@vrlsoft.com, eduardo.segura@sjsu.edu http://www.vrlsoft.com PROGRAM COMMITTEE Leonor Barroca Open University, England Sjaak Brinkkemper Utrecht University, the Netherlands Chia-Chu Chiang University of Arkansas at Little Rock, U= SA Rogerio Atem de Carvalho CEFET Campos, Brazil Andrea D'Ambrogio University of Roma TorVergata, Italy Issam Wajih Damaj Dhofar University, Salalah - Sultanate of Oman Khalil DRIRA LAAS-CNRS, France Islam A. M. El-Maddah Ain Shams University, Egypt M.E. Fayad San Jose State University & vrlSoft, Inc., USA Joao M. Fernandes Universidade do Minho, Portugal IanGraham Trireme International Ltd, London, England Jiang Guo California State University Los Angeles, USA Wilhelm Hasselbring University of Oldenburg, Germany Tarek Helmy King Fahd Univ. of Petroleum and Minerals, Saudi Arabia H.S. Hamza Cairo University, Egypt Pilar Herrero Universidad Polit=E9cnica de Madrid , Spain. Hoda Hosny American University in Cairo, Egypt Pao-Ann Hsiung National Chung Cheng University, Chiayi, TAIWAN Ali Jaoua University of Qatar, Qatar Mohamed-Khireddine KHOLLADI University of Constantine, France Dae-Kyoo Kim Oakland University, MI, USA Seok-Won Lee The University of North Carolina at Charlotte, USA Jeff Lei University of Texas at Arlington, USA Ricardo J. Machado Universidade do Minho, Portugal Ahmed Mahdy Texas A&M University - Corpus Christi, U= SA Michael Oudshoorn Montana State University, MT, USA Srini Ramaswamy University of Arkansas at Little Rock, U= SA Gustavo Rossi LIFIA, Facultad de Informatica, UNLP, Argentina Stuart Rubin SPAWAR, SSC-San Diego, USA Kannamma Sampath Coimbatore Institute of Technology, India Sanchez, Arturo University of North Florida, USA Kassem A. Saleh American University of Sharjah, UAE Arno Schmidmeier AspectSoft, Hersbruck, Germa= ny E.M. Segura San Jose State University & vrlSoft, Inc., USA Manolis Tzagarakis Research Academic Technology Institute (RACTI), Greece Laurence T. Yang St Francis Xavier University, Canada I-Ling Yen University of Texas at Dallas, USA _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 05 12:02:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7Dx-0000FE-UP; Mon, 05 Feb 2007 12:01:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7Dw-0000F8-P4 for mip6@ietf.org; Mon, 05 Feb 2007 12:01:48 -0500 Received: from tao.fdupont.fr ([82.236.136.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7Dv-0001ed-Af for mip6@ietf.org; Mon, 05 Feb 2007 12:01:48 -0500 Received: from tao.fdupont.fr (localhost [127.0.0.1]) by tao.fdupont.fr (8.13.5/8.13.5) with ESMTP id l15H1egs002320; Mon, 5 Feb 2007 18:01:41 +0100 (CET) Received: from tao.fdupont.fr (dupont@localhost) by tao.fdupont.fr (8.13.5/8.13.5/Submit) with ESMTP id l15H1b8x002316; Mon, 5 Feb 2007 18:01:39 +0100 (CET) Message-Id: <200702051701.l15H1b8x002316@tao.fdupont.fr> From: Francis Dupont To: Kazunori Miyazawa Subject: Re: [Mip6] Question about draft-sugimoto-mip6-pfkey-migrate In-reply-to: Your message of Mon, 05 Feb 2007 10:57:33 +0900. <45C68F0D.6040907@miyazawa.org> Date: Mon, 05 Feb 2007 18:01:37 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: mip6@ietf.org, Keiichi SHIMA X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: I agree. We should keep the kernel as simple as possible. But your approach is not simple on Linux, => this is not an argument. because Linux does not have an IP header and extension headers yet, => you don't need to have them, you only need to know what will be put in them. It will also have to fragment the packet => this is more than unnecessary! I understand that IKE needs to know a precise CoA for MIPv6 support. Why is it not enough to specify that the kernel sends SADB_ACQUIRE with the packet like [IPv6][DSTOPT(CoA)][MH] as SADB_X_MIPV6_PACKET or SADB_X_MIPV6BU_PACKET? => this is less general so you likely have to do it one day... SADB_X_EXT_PACKET is general approach, but it is costy for Linux. I think it is conflict with the principle on Linux. => the world shall become too warm for penguins too (:-). I think the functionality is an extension. The IPsec policy, in the kernel which support your extension, should have information that whether the SADB_ACQUIRE needs a packet copy or not. => I am not convinced it will be a real win in the long term but you can do what you want. Regards Francis.Dupont@fdupont.fr PS: the idea behind the general usage of SADB_X_EXT_PACKET is (quoting RFC 4306 page 25): To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first traffic selector in each of TSi and TSr a very specific traffic selector including the addresses in the packet triggering the request. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 06 01:10:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJVo-0005U2-EY; Tue, 06 Feb 2007 01:09:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDt6v-000607-7x for mip6@ietf.org; Sun, 04 Feb 2007 20:57:37 -0500 Received: from [203.178.140.4] (helo=miyazawa.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDt6t-000105-Ki for mip6@ietf.org; Sun, 04 Feb 2007 20:57:37 -0500 Received: from [IPv6:2001:200:1b0:2030::1] ([2001:200:1b0:2030::1]) (AUTH: PLAIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Mon, 05 Feb 2007 10:57:42 +0900 id 00046E36.45C68F16.0000146A Message-ID: <45C68F0D.6040907@miyazawa.org> Date: Mon, 05 Feb 2007 10:57:33 +0900 From: Kazunori Miyazawa User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mip6] Question about draft-sugimoto-mip6-pfkey-migrate References: <200701311026.l0VAQvOf019464@tao.fdupont.fr> In-Reply-To: <200701311026.l0VAQvOf019464@tao.fdupont.fr> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-Mailman-Approved-At: Tue, 06 Feb 2007 01:09:01 -0500 Cc: mip6@ietf.org, Keiichi SHIMA X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Francis Dupont wrote: > In your previous mail you wrote: > > I have a question about the PF_KEY extension draft (draft-sugimoto- > mip6-pfkey-migrate). > > The draft proposes SADB_ACQUIRE message extension to include the > entire (or the beginning of the) IP header that triggered the acquire > message. The reason of the extension described in the draft is to > extract the CoA of an MN that is used for IKE communication. > > The question is that, do we need to include the entire (or the > beginning of the) packet to the acquire message? If the goal is to > provide the CoA information to an IKE program, then why can't we > simply notify the address? > > => in fact you have the choice between to decode the packet in the kernel > or in the application. I am in favor of the first option for many > reasons including: > - it is better to keep the kernel as simple as possible > (i.e., KISS principle) > - we don't know a priori what applications will need. > > Including a raw packet has two drawbacks. > > 1. The IKE program that supports this extension has to parse the raw > IPv6 packet to extract a CoA. > I agree. We should keep the kernel as simple as possible. But your approach is not simple on Linux, because Linux does not have an IP header and extension headers yet, when acquiring IPsec SA. It will have to build up the packet to send SADB_ACQUIRE message (copying the data from user space, build up extenstion headers, and add an IPv6 header). It will also have to fragment the packet if necessary and the application will keep fragment headers and reassemble them to decode because the fragment header is one of the extension headers. > => someone has to do this. > > 2. Some kernel implementations do not have the final packet structure > when sending an ACQUIRE message. In these implementations, they only > have abstract information to construct the packet, and the packet > will be constructed just before it is sent. In this case, the kernel > must create a packet before sending an ACQUIRE message, that is not > necessary in their design. > > => to give the final structure doesn't matter as the decoding code is > supposed to be kernel dependent (even if there are no many choice and > it is easy to get one code working for many kernels). The only key point > is to give to the application enough information, the way they are > organized is a detail as soon as the application knows it! > I understand that IKE needs to know a precise CoA for MIPv6 support. Why is it not enough to specify that the kernel sends SADB_ACQUIRE with the packet like [IPv6][DSTOPT(CoA)][MH] as SADB_X_MIPV6_PACKET or SADB_X_MIPV6BU_PACKET? SADB_X_EXT_PACKET is general approach, but it is costy for Linux. I think it is conflict with the principle on Linux. I think the functionality is an extension. The IPsec policy, in the kernel which support your extension, should have information that whether the SADB_ACQUIRE needs a packet copy or not. Thank you, -- Kazunori Miyazawa _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 06 01:39:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJz0-00036k-0n; Tue, 06 Feb 2007 01:39:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJyy-00034T-8t for mip6@ietf.org; Tue, 06 Feb 2007 01:39:12 -0500 Received: from yskfw1.ysknet.co.jp ([210.169.255.3] helo=ksns.ks.ysknet.co.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HEJyw-0001lv-96 for mip6@ietf.org; Tue, 06 Feb 2007 01:39:12 -0500 Received: (qmail 18686 invoked from network); 6 Feb 2007 15:38:58 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 6 Feb 2007 15:38:58 +0900 To: vijay.devarapalli@azairenet.com Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA From: "K.Kawaguchi" References: <45A39A57.4020801@motorola.com> <200701161433.JBD35485.HLJBVUXB@ysknet.co.jp> <45C11700.4010400@azairenet.com> <200702011219.HCC87083.JHBLBUXV@ysknet.co.jp> <45C24312.3030903@azairenet.com> In-Reply-To: <45C24312.3030903@azairenet.com> Message-Id: <200702061538.BFC90683.XJBUVBHL@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Tue, 6 Feb 2007 15:38:57 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Thank you for your answer. But, I have not understood your answer yet. Please let me detail it down in addition for me. I enumerate two procedures in each situation though I think that the processing procedure of this packet is unrelated. Vijay Devarapalli wrote: > K.Kawaguchi wrote: > > - There are the home prefix 2001:DB8:1:1::/64 served by the HA. > > - The HA has one binding cache entry for the MN-1. > > I assume the binding cache entry is for the MN's home > address - 2001:DB8:1:1::1 Yes, it is so. > > - The MN-1 home address is 2001:DB8:1:1::1. > > - The MN-1 primary care-of address is 2001:DB8:100:100::1. > > > > How should the HA do, if the HA receives the following echo request with > > the home address option. > > > > 1) The "well known" addresses in the echo request. > > > > Echo request with the home address option > > src: MN primary care-of address (2001:DB8:100:100::1) > > dst: HA address > > home address option, home address: MN home address (2001:DB8:1:1::1) > > > > It is echo reply with the type2 routing header in my understanding. > > src: HA address > > dst: MN primary care-of address (2001:DB8:100:100::1) > > type2 routing header, home address: MN home address (2001:DB8:1:1::1) > > Correct. > > > 2) The unknown address in the source address field. > > > > Echo request with the home address option > > src: unknown address (2001:DB8:100:100::2) > > dst: HA address > > home address option, home address: MN home address (2001:DB8:1:1::1) > > > > It is binding error in my understanding. > > src: HA address > > dst: 2001:DB8:100:100::2 > > BE header, status : 1 > > home address: 2001:DB8:1:1::1 > > No. The packet is silently dropped, since the MN is sending > a packet with a different CoA. It is not using a CoA that it > has registered with the home agent. 2.1) If the home address is used as the key for searching the binding cache. 2.1 1) HA finds the binding cache entry to which the home address is corresponding. 2.1 2) However, the source address of the received packet is not corresponding to the care-of address of the binding cache entry. 2.1 3) HA silently drops the received packet. 2.1) If the care-of address is used as the key for searching the binding cache. 2.2 1) HA doesn't find the binding cache entry. 2.2 2) HA silently drops the received packet. > > 3) The unknown address in the home address field of the home address > > option. It is in home prefix. > > > > Echo request with the home address option > > src: MN primary Care-of Address (2001:DB8:100:100::1) > > dst: HA Address > > Home Address Option, home address: unknown address (2001:DB8:1:1::3) > > > > It is binding error in my understanding. > > src: HA address > > dst: 2001:DB8:100:100::1 > > BE header, status : 1 > > home address: 2001:DB8:1:1::3 > > Packet is dropped again. Sending a binding error with status > 1 would make sense here, but if you want to interpret RFC > 3775 accurately (since we are talking about a logo test), the > packet should be silently dropped and binding error message > should not be sent. I want to reflect it in the Logo test correctly interpreting RFC. Also, I want to reflect to the Logo the discussion and consensus on this ML if there is an inconvenient part on RFC. 3.1) If the home address is used as the key for searching the binding cache. 3.1 1) HA doesn't find the binding cache entry. 3.1 2) HA silently drops the received packet. 3.2) If the care-of address is used as the key for searching the binding cache. 3.2 1) HA finds the binding cache entry to which the care-of address is corresponding. 3.2 2) However, the home address of the home address destination option of the received packet is not corresponding to the home address of the binding cache entry. 3.2 3) HA silently drops the received packet. > > 4) The unknown address in the home address field of the home address > > option. It isn't in home prefix. > > > > Echo request with the home address option > > src: MN primary Care-of Address (2001:DB8:100:100::1) > > dst: HA Address > > Home Address Option, home address: unknown address (2001:DB8:4:4::4) > > > > It is binding error in my understanding. > > src: HA address > > dst: 2001:DB8:100:100::1 > > BE header, status : 1 > > home address: 2001:DB8:4:4::4 > > Correct. 4.1) If the home address is used as the key for searching the binding cache. 4.1 1) HA doesn't find the binding cache entry. 4.1 2) HA drops the received packet and sends the binding error. However, it silently drops in the case 3.1). 4.2) If the care-of address is used as the key for searching the binding cache. 4.2 1) HA finds the binding cache entry to which the care-of address is corresponding. 4.2 2) However, the home address of the home address destination option of the received packet is not corresponding to the home address of the binding cache entry. 4.2 3) HA drops the received packet and sends the binding error. However, it silently drops in the case 3.2). > > 5) The unknown address in the source address field. > > The unknown address in the home address field of the home address > > option. It is in home prefix. > > > > Echo request with the home address option > > src: unknown address (2001:DB8:500:500::5) > > dst: HA Address > > Home Address Option, home address: unknown address (2001:DB8:1:1::5) > > > > It is binding error in my understanding. > > src: HA Address > > dst: 2001:DB8:500:500::5 > > BE header, status : 1 > > home address: 2001:DB8:1:1::5 > > Packet is dropped again. Binding Error is not sent. 5.1) If the home address is used as the key for searching the binding cache. 5.1 1) HA doesn't find the binding cache entry. 5.1 2) HA silently drops the received packet. It is same as case 3.1). 5.2) If the care-of address is used as the key for searching the binding cache. 5.2 1) HA doesn't find the binding cache entry. 5.2 2) HA silently drops the received packet. It is same as case 2.2). > > 6) The unknown address in the source address field. > > The unknown address in the home address field of the home address > > option. It isn't in home prefix. > > > > Echo request with the home address option > > src: unknown address (2001:DB8:600:600::6) > > dst: HA Address > > home address in Home Address Option: unknown address (2001:DB8:6:6::6) > > > > It is binding error in my understanding. > > src: HA Address > > dst: 2001:DB8:600:600::6 > > BE header, status : 1 > > home address: 2001:DB8:6:6::6 > > Correct. 6.1) If the home address is used as the key for searching the binding cache. 6.1 1) HA doesn't find the binding cache entry. 6.1 2) HA drops the received packet and sends the binding error. However, it silently drops in the case 3.1). 6.2) If the care-of address is used as the key for searching the binding cache. 6.2 1) HA doesn't find the binding cache entry. 6.2 2) HA drops the received packet and sends the binding error. However, it silently drops in the case 3.2). Best regards --- Kiyoaki KAWAGUCHI _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 06 05:25:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HENUD-0008EU-NX; Tue, 06 Feb 2007 05:23:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HENUD-0008EP-5e for mip6@ietf.org; Tue, 06 Feb 2007 05:23:41 -0500 Received: from tao.fdupont.fr ([82.236.136.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HENUB-0000K2-PM for mip6@ietf.org; Tue, 06 Feb 2007 05:23:41 -0500 Received: from tao.fdupont.fr (localhost [127.0.0.1]) by tao.fdupont.fr (8.13.5/8.13.5) with ESMTP id l16ANVV1001698; Tue, 6 Feb 2007 11:23:31 +0100 (CET) Received: from tao.fdupont.fr (dupont@localhost) by tao.fdupont.fr (8.13.5/8.13.5/Submit) with ESMTP id l16ANTZC001693; Tue, 6 Feb 2007 11:23:30 +0100 (CET) Message-Id: <200702061023.l16ANTZC001693@tao.fdupont.fr> From: Francis Dupont To: Kazunori MIYAZAWA Subject: Re: [Mip6] Question about draft-sugimoto-mip6-pfkey-migrate In-reply-to: Your message of Tue, 06 Feb 2007 15:29:25 +0900. <45C82045.8020202@miyazawa.org> Date: Tue, 06 Feb 2007 11:23:29 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: mip6@ietf.org, Keiichi SHIMA X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: It means that it is a general IPsec stuff. Why don't you discuss it in IPsec ML but MIPv6? => in fact the right list is the departed PF_KEY list... Regards Francis.Dupont@fdupont.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 06 10:36:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESMj-0002eF-F1; Tue, 06 Feb 2007 10:36:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HESMi-0002eA-Oo for mip6@ietf.org; Tue, 06 Feb 2007 10:36:16 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HESMe-0001Qk-6u for mip6@ietf.org; Tue, 06 Feb 2007 10:36:16 -0500 Received: by nf-out-0910.google.com with SMTP id l36so216798nfa for ; Tue, 06 Feb 2007 07:36:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=g85Atkq5o3VIUpAh5fj/+CqzWpmgDzG3xtlWIrNbxKhcsB5XkIjjleLj8R1xyLXHo+EcL5VhOi1u8ur3pDp1doQb3wCv/xqrhZrWQqBsrSL1Z8YY+roEVKaHXoNGreJ3Ct5dUcgCQsrrfbmRergYTVvpzEsmhgH1zj8qitd244U= Received: by 10.48.217.11 with SMTP id p11mr346418nfg.1170776168868; Tue, 06 Feb 2007 07:36:08 -0800 (PST) Received: from ?IPv6:fd1b:2352:53b:1:20d:93ff:fe61:daae? ( [86.205.17.149]) by mx.google.com with ESMTP id o53sm2807608nfa.2007.02.06.07.36.07; Tue, 06 Feb 2007 07:36:08 -0800 (PST) In-Reply-To: <45C68F0D.6040907@miyazawa.org> References: <200701311026.l0VAQvOf019464@tao.fdupont.fr> <45C68F0D.6040907@miyazawa.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <9A8E1B10-41BD-40B8-BBC7-250AFA4A3705@gmail.com> Content-Transfer-Encoding: quoted-printable From: Arnaud Ebalard Subject: Re: [Mip6] Question about draft-sugimoto-mip6-pfkey-migrate Date: Tue, 6 Feb 2007 16:36:33 +0100 To: Kazunori Miyazawa X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Yves-Alexis Perez , mip6@ietf.org, Francis Dupont , Keiichi SHIMA X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Francis, Hi everyone, Le 5 f=E9vr. 07 =E0 02:57, Kazunori Miyazawa a =E9crit : > Francis Dupont wrote: >> In your previous mail you wrote: >> >> I have a question about the PF_KEY extension draft (draft-=20 >> sugimoto- >> mip6-pfkey-migrate). >> >> The draft proposes SADB_ACQUIRE message extension to include the >> entire (or the beginning of the) IP header that triggered the =20 >> acquire >> message. The reason of the extension described in the draft is to >> extract the CoA of an MN that is used for IKE communication. >> >> The question is that, do we need to include the entire (or the >> beginning of the) packet to the acquire message? If the goal =20 >> is to >> provide the CoA information to an IKE program, then why can't we >> simply notify the address? >> >> =3D> in fact you have the choice between to decode the packet in the =20= >> kernel >> or in the application. I am in favor of the first option for many >> reasons including: >> - it is better to keep the kernel as simple as possible >> (i.e., KISS principle) >> - we don't know a priori what applications will need. >> >> Including a raw packet has two drawbacks. >> >> 1. The IKE program that supports this extension has to parse =20 >> the raw >> IPv6 packet to extract a CoA. >> > > I agree. We should keep the kernel as simple as possible. But your =20 > approach is not > simple on Linux, because Linux does not have an IP header and =20 > extension headers yet, > when acquiring IPsec SA. Based on the draft and initial Racoon code provided by Francis =20 (developed for BSD), while implementing the MIGRATE and =20 SADB_X_EXT_PACKET for Linux Kernel (2.6.16.20), ipsec-tools (0.6.6) =20 and MIPL (CVS version), we (mostly Yves-Alexis in CC) also =20 encountered that problem and had to reconstruct a triggering packet =20 from scratch just to pass the CoA to the IKE daemon. Indeed, it is =20 pretty annoying ... IMHO, even if the problem is Linux specific, the discussion on the =20 extension is still interesting. Francis, is it possible to have some =20 comments on following points, just to clarify them: o the extension wants to be generic for future protocols that would =20 require a complete (obviously reconstructed in Linux case) packet to =20 be passed in the SADB_ACQUIRE. IMHO, keeping it generic is =20 interesting if there are many protocol that will benefit from that. =20 At the moment, only MIPv6 uses it. Is there any other planned ? o As said previously, this adds Mobile IPv6 specific code to the =20 kernel to add useless information to the PF_KEY messages (and also =20 XFRM in linux case) o from the IKE daemon standpoint (racoon in our case), the MIPv6 =20 specific code has to process the whole packet to figure that it =20 matches specific criteria and finally extract the CoA. This also adds =20= code where a simple handler associated with a MIPv6-specific "non-=20 error-prone" extension (like a TLV including the CoA) whould be =20 sufficient o If, at some point, some new (non MIPv6) mechanism wants to use the =20 information from the SADBX_EXT_PACKET packet in the IKE daemon, the =20 code that has been developed for MIPv6 will be modified (with =20 possible bug addition) where another TLV could be added to deal with =20 it in a generic way (like it is done in racoon at the moment for =20 other extensions) o same remark as previous point, but for the kernel. As a conclusion, should the SADB_X_EXT_PACKET be kept generic =20 (justified by its use in multiple mechanisms in the future) or =20 modified to avoid complete packet inclusion where it is not necessary =20= (i.e. keep only the required info). This is probably just a silly final remark but i wonder if such a =20 question has been raised when the discussion on the concept of DOI =20 has been defined for IKE/IPsec ;-) Regards, Arnaud. ps : i intend to spend quite some time in next monthes to update =20 racoon, mipl, ipsec patches we have for MIGRATE/SADB_X_EXT_PACKET for =20= current version of those kernel/userland parts. If you are interested =20= of already work on it, i'll be interested to know/work with you.= _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 06 15:50:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEXGQ-00028Z-5m; Tue, 06 Feb 2007 15:50:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEXGM-000289-LD; Tue, 06 Feb 2007 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEXGM-00067p-Dt; Tue, 06 Feb 2007 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 5EC34328F6; Tue, 6 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HEXGM-0005Th-99; Tue, 06 Feb 2007 15:50:02 -0500 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, 06 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-location-privacy-ps-05.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : IP Address Location Privacy and Mobile IPv6: Problem Statement Author(s) : R. Koodli Filename : draft-ietf-mip6-location-privacy-ps-05.txt Pages : 13 Date : 2007-2-6 In this document, we discuss Location Privacy as applicable to Mobile IPv6. We document the concerns arising from revealing Home Address to an on-looker and from disclosing Care of Address to a correspondent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-location-privacy-ps-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-location-privacy-ps-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-location-privacy-ps-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-6133920.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-location-privacy-ps-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-location-privacy-ps-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-6133920.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Tue Feb 06 23:17:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEeEf-0001To-4u; Tue, 06 Feb 2007 23:16:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJqS-0008Vx-76 for mip6@ietf.org; Tue, 06 Feb 2007 01:30:24 -0500 Received: from [203.178.140.4] (helo=miyazawa.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEJqQ-0006OJ-Jz for mip6@ietf.org; Tue, 06 Feb 2007 01:30:24 -0500 Received: from [IPv6:2001:240:2:0:205:4eff:fe42:f9b3] ([2001:240:2:0:205:4eff:fe42:f9b3]) (AUTH: LOGIN kazunori) by miyazawa.org with esmtp; Tue, 06 Feb 2007 15:30:33 +0900 id 00046E2F.45C82089.000073EB Message-ID: <45C82045.8020202@miyazawa.org> Date: Tue, 06 Feb 2007 15:29:25 +0900 From: Kazunori MIYAZAWA User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mip6] Question about draft-sugimoto-mip6-pfkey-migrate References: <200702051701.l15H1b8x002316@tao.fdupont.fr> In-Reply-To: <200702051701.l15H1b8x002316@tao.fdupont.fr> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-Mailman-Approved-At: Tue, 06 Feb 2007 23:16:44 -0500 Cc: mip6@ietf.org, Keiichi SHIMA X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello Francis, Francis Dupont wrote: > In your previous mail you wrote: > > I agree. We should keep the kernel as simple as possible. But your > approach is not simple on Linux, > > => this is not an argument. > > because Linux does not have an IP header and extension headers yet, > > => you don't need to have them, you only need to know what will be put > in them. > But does EXT_PACKET need to extract those headers, doesn't it? The Linux kernel which support the extension must copy and build the contents to extract the headers. No? > It will also have to fragment the packet > > => this is more than unnecessary! > I feel SADB_X_EXT_PACKET part of the current draft is too ambiguous to understand what should be contained and what form is used. It only describes that it contains a triggering packet. And authors recommend enough of the beginning of it. So, what is enough? OK, I know it is not fragmented. > I understand that IKE needs to know a precise CoA for MIPv6 support. > Why is it not enough to specify that the kernel sends SADB_ACQUIRE with > the packet like [IPv6][DSTOPT(CoA)][MH] as SADB_X_MIPV6_PACKET or > SADB_X_MIPV6BU_PACKET? > > => this is less general so you likely have to do it one day... > Yes it is less general. But the draft is "PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE". I think the generality of what you mean is beyound the scope of the document because I read that SADB_X_EXT_PACKET extension will be applied not only Moble IPv6 BU but also other general traffic such as TCP, UDP and so on. > SADB_X_EXT_PACKET is general approach, but it is costy for Linux. > I think it is conflict with the principle on Linux. > > => the world shall become too warm for penguins too (:-). > Is it the daemon's work? ;-) > I think the functionality is an extension. The IPsec policy, in the kernel > which support your extension, should have information that whether the > SADB_ACQUIRE needs a packet copy or not. > > => I am not convinced it will be a real win in the long term but you can > do what you want. > > Regards > > Francis.Dupont@fdupont.fr > > PS: the idea behind the general usage of SADB_X_EXT_PACKET is > (quoting RFC 4306 page 25): > > To enable the responder to choose the appropriate range in this case, > if the initiator has requested the SA due to a data packet, the > initiator SHOULD include as the first traffic selector in each of TSi > and TSr a very specific traffic selector including the addresses in > the packet triggering the request. It means that it is a general IPsec stuff. Why don't you discuss it in IPsec ML but MIPv6? Then you will write how to use/parse the extension for MIPv6 in your draft. Thank you, -- Kazunori Miyazawa _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 07 00:55:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEflb-0001is-Nv; Wed, 07 Feb 2007 00:54:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEfla-0001in-1Y for mip6@ietf.org; Wed, 07 Feb 2007 00:54:50 -0500 Received: from otm-mgo01.iij.ad.jp ([210.138.20.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEflY-0001Xk-83 for mip6@ietf.org; Wed, 07 Feb 2007 00:54:49 -0500 Received: OTM-MO(otm-mgo01) id l175sQMd002549; Wed, 7 Feb 2007 14:54:26 +0900 (JST) Received: OTM-MIX(otm-mix01) id l175sPxQ073354; Wed, 7 Feb 2007 14:54:26 +0900 (JST) Received: from [127.0.0.1] (keiichi00-4.osaka.iij.ad.jp [192.168.64.45]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp01) id l175sOm7009202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Feb 2007 14:54:25 +0900 (JST) In-Reply-To: <45C82045.8020202@miyazawa.org> References: <200702051701.l15H1b8x002316@tao.fdupont.fr> <45C82045.8020202@miyazawa.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <758463BB-456A-43FB-B51C-72C4EC5F5D2A@iijlab.net> From: Keiichi SHIMA Subject: Re: [Mip6] Question about draft-sugimoto-mip6-pfkey-migrate Date: Wed, 7 Feb 2007 14:54:23 +0900 To: Kazunori MIYAZAWA , DUPONT Francis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1611106222==" Errors-To: mip6-bounces@ietf.org --===============1611106222== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6--753061224; protocol="application/pkcs7-signature" --Apple-Mail-6--753061224 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello Francis, Kazunori, all, On 2007/02/06, at 15:29, Kazunori MIYAZAWA wrote: >> I understand that IKE needs to know a precise CoA for MIPv6 >> support. >> Why is it not enough to specify that the kernel sends >> SADB_ACQUIRE with >> the packet like [IPv6][DSTOPT(CoA)][MH] as SADB_X_MIPV6_PACKET or >> SADB_X_MIPV6BU_PACKET? >> >> => this is less general so you likely have to do it one day... >> > > Yes it is less general. But the draft is "PF_KEY Extension as an > Interface between > Mobile IPv6 and IPsec/IKE". > I think the generality of what you mean is beyound the scope of the > document > because I read that SADB_X_EXT_PACKET extension will be applied not > only Moble IPv6 BU > but also other general traffic such as TCP, UDP and so on. I don't like the above idea that notifying partial information to user space. It requires both kernel and IKE to deal with Mobile IPv6 specific issues. Instead, the ACQUIRE message should notify user programs of the end point address for the IKE communication only when the address is different from the SA's endpoint address. This makes user space program simpler and independent from Mobile IPv6. The IKE program can just use the specified address whenever such an alternate address is specified in the ACQUIRE message. There is no judgement in whether the packet is for MIP or not in the IKE program. I don't oppose defining EXT_PACKET. Such a low-level data is useful in some cases (I don't have any idea of such cases right now, anyway), similar to the raw IP socket mechanism is useful for very general packet processing cases. But, in this case (suggesting a different address for IKE communication), I think defining a dedicated option for this purpose is better. Regards, --- Keiichi SHIMA IIJ Research Laboratory WIDE Project --Apple-Mail-6--753061224 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKbjCCBF8w ggJHoAMCAQICAhIQMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAkpQMRUwEwYDVQQKEwxXSURF IFByb2plY3QxHzAdBgNVBAMTFm1lbWJlcnMgb3JpZW50ZWQgQ0EgMDIwHhcNMDYwNjEyMDQ1NTA5 WhcNMDcwNjMwMjM1OTU5WjBkMQswCQYDVQQGFAJKUDEVMBMGA1UEChQMV0lERSBQcm9qZWN0MRsw GQYDVQQDFBIwMzI4IEtlaWljaGkgU2hpbWExITAfBgkqhkiG9w0BCQEUEmtlaWljaGlAaWlqbGFi Lm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu6pTSPQTKzeSygFymRWYipFcZRaePRSU nruo6RtpQuNgDyUKvaMOa1KuNWRPYHp28hoWYe0YBrGj5SdHH2A3wbJ2zP5cXQFgMJMxJXhcWuSu +Foo7n9T1+yFjuc37Us9N4LoXZaM3krFqBHz2XSUCSigzTstdkIXWPwxDg+db4MCAwEAAaOBvTCB ujAOBgNVHQ8BAQAEBAMCBLAwIAYDVR0RAQEABBYwFIESa2VpaWNoaUBpaWpsYWIubmV0MDYGA1Ud HwEBAAQsMCowKKAmoCSGImh0dHA6Ly93d3cubW9jYS53aWRlLmFkLmpwL2NybC5jcmwwIgYDVR0j AQEABBgwFoAUOM7FCTrTDVTyVXHmSMda90Tf6bowKgYDVR0lAQEABCAwHgYIKwYBBQUHAwQGCCsG AQUFBwMDBggrBgEFBQcDAjANBgkqhkiG9w0BAQUFAAOCAgEAlB3DdeJJZ1gJh4sszEgoUg9DIHRG eaotuAi5FfGkd+KmzEARKYvgfh1A8AVAoHISFvavv0OD9w9dmzGyAmNUTBUsSMeH/5XiLuWJPbjU 3bVK467oyDEFaA+XFJurRY6RuPb4afHoi+aCHtY/pmcGCCSQPKnOuN8BviNLp/haDQyPVVwA+9it s7PwUArSkPnkBo1GXk4FSFDkijbw6zzJkXePBLHkE3QcFBYIo0woy6P2NFFYz8nPmd8M8qyT0Yh8 A9g0UVxvcWk4gUaJP0AeZ8/raNCr7eXBMByhDx5FSvparc21zEmQ5MnCVduDuM9eM8Qc8zFqzTzg mmZza69jiiq98kL1yFqjfL4+Nu7+N9D8Q/NuaIYLd9E++s20X9Kb7dW1xqMS1E30I8ZZnIwu2Fox ZRziQnKHkatDFBI+zuNY3+nIcE8bvzm/Y36xwk2GhN8p707CsT5i17ZCzkvriCdkE13riXNhXDOe qGR6Kj1aZLLBxHeLvFUa72q65+ShesszO6lOxf66auFbXYsOfzIUhG3z5YmM6Lk5NtJom6F7Drob jPjyDv2zZoGNGdIqbDbOaFkmBEYchuToVMNzYk6v6d+v4A/MrnGlexgQbzfgC0Ld32NwPlDDGFnO LPjaEZ19bFK65rWjWwEyLsO15GD7jotBrDU5yngkhu15RKowggYHMIID76ADAgECAgIJFjANBgkq hkiG9w0BAQUFADA+MQswCQYDVQQGEwJKUDEVMBMGA1UEChMMV0lERSBQcm9qZWN0MRgwFgYDVQQD Ew9XSURFIFJPT1QgQ0EgMDIwHhcNMDYwNTE4MTMzNTM2WhcNMTYwNjMwMjM1OTU5WjBFMQswCQYD VQQGEwJKUDEVMBMGA1UEChMMV0lERSBQcm9qZWN0MR8wHQYDVQQDExZtZW1iZXJzIG9yaWVudGVk IENBIDAyMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA4BYQZ8z3YdyJUt0ZbDh0+rVf fpf/Aw2J2GKNLy4fMIGpEhjS+OhAPC9TUH6rNVV2AR6myr94stzWhGY++bZjd7/oYYRLa+tCtUKa Om49ibS8CHSqfeR/Yb0YHKTrHCaAu2PUw6kENGZ3bDCiMbuDPkPLVkYuN3rSRp3qHd1XJ8DZ2bTX DbW3cwVqHFxKjVf6mdBInlL8pMs9z4T9GNpcqQO1i7Uk467KLZYbi1W1d5m23Jodr/7/y08bc078 ppWE3dP9eNEysmRxdIvKMgTHfTjtYN3ZhnfUEsYoJ6W9flc9Qoe+5UqdBt+O5ruJM3m1viWf+Rs8 xvvs9ZnodrqaxAIDwgmgpHePLCV2Qc/Fix3vkLY2Rt9KXeRCjLOzgdCYhtuJI42hY/l9dJjrRRK/ Qo5jABzbRRJzCavDlqS25q1OXenrO64nU+7T92PfFeOv1ORg5PcCSoY0dIzN9lcL51yb2PLn3cUx ya4itIYV9MHFXaIDM4inLLmBUR/0xD4Q+Ju1Zqd5n+uK5lCrQ48+kMPKbrDyrDyvqHYTo8XRuyAU Z1F56NJFv6umd+/m0ADC1M7Q9HNXwt8dRZyvVgH8l4teYu9We32NtZ7H8dyNaa34R2zs1bP2ftDT Au//Bi/3u47JTSJ6M1zE6lsc7OwP6c32okaCRCwayxVYi+FgNdUCAwEAAaOCAQYwggECMA8GA1Ud EwEB/wQFMAMBAf8wDgYDVR0PAQEABAQDAgH+MFsGA1UdIAEBAARRME8wTQYJKoMIjJwYAQECMEAw PgYIKwYBBQUHAgEWMmh0dHA6Ly9tb2NhLndpZGUuYWQuanAvbW9jYV9ndWlkZS9tb2NhX3BvbGlj eS5odG1sMDwGA1UdHwEBAAQyMDAwLqAsoCqGKGh0dHA6Ly93d3cud2lkZS5hZC5qcC9jYS93aWRl cm9vdGNybC5jcmwwIAYDVR0OAQEABBYEFDjOxQk60w1U8lVx5kjHWvdE3+m6MCIGA1UdIwEBAAQY MBaAFAzMoku5z7HsuNTr5KwJl0+xojExMA0GCSqGSIb3DQEBBQUAA4ICAQAKZpGub2X1UG9aXuAS P1MsRJtlgcataxapi6Lbox+8/5nrLXA6M5+FSD/3wjO96KEdv+KGK4WIE6AAsGKdH0dFE8jgzGVw uyoyXZg+UWhFrCMB3lbNfY9UsTBJfVx1TlMC1BXaT5qKCgp2N5dF6s2yeNa1kgGvR+xDkxNGDf6q 3xcN3QiC9ofyUyeRaZEacTjUp7bo4VREFtv3txyocbT6B961inhUS3PZNx6nIzJqiZA2CX/QGrlg 7uE1EoXgSJ+N77MdasX5Tl69Cb+fJCAdlbji1LAgWLEPXM0kHyYnfsLHfEXo4bCRdpN+GpPvqyhW DOk8ZEmrzYglsK38KIIG4Mp0tUoj25nzXhHnkNt0OCLSvzPcTopabRaPl4MnvQQ1tGsKbSafUBR5 gzdjA/f/o9bQKYwZC+fP8Gu50Ib4sYc5BbXEZdUx0Pjc/1nbIuM0t1YFrfLOiWP+Ar0x/WuPrtLZ gUyRnVBVyHm73be8T9wfE31aJw9E+2a92cjrp0lyCfWoCKjHGxdsPFvPIg1gKVG/IlgKeKEnKu1N O4PmD//LW/7p6A5V/W1vGZn8jI9ErwVz2cMiyJJfRVaviV5TcC58vrREH6qB9LfJwA7jy4CRu1oP GsaQRg5ZTMaV1JZ5cFBNHKcJiSDPTqVdKPkjmSUVUlYvEN+08pPGK/4KcTGCAgwwggIIAgEBMEsw RTELMAkGA1UEBhMCSlAxFTATBgNVBAoTDFdJREUgUHJvamVjdDEfMB0GA1UEAxMWbWVtYmVycyBv cmllbnRlZCBDQSAwMgICEhAwCQYFKw4DAhoFAKCCARcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwMjA3MDU1NDI0WjAjBgkqhkiG9w0BCQQxFgQUaTJiDqwWuIzP UEfiEKK6KvGnjcEwWgYJKwYBBAGCNxAEMU0wSzBFMQswCQYDVQQGEwJKUDEVMBMGA1UEChMMV0lE RSBQcm9qZWN0MR8wHQYDVQQDExZtZW1iZXJzIG9yaWVudGVkIENBIDAyAgISEDBcBgsqhkiG9w0B CRACCzFNoEswRTELMAkGA1UEBhMCSlAxFTATBgNVBAoTDFdJREUgUHJvamVjdDEfMB0GA1UEAxMW bWVtYmVycyBvcmllbnRlZCBDQSAwMgICEhAwDQYJKoZIhvcNAQEBBQAEgYAZ4yr2b3TtZTmDm/Qs 909RZCiuHXigB7vi4AE7jv20RR3ED4dKa0fQrhKcJStzTt4msQiS9EpoKJT8HDQ8gBCt9shjf5+C mQrrNBBW7LY6naopOE6zRSt7A8zRnwQlHGLHGfwsbT3x4SRNEEHGiDtdDthqod1C9AKN6lrB62cS ZQAAAAAAAA== --Apple-Mail-6--753061224-- --===============1611106222== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1611106222==-- From mip6-bounces@ietf.org Wed Feb 07 03:10:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEhrW-00065F-EH; Wed, 07 Feb 2007 03:09:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEhrV-00064c-SJ for mip6@ietf.org; Wed, 07 Feb 2007 03:09:05 -0500 Received: from tao.fdupont.fr ([82.236.136.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEhrU-0001Jl-Am for mip6@ietf.org; Wed, 07 Feb 2007 03:09:05 -0500 Received: from tao.fdupont.fr (localhost [127.0.0.1]) by tao.fdupont.fr (8.13.5/8.13.5) with ESMTP id l1788U7a002983; Wed, 7 Feb 2007 09:08:31 +0100 (CET) Received: from tao.fdupont.fr (dupont@localhost) by tao.fdupont.fr (8.13.5/8.13.5/Submit) with ESMTP id l1788Qm5002979; Wed, 7 Feb 2007 09:08:27 +0100 (CET) Message-Id: <200702070808.l1788Qm5002979@tao.fdupont.fr> From: Francis Dupont To: Arnaud Ebalard Subject: Re: [Mip6] Question about draft-sugimoto-mip6-pfkey-migrate In-reply-to: Your message of Tue, 06 Feb 2007 16:36:33 +0100. <9A8E1B10-41BD-40B8-BBC7-250AFA4A3705@gmail.com> Date: Wed, 07 Feb 2007 09:08:26 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Yves-Alexis Perez , mip6@ietf.org, Keiichi SHIMA X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: Based on the draft and initial Racoon code provided by Francis (developed for BSD), while implementing the MIGRATE and SADB_X_EXT_PACKET for Linux Kernel (2.6.16.20), ipsec-tools (0.6.6) and MIPL (CVS version), we (mostly Yves-Alexis in CC) also encountered that problem and had to reconstruct a triggering packet from scratch just to pass the CoA to the IKE daemon. Indeed, it is pretty annoying ... => in fact it is a bit more than just the CoA because one has to recognize a home registration binding update, perhaps not generated by the kernel, and there can be more than one home address, etc. So we come back to the first point of this thread: what (the kernel or the KMP) is the entity doing the decoding. IMHO, even if the problem is Linux specific, the discussion on the extension is still interesting. Francis, is it possible to have some comments on following points, just to clarify them: o the extension wants to be generic for future protocols that would require a complete (obviously reconstructed in Linux case) packet to be passed in the SADB_ACQUIRE. => I don't know if we'll really need something complete but: - we can't know exactly what will be needed, obviously the infos from the kernel itself are in the PCB but not the whole PCB. - again the decoding should be performed by the application. Linux is a case where this argument is not very good because it seems to decode the packet or to construct it have the same complexity. IMHO, keeping it generic is interesting if there are many protocol that will benefit from that. At the moment, only MIPv6 uses it. Is there any other planned ? => IKEv2 first TS pair. o As said previously, this adds Mobile IPv6 specific code to the kernel to add useless information to the PF_KEY messages (and also XFRM in linux case) => the purpose is to be not Mobile IPv6 specific. o from the IKE daemon standpoint (racoon in our case), the MIPv6 specific code has to process the whole packet to figure that it matches specific criteria and finally extract the CoA. This also adds code where a simple handler associated with a MIPv6-specific "non- error-prone" extension (like a TLV including the CoA) whould be sufficient => you have two arguments here: specific/general and kernel/user mode. For the first one the SADB_X_EXT_PACKET goal is to be reused for IKEv2. For the second one user mode is better at the exception of Linux. o If, at some point, some new (non MIPv6) mechanism wants to use the information from the SADB_X_EXT_PACKET packet in the IKE daemon, the code that has been developed for MIPv6 will be modified (with possible bug addition) where another TLV could be added to deal with it in a generic way (like it is done in racoon at the moment for other extensions) => I tried to anticipate the need of a second similar extension or decoder code. o same remark as previous point, but for the kernel. As a conclusion, should the SADB_X_EXT_PACKET be kept generic (justified by its use in multiple mechanisms in the future) or modified to avoid complete packet inclusion where it is not necessary (i.e. keep only the required info). This is probably just a silly final remark but i wonder if such a question has been raised when the discussion on the concept of DOI has been defined for IKE/IPsec ;-) => the DOI was an attempt to share KMPs for other things than IPsec. It clearly failed but perhaps not for good reasons... ps : i intend to spend quite some time in next monthes to update racoon, mipl, ipsec patches we have for MIGRATE/SADB_X_EXT_PACKET for current version of those kernel/userland parts. If you are interested of already work on it, i'll be interested to know/work with you. => I believe we really need an IKE/IPsec capable MIPL. This already exists for SHISA even it is not (yet?) distributed. BTW don't forget a good documentation with examples as the main issue is to get the right config. I work with racoon2/IKEv2, I can help you... Regards Francis.Dupont@fdupont.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 07 03:34:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEiGC-0000mF-NO; Wed, 07 Feb 2007 03:34:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEiGB-0000mA-90 for mip6@ietf.org; Wed, 07 Feb 2007 03:34:35 -0500 Received: from tao.fdupont.fr ([82.236.136.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEiG9-0000U2-QP for mip6@ietf.org; Wed, 07 Feb 2007 03:34:35 -0500 Received: from tao.fdupont.fr (localhost [127.0.0.1]) by tao.fdupont.fr (8.13.5/8.13.5) with ESMTP id l178YQHB003222; Wed, 7 Feb 2007 09:34:27 +0100 (CET) Received: from tao.fdupont.fr (dupont@localhost) by tao.fdupont.fr (8.13.5/8.13.5/Submit) with ESMTP id l178YOPE003218; Wed, 7 Feb 2007 09:34:25 +0100 (CET) Message-Id: <200702070834.l178YOPE003218@tao.fdupont.fr> From: Francis Dupont To: Kazunori MIYAZAWA Subject: Re: [Mip6] Question about draft-sugimoto-mip6-pfkey-migrate In-reply-to: Your message of Tue, 06 Feb 2007 15:29:25 +0900. <45C82045.8020202@miyazawa.org> Date: Wed, 07 Feb 2007 09:34:24 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: mip6@ietf.org, Keiichi SHIMA X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: > because Linux does not have an IP header and extension headers yet, > > => you don't need to have them, you only need to know what will be put > in them. > But does EXT_PACKET need to extract those headers, doesn't it? The Linux kernel which support the extension must copy and build the contents to extract the headers. No? => IMHO we only have to make the content of SADB_X_EXT_PACKET system dependent with a default to the real content at this (i.e., SPD looking up for outgoing traffic) phase. > It will also have to fragment the packet > > => this is more than unnecessary! > I feel SADB_X_EXT_PACKET part of the current draft is too ambiguous to understand what should be contained and what form is used. It only describes that it contains a triggering packet. And authors recommend enough of the beginning of it. So, what is enough? => this enough is application dependent and is implemented in BSD by a sysctl tunable. OK, I know it is not fragmented. => until the application needs something like the packet ID there is no reason at all to fragment. > I understand that IKE needs to know a precise CoA for MIPv6 support. > Why is it not enough to specify that the kernel sends SADB_ACQUIRE with > the packet like [IPv6][DSTOPT(CoA)][MH] as SADB_X_MIPV6_PACKET or > SADB_X_MIPV6BU_PACKET? > > => this is less general so you likely have to do it one day... Yes it is less general. But the draft is "PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE". I think the generality of what you mean is beyound the scope of the document because I read that SADB_X_EXT_PACKET extension will be applied not only Moble IPv6 BU but also other general traffic such as TCP, UDP and so on. => do you argue we really need two separate documents? I propose you ask in the IPsec list where the IKEv2 first TS should be extracted from, if the SADB_X_EXT_PACKET is a good solution and if yes if it needs its own document. Regards Francis.Dupont@fdupont.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 07 03:44:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEiPT-0005aJ-2h; Wed, 07 Feb 2007 03:44:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEiPR-0005a2-3V for mip6@ietf.org; Wed, 07 Feb 2007 03:44:09 -0500 Received: from tao.fdupont.fr ([82.236.136.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEiPP-0002ap-IW for mip6@ietf.org; Wed, 07 Feb 2007 03:44:09 -0500 Received: from tao.fdupont.fr (localhost [127.0.0.1]) by tao.fdupont.fr (8.13.5/8.13.5) with ESMTP id l178i1t4003278; Wed, 7 Feb 2007 09:44:01 +0100 (CET) Received: from tao.fdupont.fr (dupont@localhost) by tao.fdupont.fr (8.13.5/8.13.5/Submit) with ESMTP id l178i0hb003275; Wed, 7 Feb 2007 09:44:01 +0100 (CET) Message-Id: <200702070844.l178i0hb003275@tao.fdupont.fr> From: Francis Dupont To: Keiichi SHIMA Subject: Re: [Mip6] Question about draft-sugimoto-mip6-pfkey-migrate In-reply-to: Your message of Wed, 07 Feb 2007 14:54:23 +0900. <758463BB-456A-43FB-B51C-72C4EC5F5D2A@iijlab.net> Date: Wed, 07 Feb 2007 09:43:59 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Keiichi, you should have missed this, quoting RFC 4306: The responder is allowed to narrow the choices by selecting a subset of the traffic, for instance by eliminating or narrowing the range of one or more members of the set of traffic selectors, provided the set does not become the NULL set. It is possible for the responder's policy to contain multiple smaller ranges, all encompassed by the initiator's traffic selector, and with the responder's policy being that each of those ranges should be sent over a different SA. Continuing the example above, the responder might have a policy of being willing to tunnel those addresses to and from the initiator, but might require that each address pair be on a separately negotiated CHILD_SA. If the initiator generated its request in response to an incoming packet from 192.0.1.43 to 192.0.2.123, there would be no way for the responder to determine which pair of addresses should be included in this tunnel, and it would have to make a guess or reject the request with a status of SINGLE_PAIR_REQUIRED. * To enable the responder to choose the appropriate range in this case, * if the initiator has requested the SA due to a data packet, the * initiator SHOULD include as the first traffic selector in each of TSi * and TSr a very specific traffic selector including the addresses in * the packet triggering the request. In the example, the initiator would include in TSi two traffic selectors: the first containing the address range (192.0.1.43 - 192.0.1.43) and the source port and IP protocol from the packet and the second containing (192.0.1.0 - 192.0.1.255) with all ports and IP protocols. The initiator would similarly include two traffic selectors in TSr. If the responder's policy does not allow it to accept the entire set of traffic selectors in the initiator's request, but does allow him to accept the first selector of TSi and TSr, then the responder MUST narrow the traffic selectors to a subset that includes the initiator's first choices. In this example, the responder might respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and IP protocols. If the initiator creates the CHILD_SA pair not in response to an arriving packet, but rather, say, upon startup, then there may be no specific addresses the initiator prefers for the initial tunnel over any other. In that case, the first values in TSi and TSr MAY be ranges rather than specific values, and the responder chooses a subset of the initiator's TSi and TSr that are acceptable. If more than one subset is acceptable but their union is not, the responder MUST accept some subset and MAY include a Notify payload of type ADDITIONAL_TS_POSSIBLE to indicate that the initiator might want to try again. This case will occur only when the initiator and responder are configured differently from one another. If the initiator and responder agree on the granularity of tunnels, the initiator will never request a tunnel wider than the responder will accept. Such misconfigurations SHOULD be recorded in error logs. So my idea is to provide "enough" of the triggering packet to KMPs as: - this makes the first TS pair easy to build - with some decoding this makes the very special and specific Mobile IPv6 home registration binding update case easy to recognize and with adding a small (at the exception of Linux) code in the kernel. Thanks Francis.Dupont@fdupont.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 07 21:47:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEzJo-0007FJ-01; Wed, 07 Feb 2007 21:47:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEzJm-0007CM-6r for mip6@ietf.org; Wed, 07 Feb 2007 21:47:26 -0500 Received: from [203.178.140.4] (helo=miyazawa.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEzJk-00057E-Jk for mip6@ietf.org; Wed, 07 Feb 2007 21:47:26 -0500 Received: from [IPv6:2001:200:1b0:2030::1] ([2001:200:1b0:2030::1]) (AUTH: PLAIN kazunori, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by miyazawa.org with esmtp; Thu, 08 Feb 2007 11:47:50 +0900 id 00046E2F.45CA8F56.000070C3 Message-ID: <45CA8F4D.60803@miyazawa.org> Date: Thu, 08 Feb 2007 11:47:41 +0900 From: Kazunori Miyazawa User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mip6] Question about draft-sugimoto-mip6-pfkey-migrate References: <200702070834.l178YOPE003218@tao.fdupont.fr> In-Reply-To: <200702070834.l178YOPE003218@tao.fdupont.fr> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: mip6@ietf.org, Keiichi SHIMA X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Francis Dupont wrote: > In your previous mail you wrote: > > > because Linux does not have an IP header and extension headers yet, > > > > => you don't need to have them, you only need to know what will be put > > in them. > > > But does EXT_PACKET need to extract those headers, doesn't it? > The Linux kernel which support the extension must copy and build the > contents to extract the headers. No? > > => IMHO we only have to make the content of SADB_X_EXT_PACKET system > dependent with a default to the real content at this (i.e., SPD > looking up for outgoing traffic) phase. > > > It will also have to fragment the packet > > > > => this is more than unnecessary! > > > > I feel SADB_X_EXT_PACKET part of the current draft is too ambiguous to > understand what should be contained and what form is used. > It only describes that it contains a triggering packet. And authors > recommend enough of the beginning of it. So, what is enough? > > => this enough is application dependent and is implemented in BSD by > a sysctl tunable. > > OK, I know it is not fragmented. > > => until the application needs something like the packet ID there is > no reason at all to fragment. > > > I understand that IKE needs to know a precise CoA for MIPv6 support. > > Why is it not enough to specify that the kernel sends SADB_ACQUIRE with > > the packet like [IPv6][DSTOPT(CoA)][MH] as SADB_X_MIPV6_PACKET or > > SADB_X_MIPV6BU_PACKET? > > > > => this is less general so you likely have to do it one day... > > Yes it is less general. But the draft is "PF_KEY Extension as an > Interface between Mobile IPv6 and IPsec/IKE". > I think the generality of what you mean is beyound the scope of the document > because I read that SADB_X_EXT_PACKET extension will be applied not > only Moble IPv6 BU > but also other general traffic such as TCP, UDP and so on. > > => do you argue we really need two separate documents? > I propose you ask in the IPsec list where the IKEv2 first TS should > be extracted from, if the SADB_X_EXT_PACKET is a good solution > and if yes if it needs its own document. > I still regard SADB_X_EXT_PACKET as excessive framework to just notify an application of the CoA in Home Registration Binding Update. But I considered SADB_X_EXT_PACKET all over again from the IPsec point of view, especially in the case of PFP, as you mentioned. I get to consider it is kind of reasonable for a SGW, which receives packets from other nodes. So I decided to stop arguing at the moment. Thank you for your time and patience. -- Kazunori Miyazawa _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 08 18:50:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJ1p-0000jS-8J; Thu, 08 Feb 2007 18:50:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJ1f-0000XQ-IE; Thu, 08 Feb 2007 18:50:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFJ1f-0005th-3F; Thu, 08 Feb 2007 18:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id C8EA626EB9; Thu, 8 Feb 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HFJ1e-0006v8-GM; Thu, 08 Feb 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Feb 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-integrated-dhc-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : MIP6-bootstrapping for the Integrated Scenario Author(s) : K. Chowdhury, A. Yegin Filename : draft-ietf-mip6-bootstrapping-integrated-dhc-02.txt Pages : 19 Date : 2007-2-8 The Mobile IPv6 bootstrapping problem statement describes two main scenarios. In the first scenario (i.e. the split scenario), the mobile node's mobility service is authorized by a different service authorizer than the basic network access authorizer. In the second scenario (i.e. the integrated scenario), the mobile node's mobility service is authorized by the same service authorizer as the basic network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-bootstrapping-integrated-dhc-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-8160253.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-bootstrapping-integrated-dhc-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-8160253.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Tue Feb 13 04:37:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGu5D-0007xu-Hg; Tue, 13 Feb 2007 04:36:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGu5C-0007xd-6B for mip6@ietf.org; Tue, 13 Feb 2007 04:36:18 -0500 Received: from smtp.netregistry.net ([202.124.241.204] helo=smtp-1.servers.netregistry.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGu56-0003HO-Ni for mip6@ietf.org; Tue, 13 Feb 2007 04:36:18 -0500 Received: from [81.10.63.234] (helo=PC20005) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.50 #1 (Debian)) id 1HGu4r-0006FJ-EH for ; Tue, 13 Feb 2007 20:35:58 +1100 From: "Hesham Soliman" To: Date: Tue, 13 Feb 2007 20:35:45 +1100 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.3028 Thread-index: AcdPUlZG2PSQhxxqSiyy2hIa7Ad89g== X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Mip6] Continuing with DSMIP remaining issues X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Message-Id: Folks, Just a heads up to the list. We have two issues remaining for DSMIPv6. The issue of Dynamic NAT discovery was discussed in the last IETF and there is no movement from either side, which led us to conclude during the meeting that this implies rejection of the issue. I'm now confirming this on the list. The remaining 2 issues deal with the use of the mapped address and whether or not we need the additional checksum in the BU to protect the src address in the packet (due to the removal of the Alt-CoA). I'll be sending text on both issues this week. I hope we can co-operate on those two issues to resolve them before the submission deadline and I apologise for the delay in handling those, which is mainly due to travelling on my behalf. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 14 13:08:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOXg-0001Vv-5P; Wed, 14 Feb 2007 13:07:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOXf-0001Vp-NM for mip6@ietf.org; Wed, 14 Feb 2007 13:07:43 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHOXe-0007sW-7Y for mip6@ietf.org; Wed, 14 Feb 2007 13:07:43 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1EI4tBh008061 for ; Wed, 14 Feb 2007 20:05:02 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 20:07:05 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 12:07:02 -0600 Received: from 172.19.244.119 ([172.19.244.119]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Feb 2007 18:07:02 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 14 Feb 2007 12:10:00 -0600 From: Basavaraj Patil To: Message-ID: Thread-Topic: WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Thread-Index: AcdQY1dNlaD6hLxWEduSnQARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Feb 2007 18:07:02.0981 (UTC) FILETIME=[EDCA1750:01C75062] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070214200502-1A7B4BB0-69B74D91/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 1.1 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, This is a MIP6 Working group last call for the WG I-D: "MIP6-bootstrapping for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-02.txt I-D: http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc -02.txt Please review and submit your comments to the authors or the mailing list. The WGLC will expire on March 1st, 07. -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 14 14:53:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQBc-0000la-6O; Wed, 14 Feb 2007 14:53:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQBa-0000kf-FA for mip6@ietf.org; Wed, 14 Feb 2007 14:53:02 -0500 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHQBW-0003hH-4P for mip6@ietf.org; Wed, 14 Feb 2007 14:53:02 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50002389830.msg for ; Wed, 14 Feb 2007 20:49:34 +0100 From: "Miguel A. Diaz" To: References: Date: Wed, 14 Feb 2007 20:52:10 +0100 Message-ID: <003301c75071$9dc37f30$090ba8c0@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdQY1dNlaD6hLxWEduSnQARJNUNiAADW2Qg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-HashCash: 1:20:070214:mip6@ietf.org::BaVelGm3zjEGp+i3:00004Pgx X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: mip6@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-3.4 required=4.5 tests=BAYES_00,SUBJ_HAS_UNIQ_ID autolearn=no version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Wed, 14 Feb 2007 20:49:35 +0100 X-MDAV-Processed: consulintel.es, Wed, 14 Feb 2007 20:49:35 +0100 X-Spam-Score: 1.2 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Mip6] Question about OPTION_MIP6-RELAY option in draft-ietf-mip6-bootstrapping-integrated-02 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, I see that in draft-ietf-mip6-bootstrapping-integrated-02 is stated that the DHCPv6 relay adds the OPTION_MIP6-RELAY option to the RELAY-FORWARD message in order to inform to the DHCPv6 server about the HA to be assigned to the MN. I've looked for the OPTION_MIP6-RELAY option in several drafts, but I have no success, so I guess that the OPTION_MIP6-RELAY option is not defined yet anywhere, just it's mentioned on draft-ietf-mip6-bootstrapping-integrated-02 as theoretical option to be defined. Is this assumption right or can someone gives me information about where the format of such an option is defined? Regards Miguel ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 14 17:13:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSMV-0005iZ-AL; Wed, 14 Feb 2007 17:12:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSMU-0005iM-4y for mip6@ietf.org; Wed, 14 Feb 2007 17:12:26 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHSMP-0004YC-Q4 for mip6@ietf.org; Wed, 14 Feb 2007 17:12:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 6429F90022 for ; Wed, 14 Feb 2007 17:12:18 -0500 (EST) 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 15436-06 for ; Wed, 14 Feb 2007 17:12:13 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 14 Feb 2007 17:12:13 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 17:12:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Question about OPTION_MIP6-RELAY option indraft-ietf-mip6-bootstrapping-integrated-02 Date: Wed, 14 Feb 2007 17:12:13 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD8D6@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Question about OPTION_MIP6-RELAY option indraft-ietf-mip6-bootstrapping-integrated-02 Thread-Index: AcdQY1dNlaD6hLxWEduSnQARJNUNiAADW2QgAAT88TA= From: "Chowdhury, Kuntal" To: , X-OriginalArrivalTime: 14 Feb 2007 22:12:13.0894 (UTC) FILETIME=[2E2D4660:01C75085] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 1.1 (+) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Miguel, This option was defined in the previous version of the integrated bootstrap I-D. Based on the consensus of the WG, we decided to export the definition of the DHC options to draft-ietf-mip6-hiopt-01.txt. The -02 version of this I-D (hiopt) will have the necessary definitions.=20 Regards, Kuntal > -----Original Message----- > From: Miguel A. Diaz [mailto:miguelangel.diaz@consulintel.es] > Sent: Wednesday, February 14, 2007 1:52 PM > To: mip6@ietf.org > Subject: [Mip6] Question about OPTION_MIP6-RELAY option indraft-ietf-mip6- > bootstrapping-integrated-02 >=20 > Hello, >=20 > I see that in draft-ietf-mip6-bootstrapping-integrated-02 is stated that > the > DHCPv6 relay adds the OPTION_MIP6-RELAY option to the RELAY-FORWARD > message > in order to inform to the DHCPv6 server about the HA to be assigned to the > MN. >=20 > I've looked for the OPTION_MIP6-RELAY option in several drafts, but I have > no success, so I guess that the OPTION_MIP6-RELAY option is not defined > yet > anywhere, just it's mentioned on draft-ietf-mip6-bootstrapping-integrated- > 02 > as theoretical option to be defined. >=20 > Is this assumption right or can someone gives me information about where > the > format of such an option is defined? >=20 > Regards > Miguel >=20 >=20 >=20 >=20 > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org >=20 > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org >=20 > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 14 17:31:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSez-0007eU-Ep; Wed, 14 Feb 2007 17:31:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSey-0007dn-21 for mip6@ietf.org; Wed, 14 Feb 2007 17:31:32 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHSew-0006EZ-M9 for mip6@ietf.org; Wed, 14 Feb 2007 17:31:32 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l1EMVTlU028482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Feb 2007 14:31:29 -0800 Received: from sanexcas01.na.qualcomm.com (sanexcas01.qualcomm.com [172.30.36.175]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l1EMVTir021881; Wed, 14 Feb 2007 14:31:29 -0800 (PST) Received: from NAEX16.na.qualcomm.com ([10.47.6.157]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 14:31:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Date: Wed, 14 Feb 2007 14:31:25 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF428D742@NAEX16.na.qualcomm.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Thread-Index: AcdQY1dNlaD6hLxWEduSnQARJNUNiAAI4fFA From: "Tsirtsis, George" To: "Basavaraj Patil" , X-OriginalArrivalTime: 14 Feb 2007 22:31:28.0781 (UTC) FILETIME=[DE8B0BD0:01C75087] X-Spam-Score: 1.1 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I have the following questions. I appologise in advance if this issues have been discussed sine I have not followed the discussions closely. In section 3.2.2. (Home Agent allocation in the ASP), It is not clear what happens if the DHC server is not configured to assign local HAs to visiting MNs. Also, would it be possible for a mobile to ask for both visited and home HAs? One way would be to allow two Home Network Identifier Options, one with id-type set to 1 and another with id-type set to 0 so that the MN can request both MSP and ASP HAs. Another way would be to define id-type=3D4 "Visited and home domain" in draft-ietf-mip6-hiopt-01.txt. Thoughts? George > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > Sent: Wednesday, February 14, 2007 1:10 PM > To: mip6@ietf.org > Subject: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 >=20 >=20 > Hello, >=20 > This is a MIP6 Working group last call for the WG I-D: > "MIP6-bootstrapping for the Integrated Scenario", > draft-ietf-mip6-bootstrapping-integrated-02.txt >=20 > I-D: > http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated - > dhc > -02.txt >=20 > Please review and submit your comments to the authors or the mailing > list. The WGLC will expire on March 1st, 07. >=20 > -Chairs >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 14 21:47:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHWdU-0005jv-Sq; Wed, 14 Feb 2007 21:46:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHWdT-0005jp-Rw for mip6@ietf.org; Wed, 14 Feb 2007 21:46:15 -0500 Received: from yskfw1.ysknet.co.jp ([210.169.255.3] helo=ksns.ks.ysknet.co.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHWdS-0003i8-4a for mip6@ietf.org; Wed, 14 Feb 2007 21:46:15 -0500 Received: (qmail 11948 invoked from network); 15 Feb 2007 11:45:55 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 15 Feb 2007 11:45:55 +0900 To: mip6@ietf.org Subject: Re: [Mip6] Non-tunnelled Echo Req MN to HA From: "K.Kawaguchi" References: <45A26BA7.9060102@motorola.com> <200701091652.AAH56236.XJVBUBLH@ysknet.co.jp> <45A39A57.4020801@motorola.com> <200701161433.JBD35485.HLJBVUXB@ysknet.co.jp> <45C11700.4010400@azairenet.com> In-Reply-To: <45C11700.4010400@azairenet.com> Message-Id: <200702151145.CDF13078.XHBJVBLU@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Thu, 15 Feb 2007 11:45:53 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, To confirm a general interpretation, I try another approach. I show one flow figure. Where is the problem? ---- HA finds and processes the Home Address Option in the received message. < The home address in the Home Address Option is a unicast routable address? > (Yes) (No) | | | V | go to sending BE process | v < The message is the Bindin Update message? > (No) (Yes) | | | v | go to Binding process v < The home address in the Home Address Option is fined in the Binding Cache entry? > (Yes) (No) -----------> send BE(status 1) | | | V | go to sending BE process V < The source address in the message is fined in the current Binding Cache entry? > (Yes) (No) -----------> send BE(status 1) | | | V | go to sending BE process v go to next header process --- I reference follwing. RFC2460 section 4 --- With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. There, normal demultiplexing on the Next Header field of the IPv6 header invokes the module to process the first extension header, or the upper-layer header if no extension header is present. The contents and semantics of each extension header determine whether or not to proceed to the next header. Therefore, extension headers must be processed strictly in the order they appear in the packet; a receiver must not, for example, scan through a packet looking for a particular kind of extension header and process that header prior to processing all preceding ones. The exception referred to in the preceding paragraph is the Hop-by- Hop Options header, which carries information that must be examined --- 2) RFC3775 Section 10.3.1 --- o A Home Address destination option MUST be present in the message. It MUST be validated as described in Section 9.3.1 with the following additional rule. The Binding Cache entry existence test MUST NOT be done for IPsec packets when the Home Address option contains an address for which the receiving node could act as a home agent. --- 3) RFC3775 Section 9.3.1 --- Packets containing a Home Address option MUST be dropped if the given home address is not a unicast routable address. Mobile nodes can include a Home Address destination option in a packet if they believe the correspondent node has a Binding Cache entry for the home address of a mobile node. Packets containing a Home Address option MUST be dropped if there is no corresponding Binding Cache entry. A corresponding Binding Cache entry MUST have the same home address as appears in the Home Address destination option, and the currently registered care-of address MUST be equal to the source address of the packet. These tests MUST NOT be done for packets that contain a Home Address option and a Binding Update. If the packet is dropped due the above tests, the correspondent node MUST send the Binding Error message as described in Section 9.3.3. The Status field in this message should be set to 1 (unknown binding for Home Address destination option). --- Best regards --- Kiyoaki KAWAGUCHI "Vijay Devarapalli " wrote: > Hello Kawaguchi-san, > > Sorry for the late reply. > > K.Kawaguchi wrote: > > The test specification interprets RFC3775 as follows now. > > > > a) Whether HA transmits BRR or not. > > > > => HA doesn't send BRR. > > That is correct. > > > b) How should HA do, when HA receives the packet of Echo Request with > > Home Address destination option from MN where HA has the binding > > cache entry. > > > > => HA replies Echo Reply wtih type2 routing headr. > > When HA sends the packet to MN, the processing of HA is the same > > as CN (10.4.2 refer to 9.3.2 in RFC3775). > > In view of the situation, when HA receives the packet from MN, > > the processing of HA is the same as CN (so 10.4.x seems to have > > missed the reference to 9.3.1.). > > > c) How should HA do, when HA receives the packet of Echo Request with > > Home Address destination option from node where HA hasn't the binding > > cache entry. > > > > => HA replies Binding Error(status 1). > > The reason is the same as b). > > No. If you want to interpret RFC 3775 accurately, the HA > should send a binding error (status 1) only if the home > address in the home address option does not belong to the > home prefix served by the HA. If the HA is the home agent > for that mobile node, the packet should be dropped (no > binding error is sent). > > Vijay > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 15 17:48:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHpNi-0002XT-Nz; Thu, 15 Feb 2007 17:47:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHpNh-0002WT-E2; Thu, 15 Feb 2007 17:47:13 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHpNe-0008PV-Q7; Thu, 15 Feb 2007 17:47:13 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8D5FF198775; Fri, 16 Feb 2007 00:47:09 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 38AB119862E; Fri, 16 Feb 2007 00:47:09 +0200 (EET) Message-ID: <45D4E2ED.8040702@piuha.net> Date: Fri, 16 Feb 2007 00:47:09 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: "Tsirtsis, George" References: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List Subject: [Mip6] Re: FW: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi George, Sorry for the delay in the answer. Too much going on elsewhere... I have reviewed your new version and the answer below. I'm not completely happy with the new text, but I would nevertheless like to take the draft forward. I do have three suggested changes below, which I have tentatively added as RFC Editor notes in the ID tracker. I'm putting the draft up for IESG evaluation and unless you object, the edits will be considered if and when the draft is approved. Or, if there are other reasons to edit the draft after the evaluation, you can adopt them for the next revision. Inline: > >>> Is this true under all circumstances? For instance, >>> is it true if one uses RFC 4285 or EAP for Mobile IPv6 >>> authentication? >>> >>> Depending on the answer, please reword >>> and add the necessary explanations. >>> >>> >> GT> I believe that, assuming nothing is changed, what the draft says >> > is > >> accurate since typically applications/protocols can not share keys >> unless security is implemented at a lower layer than that of the >> application/protocol. Still, I will add something to indicate that for >> some of the mechanisms listed and with further work, it might be >> possible to optimize operations. >> >> > Do you have text? We are not talking about typical applications, > we are talking about a very specific case. And there are many > applications that can share the same credentials through, say, > AAA. > > GT> Here is what I have. > " In addition, deploying both protocols will require duplication of > security credentials on mobile nodes and home agents. This includes, > IPsec security associations, keying material, and new authentication > protocols for Mobile IPv6, in addition to the security credentials > and associations required by Mobile IPv4. Depending on the security > mechanisms used and with some further work it might be possible to > optimize some of these processes. Assuming nothing else changes, > however, such duplication is again significant with no gain to the > operator or the mobile node." > Mumble. Perhaps "... possible to rely on one set of set common credentials. Assuming ..." But I wish the draft could say something specific about the actual possibility to do this. For instance, the draft could argue the neither RFC 4285 or EAP can support Mobile IPv4 authentication (if that is the case). > >>>> 3.1. Implementation burdens >>>> >>>> As mentioned above, a node that is IPv4 and IPv6 capable mustalso >>>> > be > >>>> >>>> MIPv4 and MIPv6 capable to roam within the Internet. Clearly this >>>> will add implementation efforts, which, we argue, are not >>>> > necessary. > >>>> >>>> In addition to the implementation efforts, some vendors may not >>>> support both protocols in either mobile nodes or home agents. >>>> Although this is more of a commercial issue, it does affect the >>>> large-scale deployment of mobile devices on the Internet. >>>> >>>> >>>> >>> I'm not sure this section reflects the complete >>> picture. In a situation where host vendors >>> are independent of those who deploy the >>> mobility infrastructure, for instance, its >>> not clear that there is any reduction in >>> implementation effort. >>> >>> Please reword for better balance. >>> >>> >>> >> GT> OK, I will clarify >> >> > Good. Again, I would like to see the text... > > GT> Here it is: > " As mentioned above, a node that is IPv4 and IPv6 capable must also be > MIPv4 and MIPv6 capable to roam within the Internet. Clearly this > increases the complexity of implementations for vendors that decide > to support both protocols. > Some vendors, however, may not support both protocols in either > mobile nodes or home agents. Although this is more of a commercial > issue, it does affect the large-scale deployment of mobile devices on > the Internet." > I don't think this reflects the issue that I had. Here's a different wording: As mentioned above, a node that is IPv4 and IPv6 capable must also be MIPv4 and MIPv6 capable to roam within the Internet. The ability to employ both IP versions from one mobility protocol makes it possible to implement just that one protocol, assuming the protocol choice is known. However, in situations where the mobile node must be capable of working in any network it may still need two protocols. > >>>> 3.0 Problem description >>>> >>>> >>> I am missing an explanation of why various existing, >>> non-mobility related transition mechanisms are insufficient >>> for solving the issues listed in this document. I believe >>> they are insufficient, but the document needs to explain >>> why. >>> >>> Please add the explanation. >>> >>> >> GT> It is a bit difficult to write general negative statements like >> this. I will add a section on this and add something generic about the >> fact that current transition mechanisms do not seem to deal with >> mobility. >> >> > Ok. Text needed. > > GT> Here it is: > "4.5. IPv4 to IPv6 Transition Mechanisms > > The IETF has standardized a number of transition mechanisms to allow > networks and end nodes to gain IPv6 connectivity while the Internet > is migrating from IPv4 to IPv6. A cursory examination of such > transition mechanisms indicates that none of them is designed to deal > with mobile nodes. While some transition mechanisms can be combined > with Mobile IPv4 or Mobile IPv6, non of the known mechanisms have > been shown to assist with the issues described in this document." > Hmm... maybe it is not a good idea to reveal that we've only performed "a cursory examination" of the other possible approaches :-) Here's what I'd suggest: The IETF has standardized a number of transition mechanisms to allow networks and end nodes to gain IPv6 connectivity while the Internet is migrating from IPv4 to IPv6. However, while some transition mechanisms can be combined with Mobile IPv4 or Mobile IPv6, none of the known mechanisms have been shown to assist with the issues described in this document. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 16 03:39:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHybW-0000U9-19; Fri, 16 Feb 2007 03:38:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHybU-0000U0-HD for mip6@ietf.org; Fri, 16 Feb 2007 03:38:04 -0500 Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHybS-0004jZ-W3 for mip6@ietf.org; Fri, 16 Feb 2007 03:38:04 -0500 Received: from rly12d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly12d.srv.mailcontrol.com (MailControl) with ESMTP id l1G8bxnI021222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 Feb 2007 08:38:00 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly12d.srv.mailcontrol.com (MailControl) id l1G8bPNL020135 for mip6@ietf.org; Fri, 16 Feb 2007 08:37:25 GMT Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly12d-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l1G8bN7B020068; Fri, 16 Feb 2007 08:37:25 +0000 (GMT) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 183f_e120a046_bd95_11db_8e99_0030482aac25; Fri, 16 Feb 2007 09:15:35 +0100 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007021609342346-248112 ; Fri, 16 Feb 2007 09:34:23 +0100 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: -0.167,BAYES_00: -1.665,TOTAL_SCORE: -1.832 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Fri, 16 Feb 2007 09:38:47 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Thread-Index: AcdQY1dNlaD6hLxWEduSnQARJNUNiAAgF6Fw References: To: "Basavaraj Patil" , Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F011C8DCB@lan-ex-01.panasonic.de> Date: Fri, 16 Feb 2007 09:31:15 +0100 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-07-06-85 (www.mailcontrol.com) on 10.68.1.122 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.2 (+) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, please find below some comments about=20 draft-ietf-mip6-bootstrapping-integrated-02. The draft is well written and easy to understand (thanks to figures and message sequence text). However, some details and corner cases are not addressed, which may need to be specified, e.g.: - How does the NAS/relay map a DHCP request received from a specific MN=20 to the cached home network information previously received from AAAH=20 for this MN, so that it can include the correct home network=20 information in a received DHCP request? - What is the conceptual data structure needed for this in the NAS/DHCP=20 relay? - Any default value for how long NAS should cache home network=20 information received from AAA for a specific MN (i.e., when is NAS=20 allowed to delete cache entry?)? If this is specified in [MIP6-Dime]=20 or [MIP6-RADIUS] it should be mentioned and referenced.=20 - What should NAS do if DHCP request with Home network identifier=20 option is received from a MN and NAS doesn't find valid home network=20 information for this MN in its cache (e.g., since the cache entry=20 has expired)? - What should DHCP relay/server do if the MN does not include the=20 OPTION_CLIENTID in the DHCP request or if OPTION_MIP6-RELAY-Option=20 is missing in request? The draft may need better aligned with [HIOPT]. For instance, it is not clear to me how exactly the home network identifier option and the home=20 network information option specified in [HIOPT] are allowed to be used in draft-ietf-mip6-bootstrapping-integrated-02:=20 - [HIOPT] supports home address allocation. This is not mentioned in=20 draft-ietf-mip6-bootstrapping-integrated-02. Is this forbidden or=20 allowed or out-of-scope? If allowed, when does NAS set the A-flag in=20 the home network identifier option? - Is it allowed that multiple HA addresses are returned in the home=20 network information option? - [HIOPT] allows that the home network identifier option includes an=20 identifier of a target network, which is different from home or=20 visited network of MN. This is not mentioned in=20 draft-ietf-mip6-bootstrapping-integrated-02. Is this allowed or=20 forbidden? - Which HA information should the MN use if it receives, e.g., an FQDN=20 and a HA address in DHCP reply? [HIOPT] refers to section 3.6 of=20 draft-ietf-mip6-bootstrapping-integrated-01, but this section doesn't exist in draft-ietf-mip6-bootstrapping-integrated-02 anymore... Some other comments: - It would be good to have a section, which explicitly states=20 assumptions and applicability of the protocol. This should include: - MSA and ASA must be co-located (i.e., integrated scenario) - AAA infrastructure assumed and some kind of roaming=20 relationship between ASP and MSA/ASA is required - MSP is either co-located with ASP or MSA or both (Or are other target networks allowed; see above)? - DHCP relay and NAS must be co-located - At some places in the text the use of the term "MSP" is ambiguous,=20 since MSP can refer to at least home and visited network. Better=20 use "home MSP" for MSP in home network. - e.g., section 3.1: "Note that a home agent for usage with the mobile node might be selected in the access service provider's network or alternatively in the *home* mobility service provider's network." - or in section 3.2: "The message flows for home agent allocation in the ASP and the *home* MSP are illustrated below. =20 - or in section 3.2.1: "3.2.1. Home Agent allocation in the *home* MSP", "(4)... mobile node is requesting home agent information in the=20 *home* MSP..." - Section 3.3 currently mentions DNS-based HA address discovery method only, but [BOOT-SPLIT] also specifies an anycast-based HA address=20 discovery method. Either both or none should be mentioned. - The title of draft-ietf-mip6-bootstrapping-integrated-02 can cause=20 the impression that the draft defines a complete bootstrapping =20 procedure. But draft-ietf-mip6-bootstrapping-integrated-02 defines a=20 method for HA address assignment only. I think this is misleading.=20 Why not name the draft according to what it specifies (e.g., "HA=20 address assignment using DHCP and AAA" or "HA address assignment for=20 the integrated scenario using DHCP and AAA" instead of=20 "MIP6-bootstrapping for the integrated scenario")? Regards, Kilian > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com]=20 > Sent: Mittwoch, 14. Februar 2007 19:10 > To: mip6@ietf.org > Subject: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 >=20 >=20 > Hello, >=20 > This is a MIP6 Working group last call for the WG I-D: > "MIP6-bootstrapping for the Integrated Scenario", > draft-ietf-mip6-bootstrapping-integrated-02.txt >=20 > I-D:=20 > http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping- > integrated-dhc > -02.txt >=20 > Please review and submit your comments to the authors or the mailing > list. The WGLC will expire on March 1st, 07. >=20 > -Chairs >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 16 05:35:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI0Py-0000DO-5T; Fri, 16 Feb 2007 05:34:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI0Pw-0000AN-EV; Fri, 16 Feb 2007 05:34:16 -0500 Received: from mail127.messagelabs.com ([216.82.250.115]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HI0Pt-0004Id-QJ; Fri, 16 Feb 2007 05:34:16 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-9.tower-127.messagelabs.com!1171622052!9675610!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 15894 invoked from network); 16 Feb 2007 10:34:12 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-127.messagelabs.com with SMTP; 16 Feb 2007 10:34:12 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l1GAY7gp012770; Fri, 16 Feb 2007 03:34:08 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l1GAY5Il026110; Fri, 16 Feb 2007 04:34:06 -0600 (CST) Message-ID: <45D5889C.3060701@motorola.com> Date: Fri, 16 Feb 2007 11:34:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip6] Re: FW: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt References: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com> <45D4E2ED.8040702@piuha.net> In-Reply-To: <45D4E2ED.8040702@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Jari Arkko wrote: > Hi George, [...] >>>>> 3.0 Problem description >>>>> >>>>> >>>> I am missing an explanation of why various existing, >>>> non-mobility related transition mechanisms are insufficient >>>> for solving the issues listed in this document. I believe >>>> they are insufficient, but the document needs to explain >>>> why. >>>> >>>> Please add the explanation. >>>> >>>> >>> GT> It is a bit difficult to write general negative statements like >>> this. I will add a section on this and add something generic about the >>> fact that current transition mechanisms do not seem to deal with >>> mobility. >>> >>> >> Ok. Text needed. >> >> GT> Here it is: >> "4.5. IPv4 to IPv6 Transition Mechanisms >> >> The IETF has standardized a number of transition mechanisms to allow >> networks and end nodes to gain IPv6 connectivity while the Internet >> is migrating from IPv4 to IPv6. A cursory examination of such >> transition mechanisms indicates that none of them is designed to deal >> with mobile nodes. While some transition mechanisms can be combined >> with Mobile IPv4 or Mobile IPv6, non of the known mechanisms have >> been shown to assist with the issues described in this document." >> > Hmm... maybe it is not a good idea to reveal that we've > only performed "a cursory examination" of the other > possible approaches :-) > > Here's what I'd suggest: > > The IETF has standardized a number of transition mechanisms to allow > networks and end nodes to gain IPv6 connectivity while the Internet > is migrating from IPv4 to IPv6. However, while some transition > mechanisms can be combined with Mobile IPv4 or Mobile IPv6, none > of the known mechanisms have been shown to assist with the issues > described in this document. I'm sorry to interfere here late at a pre-submission stage. Known mechanisms have been shown to assist with the issues described in this document: 6to4 tunnel between MN and a Gateway, RAs over that tunnel and HA separated from the gateway. Just 6to4, ND and Mobile IPv6, no protocol modifications. The experiment was described in a personal draft a few years ago, in the NEMO context with a vehicular MR attaching to IPv6-WiFi and IPv4-GPRS. The description was not using 6to4/MIP6 terms, it was targeted at showing network mobility is possible. I've not felt the need to document this 6to4/MIP6 behaviour because it is very straightforward. When discussing the dsmipv6 protocol and problem statement other WG members mentioned that this 6to4/MIP6 may be possible. NAT Traversal and MIP6 and 6to4 works ok too with _certain_ types of NATs, tried that in lab. MIP6 and MIP4-NAT Traversal works ok too, but in order to traverse more special NATs some protocol enhancements to MIP4-NAT Traversal are necessary. These enhancements have been implemented and tested routinely in my lab. New message formats were designed. I copypaste that in the postscriptum. Again, I am not trying to interfere with the advancement of the problem statement draft, just to say that alternatives to DS-MIPv6 exist live and well. Being rejected by IETF doesn't mean they don't exist. Alex PS: IPv4 NAT Traversal for IPv6 Mobile Nodes HA is an IPv4 HA (implementing Mobile IPv4). HA aka GW. MN HA | ---- Tunnel Request ------------> | | <--- Tunnel Reply --------------- | | ---- Tunnel "Acknowledgement" --> | ~ ... ~ | -----Tunnel "Keepalive" --------> | No NAT Present MN HA | ---- Tunnel Request ------------> | | IP src address | | Tentative UDP dst port number| | Tentative MN Tunnel Address | | | | <--- Tunnel Reply --------------- | | Echoed Src Address | | Echoed Dst port number | | Tentative HA Tunnel Address | | Accepted TMTA, reply code 0 | | TMTA | | | ---- Tunnel "Acknowledgement" --> | | Accepted THTA | | THTA | | Reply Code 2 (no NAT) | NAT Present MN HA | ---- Tunnel Request ------------> | | IP src address | | Tentative UDP dst port number| | Tentative MN Tunnel Address | | | | <--- Tunnel Reply --------------- | | Echoed Src Address | | Echoed Dst port number | | Tentative HA Tunnel Address | | Reply Code 0 "Accepted TMTA" | | TMTA | | | | ---- Tunnel "Acknowledgement" --> | | Connection ID | | Reply Code 0 "Accepted HA and port" | THTA | | DPN (destination port number) | | | -----Tunnel "Keepalive" --------> | | Connection ID | ~ ... ~ | -----Tunnel "Keepalive" --------> | | Connection ID | | | NAT Present, Dst Port Number Discovery MN HA | ---- Tunnel Request ------------> | | IP src address | | Tentative UDP dst port number1 | Tentative MN Tunnel Address | ~ ... ~ | ---- Tunnel Request ------------> | | IP src address | | Tentative UDP dst port number2 | Tentative MN Tunnel Address | | | | <--- Tunnel Reply --------------- | | Echoed Src Address | | Echoed Dst port number | | Tentative HA Tunnel Address | | Reply Code 0 "Accepted MN and port" | | TMTA | | | ---- Tunnel "Acknowledgement" --> | | Connection ID | | Reply Code 0 "Accepted HA and port" | | THTA | DPN ~ ... ~ | -----Tunnel "Keepalive" --------> | | Connection ID | | | Auto-configuration of MN Tunnel Address MN HA | ---- Tunnel Request ------------> | | IP src address | | Tentative UDP dst port number| | Tentative MN Tunnel Address1 | | | | <--- Tunnel Reply --------------- | | Echoed Src Address | | Echoed Dst port number | | Tentative HA Tunnel Address | | Reply Code 1 "Not Accepted MN" | TMTA | | | ---- Tunnel Request ------------> | | Tentative MN Tunnel Address2 | | Sub-type 3 "Accepted HA, new MN" | THTA | | | <--- Tunnel Reply --------------- | | Reply Code 0 "Accepted MN" | | TMTA | | | ---- Tunnel "Acknowledgement" --> | | Reply Code 0 "Accepted" | | | ~ ... ~ | -----Tunnel "Keepalive" --------> | | Connection ID | | | Auto-configuration of HA Tunnel Address MN HA | ---- Tunnel Request ------------> | | IP src address | | Tentative UDP dst port number| | Tentative MN Tunnel Address | | | | <--- Tunnel Reply --------------- | | Echoed Src Address | | Echoed Dst port number | | Tentative HA Tunnel Address | | Reply Code 0 "Accepted MN" | | | | ---- Tunnel Request ------------> | | Sub-type 4 "Not Accepted HA" | | | | <--- Tunnel Reply --------------- | | Tentative HA Tunnel Address2 | | | | ---- Tunnel "Acknowledgement" --> | | Connection ID | | Reply Code 0 "Accepted" | | | ~ ... ~ | -----Tunnel "Keepalive" --------> | | Connection ID | | | UDP Tunnel Request Extension, MN to HA 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Reserved 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|R| Reserved 2| Encapsulation | Reserved 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tentative MN Tunnel Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-type: 1 Discover NAT, port and propose address MN Tunnel Address: suggests local IPv4 address that will be used as local tunnel endpoint. UDP Tunnel Reply Extension, HA to MN 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Reply Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Reserved | Keepalive Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA Tunnel Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Echoed Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Echoed Dst Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 44 Sub-type: 1 Echoed src addr/port and propose address Reply Code: 0 Accepted MN Tunnel Address 1 Not Accepted MN Tunnel Address UDP Tunnel Reply Extension, "Acknowledgement", MN to HA 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Reply Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Reserved | Keepalive Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 44 Sub-type: 2 Acknowledgement Reply Code: 0 Accepted HA Tunnel Address 1 Not Accepted HA Tunnel Address 2 No NAT Present, don't use any Connection ID (and Connection ID field not present). (and Keepalive Interval field not present). UDP Tunnel Request Extension, "Keepalive", MN to HA 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Reserved 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|R| Reserved 2| Encapsulation | Reserved 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 144 Sub-type: 2 HA-NAT State Keepalive (TBA) Tunnel Data Message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Next Header | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3012, Generalized MIP Auth Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 16 05:41:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI0Wz-0006ZO-8j; Fri, 16 Feb 2007 05:41:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI0Wx-0006YT-25; Fri, 16 Feb 2007 05:41:31 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI0Wv-0005RR-Pv; Fri, 16 Feb 2007 05:41:31 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8CB77198775; Fri, 16 Feb 2007 12:41:26 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4E2A71986DF; Fri, 16 Feb 2007 12:41:26 +0200 (EET) Message-ID: <45D58A57.7070901@piuha.net> Date: Fri, 16 Feb 2007 12:41:27 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] Re: FW: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt References: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com> <45D4E2ED.8040702@piuha.net> <45D5889C.3060701@motorola.com> In-Reply-To: <45D5889C.3060701@motorola.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Alex, > > Known mechanisms have been shown to assist with the issues described in > this document: 6to4 tunnel between MN and a Gateway, RAs over that > tunnel and HA separated from the gateway. Just 6to4, ND and Mobile IPv6, > no protocol modifications. > Ok. Do you have alternative suggested text that would better characterize the situation? Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 16 05:59:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI0oK-0004Nm-UI; Fri, 16 Feb 2007 05:59:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI0oJ-0004NT-Ld; Fri, 16 Feb 2007 05:59:27 -0500 Received: from mail127.messagelabs.com ([216.82.250.115]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HI0oI-0008UD-Au; Fri, 16 Feb 2007 05:59:27 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-13.tower-127.messagelabs.com!1171623066!11672103!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 17075 invoked from network); 16 Feb 2007 10:51:06 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-13.tower-127.messagelabs.com with SMTP; 16 Feb 2007 10:51:06 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l1GAp1oC021109; Fri, 16 Feb 2007 03:51:01 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l1GAox8W012162; Fri, 16 Feb 2007 04:51:00 -0600 (CST) Message-ID: <45D58C93.3000009@motorola.com> Date: Fri, 16 Feb 2007 11:50:59 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip6] Re: FW: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt References: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com> <45D4E2ED.8040702@piuha.net> <45D5889C.3060701@motorola.com> <45D58A57.7070901@piuha.net> In-Reply-To: <45D58A57.7070901@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Jari Arkko wrote: > Hi Alex, > > >> Known mechanisms have been shown to assist with the issues >> described in this document: 6to4 tunnel between MN and a Gateway, >> RAs over that tunnel and HA separated from the gateway. Just 6to4, >> ND and Mobile IPv6, no protocol modifications. >> > Ok. Do you have alternative suggested text that would better > characterize the situation? It is very difficult to write text along these lines. It is very difficult to discard existing IETF transitioning methods as not addressing the needs of DS-MIPv6. Maybe this: > The IETF has standardized a number of transition mechanisms to allow > networks and end nodes to gain IPv6 connectivity while the Internet > is migrating from IPv4 to IPv6. However, while some transition > mechanisms could be combined with Mobile IPv6, it takes too much time > to analyze how they could work together, hence the need to design > from scratch a new extension to MIPv6. Not sure how else could I put it. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 16 12:22:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI6mo-0002Gx-WC; Fri, 16 Feb 2007 12:22:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI6mn-0002Gm-Fj for mip6@ietf.org; Fri, 16 Feb 2007 12:22:17 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI6ml-00042R-T2 for mip6@ietf.org; Fri, 16 Feb 2007 12:22:17 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 0B30B90081 for ; Fri, 16 Feb 2007 12:22:12 -0500 (EST) 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 02271-18 for ; Fri, 16 Feb 2007 12:22:07 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 16 Feb 2007 12:22:07 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 12:22:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Date: Fri, 16 Feb 2007 12:22:07 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD900@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Thread-Index: AcdQY1dNlaD6hLxWEduSnQARJNUNiAAI4fFAAFiixMA= From: "Chowdhury, Kuntal" To: "Tsirtsis, George" , "Basavaraj Patil" , X-OriginalArrivalTime: 16 Feb 2007 17:22:07.0448 (UTC) FILETIME=[FBF3E580:01C751EE] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 1.1 (+) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi George, Thanks for your comment. Please see inline.... -Kuntal > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > Sent: Wednesday, February 14, 2007 4:31 PM > To: Basavaraj Patil; mip6@ietf.org > Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 >=20 > I have the following questions. I appologise in advance if this issues > have been discussed sine I have not followed the discussions closely. >=20 > In section 3.2.2. (Home Agent allocation in the ASP), It is not clear > what happens if the DHC server is not configured to assign local HAs to > visiting MNs. >=20 [KC>] In that case the DHCP server won't return local HA address to the MN. This is normal DHCP server behavior. It includes information in the reply based on its configuration. RFC 3315 says the following: " If the client included an Option Request option in its message, the server includes options in the Reply message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. The server MAY return additional options to the client if it has been configured to do so. " So, it is upto the local DHCP server configuration and the availability of the HA information in OPTION_MIP6-RELAY-Option. If the MN does not receive what it requested i.e. HA in the local network, it can send another information request to the DHCP server requesting HA address in the home domain (MSP) or indicate no preference i.e. id-type=3D2. > Also, would it be possible for a mobile to ask for both visited and home > HAs? One way would be to allow two Home Network Identifier Options, one > with id-type set to 1 and another with id-type set to 0 so that the MN > can request both MSP and ASP HAs. Another way would be to define > id-type=3D4 "Visited and home domain" in draft-ietf-mip6-hiopt-01.txt. >=20 > Thoughts? >=20 [KC>] It may be possible for the MN to request HA information for both visited (ASP) and home (MSP) domains in the same information request message. The current hiopt I-D has the necessary options / sub-options defined to do what you suggested. We have to make sure that there is appropriate text around it in that I-D. > George >=20 > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > > Sent: Wednesday, February 14, 2007 1:10 PM > > To: mip6@ietf.org > > Subject: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 > > > > > > Hello, > > > > This is a MIP6 Working group last call for the WG I-D: > > "MIP6-bootstrapping for the Integrated Scenario", > > draft-ietf-mip6-bootstrapping-integrated-02.txt > > > > I-D: > > > http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated > - > > dhc > > -02.txt > > > > Please review and submit your comments to the authors or the mailing > > list. The WGLC will expire on March 1st, 07. > > > > -Chairs > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 16 15:51:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIA32-00030x-0f; Fri, 16 Feb 2007 15:51:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIA2q-0002nx-4i; Fri, 16 Feb 2007 15:51:04 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HIA2p-0000Vh-NK; Fri, 16 Feb 2007 15:51:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 32E3017635; Fri, 16 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HIA1q-0000d4-H9; Fri, 16 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 16 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-hiopt-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : DHCP Option for Home Information Discovery in MIPv6 Author(s) : H. Jang, et al. Filename : draft-ietf-mip6-hiopt-02.txt Pages : 22 Date : 2007-2-16 This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home agent address, home address, and home subnet. New DHCP options are defined to carry the information from a DHCP server to the DHCP client running on the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-hiopt-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-hiopt-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-16130448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-hiopt-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-hiopt-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-16130448.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Mon Feb 19 05:46:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ61p-0005S8-4l; Mon, 19 Feb 2007 05:45:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ61m-0005Ox-Rb for mip6@ietf.org; Mon, 19 Feb 2007 05:45:51 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJ61l-0006JO-IM for mip6@ietf.org; Mon, 19 Feb 2007 05:45:50 -0500 Received: by nf-out-0910.google.com with SMTP id l36so2513597nfa for ; Mon, 19 Feb 2007 02:45:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dEvq1nbV0vfcEp+62LTGMbjINnTNT8v0VvUgKgmIShwHtwayAzlnCnYPgj5AJX9Ae06o2HA5jsjDG/Tk5FFUdpbmrgER0bHopsCEf29AuxhYidbV9mbVRY7YM4TklqY5d4/bhaME4husBmKq2gTe+TDSRnZXa0VboH1pbDRFNbc= Received: by 10.82.152.16 with SMTP id z16mr10562945bud.1171881948718; Mon, 19 Feb 2007 02:45:48 -0800 (PST) Received: by 10.82.126.11 with HTTP; Mon, 19 Feb 2007 02:45:48 -0800 (PST) Message-ID: <5e2406980702190245y3a4df7a6qa62a3010047100d1@mail.gmail.com> Date: Mon, 19 Feb 2007 11:45:48 +0100 From: "Julien Bournelle" To: mip6@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Mip6] draft-ietf-mip6-radius-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, I quickly read the document called: draft-ietf-mip6-radius-01.txt I have one general question: In the split scenario, how does the RADIUS server know that it is performing AAA for mip6 service and not for network access ? (FYI, we encounter this problem in the DiME WG and we'll solve this by using a different Application ID.) Some editorials comments: section 3.2: "Since scenario (1) is the more generic..." I think you wanted to say "scenario (2) section 4.2 s/HOA/HA section 5 I think you can add Access-Request message since the MIP6-DNS-MO may be sent in this message (if I understood well). My 2 cents, Julien _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 19 06:20:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ6Z2-0006LF-Po; Mon, 19 Feb 2007 06:20:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ6Z2-0006Kj-BX for mip6@ietf.org; Mon, 19 Feb 2007 06:20:12 -0500 Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJ6Z0-00063f-Um for mip6@ietf.org; Mon, 19 Feb 2007 06:20:12 -0500 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id l1JBK38F006834 for ; Mon, 19 Feb 2007 13:20:03 +0200 (EET) Received: from [131.177.105.234] (ws234.secureuser.sonera.fi [131.177.105.234]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id l1JBK0jV006829 for ; Mon, 19 Feb 2007 13:20:00 +0200 (EET) Message-ID: <45D987DF.2000204@teliasonera.com> Date: Mon, 19 Feb 2007 13:19:59 +0200 From: Jouni Korhonen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Mip6] MN-NAI option and decoration X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, Just wondering whether decorated NAIs are actually OK within RFC4283 MN-NAI option. RFC4283 references to RFC4282 without giving any explicit restrictions on NAI usage so I assume whatever decoration or username convention can be used as long as it conforms RC4282 NAI..? Cheers, Jouni _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 19 17:13:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJGkP-0000uR-96; Mon, 19 Feb 2007 17:12:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJGkO-0000rc-Ep for mip6@ietf.org; Mon, 19 Feb 2007 17:12:36 -0500 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 1HJGkM-0000Tx-Vk for mip6@ietf.org; Mon, 19 Feb 2007 17:12:36 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1JMAC2V020353 for ; Tue, 20 Feb 2007 00:10:22 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 00:11:43 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 16:11:37 -0600 Received: from 172.19.244.104 ([172.19.244.104]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Feb 2007 22:11:37 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 19 Feb 2007 16:14:13 -0600 From: Basavaraj Patil To: Message-ID: Thread-Topic: Volunteer to keep track of issues w.r.t RFC3775 Thread-Index: AcdUc0k8h58g+cBmEduYfAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Feb 2007 22:11:37.0805 (UTC) FILETIME=[ECBB47D0:01C75472] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070220001022-4CA54BB0-56B39A14/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Mip6] Volunteer to keep track of issues w.r.t RFC3775 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, As we are moving forward with developing various extensions and enhancements to Mobile IPv6, we also need to ensure that we are Identifying and tracking any issues with the base protocol (RFC 3775) itself. In fact the charter states: " Additionally the working group will ensure that any issues identified by implementation and interoperability experience are addressed, and that the base specifications are maintained. " We need a volunteer who will maintain such a list of issues that are identified and discussed on the mailing list. Please send the chairs a note if you would be willing to act as the base-spec issue tracker. -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 19 18:18:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJHlK-0001FJ-Te; Mon, 19 Feb 2007 18:17:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJHlJ-0001FD-7t for mip6@ietf.org; Mon, 19 Feb 2007 18:17:37 -0500 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 1HJHlH-0006g4-P8 for mip6@ietf.org; Mon, 19 Feb 2007 18:17:37 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1JNF9jP007610 for ; Tue, 20 Feb 2007 01:15:23 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 01:17:15 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 17:17:11 -0600 Received: from 172.19.244.104 ([172.19.244.104]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Feb 2007 23:17:11 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 19 Feb 2007 17:19:47 -0600 From: Basavaraj Patil To: Message-ID: Thread-Topic: WG LC: draft-ietf-mip6-ha-switch-02.txt Thread-Index: AcdUfHIUsKFpvsBvEduYfAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Feb 2007 23:17:12.0149 (UTC) FILETIME=[15C88850:01C7547C] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070220011523-18D35BB0-277C64F5/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Mip6] WG LC: draft-ietf-mip6-ha-switch-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, This is a working group last call for the I-D: Mobility Header Home Agent Switch Message This revision of the I-D has been submitted in Dec, 06. The expiry of the I-D should say June 07 and not June 06 (typo in the I-D). Please review the I-D and send your comments to the mailing list by March 8th, 07. -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 20 02:32:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJPT6-0005dU-D0; Tue, 20 Feb 2007 02:31:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJPT5-0005dP-3O for mip6@ietf.org; Tue, 20 Feb 2007 02:31:19 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJPT3-0003r8-V7 for mip6@ietf.org; Tue, 20 Feb 2007 02:31:19 -0500 Received: from ep_ms5_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JDR006D23JUGS@mailout2.samsung.com> for mip6@ietf.org; Tue, 20 Feb 2007 16:31:06 +0900 (KST) Received: from ep_spt01 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JDR0049H3JT7Y@ms5.samsung.com> for mip6@ietf.org; Tue, 20 Feb 2007 16:31:06 +0900 (KST) Content-return: prohibited Date: Tue, 20 Feb 2007 07:31:06 +0000 (GMT) From: Heejin Jang Subject: Re: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 To: Kilian Weniger Message-id: <0JDR0049I3JT7Y@ms5.samsung.com> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20070220073105201@heejin.jang X-MTR: 20070220073105201@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-Generator: NamoMIME 6.0.0.8 X-Spam-Score: 4.5 (++++) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: "mip6@ietf.org" , Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0746239942==" Errors-To: mip6-bounces@ietf.org --===============0746239942== Content-return: prohibited Content-type: text/html; charset=windows-1252 Content-transfer-encoding: base64 PEhUTUw+PEhFQUQ+CjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9J3RleHQv aHRtbDsgY2hhcnNldD13aW5kb3dzLTEyNTInPgo8dGl0bGU+U2Ftc3VuZyBFbnRlcnByaXNlIFBv cnRhbCBteVNpbmdsZTwvdGl0bGU+CjxzdHlsZT4gUCwgdGQsIGxpIHtmb250LWZhbWlseTpBcmlh bCwgYXJpYWw7IGZvbnQtc2l6ZTo5cHQ7IG1hcmdpbi10b3A6NXB4O21hcmdpbi1ib3R0b206NXB4 O30gYm9keXtmb250LWZhbWlseTpBcmlhbCwgYXJpYWw7IGZvbnQtc2l6ZTo5cHQ7fTwvc3R5bGU+ CjwvSEVBRD48Qk9EWT5IaSwgJm5ic3A7S2lsaWFuIFdlbmlnZXIuDQo8cD5UaGFua3MgZm9yIHRo ZSBkZXRhaWxlZGwgY29tbWVudHMuIDwvcD4NCjxwPlBsZWFzZSBzZWUgdGhlIGlubGluZSBjb21t ZW50cyBmb3IgdGhlIEhJT1BUIGRyYWZ0LjwvcD4NCjxicj4tLS0tLS0tIDxiPk9yaWdpbmFsIE1l c3NhZ2U8L2I+IC0tLS0tLS08YnI+PGI+U2VuZGVyPC9iPiA6IEtpbGlhbiBXZW5pZ2VyJmx0O0tp bGlhbi5XZW5pZ2VyQGV1LnBhbmFzb25pYy5jb20mZ3Q7PGJyPjxiPkRhdGU8L2I+ICAgOiAyMDA3 LTAyLTE2IDE3OjMxPGJyPjxiPlRpdGxlPC9iPiAgOiBSRTogW01pcDZdIFdHTEM6IGRyYWZ0LWll dGYtbWlwNi1ib290c3RyYXBwaW5nLWludGVncmF0ZWQtMDI8YnI+PGJyPkhpLA0KPGJyPg0KPGJy PnBsZWFzZSZuYnNwO2ZpbmQmbmJzcDtiZWxvdyZuYnNwO3NvbWUmbmJzcDtjb21tZW50cyZuYnNw O2Fib3V0Jm5ic3A7DQo8YnI+ZHJhZnQtaWV0Zi1taXA2LWJvb3RzdHJhcHBpbmctaW50ZWdyYXRl ZC0wMi4NCjxicj4NCjxicj5UaGUmbmJzcDtkcmFmdCZuYnNwO2lzJm5ic3A7d2VsbCZuYnNwO3dy aXR0ZW4mbmJzcDthbmQmbmJzcDtlYXN5Jm5ic3A7dG8mbmJzcDt1bmRlcnN0YW5kJm5ic3A7KHRo YW5rcyZuYnNwO3RvJm5ic3A7ZmlndXJlcyZuYnNwO2FuZA0KPGJyPm1lc3NhZ2UmbmJzcDtzZXF1 ZW5jZSZuYnNwO3RleHQpLiZuYnNwO0hvd2V2ZXIsJm5ic3A7c29tZSZuYnNwO2RldGFpbHMmbmJz cDthbmQmbmJzcDtjb3JuZXImbmJzcDtjYXNlcyZuYnNwO2FyZSZuYnNwO25vdA0KPGJyPmFkZHJl c3NlZCwmbmJzcDt3aGljaCZuYnNwO21heSZuYnNwO25lZWQmbmJzcDt0byZuYnNwO2JlJm5ic3A7 c3BlY2lmaWVkLCZuYnNwO2UuZy46DQo8YnI+DQo8YnI+LSZuYnNwO0hvdyZuYnNwO2RvZXMmbmJz cDt0aGUmbmJzcDtOQVMvcmVsYXkmbmJzcDttYXAmbmJzcDthJm5ic3A7REhDUCZuYnNwO3JlcXVl c3QmbmJzcDtyZWNlaXZlZCZuYnNwO2Zyb20mbmJzcDthJm5ic3A7c3BlY2lmaWMmbmJzcDtNTiZu YnNwOw0KPGJyPiZuYnNwOyZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7Y2FjaGVkJm5ic3A7aG9tZSZu YnNwO25ldHdvcmsmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO3ByZXZpb3VzbHkmbmJzcDtyZWNlaXZl ZCZuYnNwO2Zyb20mbmJzcDtBQUFIJm5ic3A7DQo8YnI+Jm5ic3A7Jm5ic3A7Zm9yJm5ic3A7dGhp cyZuYnNwO01OLCZuYnNwO3NvJm5ic3A7dGhhdCZuYnNwO2l0Jm5ic3A7Y2FuJm5ic3A7aW5jbHVk ZSZuYnNwO3RoZSZuYnNwO2NvcnJlY3QmbmJzcDtob21lJm5ic3A7bmV0d29yayZuYnNwOw0KPGJy PiZuYnNwOyZuYnNwO2luZm9ybWF0aW9uJm5ic3A7aW4mbmJzcDthJm5ic3A7cmVjZWl2ZWQmbmJz cDtESENQJm5ic3A7cmVxdWVzdD8NCjxwPiZuYnNwOzwvcD4NCjxwPkhpb3B0Jmd0OyZndDsgVGhl IG1hcHBpbmcgbWVjaGFuaXNtIGlzIGFkZGVkIGluIHNlY3Rpb24gNC4zIG9mIHRoZSBsYXRlc3Qg DQp2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCAoaGlvcHQtMDIpLjwvcD4NCjxwPlRoZSBpbmZvcm1h dGlvbiBpcyBtYXBwZWQgYmFzZWQgb24gTkFJIG5vdCBieSBOQVMgYnV0IGJ5IERIQ1Agc2VydmVy LiBScmVmZXIgDQp0byBoaW9wdC0wMiBmb3IgbW9yZSBkZXRhaWxzLjwvcD4NCjxwPjxicj4tJm5i c3A7V2hhdCZuYnNwO2lzJm5ic3A7dGhlJm5ic3A7Y29uY2VwdHVhbCZuYnNwO2RhdGEmbmJzcDtz dHJ1Y3R1cmUmbmJzcDtuZWVkZWQmbmJzcDtmb3ImbmJzcDt0aGlzJm5ic3A7aW4mbmJzcDt0aGUm bmJzcDtOQVMvREhDUCZuYnNwOw0KPGJyPiZuYnNwOyZuYnNwO3JlbGF5Pw0KPGJyPi0mbmJzcDtB bnkmbmJzcDtkZWZhdWx0Jm5ic3A7dmFsdWUmbmJzcDtmb3ImbmJzcDtob3cmbmJzcDtsb25nJm5i c3A7TkFTJm5ic3A7c2hvdWxkJm5ic3A7Y2FjaGUmbmJzcDtob21lJm5ic3A7bmV0d29yayZuYnNw Ow0KPGJyPiZuYnNwOyZuYnNwO2luZm9ybWF0aW9uJm5ic3A7cmVjZWl2ZWQmbmJzcDtmcm9tJm5i c3A7QUFBJm5ic3A7Zm9yJm5ic3A7YSZuYnNwO3NwZWNpZmljJm5ic3A7TU4mbmJzcDsoaS5lLiwm bmJzcDt3aGVuJm5ic3A7aXMmbmJzcDtOQVMmbmJzcDsNCjxicj4mbmJzcDsmbmJzcDthbGxvd2Vk Jm5ic3A7dG8mbmJzcDtkZWxldGUmbmJzcDtjYWNoZSZuYnNwO2VudHJ5Pyk/Jm5ic3A7SWYmbmJz cDt0aGlzJm5ic3A7aXMmbmJzcDtzcGVjaWZpZWQmbmJzcDtpbiZuYnNwO1tNSVA2LURpbWVdJm5i c3A7DQo8YnI+Jm5ic3A7Jm5ic3A7b3ImbmJzcDtbTUlQNi1SQURJVVNdJm5ic3A7aXQmbmJzcDtz aG91bGQmbmJzcDtiZSZuYnNwO21lbnRpb25lZCZuYnNwO2FuZCZuYnNwO3JlZmVyZW5jZWQuJm5i c3A7DQo8L3A+DQo8cD5IaW9wdCZndDsmZ3Q7IFRoaXMgaXMgaW1wbGVtZW50YXRpb24tc3BlY2lm aWMuIEknbSBub3Qgc3VyZSB3ZSBuZWVkIHRvIGRlc2NyaWJlIA0KZG93biB0byB0aGUgc21hbGxl c3QgZGV0YWlsLiA8L3A+DQo8cD48YnI+LSZuYnNwO1doYXQmbmJzcDtzaG91bGQmbmJzcDtOQVMm bmJzcDtkbyZuYnNwO2lmJm5ic3A7REhDUCZuYnNwO3JlcXVlc3QmbmJzcDt3aXRoJm5ic3A7SG9t ZSZuYnNwO25ldHdvcmsmbmJzcDtpZGVudGlmaWVyJm5ic3A7DQo8YnI+Jm5ic3A7Jm5ic3A7b3B0 aW9uJm5ic3A7aXMmbmJzcDtyZWNlaXZlZCZuYnNwO2Zyb20mbmJzcDthJm5ic3A7TU4mbmJzcDth bmQmbmJzcDtOQVMmbmJzcDtkb2VzbiYjMzk7dCZuYnNwO2ZpbmQmbmJzcDt2YWxpZCZuYnNwO2hv bWUmbmJzcDtuZXR3b3JrJm5ic3A7DQo8YnI+Jm5ic3A7Jm5ic3A7aW5mb3JtYXRpb24mbmJzcDtm b3ImbmJzcDt0aGlzJm5ic3A7TU4mbmJzcDtpbiZuYnNwO2l0cyZuYnNwO2NhY2hlJm5ic3A7KGUu Zy4sJm5ic3A7c2luY2UmbmJzcDt0aGUmbmJzcDtjYWNoZSZuYnNwO2VudHJ5Jm5ic3A7DQo8YnI+ Jm5ic3A7Jm5ic3A7aGFzJm5ic3A7ZXhwaXJlZCk/DQo8L3A+DQo8cD4mbmJzcDs8L3A+DQo8cD5I aW9wdCZndDsmZ3Q7SW4gdGhhdCBjYXNlLCB0aGVyZSBpcyBub3RoaW5nIE5BUyBjYW4gZG8uIElm IHRoZSAmbmJzcDtjb3JyZXNwb25kaW5nIA0KaW5mb3JtYXRpb24gPC9wPg0KPHA+aXMgY29uZmln dXJlZCBvbiB0aGUgREhDUCBzZXJ2ZXIgKGZvciBlLmcuLCBwcmUtY29uZmlndXJhdGlvbiksIHRo ZSBzZXJ2ZXIgDQp3aWxsPC9wPg0KPHA+cHJvdmlkZSBpdC4gT3RoZXJ3aXNlLCBpdCB3aWxsIHJl cGx5IHdpdGggMC1sZW5naCBvcHRpb24uPC9wPg0KPHA+PGJyPi0mbmJzcDtXaGF0Jm5ic3A7c2hv dWxkJm5ic3A7REhDUCZuYnNwO3JlbGF5L3NlcnZlciZuYnNwO2RvJm5ic3A7aWYmbmJzcDt0aGUm bmJzcDtNTiZuYnNwO2RvZXMmbmJzcDtub3QmbmJzcDtpbmNsdWRlJm5ic3A7dGhlJm5ic3A7DQo8 YnI+Jm5ic3A7Jm5ic3A7T1BUSU9OX0NMSUVOVElEJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtESENQ Jm5ic3A7cmVxdWVzdCZuYnNwO29yJm5ic3A7aWYmbmJzcDtPUFRJT05fTUlQNi1SRUxBWS1PcHRp b24mbmJzcDsNCjxicj4mbmJzcDsmbmJzcDtpcyZuYnNwO21pc3NpbmcmbmJzcDtpbiZuYnNwO3Jl cXVlc3Q/DQo8YnI+DQo8L3A+DQo8cD4mbmJzcDs8L3A+DQo8cD5IaW9wdCZndDsmZ3Q7IFRoZSBl eGlzdGluZyBESENQIG9wdGlvbnMgYXJlIGhhbmRsZWQgYWNjb3JkaW5nIHRvIFtSRkMgMzMxNV0u PC9wPg0KPHA+VGhlIHJlcXVlc3Qgbm90IGluY2x1ZGluZyBPUFRJT05fQ0xJRU5USUQgaXMgZGlz Y2FyZGVkIGluIHRoZSByZWxheS9zZXJ2ZXI8L3A+DQo8cD5hcyBkZXNjcmliZWQgaW4gMTUuNCBv ZiBbUkZDIDMzMTVdLiA8L3A+DQo8cD48YnI+VGhlJm5ic3A7ZHJhZnQmbmJzcDttYXkmbmJzcDtu ZWVkJm5ic3A7YmV0dGVyJm5ic3A7YWxpZ25lZCZuYnNwO3dpdGgmbmJzcDtbSElPUFRdLiZuYnNw O0ZvciZuYnNwO2luc3RhbmNlLCZuYnNwO2l0Jm5ic3A7aXMmbmJzcDtub3QNCjxicj5jbGVhciZu YnNwO3RvJm5ic3A7bWUmbmJzcDtob3cmbmJzcDtleGFjdGx5Jm5ic3A7dGhlJm5ic3A7aG9tZSZu YnNwO25ldHdvcmsmbmJzcDtpZGVudGlmaWVyJm5ic3A7b3B0aW9uJm5ic3A7YW5kJm5ic3A7dGhl Jm5ic3A7aG9tZSZuYnNwOw0KPGJyPm5ldHdvcmsmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO29wdGlv biZuYnNwO3NwZWNpZmllZCZuYnNwO2luJm5ic3A7W0hJT1BUXSZuYnNwO2FyZSZuYnNwO2FsbG93 ZWQmbmJzcDt0byZuYnNwO2JlJm5ic3A7dXNlZA0KPGJyPmluJm5ic3A7ZHJhZnQtaWV0Zi1taXA2 LWJvb3RzdHJhcHBpbmctaW50ZWdyYXRlZC0wMjombmJzcDsNCjxicj4NCjxicj4tJm5ic3A7W0hJ T1BUXSZuYnNwO3N1cHBvcnRzJm5ic3A7aG9tZSZuYnNwO2FkZHJlc3MmbmJzcDthbGxvY2F0aW9u LiZuYnNwO1RoaXMmbmJzcDtpcyZuYnNwO25vdCZuYnNwO21lbnRpb25lZCZuYnNwO2luJm5ic3A7 DQo8YnI+Jm5ic3A7Jm5ic3A7ZHJhZnQtaWV0Zi1taXA2LWJvb3RzdHJhcHBpbmctaW50ZWdyYXRl ZC0wMi4mbmJzcDtJcyZuYnNwO3RoaXMmbmJzcDtmb3JiaWRkZW4mbmJzcDtvciZuYnNwOw0KPGJy PiZuYnNwOyZuYnNwO2FsbG93ZWQmbmJzcDtvciZuYnNwO291dC1vZi1zY29wZT8mbmJzcDtJZiZu YnNwO2FsbG93ZWQsJm5ic3A7d2hlbiZuYnNwO2RvZXMmbmJzcDtOQVMmbmJzcDtzZXQmbmJzcDt0 aGUmbmJzcDtBLWZsYWcmbmJzcDtpbiZuYnNwOw0KPGJyPiZuYnNwOyZuYnNwO3RoZSZuYnNwO2hv bWUmbmJzcDtuZXR3b3JrJm5ic3A7aWRlbnRpZmllciZuYnNwO29wdGlvbj8NCjwvcD4NCjxwPiZu YnNwOzwvcD4NCjxwPkhpb3B0Jmd0OyZndDsgTkFTIFNIT1VMRCBub3QgbW9kaWZ5IHRoZSBIb21l IE5ldHdvcmsgSWRlbnRpZmllciBvcHRpb24uIDwvcD4NCjxwPlRoZSBBLWZsYWcgaXMgc2V0IHRv IDAvMSBvbmx5IGJ5IHRoZSBtb2JpbGUgbm9kZS4gSWYgdGhlcmUgaXMgaG9tZSBhZGRyZXNzPC9w Pg0KPHA+aW5mb3JtYXRpb24gYXQgTkFTIHRoYXQgd2FzIGFjcXVpcmVkIGR1cmluZyBBQUEgdHJh bnNhY3Rpb24sIGl0IGlzIGRlbGl2ZXJlZDwvcD4NCjxwPnRvIHRoZSBESENQIHNlcnZlciB3aXRo IE1JUDYtUmVsYXkgb3B0aW9uLiAoUmVmZXIgaGlvcHQtMDIudHh0KTwvcD4NCjxwPjxicj4tJm5i c3A7SXMmbmJzcDtpdCZuYnNwO2FsbG93ZWQmbmJzcDt0aGF0Jm5ic3A7bXVsdGlwbGUmbmJzcDtI QSZuYnNwO2FkZHJlc3NlcyZuYnNwO2FyZSZuYnNwO3JldHVybmVkJm5ic3A7aW4mbmJzcDt0aGUm bmJzcDtob21lJm5ic3A7DQo8YnI+Jm5ic3A7Jm5ic3A7bmV0d29yayZuYnNwO2luZm9ybWF0aW9u Jm5ic3A7b3B0aW9uPw0KPC9wPg0KPHA+Jm5ic3A7PC9wPg0KPHA+SGlvcHQmZ3Q7Jmd0OyBJdCBp cyBhbGxvd2VkIGJ5IHVzaW5nIG11bHRpcGxlIGhvbWUgbmV0d29yayBpbmZvcm1hdGlvbiBvcHRp b24uPC9wPg0KPHA+Jm5ic3A7Jm5ic3A7JnF1b3Q7TXVsdGlwbGUgc3ViLW9wdGlvbnMgbWF5IGV4 aXN0IGluIGEgSG9tZSBOZXR3b3JrIEluZm9ybWF0aW9uIA0Kb3B0aW9uPC9wPg0KPHA+Jm5ic3A7 Jm5ic3A7Jm5ic3A7dG8gY2FycnkgbW9yZSB0aGFuIG9uZSBob21lIGluZm9ybWF0aW9uLiZxdW90 OyAoaW4gc2VjdGlvbiANCjMuMy4xKTwvcD4NCjxwPjxicj4tJm5ic3A7W0hJT1BUXSZuYnNwO2Fs bG93cyZuYnNwO3RoYXQmbmJzcDt0aGUmbmJzcDtob21lJm5ic3A7bmV0d29yayZuYnNwO2lkZW50 aWZpZXImbmJzcDtvcHRpb24mbmJzcDtpbmNsdWRlcyZuYnNwO2FuJm5ic3A7DQo8YnI+Jm5ic3A7 Jm5ic3A7aWRlbnRpZmllciZuYnNwO29mJm5ic3A7YSZuYnNwO3RhcmdldCZuYnNwO25ldHdvcmss Jm5ic3A7d2hpY2gmbmJzcDtpcyZuYnNwO2RpZmZlcmVudCZuYnNwO2Zyb20mbmJzcDtob21lJm5i c3A7b3ImbmJzcDsNCjxicj4mbmJzcDsmbmJzcDt2aXNpdGVkJm5ic3A7bmV0d29yayZuYnNwO29m Jm5ic3A7TU4uJm5ic3A7VGhpcyZuYnNwO2lzJm5ic3A7bm90Jm5ic3A7bWVudGlvbmVkJm5ic3A7 aW4mbmJzcDsNCjxicj4mbmJzcDsmbmJzcDtkcmFmdC1pZXRmLW1pcDYtYm9vdHN0cmFwcGluZy1p bnRlZ3JhdGVkLTAyLiZuYnNwO0lzJm5ic3A7dGhpcyZuYnNwO2FsbG93ZWQmbmJzcDtvciZuYnNw Ow0KPGJyPiZuYnNwOyZuYnNwO2ZvcmJpZGRlbj8NCjwvcD4NCjxwPiZuYnNwOzwvcD4NCjxwPkhp b3B0Jmd0OyZndDsgQSB0YXJnZXQgbmV0d29yayBtYXkgb3IgbWF5IG5vdCBiZSBob21lIG5ldHdv cmsgb2YgdGhlIE1OLiANCiZuYnNwOzwvcD4NCjxwPkluIGN1cnJlbnQgZHJhZnQsIHRoZSBzZXJ2 ZXIgaXMgc3VwcG9zZWQgdG8gcHJvdmlkZSB0aGUgSEEgaW5mb3JtYXRpb24gaWYgDQppdCBoYXM8 L3A+DQo8cD50aGUgY29ycmVzcG9uZGluZyBpbmZvcm1hdGlvbi4gSWYgdGhlIGdpdmVuIEhBIGRv ZXMgbm90IGZ1bmN0aW9uIGFzIEhBIGZvcjwvcD4NCjxwPnRoZSByZXF1ZXN0aW5nIE1OLCBpdCB3 aWxsIHJlcGx5IHdpdGggdGhlIEJBIHN0YXR1cyA9IDEzMiBvciAxMzMgJm5ic3A7PC9wPg0KPHA+ KE5vdCBob21lIHN1Ym5ldCAvIGhvbWUgYWdlbnQgZm9yIHRoaXMgbW9iaWxlIG5vZGUpIGR1cmlu ZyBNTidzIHJlZ2lzdHJhdGlvbi48L3A+DQo8cD48YnI+LSZuYnNwO1doaWNoJm5ic3A7SEEmbmJz cDtpbmZvcm1hdGlvbiZuYnNwO3Nob3VsZCZuYnNwO3RoZSZuYnNwO01OJm5ic3A7dXNlJm5ic3A7 aWYmbmJzcDtpdCZuYnNwO3JlY2VpdmVzLCZuYnNwO2UuZy4sJm5ic3A7YW4mbmJzcDtGUUROJm5i c3A7DQo8YnI+Jm5ic3A7Jm5ic3A7YW5kJm5ic3A7YSZuYnNwO0hBJm5ic3A7YWRkcmVzcyZuYnNw O2luJm5ic3A7REhDUCZuYnNwO3JlcGx5PyZuYnNwO1tISU9QVF0mbmJzcDtyZWZlcnMmbmJzcDt0 byZuYnNwO3NlY3Rpb24mbmJzcDszLjYmbmJzcDtvZiZuYnNwOw0KPGJyPiZuYnNwOyZuYnNwO2Ry YWZ0LWlldGYtbWlwNi1ib290c3RyYXBwaW5nLWludGVncmF0ZWQtMDEsJm5ic3A7YnV0Jm5ic3A7 dGhpcyZuYnNwO3NlY3Rpb24mbmJzcDtkb2VzbiYjMzk7dA0KPGJyPiZuYnNwOyZuYnNwO2V4aXN0 Jm5ic3A7aW4mbmJzcDtkcmFmdC1pZXRmLW1pcDYtYm9vdHN0cmFwcGluZy1pbnRlZ3JhdGVkLTAy Jm5ic3A7YW55bW9yZS4uLg0KPGJyPg08L3A+DQo8cD4mbmJzcDs8L3A+DQo8cD5IaW9wdCZndDsm Z3Q7IEl0IGlzIHdpdGhpbiB0aGUgTU4ncyBvd24gZGlzY3JldGlvbiBhcyBmb2xsb3dzLiA8L3A+ DQo8cD5JIGRvbid0IHRoaW5rIGl0IHNob3VsZCBiZSBzdGFuZGFyZGl6ZWQgaW4gSElPUFQgZG9j dW1lbnQuIDwvcD4NCjxwPiZxdW90O0ZvciBleGFtcGxlLCBpZiB0aGUgbW9iaWxlIG5vZGUgYWNx dWlyZXMgYm90aCBJUHY2IGFkZHJlc3MoZXMpIGFuZCANCkZRRE4ocyk8L3A+DQo8cD4mbmJzcDtv ZiB0aGUgaG9tZSBhZ2VudHMsIGl0IG1heSB0cnkgdG8gdXNlIHRoZSBhZGRyZXNzIGluZm9ybWF0 aW9uIG9mIHRoZSANCmhvbWUgYWdlbnQocykgZmlyc3QuJnF1b3Q7PC9wPg0KPHA+Jm5ic3A7PC9w Pg0KPHA+Cjxicj5Tb21lJm5ic3A7b3RoZXImbmJzcDtjb21tZW50czoNCjxicj4NCjxicj4tJm5i c3A7SXQmbmJzcDt3b3VsZCZuYnNwO2JlJm5ic3A7Z29vZCZuYnNwO3RvJm5ic3A7aGF2ZSZuYnNw O2EmbmJzcDtzZWN0aW9uLCZuYnNwO3doaWNoJm5ic3A7ZXhwbGljaXRseSZuYnNwO3N0YXRlcyZu YnNwOw0KPGJyPiZuYnNwOyZuYnNwO2Fzc3VtcHRpb25zJm5ic3A7YW5kJm5ic3A7YXBwbGljYWJp bGl0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7cHJvdG9jb2wuJm5ic3A7VGhpcyZuYnNwO3Nob3Vs ZCZuYnNwO2luY2x1ZGU6DQo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LSZuYnNwO01TQSZu YnNwO2FuZCZuYnNwO0FTQSZuYnNwO211c3QmbmJzcDtiZSZuYnNwO2NvLWxvY2F0ZWQmbmJzcDso aS5lLiwmbmJzcDtpbnRlZ3JhdGVkJm5ic3A7c2NlbmFyaW8pDQo8YnI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7LSZuYnNwO0FBQSZuYnNwO2luZnJhc3RydWN0dXJlJm5ic3A7YXNzdW1lZCZuYnNw O2FuZCZuYnNwO3NvbWUmbmJzcDtraW5kJm5ic3A7b2YmbmJzcDtyb2FtaW5nJm5ic3A7DQo8YnI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVsYXRpb25z aGlwJm5ic3A7YmV0d2VlbiZuYnNwO0FTUCZuYnNwO2FuZCZuYnNwO01TQS9BU0EmbmJzcDtpcyZu YnNwO3JlcXVpcmVkDQo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LSZuYnNwO01TUCZuYnNw O2lzJm5ic3A7ZWl0aGVyJm5ic3A7Y28tbG9jYXRlZCZuYnNwO3dpdGgmbmJzcDtBU1AmbmJzcDtv ciZuYnNwO01TQSZuYnNwO29yJm5ic3A7Ym90aA0KPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyhPciZuYnNwO2FyZSZuYnNwO290aGVyJm5ic3A7dGFy Z2V0Jm5ic3A7bmV0d29ya3MmbmJzcDthbGxvd2VkOyZuYnNwO3NlZSZuYnNwO2Fib3ZlKT8NCjxi cj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstJm5ic3A7REhDUCZuYnNwO3JlbGF5Jm5ic3A7YW5k Jm5ic3A7TkFTJm5ic3A7bXVzdCZuYnNwO2JlJm5ic3A7Y28tbG9jYXRlZA0KPGJyPg0KPGJyPi0m bmJzcDtBdCZuYnNwO3NvbWUmbmJzcDtwbGFjZXMmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO3RleHQm bmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3Rlcm0mbmJzcDsmcXVvdDtN U1AmcXVvdDsmbmJzcDtpcyZuYnNwO2FtYmlndW91cywmbmJzcDsNCjxicj4mbmJzcDsmbmJzcDtz aW5jZSZuYnNwO01TUCZuYnNwO2NhbiZuYnNwO3JlZmVyJm5ic3A7dG8mbmJzcDthdCZuYnNwO2xl YXN0Jm5ic3A7aG9tZSZuYnNwO2FuZCZuYnNwO3Zpc2l0ZWQmbmJzcDtuZXR3b3JrLiZuYnNwO0Jl dHRlciZuYnNwOw0KPGJyPiZuYnNwOyZuYnNwO3VzZSZuYnNwOyZxdW90O2hvbWUmbmJzcDtNU1Am cXVvdDsmbmJzcDtmb3ImbmJzcDtNU1AmbmJzcDtpbiZuYnNwO2hvbWUmbmJzcDtuZXR3b3JrLg0K PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0mbmJzcDtlLmcuLCZuYnNwO3NlY3Rpb24mbmJz cDszLjE6DQo8YnI+Jm5ic3A7Jm5ic3A7JnF1b3Q7Tm90ZSZuYnNwO3RoYXQmbmJzcDthJm5ic3A7 aG9tZSZuYnNwO2FnZW50Jm5ic3A7Zm9yJm5ic3A7dXNhZ2UNCjxicj4mbmJzcDsmbmJzcDsmbmJz cDt3aXRoJm5ic3A7dGhlJm5ic3A7bW9iaWxlJm5ic3A7bm9kZSZuYnNwO21pZ2h0Jm5ic3A7YmUm bmJzcDtzZWxlY3RlZCZuYnNwO2luJm5ic3A7dGhlJm5ic3A7YWNjZXNzJm5ic3A7c2VydmljZQ0K PGJyPiZuYnNwOyZuYnNwOyZuYnNwO3Byb3ZpZGVyJiMzOTtzJm5ic3A7bmV0d29yayZuYnNwO29y Jm5ic3A7YWx0ZXJuYXRpdmVseSZuYnNwO2luJm5ic3A7dGhlJm5ic3A7KmhvbWUqJm5ic3A7bW9i aWxpdHkmbmJzcDtzZXJ2aWNlDQo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7cHJvdmlkZXImIzM5O3Mm bmJzcDtuZXR3b3JrLiZxdW90Ow0KPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0mbmJzcDtv ciZuYnNwO2luJm5ic3A7c2VjdGlvbiZuYnNwOzMuMjoNCjxicj4mbmJzcDsmbmJzcDsmcXVvdDtU aGUmbmJzcDttZXNzYWdlJm5ic3A7Zmxvd3MmbmJzcDtmb3ImbmJzcDtob21lJm5ic3A7YWdlbnQN Cjxicj4mbmJzcDsmbmJzcDsmbmJzcDthbGxvY2F0aW9uJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtB U1AmbmJzcDthbmQmbmJzcDt0aGUmbmJzcDsqaG9tZSombmJzcDtNU1AmbmJzcDthcmUmbmJzcDtp bGx1c3RyYXRlZCZuYnNwO2JlbG93LiZuYnNwOyZuYnNwOw0KPGJyPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOy0mbmJzcDtvciZuYnNwO2luJm5ic3A7c2VjdGlvbiZuYnNwOzMuMi4xOg0KPGJyPiZu YnNwOyZuYnNwOyZxdW90OzMuMi4xLiZuYnNwOyZuYnNwO0hvbWUmbmJzcDtBZ2VudCZuYnNwO2Fs bG9jYXRpb24mbmJzcDtpbiZuYnNwO3RoZSZuYnNwOypob21lKiZuYnNwO01TUCZxdW90OywNCjxi cj4mbmJzcDsmbmJzcDsmcXVvdDsoNCkuLi4mbmJzcDttb2JpbGUmbmJzcDtub2RlJm5ic3A7aXMm bmJzcDtyZXF1ZXN0aW5nJm5ic3A7aG9tZSZuYnNwO2FnZW50Jm5ic3A7aW5mb3JtYXRpb24mbmJz cDtpbiZuYnNwO3RoZSZuYnNwOw0KPGJyPiZuYnNwOyZuYnNwOypob21lKiZuYnNwO01TUC4uLiZx dW90Ow0KPGJyPg0KPGJyPi0mbmJzcDtTZWN0aW9uJm5ic3A7My4zJm5ic3A7Y3VycmVudGx5Jm5i c3A7bWVudGlvbnMmbmJzcDtETlMtYmFzZWQmbmJzcDtIQSZuYnNwO2FkZHJlc3MmbmJzcDtkaXNj b3ZlcnkmbmJzcDttZXRob2QNCjxicj4mbmJzcDsmbmJzcDtvbmx5LCZuYnNwO2J1dCZuYnNwO1tC T09ULVNQTElUXSZuYnNwO2Fsc28mbmJzcDtzcGVjaWZpZXMmbmJzcDthbiZuYnNwO2FueWNhc3Qt YmFzZWQmbmJzcDtIQSZuYnNwO2FkZHJlc3MmbmJzcDsNCjxicj4mbmJzcDsmbmJzcDtkaXNjb3Zl cnkmbmJzcDttZXRob2QuJm5ic3A7RWl0aGVyJm5ic3A7Ym90aCZuYnNwO29yJm5ic3A7bm9uZSZu YnNwO3Nob3VsZCZuYnNwO2JlJm5ic3A7bWVudGlvbmVkLg0KPGJyPg0KPGJyPi0mbmJzcDtUaGUm bmJzcDt0aXRsZSZuYnNwO29mJm5ic3A7ZHJhZnQtaWV0Zi1taXA2LWJvb3RzdHJhcHBpbmctaW50 ZWdyYXRlZC0wMiZuYnNwO2NhbiZuYnNwO2NhdXNlJm5ic3A7DQo8YnI+Jm5ic3A7Jm5ic3A7dGhl Jm5ic3A7aW1wcmVzc2lvbiZuYnNwO3RoYXQmbmJzcDt0aGUmbmJzcDtkcmFmdCZuYnNwO2RlZmlu ZXMmbmJzcDthJm5ic3A7Y29tcGxldGUmbmJzcDtib290c3RyYXBwaW5nJm5ic3A7Jm5ic3A7DQo8 YnI+Jm5ic3A7Jm5ic3A7cHJvY2VkdXJlLiZuYnNwO0J1dCZuYnNwO2RyYWZ0LWlldGYtbWlwNi1i b290c3RyYXBwaW5nLWludGVncmF0ZWQtMDImbmJzcDtkZWZpbmVzJm5ic3A7YSZuYnNwOw0KPGJy PiZuYnNwOyZuYnNwO21ldGhvZCZuYnNwO2ZvciZuYnNwO0hBJm5ic3A7YWRkcmVzcyZuYnNwO2Fz c2lnbm1lbnQmbmJzcDtvbmx5LiZuYnNwO0kmbmJzcDt0aGluayZuYnNwO3RoaXMmbmJzcDtpcyZu YnNwO21pc2xlYWRpbmcuJm5ic3A7DQo8YnI+Jm5ic3A7Jm5ic3A7V2h5Jm5ic3A7bm90Jm5ic3A7 bmFtZSZuYnNwO3RoZSZuYnNwO2RyYWZ0Jm5ic3A7YWNjb3JkaW5nJm5ic3A7dG8mbmJzcDt3aGF0 Jm5ic3A7aXQmbmJzcDtzcGVjaWZpZXMmbmJzcDsoZS5nLiwmbmJzcDsmcXVvdDtIQSZuYnNwOw0K PGJyPiZuYnNwOyZuYnNwO2FkZHJlc3MmbmJzcDthc3NpZ25tZW50Jm5ic3A7dXNpbmcmbmJzcDtE SENQJm5ic3A7YW5kJm5ic3A7QUFBJnF1b3Q7Jm5ic3A7b3ImbmJzcDsmcXVvdDtIQSZuYnNwO2Fk ZHJlc3MmbmJzcDthc3NpZ25tZW50Jm5ic3A7Zm9yJm5ic3A7DQo8YnI+Jm5ic3A7Jm5ic3A7dGhl Jm5ic3A7aW50ZWdyYXRlZCZuYnNwO3NjZW5hcmlvJm5ic3A7dXNpbmcmbmJzcDtESENQJm5ic3A7 YW5kJm5ic3A7QUFBJnF1b3Q7Jm5ic3A7aW5zdGVhZCZuYnNwO29mJm5ic3A7DQo8YnI+Jm5ic3A7 Jm5ic3A7JnF1b3Q7TUlQNi1ib290c3RyYXBwaW5nJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7aW50 ZWdyYXRlZCZuYnNwO3NjZW5hcmlvJnF1b3Q7KT8NCjxicj4NCjxicj5SZWdhcmRzLA0KPGJyPg0K PGJyPktpbGlhbg0KPGJyPg0KPGJyPiZndDsmbmJzcDstLS0tLU9yaWdpbmFsJm5ic3A7TWVzc2Fn ZS0tLS0tDQo8YnI+Jmd0OyZuYnNwO0Zyb206Jm5ic3A7QmFzYXZhcmFqJm5ic3A7UGF0aWwmbmJz cDtbbWFpbHRvOmJhc2F2YXJhai5wYXRpbEBub2tpYS5jb21dJm5ic3A7DQo8YnI+Jmd0OyZuYnNw O1NlbnQ6Jm5ic3A7TWl0dHdvY2gsJm5ic3A7MTQuJm5ic3A7RmVicnVhciZuYnNwOzIwMDcmbmJz cDsxOToxMA0KPGJyPiZndDsmbmJzcDtUbzombmJzcDttaXA2QGlldGYub3JnDQo8YnI+Jmd0OyZu YnNwO1N1YmplY3Q6Jm5ic3A7W01pcDZdJm5ic3A7V0dMQzombmJzcDtkcmFmdC1pZXRmLW1pcDYt Ym9vdHN0cmFwcGluZy1pbnRlZ3JhdGVkLTAyDQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJz cDsNCjxicj4mZ3Q7Jm5ic3A7SGVsbG8sDQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDtU aGlzJm5ic3A7aXMmbmJzcDthJm5ic3A7TUlQNiZuYnNwO1dvcmtpbmcmbmJzcDtncm91cCZuYnNw O2xhc3QmbmJzcDtjYWxsJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7V0cmbmJzcDtJLUQ6DQo8YnI+ Jmd0OyZuYnNwOyZxdW90O01JUDYtYm9vdHN0cmFwcGluZyZuYnNwO2ZvciZuYnNwO3RoZSZuYnNw O0ludGVncmF0ZWQmbmJzcDtTY2VuYXJpbyZxdW90OywNCjxicj4mZ3Q7Jm5ic3A7ZHJhZnQtaWV0 Zi1taXA2LWJvb3RzdHJhcHBpbmctaW50ZWdyYXRlZC0wMi50eHQNCjxicj4mZ3Q7Jm5ic3A7DQo8 YnI+Jmd0OyZuYnNwO0ktRDombmJzcDsNCjxicj4mZ3Q7Jm5ic3A7aHR0cDovL2lldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1pcDYtYm9vdHN0cmFwcGluZy0NCjxicj4mZ3Q7Jm5i c3A7aW50ZWdyYXRlZC1kaGMNCjxicj4mZ3Q7Jm5ic3A7LTAyLnR4dA0KPGJyPiZndDsmbmJzcDsN Cjxicj4mZ3Q7Jm5ic3A7UGxlYXNlJm5ic3A7cmV2aWV3Jm5ic3A7YW5kJm5ic3A7c3VibWl0Jm5i c3A7eW91ciZuYnNwO2NvbW1lbnRzJm5ic3A7dG8mbmJzcDt0aGUmbmJzcDthdXRob3JzJm5ic3A7 b3ImbmJzcDt0aGUmbmJzcDttYWlsaW5nDQo8YnI+Jmd0OyZuYnNwO2xpc3QuJm5ic3A7VGhlJm5i c3A7V0dMQyZuYnNwO3dpbGwmbmJzcDtleHBpcmUmbmJzcDtvbiZuYnNwO01hcmNoJm5ic3A7MXN0 LCZuYnNwOzA3Lg0KPGJyPiZndDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7LUNoYWlycw0KPGJyPiZn dDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwO19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo8YnI+Jmd0OyZuYnNwO01pcDYmbmJzcDtt YWlsaW5nJm5ic3A7bGlzdA0KPGJyPiZndDsmbmJzcDtNaXA2QGlldGYub3JnDQo8YnI+Jmd0OyZu YnNwO2h0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pcDYNCjxicj4mZ3Q7 Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPg0KPGJyPg0KPGJyPlBhbmFzb25pYyZuYnNwO1Im YW1wO0QmbmJzcDtDZW50ZXImbmJzcDtHZXJtYW55Jm5ic3A7R21iSA0KPGJyPjYzMjI1Jm5ic3A7 TGFuZ2VuLCZuYnNwO0hlc3NlbiwmbmJzcDtHZXJtYW55DQo8YnI+UmVnOiZuYnNwO0FHJm5ic3A7 T2ZmZW5iYWNoJm5ic3A7KEhlc3NlbikmbmJzcDtIUkImbmJzcDszMzk3NA0KPGJyPk1hbmFnaW5n Jm5ic3A7RGlyZWN0b3I6Jm5ic3A7VGhvbWFzJm5ic3A7TWlja2UNCjxicj4NCjxicj4NCjxicj4N Cjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJy Pk1pcDYmbmJzcDttYWlsaW5nJm5ic3A7bGlzdA0KPGJyPk1pcDZAaWV0Zi5vcmcNCjxicj5odHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taXA2DQo8YnI+DQo8YnI+DQo8YnI+ PC9wPg0KPC9CT0RZPjwvSFRNTD4= --===============0746239942== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0746239942==-- From mip6-bounces@ietf.org Tue Feb 20 10:00:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJWSG-0004jL-1Y; Tue, 20 Feb 2007 09:58:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJWSF-0004jE-5V for mip6@ietf.org; Tue, 20 Feb 2007 09:58:55 -0500 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJWSA-00065F-09 for mip6@ietf.org; Tue, 20 Feb 2007 09:58:55 -0500 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50002397008.msg for ; Tue, 20 Feb 2007 15:55:39 +0100 From: "Miguel A. Diaz" To: References: Date: Tue, 20 Feb 2007 15:58:13 +0100 Message-ID: <004301c754ff$8bd62790$090ba8c0@consulintel.es> 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.3028 Thread-Index: AcdSDDvRXzGjBhzRThmyUVscViCmGwCyfDIA In-Reply-To: X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-HashCash: 1:20:070220:mip6@ietf.org::T5KtYn0FzaoFbAjv:00003Y5j X-MDRemoteIP: 213.172.48.138 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: mip6@ietf.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Tue, 20 Feb 2007 15:55:40 +0100 X-MDAV-Processed: consulintel.es, Tue, 20 Feb 2007 15:55:41 +0100 X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [Mip6] Questions about draft-ietf-mip6-hiopt-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: miguelangel.diaz@consulintel.es List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, I've been reading the new version of hiopt (draft-ietf-mip6-hiopt-02) and I would like to post a couple of comments. 1) Home Network Identifier Option. The Home Network Identifier seems to me a bit ambiguous when the id-type field is set to 0 [Visited domain (local ASP)]. In section 3.1 it's stated: "Id-type 0 indicates the mobile node is interested in learning the home network information that pertains to the currently visited network. This type can be used to discover local home agents in the local ASP. The Home Network Identifier field can be set to 0 or the target home MSP. In case the DHCP server is not configured with the local home information, the home information for the specified home MSP is provided." I think that if the Id-type is 0, the Home Network Identifier SHOULD/MUST be always 0 because the MN is willing to get information about the visited domain. It seems to me that setting both id-type to zero and the Home Network Identifier to the target home MSP have no sense. If MN wants to retrieve both home and visited network information, then it must be set two sub-options within the OPTION_MIP6-HNID option. The first one would have the id-type set to 0 and the Home Network Identifier field set to 0 also. The second one would have the id-type set to 1 and the Home Network Identifier field set to the home FQDN. Even if the MN has no preference, it should set the id-type to 2, according to section 3.1 of draft-ietf-mip6-hiopt-02. 2) Relay Agent Behavior. In section 4.2, it is stated: "The DHCP relay agent MUST insert MN-NAI option [8] in the Relay-Forward message in order to indicate the home netowrk of the user to the DHCP server." Is that really needed always? When the MN only wants information about the visited network (id-type set to 0 in OPTION_MIP6-HNID option), why the MN-NAI must be inserted into the Relay-Forward message? I think that there is no reasons to do that because: A) When the OPTION_MIP6-RELAY is sent, the DHCPv6 server will provide home network information based on such information B) If MN requires information about its home network, it provides its home network realm by using the OPTION_MIP6-HNID option C) MN's identity should not be required by the DHCPv6 server but by the ASA/MSA in order to authorize the mobility service to the MN Regards Miguel ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 20 10:53:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXIF-0007rk-Lj; Tue, 20 Feb 2007 10:52:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXIE-0007pw-Ex; Tue, 20 Feb 2007 10:52:38 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJXIB-0001fQ-Qn; Tue, 20 Feb 2007 10:52:37 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 38BD0198777; Tue, 20 Feb 2007 17:52:35 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DA18C1986AF; Tue, 20 Feb 2007 17:52:34 +0200 (EET) Message-ID: <45DB1943.80908@piuha.net> Date: Tue, 20 Feb 2007 17:52:35 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip6] Re: FW: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt References: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com> <45D4E2ED.8040702@piuha.net> <45D5889C.3060701@motorola.com> <45D58A57.7070901@piuha.net> <45D58C93.3000009@motorola.com> In-Reply-To: <45D58C93.3000009@motorola.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List , Alexandru Petrescu X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org George, others? I don't really like either the original formulation and I hope what Alex suggested isn't true either. I'm sure there are technical issues that you could talk about. Please suggest text -- the draft is up for discussion in Thursday's IESG telechat so I would like to see a better proposal before that. Jari Alexandru Petrescu kirjoitti: > Jari Arkko wrote: >> Hi Alex, >> >> >>> Known mechanisms have been shown to assist with the issues described >>> in this document: 6to4 tunnel between MN and a Gateway, RAs over >>> that tunnel and HA separated from the gateway. Just 6to4, ND and >>> Mobile IPv6, no protocol modifications. >>> >> Ok. Do you have alternative suggested text that would better >> characterize the situation? > > It is very difficult to write text along these lines. It is very > difficult to discard existing IETF transitioning methods as not > addressing the needs of DS-MIPv6. > > Maybe this: > >> The IETF has standardized a number of transition mechanisms to allow >> networks and end nodes to gain IPv6 connectivity while the Internet >> is migrating from IPv4 to IPv6. However, while some transition >> mechanisms could be combined with Mobile IPv6, it takes too much time >> to analyze how they could work together, hence the need to design >> from scratch a new extension to MIPv6. > > Not sure how else could I put it. > > Alex > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 20 13:38:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJZs7-0004f7-Br; Tue, 20 Feb 2007 13:37:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJZs6-0004f2-HL for mip6@ietf.org; Tue, 20 Feb 2007 13:37:50 -0500 Received: from mail127.messagelabs.com ([216.82.250.115]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJZs2-0008EG-4L for mip6@ietf.org; Tue, 20 Feb 2007 13:37:50 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-2.tower-127.messagelabs.com!1171996665!2863265!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 32635 invoked from network); 20 Feb 2007 18:37:45 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-2.tower-127.messagelabs.com with SMTP; 20 Feb 2007 18:37:45 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l1KIbi91017946; Tue, 20 Feb 2007 12:37:44 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l1KIbgWx005249; Tue, 20 Feb 2007 12:37:43 -0600 (CST) Message-ID: <45DB3FF6.3020804@motorola.com> Date: Tue, 20 Feb 2007 19:37:42 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] Volunteer to keep track of issues w.r.t RFC3775 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I volunteer that. Alex Basavaraj Patil wrote: > > Hello, > > As we are moving forward with developing various extensions and > enhancements to Mobile IPv6, we also need to ensure that we are > Identifying and tracking any issues with the base protocol (RFC 3775) > itself. In fact the charter states: > " > Additionally the working group will ensure > that any issues identified by implementation and interoperability > experience are addressed, and that the base specifications are > maintained. > " > > We need a volunteer who will maintain such a list of issues that are > identified and discussed on the mailing list. Please send the chairs a > note if you would be willing to act as the base-spec issue tracker. > > -Raj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 20 13:52:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJa6F-0002IJ-A8; Tue, 20 Feb 2007 13:52:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJa6E-0002IB-Sn; Tue, 20 Feb 2007 13:52:26 -0500 Received: from mail127.messagelabs.com ([216.82.250.115]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJa6D-00027s-Hh; Tue, 20 Feb 2007 13:52:26 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-13.tower-127.messagelabs.com!1171997544!12131053!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14851 invoked from network); 20 Feb 2007 18:52:24 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-127.messagelabs.com with SMTP; 20 Feb 2007 18:52:24 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l1KIqJtJ029177; Tue, 20 Feb 2007 11:52:19 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l1KIqItc012153; Tue, 20 Feb 2007 12:52:18 -0600 (CST) Message-ID: <45DB4361.9030200@motorola.com> Date: Tue, 20 Feb 2007 19:52:17 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip6] Re: FW: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt References: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com> <45D4E2ED.8040702@piuha.net> <45D5889C.3060701@motorola.com> <45D58A57.7070901@piuha.net> <45D58C93.3000009@motorola.com> <45DB1943.80908@piuha.net> In-Reply-To: <45DB1943.80908@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Jari Arkko wrote: > George, others? I don't really like either the original formulation > and I hope what Alex suggested isn't true either. I'm sure there are > technical issues that you could talk about. Please suggest text -- > the draft is up for discussion in Thursday's IESG telechat so I would > like to see a better proposal before that. YEs, please anybody else send a comment regarding the quoted paragraph in the DSMIP Problem Statement draft for section 4.5 IPv4 to IPv6 Transition Mechanisms. I also believe we can't simply write there wasn't enough time to deal with all issues. It may be that a way out of this is to _list_ the other IPv4-to-IPv6 transition mechanisms that this problem statement considered. I'm sure 6to4 was considered by the authors. I'm not sure whether STUN was considered. IKEv2 NAT traversal _was_ considered by authors. For each of those we list, we can say why they're not adapted for DSMIP problem. For example: list 6to4, abstract what it does, how it offers IPv6 connectivity through the NAT, and then say that it may work with certain NATs but not with others. It won't work with NATs that only allow MIP6 through. Also, list IKEv2 NAT traversal, say in short how it does it, then say about IKEv2 being independent of running over IPv4 and IPv6 and that it is necessary for MN-to-HA. However, say that MIP4 NAT Traversal may be better adapted for this task because many nodes already implement MIP4 NAT Traversal (as a reminiscent of their MIP4 implementation). I believe many of these things were discussed at least publicly. But this is more than one paragraph. Alex > > Jari > > Alexandru Petrescu kirjoitti: >> Jari Arkko wrote: >>> Hi Alex, >>> >>> >>>> Known mechanisms have been shown to assist with the issues >>>> described in this document: 6to4 tunnel between MN and a >>>> Gateway, RAs over that tunnel and HA separated from the >>>> gateway. Just 6to4, ND and Mobile IPv6, no protocol >>>> modifications. >>>> >>> Ok. Do you have alternative suggested text that would better >>> characterize the situation? >> It is very difficult to write text along these lines. It is very >> difficult to discard existing IETF transitioning methods as not >> addressing the needs of DS-MIPv6. >> >> Maybe this: >> >>> The IETF has standardized a number of transition mechanisms to >>> allow networks and end nodes to gain IPv6 connectivity while the >>> Internet is migrating from IPv4 to IPv6. However, while some >>> transition mechanisms could be combined with Mobile IPv6, it >>> takes too much time to analyze how they could work together, >>> hence the need to design from scratch a new extension to MIPv6. >> Not sure how else could I put it. >> >> Alex >> >> >> > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 20 14:06:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJaJs-0003jP-Oh; Tue, 20 Feb 2007 14:06:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJaJq-0003jH-TG; Tue, 20 Feb 2007 14:06:30 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJaJp-0005Uj-Fd; Tue, 20 Feb 2007 14:06:30 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l1KJ6SmV031526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Feb 2007 11:06:28 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l1KJ6R3D013618; Tue, 20 Feb 2007 11:06:27 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 11:06:27 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt Date: Tue, 20 Feb 2007 11:06:25 -0800 Message-ID: In-Reply-To: <45DB1943.80908@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt Thread-Index: AcdVCFLlD4sRScf4T+69ZsmfiU5a7gAFx7Kw References: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com><45D4E2ED.8040702@piuha.net> <45D5889C.3060701@motorola.com><45D58A57.7070901@piuha.net> <45D58C93.3000009@motorola.com> <45DB1943.80908@piuha.net> From: "Narayanan, Vidya" To: "Jari Arkko" , "Tsirtsis, George" X-OriginalArrivalTime: 20 Feb 2007 19:06:27.0453 (UTC) FILETIME=[38DBDAD0:01C75522] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List , Alexandru Petrescu X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I think what Alex is saying is somewhat true. It is feasible to use other transition mechanisms with MIP6. However, those will be heavier and less efficient. I think it is most straightforward to build the transition into MIP6 for the purpose of mobility. Without this, for instance, supporting IPv4-only access networks would mean that the MN supports some of these other transition mechanisms, which is quite painful. When there is already a transition mechanism used in the access network, it is feasible to use that, but, given we are dealing with mobile nodes and they can roam into any access network, that is not an assumption we can make.=20 Vidya > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Tuesday, February 20, 2007 7:53 AM > To: Tsirtsis, George > Cc: Mobile IPv6 Mailing List; Mobile IPv4 Mailing List;=20 > Alexandru Petrescu > Subject: Re: [Mip6] Re: FW: [Mip4] AD reviewof=20 > draft-ietf-mip6-dsmip-problem-02.txt >=20 > George, others? I don't really like either the original=20 > formulation and I hope what Alex suggested isn't true either.=20 > I'm sure there are technical issues that you could talk=20 > about. Please suggest text -- the draft is up for discussion=20 > in Thursday's IESG telechat so I would like to see a better=20 > proposal before that. >=20 > Jari >=20 > Alexandru Petrescu kirjoitti: > > Jari Arkko wrote: > >> Hi Alex, > >> > >> > >>> Known mechanisms have been shown to assist with the=20 > issues described=20 > >>> in this document: 6to4 tunnel between MN and a Gateway, RAs over=20 > >>> that tunnel and HA separated from the gateway. Just 6to4, ND and=20 > >>> Mobile IPv6, no protocol modifications. > >>> > >> Ok. Do you have alternative suggested text that would better=20 > >> characterize the situation? > > > > It is very difficult to write text along these lines. It is very=20 > > difficult to discard existing IETF transitioning methods as not=20 > > addressing the needs of DS-MIPv6. > > > > Maybe this: > > > >> The IETF has standardized a number of transition=20 > mechanisms to allow =20 > >> networks and end nodes to gain IPv6 connectivity while the=20 > Internet =20 > >> is migrating from IPv4 to IPv6. However, while some transition=20 > >> mechanisms could be combined with Mobile IPv6, it takes=20 > too much time=20 > >> to analyze how they could work together, hence the need to design=20 > >> from scratch a new extension to MIPv6. > > > > Not sure how else could I put it. > > > > Alex > > > > > > >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 20 15:37:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbj5-0004oz-Dc; Tue, 20 Feb 2007 15:36:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbj4-0004ou-Ie for mip6@ietf.org; Tue, 20 Feb 2007 15:36:38 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJbj3-0006if-2F for mip6@ietf.org; Tue, 20 Feb 2007 15:36:38 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1KKXTHV013508; Tue, 20 Feb 2007 22:33:43 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 22:36:10 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 14:36:08 -0600 Received: from 172.19.244.105 ([172.19.244.105]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Feb 2007 20:36:07 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 20 Feb 2007 14:38:44 -0600 Subject: Re: [Mip6] Volunteer to keep track of issues w.r.t RFC3775 From: Basavaraj Patil To: Basavaraj Patil , Message-ID: Thread-Topic: [Mip6] Volunteer to keep track of issues w.r.t RFC3775 Thread-Index: AcdUc0k8h58g+cBmEduYfAARJNUNiAAu9Oqq In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Feb 2007 20:36:08.0174 (UTC) FILETIME=[C004B8E0:01C7552E] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070220223343-30196BB0-5ABDE0D1/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, Rich Groves has volunteered to maintain the issue list for the base specification (RFC3775). We will use the issue tracker at: http://www.mip4.org/issues/tracker/mip6/ as the tool for tracking the issues. If you have any known issues at this time, please send them to Rich ( rich.groves at twcable.com) -Raj On 2/19/07 4:14 PM, "ext Basavaraj Patil" wrote: > > > Hello, > > As we are moving forward with developing various extensions and > enhancements to Mobile IPv6, we also need to ensure that we are > Identifying and tracking any issues with the base protocol (RFC 3775) > itself. In fact the charter states: > " > Additionally the working group will ensure > that any issues identified by implementation and interoperability > experience are addressed, and that the base specifications are > maintained. > " > > We need a volunteer who will maintain such a list of issues that are > identified and discussed on the mailing list. Please send the chairs a > note if you would be willing to act as the base-spec issue tracker. > > -Raj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 20 15:41:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbn9-0006lb-6z; Tue, 20 Feb 2007 15:40:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbn7-0006lT-K5 for mip6@ietf.org; Tue, 20 Feb 2007 15:40:49 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJbn6-0007RD-4z for mip6@ietf.org; Tue, 20 Feb 2007 15:40:49 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1KKanvx017058; Tue, 20 Feb 2007 22:37:06 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 22:40:45 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 14:40:22 -0600 Received: from 172.19.244.105 ([172.19.244.105]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Feb 2007 20:40:22 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 20 Feb 2007 14:43:00 -0600 Subject: Re: [Mip6] Volunteer to keep track of issues w.r.t RFC3775 From: Basavaraj Patil To: ext Alexandru Petrescu , Message-ID: Thread-Topic: [Mip6] Volunteer to keep track of issues w.r.t RFC3775 Thread-Index: AcdVL7V88//OkMEiEduywAARJNUNiA== In-Reply-To: <45DB3FF6.3020804@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Feb 2007 20:40:22.0978 (UTC) FILETIME=[57E4BA20:01C7552F] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070220223706-4205CBB0-02ED3F79/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alex, Thanks for volunteering. But Rich Groves had sent in an email prior to yours and we chose him. Your efforts or help in other tasks for this WG would be appreciated and we will ask you for such in the near future. -Raj On 2/20/07 12:37 PM, "ext Alexandru Petrescu" wrote: > I volunteer that. > > Alex > > Basavaraj Patil wrote: >> >> Hello, >> >> As we are moving forward with developing various extensions and >> enhancements to Mobile IPv6, we also need to ensure that we are >> Identifying and tracking any issues with the base protocol (RFC 3775) >> itself. In fact the charter states: >> " >> Additionally the working group will ensure >> that any issues identified by implementation and interoperability >> experience are addressed, and that the base specifications are >> maintained. >> " >> >> We need a volunteer who will maintain such a list of issues that are >> identified and discussed on the mailing list. Please send the chairs a >> note if you would be willing to act as the base-spec issue tracker. >> >> -Raj >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 20 15:47:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbtZ-0002aG-Hy; Tue, 20 Feb 2007 15:47:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbtY-0002ZB-2Z; Tue, 20 Feb 2007 15:47:28 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJbtW-0008L6-HZ; Tue, 20 Feb 2007 15:47:28 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1KKiI1T015141; Tue, 20 Feb 2007 22:44:34 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 22:46:55 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 14:46:39 -0600 Received: from 172.19.244.105 ([172.19.244.105]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Feb 2007 20:46:39 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 20 Feb 2007 14:49:16 -0600 Subject: Re: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt From: Basavaraj Patil To: "ext Narayanan, Vidya" , Jari Arkko , "Tsirtsis, George" Message-ID: Thread-Topic: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt Thread-Index: AcdVCFLlD4sRScf4T+69ZsmfiU5a7gAFx7KwAARI+8E= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Feb 2007 20:46:39.0645 (UTC) FILETIME=[38678CD0:01C75530] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List , Alexandru Petrescu X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Jari, You can consider DS-MIP as yet another transition mechanism. And one that is required or even essential for certain deployments even though we acknowledge there are several transition mechanisms that have been developed and can be used. The fact is that Mobile IP is being deployed and it makes sense for such deployments to use the Mobile IP infrastructure (i.e the HA in this case) as a transition solution as well. Hence this add-on capability/feature to Mobile IP is useful and needed. -Raj On 2/20/07 1:06 PM, "ext Narayanan, Vidya" wrote: > > I think what Alex is saying is somewhat true. It is feasible to use > other transition mechanisms with MIP6. However, those will be heavier > and less efficient. I think it is most straightforward to build the > transition into MIP6 for the purpose of mobility. Without this, for > instance, supporting IPv4-only access networks would mean that the MN > supports some of these other transition mechanisms, which is quite > painful. When there is already a transition mechanism used in the access > network, it is feasible to use that, but, given we are dealing with > mobile nodes and they can roam into any access network, that is not an > assumption we can make. > > Vidya > >> -----Original Message----- >> From: Jari Arkko [mailto:jari.arkko@piuha.net] >> Sent: Tuesday, February 20, 2007 7:53 AM >> To: Tsirtsis, George >> Cc: Mobile IPv6 Mailing List; Mobile IPv4 Mailing List; >> Alexandru Petrescu >> Subject: Re: [Mip6] Re: FW: [Mip4] AD reviewof >> draft-ietf-mip6-dsmip-problem-02.txt >> >> George, others? I don't really like either the original >> formulation and I hope what Alex suggested isn't true either. >> I'm sure there are technical issues that you could talk >> about. Please suggest text -- the draft is up for discussion >> in Thursday's IESG telechat so I would like to see a better >> proposal before that. >> >> Jari >> >> Alexandru Petrescu kirjoitti: >>> Jari Arkko wrote: >>>> Hi Alex, >>>> >>>> >>>>> Known mechanisms have been shown to assist with the >> issues described >>>>> in this document: 6to4 tunnel between MN and a Gateway, RAs over >>>>> that tunnel and HA separated from the gateway. Just 6to4, ND and >>>>> Mobile IPv6, no protocol modifications. >>>>> >>>> Ok. Do you have alternative suggested text that would better >>>> characterize the situation? >>> >>> It is very difficult to write text along these lines. It is very >>> difficult to discard existing IETF transitioning methods as not >>> addressing the needs of DS-MIPv6. >>> >>> Maybe this: >>> >>>> The IETF has standardized a number of transition >> mechanisms to allow >>>> networks and end nodes to gain IPv6 connectivity while the >> Internet >>>> is migrating from IPv4 to IPv6. However, while some transition >>>> mechanisms could be combined with Mobile IPv6, it takes >> too much time >>>> to analyze how they could work together, hence the need to design >>>> from scratch a new extension to MIPv6. >>> >>> Not sure how else could I put it. >>> >>> Alex >>> >>> >>> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 20 16:13:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJcIN-0004qg-Gi; Tue, 20 Feb 2007 16:13:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJcIM-0004qC-KD for mip6@ietf.org; Tue, 20 Feb 2007 16:13:06 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HJcHt-0005L9-5E for mip6@ietf.org; Tue, 20 Feb 2007 16:13:06 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1KL8evF028601 for ; Tue, 20 Feb 2007 23:08:49 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 23:12:33 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 15:12:31 -0600 Received: from 172.19.244.105 ([172.19.244.105]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Feb 2007 21:12:31 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 20 Feb 2007 15:15:08 -0600 From: Basavaraj Patil To: Mobile IPv6 Mailing List Message-ID: Thread-Topic: Soliciting agenda items for MIP6 WG meeting at IETF68 Thread-Index: AcdVNDKpcWpKZMEnEduywAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Feb 2007 21:12:31.0890 (UTC) FILETIME=[D59D5720:01C75533] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070220230849-6DC58BB0-349A71DA/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Mip6] Soliciting agenda items for MIP6 WG meeting at IETF68 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org MIP6 WG is scheduled to meet in Prague on TUESDAY, March 20, 2007 from 1520-1720 Afternoon Session II If you need a slot on the agenda, please send a request ASAP to the chairs. Please include the following information in your request: 1. I-D name 2. Amount of time being requested 3. If the I-D is not a WG document, explain how this fits into the charter of the MIP6 WG or why it is relevant. And if it is a recent I-D, please ensure there has been some discussion on the mailing list prior to the Prague meeting. -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 20 17:06:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJd7c-0004HY-C2; Tue, 20 Feb 2007 17:06:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJd7a-0004Fc-PY; Tue, 20 Feb 2007 17:06:02 -0500 Received: from omta02ps.mx.bigpond.com ([144.140.83.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJd7Z-0003Nn-9r; Tue, 20 Feb 2007 17:06:02 -0500 Received: from oaamta02ps.mx.bigpond.com ([124.191.178.123]) by omta02ps.mx.bigpond.com with ESMTP id <20070220220556.SIYE24597.omta02ps.mx.bigpond.com@oaamta02ps.mx.bigpond.com>; Tue, 20 Feb 2007 22:05:56 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta02ps.mx.bigpond.com with ESMTP id <20070220220551.OETC17816.oaamta02ps.mx.bigpond.com@PC20005>; Tue, 20 Feb 2007 22:05:51 +0000 From: "Hesham Soliman" To: "'Jari Arkko'" , "'Tsirtsis, George'" Subject: RE: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt Date: Wed, 21 Feb 2007 09:05:44 +1100 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: <45DB1943.80908@piuha.net> Thread-Index: AcdVB0L3pxAbbAGXTXGfCw93eMD0gQAMtoIQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070220220551.OETC17816.oaamta02ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: 'Mobile IPv6 Mailing List' , 'Mobile IPv4 Mailing List' , 'Alexandru Petrescu' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > George, others? I don't really like either the original > formulation and I hope what Alex suggested isn't > true either. I'm sure there are technical issues > that you could talk about. Please suggest text -- > the draft is up for discussion in Thursday's IESG > telechat so I would like to see a better proposal > before that. => Here is a suggestion: The IETF has standardized a number of transition mechanisms to allow networks and end nodes to gain IPv6 connectivity while the Internet is migrating from IPv4 to IPv6. These transition mechanisms can be categorised under two main items: Tunnelling and Protocol Translation. Protocol Translation mechanisms are not suitable for Mobile IP signalling as they break end to end integrity. Tunnelling mechanisms, (both static and dynamic), when suitable, add unnecessary overheads to the signalling and data between the mobile node and the home agent. Furthermore, none of those mechanisms can solve the scenario where IPv4 needs to be dynamically tunnelled in IPv6 (i.e. when a node uses an IPv4 home address in an IPv6 network). Due to these reasons, there is a need for a new transition mechanism that utilises the dynamic tunnelling capabilities of Mobile IP. Hesham > > Jari > > Alexandru Petrescu kirjoitti: > > Jari Arkko wrote: > >> Hi Alex, > >> > >> > >>> Known mechanisms have been shown to assist with the > issues described > >>> in this document: 6to4 tunnel between MN and a Gateway, RAs over > >>> that tunnel and HA separated from the gateway. Just 6to4, ND and > >>> Mobile IPv6, no protocol modifications. > >>> > >> Ok. Do you have alternative suggested text that would better > >> characterize the situation? > > > > It is very difficult to write text along these lines. It is very > > difficult to discard existing IETF transitioning methods as not > > addressing the needs of DS-MIPv6. > > > > Maybe this: > > > >> The IETF has standardized a number of transition > mechanisms to allow > >> networks and end nodes to gain IPv6 connectivity while > the Internet > >> is migrating from IPv4 to IPv6. However, while some transition > >> mechanisms could be combined with Mobile IPv6, it takes > too much time > >> to analyze how they could work together, hence the need to design > >> from scratch a new extension to MIPv6. > > > > Not sure how else could I put it. > > > > Alex > > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 21 01:35:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJl4D-0000TQ-4F; Wed, 21 Feb 2007 01:35:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJl4C-0000TD-5z; Wed, 21 Feb 2007 01:35:04 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJl4A-0007Ve-PZ; Wed, 21 Feb 2007 01:35:04 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 89488198776; Wed, 21 Feb 2007 08:34:59 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3951D198775; Wed, 21 Feb 2007 08:34:59 +0200 (EET) Message-ID: <45DBE813.6080101@piuha.net> Date: Wed, 21 Feb 2007 08:34:59 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt References: <20070220220551.OETC17816.oaamta02ps.mx.bigpond.com@PC20005> In-Reply-To: <20070220220551.OETC17816.oaamta02ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 'Mobile IPv6 Mailing List' , 'Mobile IPv4 Mailing List' , 'Alexandru Petrescu' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham Soliman kirjoitti: > > > George, others? I don't really like either the original > > formulation and I hope what Alex suggested isn't > > true either. I'm sure there are technical issues > > that you could talk about. Please suggest text -- > > the draft is up for discussion in Thursday's IESG > > telechat so I would like to see a better proposal > > before that. > > => Here is a suggestion: > > The IETF has standardized a number of transition mechanisms to allow > networks and end nodes to gain IPv6 connectivity while the Internet > is migrating from IPv4 to IPv6. These transition mechanisms can be > categorised under two > main items: Tunnelling and Protocol Translation. Protocol Translation > mechanisms are not suitable for Mobile IP signalling as they break end to > end integrity. Tunnelling mechanisms, (both static and dynamic), when > suitable, add unnecessary overheads to the signalling and data between the > mobile node and the home agent. Furthermore, none of those mechanisms can > solve the scenario where IPv4 needs to be dynamically tunnelled in IPv6 > (i.e. when a node uses an IPv4 home address in an IPv6 network). Due to > these reasons, there is a need for a new transition mechanism that utilises > the dynamic tunnelling capabilities of Mobile IP. > Ok. This is closer to what I had in mind. Do people agree with this? Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 21 04:42:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJnyZ-0007QC-3O; Wed, 21 Feb 2007 04:41:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJnyX-0007Pz-Iw for mip6@ietf.org; Wed, 21 Feb 2007 04:41:25 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJnyW-0000J3-7N for mip6@ietf.org; Wed, 21 Feb 2007 04:41:25 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1172050883!4620762!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 31393 invoked from network); 21 Feb 2007 09:41:23 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-3.tower-128.messagelabs.com with SMTP; 21 Feb 2007 09:41:23 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l1L9fMuP004627; Wed, 21 Feb 2007 02:41:22 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l1L9fLJq029806; Wed, 21 Feb 2007 03:41:22 -0600 (CST) Message-ID: <45DC13C1.8000901@motorola.com> Date: Wed, 21 Feb 2007 10:41:21 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] Volunteer to keep track of issues w.r.t RFC3775 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Basavaraj Patil wrote: > Alex, > > Thanks for volunteering. But Rich Groves had sent in an email prior > to yours and we chose him. Your efforts or help in other tasks for > this WG would be appreciated and we will ask you for such in the near > future. That's fine thanks, I'll comment on these issues anyways. The issues around 3775 have been discussed on the mailing list mip6@ietf.org and on the prior mobileip list at playground at SUN since June 2004. So that's a lot of archived mail to search :-( I could remember the following: -a certain MH type wrongly documented as '2' in RFC. -DHAAD and MPD could be used for botstrapping. -HA sends Binding Error or not and in which cases. -HA sends Binding Refresh Request or not and in which cases. I'm almost 100% sure that more issues than these 4 were discussed. And I think there are more issues that have not been discussed at all since June 2004, at least DHCP and multicast with the MN-HA tunnel. Alex > > -Raj > > > On 2/20/07 12:37 PM, "ext Alexandru Petrescu" > wrote: > >> I volunteer that. >> >> Alex >> >> Basavaraj Patil wrote: >>> Hello, >>> >>> As we are moving forward with developing various extensions and >>> enhancements to Mobile IPv6, we also need to ensure that we are >>> Identifying and tracking any issues with the base protocol (RFC >>> 3775) itself. In fact the charter states: " Additionally the >>> working group will ensure that any issues identified by >>> implementation and interoperability experience are addressed, and >>> that the base specifications are maintained. " >>> >>> We need a volunteer who will maintain such a list of issues that >>> are identified and discussed on the mailing list. Please send the >>> chairs a note if you would be willing to act as the base-spec >>> issue tracker. >>> >>> -Raj >>> >>> >>> _______________________________________________ Mip6 mailing list >>> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 >>> > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 21 04:47:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJo3w-0001Ec-T6; Wed, 21 Feb 2007 04:47:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJo3v-0001ES-JC; Wed, 21 Feb 2007 04:46:59 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJo3u-0001oJ-93; Wed, 21 Feb 2007 04:46:59 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1172051217!15503843!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6872 invoked from network); 21 Feb 2007 09:46:57 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-128.messagelabs.com with SMTP; 21 Feb 2007 09:46:57 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l1L9km2T005749; Wed, 21 Feb 2007 02:46:48 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l1L9kjwb011024; Wed, 21 Feb 2007 03:46:46 -0600 (CST) Message-ID: <45DC1504.7030302@motorola.com> Date: Wed, 21 Feb 2007 10:46:44 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt References: <20070220220551.OETC17816.oaamta02ps.mx.bigpond.com@PC20005> In-Reply-To: <20070220220551.OETC17816.oaamta02ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'Mobile IPv6 Mailing List' , 'Mobile IPv4 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham Soliman wrote: > >> George, others? I don't really like either the original formulation >> and I hope what Alex suggested isn't true either. I'm sure there >> are technical issues that you could talk about. Please suggest text >> -- the draft is up for discussion in Thursday's IESG telechat so I >> would like to see a better proposal before that. > > => Here is a suggestion: > > The IETF has standardized a number of transition mechanisms to allow > networks and end nodes to gain IPv6 connectivity while the Internet > is migrating from IPv4 to IPv6. These transition mechanisms can be > categorised under two main items: Tunnelling and Protocol > Translation. Protocol Translation mechanisms are not suitable for > Mobile IP signalling as they break end to end integrity. Tunnelling > mechanisms, (both static and dynamic), when suitable, add unnecessary > overheads to the signalling and data between the mobile node and the > home agent. Furthermore, none of those mechanisms can solve the > scenario where IPv4 needs to be dynamically tunnelled in IPv6 (i.e. > when a node uses an IPv4 home address in an IPv6 network). Due to > these reasons, there is a need for a new transition mechanism that > utilises the dynamic tunnelling capabilities of Mobile IP. I agree with the way it is formulated and it makes sense overall. I would like to insist on using specific protocol names with specific transitioning mechanisms and RFC numbers. For example: "Protocol Translation mechanisms (SIIT [xx]) are not suitable for Mobile IP signaling as they break end-to-end integrity." "Tunnelling mechanisms (6to4 [xx], STUN [xx]), when suitable, add unnecessary overheads to the signalling and data between the mobile node and the home agent" Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 21 09:09:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJs9g-0000iu-4u; Wed, 21 Feb 2007 09:09:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJs9f-0000iI-D5; Wed, 21 Feb 2007 09:09:11 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJs9e-00008p-0Q; Wed, 21 Feb 2007 09:09:11 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E6463198775; Wed, 21 Feb 2007 16:09:02 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A11C119862E; Wed, 21 Feb 2007 16:09:02 +0200 (EET) Message-ID: <45DC527F.5060301@piuha.net> Date: Wed, 21 Feb 2007 16:09:03 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt References: <20070220220551.OETC17816.oaamta02ps.mx.bigpond.com@PC20005> <45DC1504.7030302@motorola.com> In-Reply-To: <45DC1504.7030302@motorola.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 'Mobile IPv6 Mailing List' , 'Mobile IPv4 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Hesham Soliman wrote: >> >>> George, others? I don't really like either the original formulation >>> and I hope what Alex suggested isn't true either. I'm sure there >>> are technical issues that you could talk about. Please suggest text >>> -- the draft is up for discussion in Thursday's IESG telechat so I >>> would like to see a better proposal before that. >> >> => Here is a suggestion: >> >> The IETF has standardized a number of transition mechanisms to allow >> networks and end nodes to gain IPv6 connectivity while the Internet >> is migrating from IPv4 to IPv6. These transition mechanisms can be >> categorised under two main items: Tunnelling and Protocol >> Translation. Protocol Translation mechanisms are not suitable for >> Mobile IP signalling as they break end to end integrity. Tunnelling >> mechanisms, (both static and dynamic), when suitable, add unnecessary >> overheads to the signalling and data between the mobile node and the >> home agent. Furthermore, none of those mechanisms can solve the >> scenario where IPv4 needs to be dynamically tunnelled in IPv6 (i.e. >> when a node uses an IPv4 home address in an IPv6 network). Due to >> these reasons, there is a need for a new transition mechanism that >> utilises the dynamic tunnelling capabilities of Mobile IP. Isn't there also an issue with the two mobility protocol configurations, credentials, etc., even if we have perfect IPv4 and IPv6 connectivity everywhere through transition mechanisms? Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 21 11:03:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtvm-0005Mz-PC; Wed, 21 Feb 2007 11:02:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtkK-0008Ka-VU; Wed, 21 Feb 2007 10:51:09 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HJtkE-0007nP-Qc; Wed, 21 Feb 2007 10:51:08 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id AE82D17625; Wed, 21 Feb 2007 15:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HJtjG-0008Th-Eo; Wed, 21 Feb 2007 10:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 21 Feb 2007 10:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-location-privacy-ps-06.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : IP Address Location Privacy and Mobile IPv6: Problem Statement Author(s) : R. Koodli Filename : draft-ietf-mip6-location-privacy-ps-06.txt Pages : 11 Date : 2007-2-21 In this document, we discuss Location Privacy as applicable to Mobile IPv6. We document the concerns arising from revealing Home Address to an on-looker and from disclosing Care of Address to a correspondent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-location-privacy-ps-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-location-privacy-ps-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-location-privacy-ps-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-21090250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-location-privacy-ps-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-location-privacy-ps-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-21090250.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Wed Feb 21 12:34:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvLd-00034r-4Z; Wed, 21 Feb 2007 12:33:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvLb-00033x-99; Wed, 21 Feb 2007 12:33:43 -0500 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJvLZ-00083l-HI; Wed, 21 Feb 2007 12:33:43 -0500 Received: from PC20005 ([124.191.178.123]) by omta05ps.mx.bigpond.com with ESMTP id <20070221173333.VOCF19269.omta05ps.mx.bigpond.com@PC20005>; Wed, 21 Feb 2007 17:33:33 +0000 From: "Hesham Soliman" To: "'Jari Arkko'" Subject: RE: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt Date: Thu, 22 Feb 2007 04:33:27 +1100 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: <45DC527F.5060301@piuha.net> Thread-Index: AcdVwd0cxoNs2Hi+ROalaZ2ELSmC1QAG/EZQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070221173333.VOCF19269.omta05ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'Mobile IPv6 Mailing List' , 'Mobile IPv4 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > >> The IETF has standardized a number of transition > mechanisms to allow > >> networks and end nodes to gain IPv6 connectivity while > the Internet > >> is migrating from IPv4 to IPv6. These transition mechanisms can be > >> categorised under two main items: Tunnelling and Protocol > >> Translation. Protocol Translation mechanisms are not suitable for > >> Mobile IP signalling as they break end to end integrity. > Tunnelling > >> mechanisms, (both static and dynamic), when suitable, add > unnecessary > >> overheads to the signalling and data between the mobile > node and the > >> home agent. Furthermore, none of those mechanisms can solve the > >> scenario where IPv4 needs to be dynamically tunnelled in > IPv6 (i.e. > >> when a node uses an IPv4 home address in an IPv6 network). Due to > >> these reasons, there is a need for a new transition mechanism that > >> utilises the dynamic tunnelling capabilities of Mobile IP. > > Isn't there also an issue with the two mobility protocol > configurations, > credentials, etc., even if we have perfect IPv4 and IPv6 connectivity > everywhere through transition mechanisms? => Yes but this point is mentioned elsewhere. I was trying to solve the issue of why current transition mechanisms are not sufficient. Hesham > > Jari > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 21 13:49:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwWp-0003F0-0Y; Wed, 21 Feb 2007 13:49:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwWn-0003El-UX for mip6@ietf.org; Wed, 21 Feb 2007 13:49:21 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJwWl-00028n-10 for mip6@ietf.org; Wed, 21 Feb 2007 13:49:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id C9CBF90001 for ; Wed, 21 Feb 2007 13:49:14 -0500 (EST) 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 04883-07 for ; Wed, 21 Feb 2007 13:49:10 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 21 Feb 2007 13:49:10 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 13:49:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Date: Wed, 21 Feb 2007 13:49:09 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD940@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Thread-Index: AcdQY1dNlaD6hLxWEduSnQARJNUNiAAgF6FwARg2mFA= From: "Chowdhury, Kuntal" To: "Kilian Weniger" , "Basavaraj Patil" , X-OriginalArrivalTime: 21 Feb 2007 18:49:09.0980 (UTC) FILETIME=[F8E3C9C0:01C755E8] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 1.1 (+) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Killian, Thanks for reviewing the draft. I see that Heejin already responded to you. Let me add some of my comments...please see inline. Regards, Kuntal > -----Original Message----- > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > Sent: Friday, February 16, 2007 2:31 AM > To: Basavaraj Patil; mip6@ietf.org > Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 >=20 > Hi, >=20 > please find below some comments about > draft-ietf-mip6-bootstrapping-integrated-02. >=20 > The draft is well written and easy to understand (thanks to figures and > message sequence text). However, some details and corner cases are not > addressed, which may need to be specified, e.g.: >=20 > - How does the NAS/relay map a DHCP request received from a specific MN > to the cached home network information previously received from AAAH > for this MN, so that it can include the correct home network > information in a received DHCP request? [KC>] Normally NAS maintain session states along with lower layer identifiers such as tunnel ID, MAC address etc. These identifiers help NAS in locating the correct cached info for the MN. > - What is the conceptual data structure needed for this in the NAS/DHCP > relay? > - Any default value for how long NAS should cache home network > information received from AAA for a specific MN (i.e., when is NAS > allowed to delete cache entry?)? If this is specified in [MIP6-Dime] > or [MIP6-RADIUS] it should be mentioned and referenced. [KC>] As Heejin mentioned, I think these are implementation specific details. > - What should NAS do if DHCP request with Home network identifier > option is received from a MN and NAS doesn't find valid home network > information for this MN in its cache (e.g., since the cache entry > has expired)? [KC>] If a NAS implementation does not store the home network information as long as the MN's session remains in the ASP, this scenario may happen if the MN delays sending DHCP request. In such case, the NAS/DHCP relay won't include the OPTION_MIP6-RELAY-Option in the Relay Forward message. > - What should DHCP relay/server do if the MN does not include the > OPTION_CLIENTID in the DHCP request or if OPTION_MIP6-RELAY-Option > is missing in request? >=20 [KC>] I think Heejin already clarified this with you. > The draft may need better aligned with [HIOPT]. For instance, it is not > clear to me how exactly the home network identifier option and the home > network information option specified in [HIOPT] are allowed to be used > in draft-ietf-mip6-bootstrapping-integrated-02: >=20 [KC>] This part was in this I-D. However, based on the consensus we had in the WG, we decided to move all the DHCP related behavior to HIOT. Please look at section 4 in HIOT. > - [HIOPT] supports home address allocation. This is not mentioned in > draft-ietf-mip6-bootstrapping-integrated-02. Is this forbidden or > allowed or out-of-scope? If allowed, when does NAS set the A-flag in > the home network identifier option? [KC>] Please see Heejin's clarification. > - Is it allowed that multiple HA addresses are returned in the home > network information option? [KC>] yes, it is allowed. > - [HIOPT] allows that the home network identifier option includes an > identifier of a target network, which is different from home or > visited network of MN. This is not mentioned in > draft-ietf-mip6-bootstrapping-integrated-02. Is this allowed or > forbidden? [KC>] the main assumption in integrated scenario is ASA =3D=3D MSA. It = is the MSA that authorizes the MN for mobility service and assigns appropriate number of Home Agents (in each MSPs if there are multiple MSPs) for the MN. If the MN sends DHCP request with home network identifier option set to one of the authorized MSPs and there is a HA assignment for that MSP by the MSA, the MN will get that HA's address. If the MN sends anything else (i.e. a domain that is not part of the authorized list of MSPs by the MSA), the MN may not get any Home Agent address in the reply.=20 > - Which HA information should the MN use if it receives, e.g., an FQDN > and a HA address in DHCP reply? [HIOPT] refers to section 3.6 of > draft-ietf-mip6-bootstrapping-integrated-01, but this section doesn't > exist in draft-ietf-mip6-bootstrapping-integrated-02 anymore... >=20 [KC>] This text was exported to HIOT draft. > Some other comments: >=20 > - It would be good to have a section, which explicitly states > assumptions and applicability of the protocol. This should include: > - MSA and ASA must be co-located (i.e., integrated scenario) [KC>] The definition of integrated scenario exists in RFC 4640.=20 > - AAA infrastructure assumed and some kind of roaming > relationship between ASP and MSA/ASA is required [KC>] We have ample references to AAA infrastructure for ASA and MSA. However, we can still add a sentence about the use of AAA infrastructure to authenticate and authorize the MN. Regarding roaming, I think your comment is valid. ASP <-> ASA/MSA and MSP <-> ASA/MSA roaming relationships are basic requirements for any access auth/authz for the MN. However, I think it is a generic requirement. Even in case of split scenario, ASP <-> ASA and MSP <-> MSA roaming relationships are necessary. Look at section 6 in RFC 4640 and let me know what you think. > - MSP is either co-located with ASP or MSA or both > (Or are other target networks allowed; see above)? [KC>] Why we need to mandate collocation of MSP with ASA or MSA? The draft HIOT allows any target network, but that does not mean that in the integrated scenario, the MSA can bootstrap the MN for any (random) target network. > - DHCP relay and NAS must be co-located >=20 [KC>] I think it is already mentioned in the draft: " Also, the mechanism defined in this document requires the NAS to support Mobile IPv6 specific AAA attributes and a collocated DHCP relay agent. " > - At some places in the text the use of the term "MSP" is ambiguous, > since MSP can refer to at least home and visited network. Better > use "home MSP" for MSP in home network. > - e.g., section 3.1: > "Note that a home agent for usage > with the mobile node might be selected in the access service > provider's network or alternatively in the *home* mobility service > provider's network." [KC>] I understand your point. We can clarify by saying that: " Note that a home agent for usage with the mobile node might be selected in the access service provider's network (ASP is the visited MSP in this case) or alternatively in the *home* mobility service provider's network (home MSP). " What do you think? If you agree, I will ensure that this is clarified elsewhere in the document. > - or in section 3.2: > "The message flows for home agent > allocation in the ASP and the *home* MSP are illustrated below. [KC>] Similarly we can clarify: "=20 The message flows for home agent allocation in the ASP (ASP is the visited MSP in this case) and the *home* MSP are illustrated below. " > - or in section 3.2.1: > "3.2.1. Home Agent allocation in the *home* MSP", > "(4)... mobile node is requesting home agent information in the > *home* MSP..." >=20 > - Section 3.3 currently mentions DNS-based HA address discovery method > only, but [BOOT-SPLIT] also specifies an anycast-based HA address > discovery method. Either both or none should be mentioned. >=20 [KC>] I see your point. May be we just need to say that incase the DHCP reply comes back with no Home Agent address, the MN may fallback to other methods for Home Agent bootstrapping. Some of those methods are mentioned in [BOOT-SPLIT].=20 > - The title of draft-ietf-mip6-bootstrapping-integrated-02 can cause > the impression that the draft defines a complete bootstrapping > procedure. But draft-ietf-mip6-bootstrapping-integrated-02 defines a > method for HA address assignment only. I think this is misleading. > Why not name the draft according to what it specifies (e.g., "HA > address assignment using DHCP and AAA" or "HA address assignment for > the integrated scenario using DHCP and AAA" instead of > "MIP6-bootstrapping for the integrated scenario")? >=20 [KC>] I agree with you that the Home Agent assignment is the focus of the integrated scenario solution I-D. But, the suggested title change will be misleading too. One of the primary assumption in the integrated scenario for mip6 bootstrapping is ASA =3D=3D MSA. This is the main = reason why the MSA can authorize the MN to have mobility service at the time of access auth/authz at the ASA. As per this assumption, the MSA assigns Home Agent info to the MN at the time of access auth. The MSA can potentially assign the HoA as well (in some deployments that may very well be the case), but we stayed away from mentioning that in the draft based on consensus. Another reason was to reuse text from other drafts as much possible.=20 That said, the scope and focus of this I-D is to address mip6 bootstrapping solution for the "Integrated ASP Network Scenario" as defined by RFC 4640. So, the current title is fine, IMHO. > Regards, >=20 > Kilian >=20 > > -----Original Message----- > > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > > Sent: Mittwoch, 14. Februar 2007 19:10 > > To: mip6@ietf.org > > Subject: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 > > > > > > Hello, > > > > This is a MIP6 Working group last call for the WG I-D: > > "MIP6-bootstrapping for the Integrated Scenario", > > draft-ietf-mip6-bootstrapping-integrated-02.txt > > > > I-D: > > http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping- > > integrated-dhc > > -02.txt > > > > Please review and submit your comments to the authors or the mailing > > list. The WGLC will expire on March 1st, 07. > > > > -Chairs > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 22 04:19:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKA5W-0002os-1A; Thu, 22 Feb 2007 04:18:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKA5U-0002nt-KI for mip6@ietf.org; Thu, 22 Feb 2007 04:18:04 -0500 Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKA5T-0000po-65 for mip6@ietf.org; Thu, 22 Feb 2007 04:18:04 -0500 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id l1M9Hxer018865 for ; Thu, 22 Feb 2007 11:18:00 +0200 (EET) Received: from [131.177.105.186] (ws186.secureuser.sonera.fi [131.177.105.186]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id l1M9HtaT018858 for ; Thu, 22 Feb 2007 11:17:59 +0200 (EET) Message-ID: <45DD5FC2.2070705@teliasonera.com> Date: Thu, 22 Feb 2007 11:17:54 +0200 From: Jouni Korhonen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Mip6] New I-D: Service Selection for [CP]MIPv6 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, Comments are welcome. http://www.ietf.org/internet-drafts/draft-korhonen-mip6-service-00.txt "Mobile IPv6 has a Mobile Node Identifier option (MN-NAI) that provides a flexible way to identify mobile nodes using other identifiers than IPv6 addresses. Example of such identifier is a Network Access Identifier (NAI). Similarly, in some Mobile IPv6 deployments identifying the mobile node or the mobility service subscriber via a proxy representative is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. The capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers to provide multiple services within the same mobility service subscription." Cheers, Jouni _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 22 06:10:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKBpG-00021l-9S; Thu, 22 Feb 2007 06:09:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKBpF-00021g-AD for mip6@ietf.org; Thu, 22 Feb 2007 06:09:25 -0500 Received: from cluster-e.mailcontrol.com ([217.79.216.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKBpE-0001zO-6s for mip6@ietf.org; Thu, 22 Feb 2007 06:09:25 -0500 Received: from rly57e.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly57e.srv.mailcontrol.com (MailControl) with ESMTP id l1MB9EQW022775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Feb 2007 11:09:18 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly57e.srv.mailcontrol.com (MailControl) id l1MB91A5022251 for mip6@ietf.org; Thu, 22 Feb 2007 11:09:01 GMT Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly57e-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l1MB8s5F021927; Thu, 22 Feb 2007 11:09:01 +0000 (GMT) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 65bb_1af38876_c262_11db_95d8_0030482aac25; Thu, 22 Feb 2007 11:47:34 +0100 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007022212085022-612993 ; Thu, 22 Feb 2007 12:08:50 +0100 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: -0.160,BAYES_00: -1.665,TOTAL_SCORE: -1.825 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Thu, 22 Feb 2007 12:13:43 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 In-Reply-To: <7CCD07160348804497EF29E9EA5560D7FBD940$0001@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Thread-Index: AcdQY1dNlaD6hLxWEduSnQARJNUNiAAgF6FwARg2mFAARgirYA== References: <7CCD07160348804497EF29E9EA5560D7FBD940$0001@exchtewks2.starentnetworks.com> To: "Chowdhury, Kuntal" Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F01278022@lan-ex-01.panasonic.de> Date: Thu, 22 Feb 2007 12:05:59 +0100 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-06-00-00 (www.mailcontrol.com) on 10.69.1.167 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.2 (+) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Kuntal, thanks for you comments. See my comments inline. > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > Sent: Mittwoch, 21. Februar 2007 19:49 > To: Kilian Weniger; Basavaraj Patil; mip6@ietf.org > Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 >=20 > Hi Killian, >=20 > Thanks for reviewing the draft. I see that Heejin already responded to > you. Let me add some of my comments...please see inline. I will reply to Heejin in a separate mail. >=20 > Regards, > Kuntal >=20 >=20 > > -----Original Message----- > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > Sent: Friday, February 16, 2007 2:31 AM > > To: Basavaraj Patil; mip6@ietf.org > > Subject: RE: [Mip6] WGLC:=20 > draft-ietf-mip6-bootstrapping-integrated-02 > >=20 > > Hi, > >=20 > > please find below some comments about > > draft-ietf-mip6-bootstrapping-integrated-02. > >=20 > > The draft is well written and easy to understand (thanks to figures > and > > message sequence text). However, some details and corner=20 > cases are not > > addressed, which may need to be specified, e.g.: > >=20 > > - How does the NAS/relay map a DHCP request received from a specific > MN > > to the cached home network information previously=20 > received from AAAH > > for this MN, so that it can include the correct home network > > information in a received DHCP request? >=20 > [KC>] Normally NAS maintain session states along with lower layer > identifiers such as tunnel ID, MAC address etc. These identifiers help > NAS in locating the correct cached info for the MN. ok, I was expecting that. Maybe this could be clarified in the draft for better understanding (without mandating a specific lower layer identifier of course). >=20 > > - What is the conceptual data structure needed for this in the > NAS/DHCP > > relay? > > - Any default value for how long NAS should cache home network > > information received from AAA for a specific MN (i.e., when is NAS > > allowed to delete cache entry?)? If this is specified in=20 > [MIP6-Dime] > > or [MIP6-RADIUS] it should be mentioned and referenced. >=20 > [KC>] As Heejin mentioned, I think these are implementation specific > details. yes, but I think some guidance with respect to values that make sense might be helpful for implementors. >=20 >=20 > > - What should NAS do if DHCP request with Home network identifier > > option is received from a MN and NAS doesn't find valid=20 > home network > > information for this MN in its cache (e.g., since the cache entry > > has expired)? >=20 > [KC>] If a NAS implementation does not store the home network > information as long as the MN's session remains in the ASP, this > scenario may happen if the MN delays sending DHCP request. In=20 > such case, > the NAS/DHCP relay won't include the OPTION_MIP6-RELAY-Option in the > Relay Forward message. ok. Shouldn't the draft specify this behaviour? >=20 > > - What should DHCP relay/server do if the MN does not include the > > OPTION_CLIENTID in the DHCP request or if OPTION_MIP6-RELAY-Option > > is missing in request? > >=20 >=20 > [KC>] I think Heejin already clarified this with you. >=20 > > The draft may need better aligned with [HIOPT]. For instance, it is > not > > clear to me how exactly the home network identifier option and the > home > > network information option specified in [HIOPT] are allowed=20 > to be used > > in draft-ietf-mip6-bootstrapping-integrated-02: > >=20 > [KC>] This part was in this I-D. However, based on the=20 > consensus we had > in the WG, we decided to move all the DHCP related behavior to HIOT. > Please look at section 4 in HIOT. ok. So the split is that HIOPT specifies all the DHCP related behaviour and defines the DHCP messages/options and draft-ietf-mip6-bootstrapping-integrated-02 defines how this interworks with AAA and gives the overall picture? Is this correct? I think draft-ietf-mip6-bootstrapping-integrated-02 should clearly say what its scope is and how the split is with respect to HIOPT (and the reference should be updated to new HIOPT-version). >=20 > > - [HIOPT] supports home address allocation. This is not mentioned in > > draft-ietf-mip6-bootstrapping-integrated-02. Is this forbidden or > > allowed or out-of-scope? If allowed, when does NAS set=20 > the A-flag in > > the home network identifier option? >=20 > [KC>] Please see Heejin's clarification. >=20 > > - Is it allowed that multiple HA addresses are returned in the home > > network information option? > [KC>] yes, it is allowed. ok. In general, I think all the supported features should be mentioned in draft-ietf-mip6-bootstrapping-integrated-02.=20 >=20 > > - [HIOPT] allows that the home network identifier option includes an > > identifier of a target network, which is different from home or > > visited network of MN. This is not mentioned in > > draft-ietf-mip6-bootstrapping-integrated-02. Is this allowed or > > forbidden? > [KC>] the main assumption in integrated scenario is ASA =3D=3D MSA. It = is > the MSA that authorizes the MN for mobility service and assigns > appropriate number of Home Agents (in each MSPs if there are multiple > MSPs) for the MN. If the MN sends DHCP request with home network > identifier option set to one of the authorized MSPs and there is a HA > assignment for that MSP by the MSA, the MN will get that HA's address. > If the MN sends anything else (i.e. a domain that is not part of the > authorized list of MSPs by the MSA), the MN may not get any Home Agent > address in the reply.=20 I see. So every realm of any MSP that has a trust relationship to the MN's MSA and that is supported by the MSA's allocation policy can be included as target network in the home network identifier option, right? (That's what I meant by "a target network, which is different from home or visited network of MN".)=20 Hmm, after checking RFC4640, it seems that there is a mismatch between your comment and what the draft says:=20 - Section 3.2.1 of draft-ietf-mip6-bootstrapping-integrated-02 says "This section describes a scenario where the home agent is allocated in the mobile node's *home MSP* network."=20 - RFC 4640 says in section 6: "A network operator providing Mobile IPv6 service is called a mobility service provider (MSP). ...A network operator that authenticates a mobile node and authorizes mobility service is called a mobility service authorizer (MSA). If both types of operation are performed by the same operator, that operator is called a *home mobility service provider*.".=20 So according to RFC4640 the home MSP is always the MSA. Since you said HA allocation from other networks is supported, I think the use of "home MSP" in the section 3.2.1 is not correct. Or am I missing something here? And I think the support of the feature of HA allocation from MSP !=3D = MSA and !=3D ASP should be mentioned in the draft.=20 >=20 > > - Which HA information should the MN use if it receives,=20 > e.g., an FQDN > > and a HA address in DHCP reply? [HIOPT] refers to section 3.6 of > > draft-ietf-mip6-bootstrapping-integrated-01, but this section > doesn't > > exist in draft-ietf-mip6-bootstrapping-integrated-02 anymore... > >=20 > [KC>] This text was exported to HIOT draft. >=20 > > Some other comments: > >=20 > > - It would be good to have a section, which explicitly states > > assumptions and applicability of the protocol. This=20 > should include: > > - MSA and ASA must be co-located (i.e., integrated scenario) >=20 > [KC>] The definition of integrated scenario exists in RFC 4640.=20 >=20 > > - AAA infrastructure assumed and some kind of roaming > > relationship between ASP and MSA/ASA is required >=20 > [KC>] We have ample references to AAA infrastructure for ASA and MSA. > However, we can still add a sentence about the use of AAA=20 > infrastructure > to authenticate and authorize the MN. Regarding roaming, I think your > comment is valid. ASP <-> ASA/MSA and MSP <-> ASA/MSA roaming > relationships are basic requirements for any access auth/authz for the > MN. However, I think it is a generic requirement. Even in=20 > case of split > scenario, ASP <-> ASA and MSP <-> MSA roaming relationships are > necessary. Look at section 6 in RFC 4640 and let me know what=20 > you think. ASP <-> ASA is general requirement for network access in roaming scenarios, I agree. But the required MSP <-> ASA roaming relationship is specific to this draft and it would be worth mentioning IMHO.=20 You are right, the reader could deduced it to some extent from RFC4640, which says that MSA <-> MSP roaming relationship is *supported* (not required) for MIP bootstrapping and MSA =3D ASA is an assumption in integrated scenario. I prefer to make a clear statement about assumptions/requirements of solutions in the draft. >=20 > > - MSP is either co-located with ASP or MSA or both > > (Or are other target networks allowed; see above)? >=20 > [KC>] Why we need to mandate collocation of MSP with ASA or MSA? The > draft HIOT allows any target network, but that does not mean=20 > that in the > integrated scenario, the MSA can bootstrap the MN for any (random) > target network. This requirements comes from the misunderstanding about the home MSP explained above. Since you clarified that target network !=3D MSA and = !=3D ASP is supported, you are right that this requirement is not valid anymore... >=20 > > - DHCP relay and NAS must be co-located > >=20 > [KC>] I think it is already mentioned in the draft: > " > Also, the mechanism defined in this document requires the NAS=20 > to support > Mobile IPv6 specific AAA attributes and a collocated DHCP relay agent. > " yes, it is somewhat redundant. I just prefer it if the applicability and all the requirements for the solution are clearly stated (preferably in a separate section, as opposed to hidden in the text). >=20 > > - At some places in the text the use of the term "MSP" is ambiguous, > > since MSP can refer to at least home and visited network. Better > > use "home MSP" for MSP in home network. > > - e.g., section 3.1: > > "Note that a home agent for usage > > with the mobile node might be selected in the access service > > provider's network or alternatively in the *home*=20 > mobility service > > provider's network." >=20 > [KC>] I understand your point. We can clarify by saying that: >=20 > " > Note that a home agent for usage with the mobile node might=20 > be selected > in the access service provider's network (ASP is the visited=20 > MSP in this > case) or alternatively in the *home* mobility service=20 > provider's network > (home MSP). > " > What do you think? If you agree, I will ensure that this is clarified > elsewhere in the document. Hmm, after having read your comments, "home MSP" might not be correct here, since MSP can be !=3D MSA (i.e., !=3D home MSP) in this section. = How about "MSP different from ASP" instead of "home MSP"? >=20 > > - or in section 3.2: > > "The message flows for home agent > > allocation in the ASP and the *home* MSP are illustrated below. >=20 > [KC>] Similarly we can clarify: >=20 > "=20 > The message flows for home agent allocation in the ASP (ASP is the > visited MSP in this case) and the *home* MSP are illustrated below. > " Home MSP might not be correct (see above). How about "The message flows for home agent allocation in the MSP for the cases that the MSP is equal to the ASP and different from the ASP are illustrated below." >=20 > > - or in section 3.2.1: > > "3.2.1. Home Agent allocation in the *home* MSP", > > "(4)... mobile node is requesting home agent information in the > > *home* MSP..." > >=20 > > - Section 3.3 currently mentions DNS-based HA address=20 > discovery method > > only, but [BOOT-SPLIT] also specifies an anycast-based HA address > > discovery method. Either both or none should be mentioned. > >=20 > [KC>] I see your point. May be we just need to say that=20 > incase the DHCP > reply comes back with no Home Agent address, the MN may fallback to > other methods for Home Agent bootstrapping. Some of those methods are > mentioned in [BOOT-SPLIT].=20 sounds good. >=20 >=20 > > - The title of draft-ietf-mip6-bootstrapping-integrated-02 can cause > > the impression that the draft defines a complete bootstrapping > > procedure. But=20 > draft-ietf-mip6-bootstrapping-integrated-02 defines a > > method for HA address assignment only. I think this is misleading. > > Why not name the draft according to what it specifies (e.g., "HA > > address assignment using DHCP and AAA" or "HA address=20 > assignment for > > the integrated scenario using DHCP and AAA" instead of > > "MIP6-bootstrapping for the integrated scenario")? > >=20 > [KC>] I agree with you that the Home Agent assignment is the focus of > the integrated scenario solution I-D. But, the suggested title change > will be misleading too. One of the primary assumption in the=20 > integrated > scenario for mip6 bootstrapping is ASA =3D=3D MSA. This is the main = reason > why the MSA can authorize the MN to have mobility service at=20 > the time of > access auth/authz at the ASA. As per this assumption, the MSA assigns > Home Agent info to the MN at the time of access auth. The MSA can > potentially assign the HoA as well (in some deployments that may very > well be the case), but we stayed away from mentioning that in=20 > the draft > based on consensus. Another reason was to reuse text from other drafts > as much possible.=20 >=20 > That said, the scope and focus of this I-D is to address mip6 > bootstrapping solution for the "Integrated ASP Network Scenario" as > defined by RFC 4640. So, the current title is fine, IMHO. Since the introduction says "This document defines a mechanism for home agent address discovery. For the rest of components, please refer to [BOOT-SPLIT].", I think the title is still ok.=20 However, you mentioned that HoA allocation can be done by the MSA (probably by using the method specified in HIOPT). If this shall be supported in the integrated scenario, I think the draft has to mention it. Currently, the draft clearly says that HoA allocation is according to [BOOT-SPLIT]... Regards, Kilian=20 >=20 >=20 >=20 > > Regards, > >=20 > > Kilian > >=20 > > > -----Original Message----- > > > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > > > Sent: Mittwoch, 14. Februar 2007 19:10 > > > To: mip6@ietf.org > > > Subject: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 > > > > > > > > > Hello, > > > > > > This is a MIP6 Working group last call for the WG I-D: > > > "MIP6-bootstrapping for the Integrated Scenario", > > > draft-ietf-mip6-bootstrapping-integrated-02.txt > > > > > > I-D: > > > http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping- > > > integrated-dhc > > > -02.txt > > > > > > Please review and submit your comments to the authors or=20 > the mailing > > > list. The WGLC will expire on March 1st, 07. > > > > > > -Chairs > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > >=20 > >=20 > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke > >=20 > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > "This email message and any attachments are confidential=20 > information of Starent Networks, Corp. The information=20 > transmitted may not be used to create or change any=20 > contractual obligations of Starent Networks, Corp. Any=20 > review, retransmission, dissemination or other use of, or=20 > taking of any action in reliance upon this e-mail and its=20 > attachments by persons or entities other than the intended=20 > recipient is prohibited. If you are not the intended=20 > recipient, please notify the sender immediately -- by=20 > replying to this message or by sending an email to=20 > postmaster@starentnetworks.com -- and destroy all copies of=20 > this message and any attachments without reading or=20 > disclosing their contents. Thank you." >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 22 09:05:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKEYo-0005RY-8c; Thu, 22 Feb 2007 09:04:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKEYm-0005Q8-Qf for mip6@ietf.org; Thu, 22 Feb 2007 09:04:37 -0500 Received: from cluster-j.mailcontrol.com ([86.111.223.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKEYm-0003X5-22 for mip6@ietf.org; Thu, 22 Feb 2007 09:04:36 -0500 Received: from rly08j.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly08j.srv.mailcontrol.com (MailControl) with ESMTP id l1ME3jUR006072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Feb 2007 14:04:22 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly08j.srv.mailcontrol.com (MailControl) id l1ME3ekk005900 for mip6@ietf.org; Thu, 22 Feb 2007 14:03:40 GMT Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly08j-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l1ME3WPO005580; Thu, 22 Feb 2007 14:03:40 +0000 (GMT) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 65fa_80e58b08_c27a_11db_998a_0030482aac25; Thu, 22 Feb 2007 14:42:13 +0100 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007022215032830-627403 ; Thu, 22 Feb 2007 15:03:28 +0100 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: -0.159,BAYES_00: -1.665,TOTAL_SCORE: -1.824 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Thu, 22 Feb 2007 15:08:20 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 In-Reply-To: <0JDR0049I3JT7Y@ms5.samsung.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Thread-Index: AcdUwMUyhF+tuBaFTgu1pTm7wLnJ/QA2seuA References: <0JDR0049I3JT7Y@ms5.samsung.com> To: "Heejin Jang" Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F01278054@lan-ex-01.panasonic.de> Date: Thu, 22 Feb 2007 15:00:36 +0100 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-06-00-00 (www.mailcontrol.com) on 10.74.1.118 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.2 (+) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Heejin, thanks for your comments, see my replies inline.=20 Please note that the comments in my mail were referring to draft-ietf-mip6-bootstrapping-integrated-02. And since the reference [HIOPT] in draft-ietf-mip6-bootstrapping-integrated-02 is hiopt-01, I didn't consider hiopt-02.=20 > -----Original Message----- > From: Heejin Jang [mailto:heejin.jang@samsung.com]=20 > Sent: Dienstag, 20. Februar 2007 08:31 > To: Kilian Weniger > Cc: Basavaraj Patil; mip6@ietf.org > Subject: Re: RE: [Mip6] WGLC:=20 > draft-ietf-mip6-bootstrapping-integrated-02 >=20 > Hi, Kilian Weniger.=20 >=20 > Thanks for the detailedl comments.=20 >=20 > Please see the inline comments for the HIOPT draft. >=20 >=20 > ------- Original Message ------- > Sender : Kilian Weniger > Date : 2007-02-16 17:31 > Title : RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 >=20 > Hi,=20 >=20 > please find below some comments about =20 > draft-ietf-mip6-bootstrapping-integrated-02.=20 >=20 > The draft is well written and easy to understand (thanks to=20 > figures and=20 > message sequence text). However, some details and corner=20 > cases are not=20 > addressed, which may need to be specified, e.g.:=20 >=20 > - How does the NAS/relay map a DHCP request received from a=20 > specific MN =20 > to the cached home network information previously received=20 > from AAAH =20 > for this MN, so that it can include the correct home network =20 > information in a received DHCP request?=20 >=20 > =20 >=20 > Hiopt>> The mapping mechanism is added in section 4.3 of the=20 > latest version of the document (hiopt-02). It should be in section 4.2, since my question was related to the DHCP relay behaviour. Maybe I missed it, but I can't see any related text in section 4.2 of hiopt-02 about mapping of home information received from AAA server to DHCP request received from MN. But Kuntal answered to my question in his reply email.=20 >=20 > The information is mapped based on NAI not by NAS but by DHCP=20 > server. Rrefer to hiopt-02 for more details. >=20 >=20 > - What is the conceptual data structure needed for this in=20 > the NAS/DHCP =20 > relay?=20 > - Any default value for how long NAS should cache home network =20 > information received from AAA for a specific MN (i.e., when is NAS =20 > allowed to delete cache entry?)? If this is specified in=20 > [MIP6-Dime] =20 > or [MIP6-RADIUS] it should be mentioned and referenced. =20 >=20 > Hiopt>> This is implementation-specific. I'm not sure we need=20 > to describe down to the smallest detail.=20 A value doesn't need to be mandated, but I think some guidance to the implementor would be good. >=20 >=20 > - What should NAS do if DHCP request with Home network identifier =20 > option is received from a MN and NAS doesn't find valid=20 > home network =20 > information for this MN in its cache (e.g., since the cache entry =20 > has expired)?=20 >=20 > =20 >=20 > Hiopt>>In that case, there is nothing NAS can do. If the =20 > corresponding information=20 >=20 > is configured on the DHCP server (for e.g.,=20 > pre-configuration), the server will > provide it. Otherwise, it will reply with 0-lengh option. ok. My comment was that this should be documented (i.e., DHCP server must reply with 0-lengh option in this case) >=20 >=20 > - What should DHCP relay/server do if the MN does not include the =20 > OPTION_CLIENTID in the DHCP request or if OPTION_MIP6-RELAY-Option =20 > is missing in request?=20 >=20 >=20 > =20 >=20 > Hiopt>> The existing DHCP options are handled according to [RFC 3315]. >=20 > The request not including OPTION_CLIENTID is discarded in the=20 > relay/server >=20 > as described in 15.4 of [RFC 3315].=20 ok. >=20 >=20 > The draft may need better aligned with [HIOPT]. For instance,=20 > it is not=20 > clear to me how exactly the home network identifier option=20 > and the home =20 > network information option specified in [HIOPT] are allowed=20 > to be used=20 > in draft-ietf-mip6-bootstrapping-integrated-02: =20 >=20 > - [HIOPT] supports home address allocation. This is not mentioned in =20 > draft-ietf-mip6-bootstrapping-integrated-02. Is this forbidden or =20 > allowed or out-of-scope? If allowed, when does NAS set the=20 > A-flag in =20 > the home network identifier option?=20 >=20 > =20 >=20 > Hiopt>> NAS SHOULD not modify the Home Network Identifier option.=20 > The A-flag is set to 0/1 only by the mobile node. If there is=20 > home address > information at NAS that was acquired during AAA transaction,=20 > it is delivered > to the DHCP server with MIP6-Relay option. (Refer hiopt-02.txt) I was aware of HoA allocation support in [HIOPT]. My question was whether it is supported in draft-ietf-mip6-bootstrapping-integrated-02 as well, since HoA allocation is not mentioned there. >=20 >=20 > - Is it allowed that multiple HA addresses are returned in the home =20 > network information option?=20 >=20 > =20 >=20 > Hiopt>> It is allowed by using multiple home network=20 > information option. >=20 > "Multiple sub-options may exist in a Home Network Information option >=20 > to carry more than one home information." (in section 3.3.1) >=20 >=20 > - [HIOPT] allows that the home network identifier option includes an =20 > identifier of a target network, which is different from home or =20 > visited network of MN. This is not mentioned in =20 > draft-ietf-mip6-bootstrapping-integrated-02. Is this allowed or =20 > forbidden?=20 >=20 > =20 >=20 > Hiopt>> A target network may or may not be home network of the MN. =20 good. I guess "home network" means "home MSP" in this case, right? According to RFC4640, the "home MSP" is MN's MSA providing mobility service to MN.=20 According to Kuntal's comment, also MSPs other than MSA (or "home MSP") and ASP are supported as target networks. If this is true for hiopt (and it should be if it is true for draft-ietf-mip6-bootstrapping-integrated-02), then it seems that the hiopt draft also uses the term "home MSP" differently than defined in RFC4640. For instance, section 4.3, case C (id-type 2) says=20 "In case the server cannot not find any home information neither for the local network nor for the *home MSP*, it MUST return a Home Network Information option with the 0-length data." This would restrict HA/HoA allocation from ASP and MSA (=3Dhome MSP). I guess you also want to support allocation from MSPs other than ASP and MSA, no? So shouldn't "home MSP" be replaced by "any other MSP with roaming relationship to MN's MSA"? Same for id-type 1: section 3.1 says=20 " id-type The type of Home Network Identifier: 0 Visited domain (local ASP) 1 Home domain (home MSP) .... Id-type 1 indicates the mobile node is interested in learning the home network information that pertains to the given realm. This type can be used to discover home agents that are hosted by a user's home domain (as indicated by his/her NAI-based username -- user@ HomeRealm). The Home Network Identifier field MUST be set to the target home MSP. " This text implies that HA/HoA allocation from other MSPs than home MSP (which is equal to MSA) is not supported with id-type 1, even if those MSPs have a roaming relationship with the MN's MSA. Is this true?=20 Regards, Kilian >=20 > In current draft, the server is supposed to provide the HA=20 > information if it has >=20 > the corresponding information. If the given HA does not=20 > function as HA for >=20 > the requesting MN, it will reply with the BA status =3D 132 or 133 =20 >=20 > (Not home subnet / home agent for this mobile node) during=20 > MN's registration. >=20 >=20 > - Which HA information should the MN use if it receives,=20 > e.g., an FQDN =20 > and a HA address in DHCP reply? [HIOPT] refers to section 3.6 of =20 > draft-ietf-mip6-bootstrapping-integrated-01, but this=20 > section doesn't=20 > exist in draft-ietf-mip6-bootstrapping-integrated-02 anymore...=20 >=20 >=20 > =20 >=20 > Hiopt>> It is within the MN's own discretion as follows.=20 >=20 > I don't think it should be standardized in HIOPT document.=20 >=20 > "For example, if the mobile node acquires both IPv6=20 > address(es) and FQDN(s) > of the home agents, it may try to use the address=20 > information of the home agent(s) first." >=20 > =20 >=20 >=20 > Some other comments:=20 >=20 > - It would be good to have a section, which explicitly states =20 > assumptions and applicability of the protocol. This should include:=20 > - MSA and ASA must be co-located (i.e., integrated scenario)=20 > - AAA infrastructure assumed and some kind of roaming =20 > relationship between ASP and MSA/ASA is required=20 > - MSP is either co-located with ASP or MSA or both=20 > (Or are other target networks allowed; see above)?=20 > - DHCP relay and NAS must be co-located=20 >=20 > - At some places in the text the use of the term "MSP" is ambiguous, =20 > since MSP can refer to at least home and visited network. Better =20 > use "home MSP" for MSP in home network.=20 > - e.g., section 3.1:=20 > "Note that a home agent for usage=20 > with the mobile node might be selected in the access service=20 > provider's network or alternatively in the *home* mobility service=20 > provider's network."=20 > - or in section 3.2:=20 > "The message flows for home agent=20 > allocation in the ASP and the *home* MSP are illustrated below. =20 > - or in section 3.2.1:=20 > "3.2.1. Home Agent allocation in the *home* MSP",=20 > "(4)... mobile node is requesting home agent information in the =20 > *home* MSP..."=20 >=20 > - Section 3.3 currently mentions DNS-based HA address=20 > discovery method=20 > only, but [BOOT-SPLIT] also specifies an anycast-based HA address =20 > discovery method. Either both or none should be mentioned.=20 >=20 > - The title of draft-ietf-mip6-bootstrapping-integrated-02 can cause =20 > the impression that the draft defines a complete bootstrapping =20 > procedure. But draft-ietf-mip6-bootstrapping-integrated-02=20 > defines a =20 > method for HA address assignment only. I think this is misleading. =20 > Why not name the draft according to what it specifies (e.g., "HA =20 > address assignment using DHCP and AAA" or "HA address=20 > assignment for =20 > the integrated scenario using DHCP and AAA" instead of =20 > "MIP6-bootstrapping for the integrated scenario")?=20 >=20 > Regards,=20 >=20 > Kilian=20 >=20 > > -----Original Message-----=20 > > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] =20 > > Sent: Mittwoch, 14. Februar 2007 19:10=20 > > To: mip6@ietf.org=20 > > Subject: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02=20 > > =20 > > =20 > > Hello,=20 > > =20 > > This is a MIP6 Working group last call for the WG I-D:=20 > > "MIP6-bootstrapping for the Integrated Scenario",=20 > > draft-ietf-mip6-bootstrapping-integrated-02.txt=20 > > =20 > > I-D: =20 > > http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-=20 > > integrated-dhc=20 > > -02.txt=20 > > =20 > > Please review and submit your comments to the authors or=20 > the mailing=20 > > list. The WGLC will expire on March 1st, 07.=20 > > =20 > > -Chairs=20 > > =20 > > =20 > > _______________________________________________=20 > > Mip6 mailing list=20 > > Mip6@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/mip6=20 > > =20 > > =20 >=20 >=20 > Panasonic R&D Center Germany GmbH=20 > 63225 Langen, Hessen, Germany=20 > Reg: AG Offenbach (Hessen) HRB 33974=20 > Managing Director: Thomas Micke=20 >=20 >=20 >=20 > _______________________________________________=20 > Mip6 mailing list=20 > Mip6@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/mip6=20 >=20 >=20 >=20 >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 22 18:11:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKN45-00046B-EC; Thu, 22 Feb 2007 18:09:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKN44-000465-UE for mip6@ietf.org; Thu, 22 Feb 2007 18:09:28 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKN43-0004c4-Jt for mip6@ietf.org; Thu, 22 Feb 2007 18:09:28 -0500 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 l1MN9Or20176; Thu, 22 Feb 2007 18:09:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Volunteer to keep track of issues w.r.t RFC3775 Date: Thu, 22 Feb 2007 17:09:22 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437112DE468B@zrc2hxm2.corp.nortel.com> In-Reply-To: <45DC13C1.8000901@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Volunteer to keep track of issues w.r.t RFC3775 Thread-index: AcdVnMpT/ZojzLk5TdW28ouvBgPoMAAMd38w From: "Ahmad Muhanna" To: "Alexandru Petrescu" , "Basavaraj Patil" X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org One more issue that I think needs to be addressed is the following: ______________________________________________=20 From: Muhanna, Ahmad [RICH2:2Q30:EXCH] =20 Sent: Thursday, May 18, 2006 9:27 AM To: 'mip6@ietf.org' Cc: 'dbj@cs.rice.edu'; 'Charles E. Perkins'; 'jari.arkko@ericsson.com'; Khalil, Mohamed [RICH2:2S20:EXCH]; 'Basavaraj Patil'; 'Gopal Dommety' Subject: MIPv6: Using the last Accepted Sequence Number in BA Hi all, In response to a Binding Update which contains an out of range sequence number, as per sections 9.5.1 and 11.7.1, the CN or HA is allowed to send a Binding Acknowledgement with a status of 135 after inserting the last accepted sequence number received in the last valid Binding Update in the sequence number field (Different from the sequence number received in the outstanding BU) According to MN processing of the Binding Acknowledgement as specified under section 11.7.3., the MN will silently discard the received BA rather than picking the last accepted sequence number and then generate a new sequence number.=20 I think the intention was to allow the HA or CN to communicate back to the MN the last accepted sequence number, however, we are breaking the protocol by using this mechanism. Could you please comment on this and let me know if I am on the right track. Thanks. Regards, Ahmad =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 > Sent: Wednesday, February 21, 2007 3:41 AM > To: Basavaraj Patil > Cc: mip6@ietf.org > Subject: Re: [Mip6] Volunteer to keep track of issues w.r.t RFC3775 >=20 > Basavaraj Patil wrote: > > Alex, > >=20 > > Thanks for volunteering. But Rich Groves had sent in an=20 > email prior to=20 > > yours and we chose him. Your efforts or help in other tasks=20 > for this=20 > > WG would be appreciated and we will ask you for such in the near=20 > > future. >=20 > That's fine thanks, I'll comment on these issues anyways. >=20 > The issues around 3775 have been discussed on the mailing=20 > list mip6@ietf.org and on the prior mobileip list at=20 > playground at SUN since June 2004. So that's a lot of=20 > archived mail to search :-( >=20 > I could remember the following: >=20 > -a certain MH type wrongly documented as '2' in RFC. > -DHAAD and MPD could be used for botstrapping. > -HA sends Binding Error or not and in which cases. > -HA sends Binding Refresh Request or not and in which cases. >=20 > I'm almost 100% sure that more issues than these 4 were=20 > discussed. And I think there are more issues that have not=20 > been discussed at all since June 2004, at least DHCP and=20 > multicast with the MN-HA tunnel. >=20 > Alex >=20 > >=20 > > -Raj > >=20 > >=20 > > On 2/20/07 12:37 PM, "ext Alexandru Petrescu"=20 > > wrote: > >=20 > >> I volunteer that. > >>=20 > >> Alex > >>=20 > >> Basavaraj Patil wrote: > >>> Hello, > >>>=20 > >>> As we are moving forward with developing various extensions and=20 > >>> enhancements to Mobile IPv6, we also need to ensure that we are=20 > >>> Identifying and tracking any issues with the base protocol (RFC > >>> 3775) itself. In fact the charter states: " Additionally=20 > the working=20 > >>> group will ensure that any issues identified by=20 > implementation and=20 > >>> interoperability experience are addressed, and that the base=20 > >>> specifications are maintained. " > >>>=20 > >>> We need a volunteer who will maintain such a list of=20 > issues that are=20 > >>> identified and discussed on the mailing list. Please send=20 > the chairs=20 > >>> a note if you would be willing to act as the base-spec issue=20 > >>> tracker. > >>>=20 > >>> -Raj > >>>=20 > >>>=20 > >>> _______________________________________________ Mip6=20 > mailing list =20 > >>> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > >>>=20 > >=20 > >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 23 03:46:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKW3o-0003j9-Ji; Fri, 23 Feb 2007 03:45:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKW3n-0003j1-Ct for mip6@ietf.org; Fri, 23 Feb 2007 03:45:47 -0500 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKW3h-0005G7-Qc for mip6@ietf.org; Fri, 23 Feb 2007 03:45:47 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id DCFC423DA5B for ; Fri, 23 Feb 2007 09:45:38 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14906-01-83 for ; Fri, 23 Feb 2007 09:45:38 +0100 (CET) Received: from [155.54.205.230] (inf-205-230.um.es [155.54.205.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id B29CD23DA71 for ; Fri, 23 Feb 2007 09:45:28 +0100 (CET) Message-ID: <45DEA9A8.10506@dif.um.es> Date: Fri, 23 Feb 2007 09:45:28 +0100 From: "Pedro M. Ruiz" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [Mip6] ACM MobiCom 2007 paper registration deadline is Feb 23 11:59 PM PST X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Apologies if you receive multiple copies of this message. This is a reminder for authors, that the deadline for registering the title and abstract of the paper in the submission system is February 23, 2007 at 11:59PM PST CALL FOR PAPERS MobiCom 2007 The Thirteenth Annual International Conference on Mobile Computing and Networking September 9-14, 2007 Montreal, QC, Canada http://www.sigmobile.org/mobicom/2007/ Sponsored by ACM SIGMOBILE ACM MobiCom is the premier international conference dedicated to addressing the challenges in the areas of mobile computing and wireless and mobile networking. It has served as an exciting international forum since 1995, addressing networks, systems, algorithms, and applications that support the symbiosis of mobile computers and wireless networks. MobiCom is a highly selective conference focusing on all issues in mobile computing and wireless and mobile networking at the link layer and above. New this year, Mobicom will be jointly held with ACM Mobihoc. The two conferences will run in parallel, and will have many joint plenary sessions (such as the keynote, panels, and welcoming reception). Authors are invited to submit full papers, challenges papers, student posters, and research demos and exhibits, presenting new research related to the theory or practice of mobile computing and/or wireless and mobile networking. All submissions must describe original research, not published or currently under review for another conference or journal. Areas of interest include, but are not limited to: * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, limited power and/or intermittent connectivity * Applications and services for mobile users * Cyber-physical computing and networking * Delay/disruption tolerant networks * Fundamental understanding of mobile computing and wireless networking * Implementations and experimental testbeds for mobile/wireless networks * Integration and interworking of wired and wireless networks * Modeling, measurement and simulation of mobile networks * Mobile ad hoc and sensor networks * Operating system and middleware support for mobile computing and networking * Performance evaluation of mobile and wireless networks and systems * Protocols exploiting dynamic spectrum, UWB, MIMO, directional antennas * Resource management and quality-of-service for real-time traffic support * Security, privacy, and fault-tolerance of mobile/wireless systems * Wireless access technologies (e.g., mesh networks, personal area networks) Submission Instructions Detailed instructions on how and where to submit your paper can be found at http://www.sigmobile.org/mobicom/2007/cfp.html Panel proposals must be submitted by February 23 to either of the panel co-chairs: Martha Steenstrup (steenie@rcn.com) Ioanis Nikolaidis (yannis@cs.ualberta.ca) Important Dates Abstracts submission due: February 23, 2007 Panel proposals submission due: February 23, 2007 Paper submissions due: March 2, 2007 Notification of acceptance: June 4, 2007 Camera-ready version due: June 29, 2007 General Chair: Evangelos Kranakis, kranakis@scs.carleton.ca Technical Co-Chairs: Jennifer C. Hou, jhou@cs.uiuc.edu Ram Ramanathan, ramanath@bbn.com TPC Vice-Chair: Srikanth Krishnamurthy UC Riverside krish@cs.ucr.edu FOR MORE INFORMATION: Please contact the General Chair or Program Co-Chairs for more information. For information on ACM SIGMOBILE and the MobiCom series of conferences, see http://www.sigmobile.org/ or contact mobicom_info@acm.org. -- --------------------------------------------------------------------- Pedro M. Ruiz, Ph.D. E-mail: pedrom@dif.um.es Fac. Informatica, Univ. of Murcia Phone: +34968364335 Campus de Espinardo s/n Fax: +34968364151 E-30100, Espinardo, Murcia www: ants.dif.um.es/~pedrom/ SPAIN --------------------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 23 06:04:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKYD7-0005I9-VN; Fri, 23 Feb 2007 06:03:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKYD6-0005Gi-WF for mip6@ietf.org; Fri, 23 Feb 2007 06:03:33 -0500 Received: from cluster-e.mailcontrol.com ([217.79.216.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKYD5-0007KE-HP for mip6@ietf.org; Fri, 23 Feb 2007 06:03:32 -0500 Received: from rly08e.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly08e.srv.mailcontrol.com (MailControl) with ESMTP id l1NB32qE026744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Feb 2007 11:03:23 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly08e.srv.mailcontrol.com (MailControl) id l1NB2nkL026082 for mip6@ietf.org; Fri, 23 Feb 2007 11:02:49 GMT Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly08e-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l1NB2fhh025752; Fri, 23 Feb 2007 11:02:49 +0000 (GMT) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 33f9_6a1cce3a_c32a_11db_9584_0030482aac25; Fri, 23 Feb 2007 11:41:27 +0100 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007022312023425-688999 ; Fri, 23 Feb 2007 12:02:34 +0100 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: -0.159,BAYES_00: -1.665,TOTAL_SCORE: -1.824 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Fri, 23 Feb 2007 12:07:27 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 In-Reply-To: <0JDR0049I3JT7Y@ms5.samsung.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Thread-Index: AcdUwMUyhF+tuBaFTgu1pTm7wLnJ/QCci1Hg References: <0JDR0049I3JT7Y@ms5.samsung.com> To: "Heejin Jang" , "Chowdhury, Kuntal" Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F012780BD@lan-ex-01.panasonic.de> Date: Fri, 23 Feb 2007 11:59:41 +0100 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-07-06-85 (www.mailcontrol.com) on 10.69.1.118 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.2 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Kuntal, Heejin,=20 =20 I have another comments wrt draft-ietf-mip6-bootstrapping-integrated-02 and draft-ietf-mip6-hiopt-02.txt: it seems service-based HA address assignment is currently not supported. What I mean is, for instance, that in case the MN wants to use DS-MIPv6 HA service, the network is able to allocate a different HA to the MN than in case the MN wants to use MIPv6 (RFC3775) HA service.=20 I heard at least one operator requesting such feature (and note that this is in principle possible with the HA discovery/assignment mechanisms defined in the split scenario bootstrapping draft). A simple way to support this in the integrated scenario would be to add something like a "type of requested HA service" field in the Home Network Identifier Option of the DHCP information request sent by the MN. The new field would encode the type of service, e.g., 0=3DMIPv6, = 1=3DDS-MIPv6, 2=3DNEMO,...). Similarly, the Home Network Information Sub-option could include a "type of HA service" field to inform the MN about the type of service supported by the HA offered in this option. However, since the AAAH wouldn't know the HA service requested by the MN, AAAH would need to send at least one HA address per supported service to the NAS. =20 What do you think? =20 Cheers, =20 Kilian Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 23 09:52:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKbeH-0000fZ-LD; Fri, 23 Feb 2007 09:43:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKbeD-0000a8-U0 for mip6@ietf.org; Fri, 23 Feb 2007 09:43:45 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKbbR-0004cj-6m for mip6@ietf.org; Fri, 23 Feb 2007 09:40:54 -0500 Received: by ug-out-1314.google.com with SMTP id 72so337912ugd for ; Fri, 23 Feb 2007 06:40:52 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MO7vp0oLui2sVbD1JcJQkbCnK2r1EQTVrFWkaaTIsNNnX9NZK7Oge7k7LCvtLdV7deHMkfpCO+86DGAaMg572DzJZOWzwNwPAueSk6pkoXqJLmUv7wm4so3US1kjo79h5gianygSVBbEP2zAXZfM+lXM1L1U538RhNbl5t2ahVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Zp2y5GT8gZxMdJ/GCdEkQ5/OzK1t/ZzTQ2L3ulC4JkLzLqSP4y5GjJpxa9lEGDSD2lOhZmXMPeXM5JrUUy+aS5F2mx73hAaeQXhQwiKZ4svYuS2gRAu/6z5q0dC9Vfh7vXL35TmcnG29iWO4xm10pLh1snmcT9JrbaxEYFfOa/k= Received: by 10.67.19.13 with SMTP id w13mr2276429ugi.1172241649287; Fri, 23 Feb 2007 06:40:49 -0800 (PST) Received: by 10.66.238.6 with HTTP; Fri, 23 Feb 2007 06:40:49 -0800 (PST) Message-ID: Date: Fri, 23 Feb 2007 15:40:49 +0100 From: "Gerardo Giaretta" To: "Jari Arkko" Subject: Re: [Mip6] AD review of draft-ietf-mip6-bootstrapping-split In-Reply-To: <459A5A6C.5070602@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <459A5A6C.5070602@piuha.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 819069d28e3cfe534e22b502261ce83f Cc: Mobile IPv6 Mailing List , James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Jari, please see my comments below. Sorry for the late reply. On 1/2/07, Jari Arkko wrote: > > Hi all, > > I have reviewed this specification. Overall, I like > the basic approach and this will be very useful. > The document is generally in good shape. > > However, there are a few technical issues > that need to be resolved before we can > move forward. In particular, the authorization > steps need to be specified in greater detail, > and I also had question marks about the > particular approach to anycast. > > Also, I have asked the DNS directorate > to review the DNS-relevant parts. > > Please find the detailed comments below: > > Technical: > > > This > > implies that the mobility service is bootstrapped independently > > from the authentication protocol for network access used (e.g. > > PANA, EAP). > Perhaps you should allow for the possibility > that there is no access authorization. Suggested > edit: "... from the security mechanisms used for > network access (e.g., EAP or even open access) Actually the open access was one of the main motivations for this architecture therefore I'll add the text you suggest. > > Additionally, the ability to provide a mobile node with a > > localized home agent (e.g. on the visited link) can help to > > optimize handover signaling and improve routing efficiency in bi- > > directional tunneling mode. There are a variety of ways this can > > be achieved in an interoperable way. One way is to provision the > > mobile node with an FQDN for a local home agent when it configures > > for the local link. Another way is to specify an interoperable > > naming convention for constructing home agent FQDNs based on > > location. For example, an operator might assign the FQDN > > "ha.locationA.operator.com" to the Home Agent located in "location > > A" and the FQDN "ha.locationB.operator.com" to the Home Agent > > located in "location B". If the Mobile Node wants to use a Home > > Agent located in "location A", it will set the QNAME to > > "ha.locationA.operator.com" in the DNS request. The exact way in > > which localized Home Agents are configured is out of scope for > > this draft. > This part is rather handwavy. I could not implement anything > interoperable based on it. > > I realize that we debated this in 2005, based on my earlier > review of the same document. From the mailing list discussion > that I went through, it seemed that there was some support > in the WG for keeping the local assignments out of scope. > Yes, and this is what is stated in last sentence of the paragraph; the naming convention was just to give an example or a hint of how we may do that. > Here's a suggested rewrite: > > Note that the configuration of a fixed home agent FQDN does > allow dynamic assignment of a localized home agent. Such > dynamic assignment would be useful, however, for instance > from the point of view of improving routing efficiency in bidirectional > tunneling mode. Enhancements or conventions for dynamic > assignment are possible, but are outside the scope of this > specification. > I guess your text proposal is "Note that the configuration of a fixed home agent FQDN does not allow dynamic assignment of a localized home agent..." If so, I'm ok with this text. As mentioned earlier, the naming convention was just an example provided by Vijay. Vijay: do you agree to replace the paragraph with the text provided by Jari? > > If an anycast address is returned in response to DNS resolution of > > an FQDN, the IKEv2 transaction between the Mobile Node and Home > > Agent is slightly modified. The Mobile Node sends the IKE_SA_INIT > > request to the anycast address. The node which has the anycast > > address assigned to one of its network interfaces selects a Home > > Agent address from the set of Home Agents managed by the node, and > > forwards the IKE_SA_INIT. If the set of Home Agents is empnty, the > > node simply drops the packet. The Home Agent answers using its own > > address, and includes an "under attack" cookie, in accordance with > > RFC 4306 [7]. The Mobile Node notes the Home Agent address and > > resends the IKE_SA_INIT message to the Home Agent, along with the > > cookie. > There are several issues in this. First, I think I understand > at least one reason why the cookie exchange makes sense, > but is that something that has to be mandated? What if the > home network simply figures out what HA should be used and > responds in the usual IKEv2 way? > > Secondly, responding with the home agent's own address > is in violation of a MUST in RFC 4306, Section 2.11. I talked > to one of the IKEv2 designers about this and his advice > was that the MUST may have been a mistake. Or at least it > should be limited to unicast addresses, and leave the behaviour > for anycast addresses for future documents. In any case, > this deviation from RFC 4306 should be highlighted and > justified in the document. > > The third issue is the above notion of a node that owns an > anycast address. How does this relate to the usual arrangement > where the routing system handles the delivery of the anycast > packets to the "closest" place that advertises that address? > When you say "forwards", do you mean that the packet is > forwarded unmodified, or that the particular home agent's > address replaces the destination address? Do you allow > each home agent to configure the same anycast address? > > Four: What happens when the IKE SA dies or is > deleted, but a binding for the mobile node remains > in the selected home agent? Will the mobile node > re-establish the IKE SA using the anycast address, > or the address of the selected home agent? > > Finally, I wonder how useful the anycast part of > this spec is given that DNS can already provide > a set of addresses. > I will leave other authors (James, Francis and Kilian in particular) to handle the specific issues on anycast. One comment from my side, though: this mechanism was included in the document in order to respond to a request from several WG members to define a HA assignment mechanism in split scenario. The DNS mechanism provides just a discovery mechanism and based on this the network provider is not able to assign a specific HA to a specific UE. The mechanism based on anycast and IKEv2 should fill this gap and provide means to have HA assignment also in the split scenario, as we have HA assignment in the integrated scenario based on DHCP. > > o MN identity - the identity of the Mobile Node to be used by the > > Home Agent to send a Dynamic DNS update. It is a variable > > length field. > What format is this in? Please specify. > It's a FQDN format. I'll fix it. > > The Home Agent MUST set up authorization by linking the home > > address to the identity of the IPsec SAs used to authenticate the > > Binding Update message. The linking MUST be done either during the > > IKE_AUTH phase or CREATE_CHILD_SA phase when the IPsec SAs are > > constructed. > > > > If the address is auto-configured, RFC 3775 requires the Home > > Agent to proxy-defend the address on the home link after the > > Mobile Node performs the initial Binding Update. Since it is not > > currently possible to securely proxy CGAs using SEND, attacks on > > address resolution for Neighbor Discovery listed in RFC 3756 are > > possible on dynamically assigned home addresses that are proxied > > by the Home Agent. > I do not know what to implement based on the above > description. Its clear that a link must be established between > the IKE identity and the requested home address. But how? > What should be done with the information about the link? > Isn't this described also in MIP6-IKEv2 draft? VIjay? > By the way, why does the text say "identity of the IPsec SAs"? > I believe you should talk about the identity used in the IKEv2 > authentication process. > Yes, that's right. The identity is the IKEv2 identity. > There are other reasons beyond lack of SEND proxy mode > that make the use of DAD for authorization bad. Its not > reliable, not all nodes may be on or reachable at all times, > etc. > > Here's a possible rewrite of the text. Let me know if this > is what you intended to do: > > "The home agent MUST authorize each home address > allocation and use. This authorization is based on linking > the mobile node identity used in the IKEv2 authentication > process and the home address. Home agents MUST support > at least the following two modes of authorization: > > o Configured home address(es) for each mobile node. > In this mode, the home agent or infrastructure nodes > behind it know what addresses a specific mobile node > is authorized to use. The mobile node is allowed to > request these addresses, or if the mobile node requests > any home address, these addresses are returned to it. > > o First-come-first-served (FCFS). In this mode, the home agent > maintains a pool of "used" addresses, and allows mobile > nodes to request any address, as long as it is not used by > another mobile node. > > Addresses MUST be marked as used for at least as long as > the binding exists, and are associated with the identity > of the mobile node that made the allocation. > > In addition, the home agent MUST ensure that the requested > address is not the authorized address of any other mobile > node, if both FCFS and configured modes use the same > address space." > Text is fine with me. The original idea is that we need to add an authorization step in order to check if the MN can or cannot auto-configure the Home Address. I think your text resolves this issue, giving also more details. > > Mobile IPv6 bootstrapping recommends the Home Agent to update the > > Mobile Node's FQDN with a dynamically assigned home address rather > > than have the Mobile Node itself do it (see Section 6 above). This > > choice was motivated by a concern for preventing redirection-based > > flooding attacks (see draft-ietf-mip6-ro-sec [21] for more > > information about redirection-based flooding attacks and the role > > preventing them played in the design of Mobile IPv6 route > > optimization security). Exactly as for route optimization, it is > > possible for a node that is the legitimate owner of a DNS FQDN - > > in the sense that it has a security association with the DNS > > server allowing it to perform dynamic DNS update of its FQDN - to > > bind its FQDN to the address of a victim, then redirect large > > volumes of traffic at the victim. The attack may be propagated > > without the owner's knowledge, for example, if the node is > > compromised by malware, or it may be intentional if the node > > itself is the attacker. > > > > While it is possible to prevent redirection attacks through > > ingress filtering on access routers, ISPs have little or no > > incentive to deploy ingress filtering. In some cases, if an attack > > could result in substantial financial gain, it is even possible > > that a corrupt ISP may have an incentive not to deploy ingress > > filters such as has been the case for spam. Consequently, the > > security for dynamic Mobile Node FQDN update has been assigned to > > the Home Agent, where active network administration and vigilant > > defense measures are more likely to (but are not assured of) > > mitigating problems, and the owner of the Mobile Node is more > > likely to detect a problem if it occurs. > There are good reasons why using a proxy to do the > DynDNS update from your behalf makes sense. But I > don't think the above is such a good reason. The > route optimization redirect problem assumes that > traffic from an ongoing session is suddenly moved > to a new address. If you just change the DNS information, > ongoing sessions are not affected, and all new sessions > go through the usual TCP slow start etc. > > (A good reason why it makes sense to use a proxy > is that then you just need a secret between the > DNS server and the home agent, not between the > DNS server and every mobile node.) > I'm fine with removing that text. However, I would like to hear thoughts from James, since he has been very active in that part of the draft. > > Notice that if certificates are used in > > IKEv2, the authorization information about the FQDN for DNS update > > MUST be present in the certificate provided by the Mobile Node. > Yes -- but can you write this in more explicit > form? For instance, I assume that you meant > the FQDN must appear in some specific field > in the certificate. > Yes, this is certainly one option. Again I would leave to James the proposed text on this. > > Regardless of whether the AAA server or Home Agent performs DNS > > update, the authorization of the Mobile Node to update a FQDN MUST > > be checked prior to the performance of the update. It is an > > implementation issue as to how authorization is determined. > > However, in order to allow this authorization step, the Mobile > > Node MUST use a FQDN as the IDi in IKE_AUTH step of the IKEv2 > > exchange. The FQDN MUST be the same that will be provided by the > > Mobile Node in the DNS Update Option. This allows the Home Agent > > to get authorization information about the Mobile Node's FQDN via > > the AAA back end communication performed during IKEv2 exchange. > > The outcome of this step will give the Home Agent the necessary > > information to authorize the DNS update request of the Mobile > > Node. See draft-ietf-mip6-aaa-ha-goals [14] for details about the > > communication between the AAA server and the Home Agent needed to > > perform the authorization. Notice that if certificates are used in > > IKEv2, the authorization information about the FQDN for DNS update > > MUST be present in the certificate provided by the Mobile Node. > This is another case where I believe the important > authorization step is underspecified, and needs to be > specified in more detail to make sure people actually > can implement it. And that they will get it right. > ok, are you suggesting to have the same text here and above about FQDN in certificates? > Also, I am unsure if the requirement to use the > FQDN in the IKEv2 exchange is helpful. If an > FQDN X is used in the IKEv2 exchange, but the > actual authentication employs IKEv2/EAP with > a method that does its own identity exchange > with FQDN Y, what happens? Also, you are > preventing privacy NAI usage in the IKEv2 > exchange. And if you use a FQDN (no "@", i.e., > not a NAI) in the IKEv2 identity, how will the > gateway be able to route the AAA request? > > One alternative approach would be to require > the following: > > - If certificates are used, then the FQDN must > appear there (but see my previous comment). > > - Otherwise, the mobile node's identity is > taken as asserted in the EAP method > where available and otherwise from the > IKEv2 exchange. > > - Home agent must be able to match > mobile node identities to allowed FQDNs. > For certs, step 1 above suffices. In other > cases its basically configured information. > > - The division of work between the home > agent and AAA is outside the scope of > this document. Note that there may be > non-trivial issues, such as when the > actual identity is end-to-end hidden > between the mobile node and the AAA > server. > In case the FQDN is known by the AAA server via EAP, I see two possible approaches: - the AAA server provides the HA with the MN's FQDN received via EAP (e.g. during Diameter EAP application) and the HA stores the "authorized" FQDN. This would require a change in current Diameter application - the HA performs a AAA exchange when it receives a BU with a DNS Update mobility option; this AAA exchange should be part of the Mobile IPv6 Diameter application (work in progress in DIME WG) and should be used by the HA to get the authorized FQDN from the AAA server in order to update the DNS The draft should leave the actual definition of either mechanism as out of scope (as you suggested), but we should put a reference to the solution. As a summary, in this draft, I think it is enough to clarify the need of the FQDN in the cert for the certificates scenario. For the AAA/EAP scenario, we should provide a reference for the HA-AAA coordination needed in case EAP is used, but we should at least include some text on one of the two alternatives described above. What do you think? > Editorial: > > > mobility service.. > s/.././ > > > MSP. Figure 3 illustrates. > s/illustrates/illustrates this/ > > > forwards the IKE_SA_INIT. If the set of Home Agents is empnty, the > > Typo > > > o Home Prefix (16 octets) - The prefix of the home link through > > which the Mobile Node must auto-configure its Home Address. > s/must/may/ -- there can be multiple such prefixes, so the mobile > node cannot be mandated to use _this_ prefix. Alternatively, > you can explain that the use of a particular prefix or auto-configuration > is optional, but that if autoconfiguration is used, then one of the > provided prefixes must be used. > > Security considerations for discovering HA using DHCP are covered > > in draft-jang-dhc-haopt-01 [15]. > > [15] Koodli, R., Devarapalli, V., Perkins, C., Flinck, H., > > "Solutions for IP Address Location Privacy in the presence > > of IP Mobility", Internet-Draft, draft-koodli-mip6-location- > > privacy-solutions-00, February 2005. > I suppose referring to draft-jang is no longer necessary, if > the contents are being moved to a MIP6 WG item draft. > > Also, the draft name and reference number do not match. > > Thanks, I will fix these editorial issues in next version. Regards, --Gerardo > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 23 10:11:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKc4A-0000Gy-Re; Fri, 23 Feb 2007 10:10:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKc49-0000Gf-DJ for mip6@ietf.org; Fri, 23 Feb 2007 10:10:33 -0500 Received: from tao.fdupont.fr ([82.236.136.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKc1b-0002Z7-SO for mip6@ietf.org; Fri, 23 Feb 2007 10:08:00 -0500 Received: from tao.fdupont.fr (localhost [127.0.0.1]) by tao.fdupont.fr (8.13.5/8.13.5) with ESMTP id l1NF7RfD007883 for ; Fri, 23 Feb 2007 16:07:27 +0100 (CET) Received: from tao.fdupont.fr (dupont@localhost) by tao.fdupont.fr (8.13.5/8.13.5/Submit) with ESMTP id l1NF7QxC007880 for ; Fri, 23 Feb 2007 16:07:27 +0100 (CET) Message-Id: <200702231507.l1NF7QxC007880@tao.fdupont.fr> From: Francis Dupont To: mip6@ietf.org Date: Fri, 23 Feb 2007 16:07:26 +0100 X-Spam-Score: 1.7 (+) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Mip6] caps or lowercase? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org For draft-ietf-mip6-cn-ipsec I-D we have the choice between to put "binding update" or "Binding Update". The first is the rule in English (i.e., not in German) for common names, the second makes the promote the term as it was done in RFC 3775. What is your advice? Regards Francis.Dupont@fdupont.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 23 10:51:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKcgt-0000em-PA; Fri, 23 Feb 2007 10:50:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKcgq-0000du-VK; Fri, 23 Feb 2007 10:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HKcgq-0006Ia-Li; Fri, 23 Feb 2007 10:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 96D331766F; Fri, 23 Feb 2007 15:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HKcgM-00026P-C8; Fri, 23 Feb 2007 10:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 23 Feb 2007 10:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-vsm-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 Vendor Specific Option Author(s) : V. Devarapalli, et al. Filename : draft-ietf-mip6-vsm-01.txt Pages : 7 Date : 2007-2-23 There is a need for vendor specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes. This document defines a new vendor specific mobility option. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-vsm-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-vsm-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-vsm-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-23095846.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-vsm-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-vsm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-23095846.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Fri Feb 23 11:52:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKde5-0001NZ-UW; Fri, 23 Feb 2007 11:51:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKde4-0001NO-4O for mip6@ietf.org; Fri, 23 Feb 2007 11:51:44 -0500 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 1HKde1-0000ui-KN for mip6@ietf.org; Fri, 23 Feb 2007 11:51:44 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1NGnLUs022507 for ; Fri, 23 Feb 2007 18:49:31 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 18:51:32 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 10:50:52 -0600 Received: from 172.19.244.124 ([172.19.244.124]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 23 Feb 2007 16:50:51 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 23 Feb 2007 10:50:53 -0600 From: Basavaraj Patil To: Mobile IPv6 Mailing List Message-ID: Thread-Topic: WG LC: draft-ietf-mip6-hiopt-02.txt Thread-Index: AcdXaseWBka+AMNeEduAQAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Feb 2007 16:50:52.0283 (UTC) FILETIME=[C728ACB0:01C7576A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Mip6] WG LC: draft-ietf-mip6-hiopt-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, This is a working group last call for the I-D: DHCP Option for Home Information Discovery in MIPv6, draft-ietf-mip6-hiopt-02.txt http://ietf.org/internet-drafts/draft-ietf-mip6-hiopt-02.txt The last call will expire on March, 16 2007. Please review and send your comments to the list. -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 23 14:19:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKfvZ-00019x-3N; Fri, 23 Feb 2007 14:17:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKfvY-00019s-HA for mip6@ietf.org; Fri, 23 Feb 2007 14:17:56 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKfvJ-0005mR-Uh for mip6@ietf.org; Fri, 23 Feb 2007 14:17:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 2F442900B6 for ; Fri, 23 Feb 2007 14:17:38 -0500 (EST) 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 32216-04 for ; Fri, 23 Feb 2007 14:17:33 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 23 Feb 2007 14:17:33 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 14:17:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] draft-ietf-mip6-radius-01.txt Date: Fri, 23 Feb 2007 14:17:32 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD973@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] draft-ietf-mip6-radius-01.txt Thread-Index: AcdUE40hR99oozgSQV27ZSHEkXVs7wDa4Bdw From: "Chowdhury, Kuntal" To: "Julien Bournelle" , X-OriginalArrivalTime: 23 Feb 2007 19:17:33.0149 (UTC) FILETIME=[44E240D0:01C7577F] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Avi Lior X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Julien, Forwarding Avi's reply to you.... --------------------------------- Julien, Thanx for the review. Regarding your question: > I have one general question: >=20 > In the split scenario, how does the RADIUS server know that it is=20 > performing AAA for mip6 service and not for network access ? >=20 > (FYI, we encounter this problem in the DiME WG and we'll solve this by > using a different Application ID.) In RADIUS we don't have an application id therefore the AAA server determines the context of the packet it receives by examining the attributes. =20 For example: The presence of an attribute in an Access-Request packet that only an HA or even more specifically a MIPv6 HA would provide in this case: MIP6-HA Attribute. But this attribute is not a required attribute. NAS-Port-Type: can be set to a value such as HA-IPv6. This is the most reliable attribute but we need IANA to assign the attribute. The AAA may also know the context by using the NAS-IP and/or the NAS-Ids, that is, it will know that a particular NAS-IP is an HA vs a NAS. This obivously doesn't scale to large deployments. I think we need to update the draft to cover this discussion and request IANA for a NAS-Port-Type. --------------------------------- > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@gmail.com] > Sent: Monday, February 19, 2007 4:46 AM > To: mip6@ietf.org > Subject: [Mip6] draft-ietf-mip6-radius-01.txt >=20 > Hi, >=20 > I quickly read the document called: draft-ietf-mip6-radius-01.txt >=20 > I have one general question: >=20 > In the split scenario, how does the RADIUS server know that it is > performing AAA for mip6 service and not for network access ? >=20 > (FYI, we encounter this problem in the DiME WG and we'll solve this > by using a different Application ID.) >=20 > Some editorials comments: >=20 > section 3.2: >=20 > "Since scenario (1) is the more generic..." >=20 > I think you wanted to say "scenario (2) >=20 > section 4.2 >=20 > s/HOA/HA >=20 > section 5 >=20 > I think you can add Access-Request message since the MIP6-DNS-MO may be > sent in this message (if I understood well). >=20 > My 2 cents, >=20 > Julien >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 23 14:24:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKg2K-0003kG-SU; Fri, 23 Feb 2007 14:24:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKg2J-0003k5-GX for mip6@ietf.org; Fri, 23 Feb 2007 14:24:55 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKg2B-0008TN-By for mip6@ietf.org; Fri, 23 Feb 2007 14:24:55 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 11:24:44 -0800 Message-ID: <45DF3F77.7070203@azairenet.com> Date: Fri, 23 Feb 2007 11:24:39 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Gerardo Giaretta , Jari Arkko Subject: Re: [Mip6] AD review of draft-ietf-mip6-bootstrapping-split References: <459A5A6C.5070602@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2007 19:24:44.0164 (UTC) FILETIME=[45C9EC40:01C75780] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: Mobile IPv6 Mailing List , James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org A few comments inline. Gerardo Giaretta wrote: >> > Additionally, the ability to provide a mobile node with a >> > localized home agent (e.g. on the visited link) can help to >> > optimize handover signaling and improve routing efficiency in bi- >> > directional tunneling mode. There are a variety of ways this can >> > be achieved in an interoperable way. One way is to provision the >> > mobile node with an FQDN for a local home agent when it configures >> > for the local link. Another way is to specify an interoperable >> > naming convention for constructing home agent FQDNs based on >> > location. For example, an operator might assign the FQDN >> > "ha.locationA.operator.com" to the Home Agent located in "location >> > A" and the FQDN "ha.locationB.operator.com" to the Home Agent >> > located in "location B". If the Mobile Node wants to use a Home >> > Agent located in "location A", it will set the QNAME to >> > "ha.locationA.operator.com" in the DNS request. The exact way in >> > which localized Home Agents are configured is out of scope for >> > this draft. >> This part is rather handwavy. I could not implement anything >> interoperable based on it. >> >> I realize that we debated this in 2005, based on my earlier >> review of the same document. From the mailing list discussion >> that I went through, it seemed that there was some support >> in the WG for keeping the local assignments out of scope. >> > > Yes, and this is what is stated in last sentence of the paragraph; the > naming convention was just to give an example or a hint of how we may > do that. > >> Here's a suggested rewrite: >> >> Note that the configuration of a fixed home agent FQDN does >> allow dynamic assignment of a localized home agent. Such >> dynamic assignment would be useful, however, for instance >> from the point of view of improving routing efficiency in bidirectional >> tunneling mode. Enhancements or conventions for dynamic >> assignment are possible, but are outside the scope of this >> specification. >> > > I guess your text proposal is "Note that the configuration of a fixed > home agent FQDN does not allow dynamic assignment of a localized home > agent..." > > If so, I'm ok with this text. As mentioned earlier, the naming > convention was just an example provided by Vijay. Vijay: do you agree > to replace the paragraph with the text provided by Jari? There was an explicit requirement to support local HA assignment using DNS. IMO, local HA assignment is required for any HA discovery/assignment mechanism. So I would like to keep the text instead of saying it is out of scope. The example is trying to describe how a particular operator may "name" the home agents, what entries appear in the DNS servers, and what FQDNs are provisioned in the mobile node. This particular paragraph underwent multiple changes. I can re-write the text to better explain how it can be done or to address any specific concern. >> > If an anycast address is returned in response to DNS resolution of >> > an FQDN, the IKEv2 transaction between the Mobile Node and Home >> > Agent is slightly modified. The Mobile Node sends the IKE_SA_INIT >> > request to the anycast address. The node which has the anycast >> > address assigned to one of its network interfaces selects a Home >> > Agent address from the set of Home Agents managed by the node, and >> > forwards the IKE_SA_INIT. If the set of Home Agents is empnty, the >> > node simply drops the packet. The Home Agent answers using its own >> > address, and includes an "under attack" cookie, in accordance with >> > RFC 4306 [7]. The Mobile Node notes the Home Agent address and >> > resends the IKE_SA_INIT message to the Home Agent, along with the >> > cookie. >> There are several issues in this. First, I think I understand >> at least one reason why the cookie exchange makes sense, >> but is that something that has to be mandated? What if the >> home network simply figures out what HA should be used and >> responds in the usual IKEv2 way? I don't think the IKE SA can be setup if the destination address on the IKE_SA_INIT request is an anycast address and the source address on the IKE_SA_INIT response is a unicast address of a particular responder. You need the cookie exchange to tell mobile node to initiate IKE_SA_INIT exchange again to setup the IKE SA. The IKE SA is setup only after the second exchange. >> Secondly, responding with the home agent's own address >> is in violation of a MUST in RFC 4306, Section 2.11. I talked >> to one of the IKEv2 designers about this and his advice >> was that the MUST may have been a mistake. Or at least it >> should be limited to unicast addresses, and leave the behaviour >> for anycast addresses for future documents. In any case, >> this deviation from RFC 4306 should be highlighted and >> justified in the document. Sure. It is obvious that if the packet was sent to an anycast address, the response comes back from an unicast address. Any host that sends an IP packet to an anycast address should except this irrespective of what protocol is used. We can mention that the "MUST" in section 2.11 is violated in this case. >> The third issue is the above notion of a node that owns an >> anycast address. How does this relate to the usual arrangement >> where the routing system handles the delivery of the anycast >> packets to the "closest" place that advertises that address? >> When you say "forwards", do you mean that the packet is >> forwarded unmodified, or that the particular home agent's >> address replaces the destination address? Do you allow >> each home agent to configure the same anycast address? When the home agents are part of the anycast group, they all configure the same anycast address on one of their interfaces. The current text is confusing since it says that one node is configured with the anycast address and it decides which home agent the request should be forwarded to. This needs to be fixed to say that one of the home agents gets the request and based on the load conditions forwards the request to another home agent that is part of the anycast group. By "forwarding", we meant the packet can be sent to another home agent unmodified if the home agents are all on the same link. >> Four: What happens when the IKE SA dies or is >> deleted, but a binding for the mobile node remains >> in the selected home agent? Will the mobile node >> re-establish the IKE SA using the anycast address, >> or the address of the selected home agent? If the mobile node has a binding with a particular home agent it must send the IKE_SA_INIT request to the same home agent and not use the anycast address. I guess this needs to be said explicitly. >> Finally, I wonder how useful the anycast part of >> this spec is given that DNS can already provide >> a set of addresses. This mechanism was added because some folks wanted a mechanism that can return home agents based on the load on the home agents instead of just returning a set of addresses. >> > The Home Agent MUST set up authorization by linking the home >> > address to the identity of the IPsec SAs used to authenticate the >> > Binding Update message. The linking MUST be done either during the >> > IKE_AUTH phase or CREATE_CHILD_SA phase when the IPsec SAs are >> > constructed. >> > >> > If the address is auto-configured, RFC 3775 requires the Home >> > Agent to proxy-defend the address on the home link after the >> > Mobile Node performs the initial Binding Update. Since it is not >> > currently possible to securely proxy CGAs using SEND, attacks on >> > address resolution for Neighbor Discovery listed in RFC 3756 are >> > possible on dynamically assigned home addresses that are proxied >> > by the Home Agent. >> I do not know what to implement based on the above >> description. Its clear that a link must be established between >> the IKE identity and the requested home address. But how? >> What should be done with the information about the link? >> > > Isn't this described also in MIP6-IKEv2 draft? VIjay? draft-ietf-mip6-ikev2-ipsec only deals with home address assignment. The HA always gives out an 128 bit home address to the mobile node. Jari's text below looks good to me. >> "The home agent MUST authorize each home address >> allocation and use. This authorization is based on linking >> the mobile node identity used in the IKEv2 authentication >> process and the home address. Home agents MUST support >> at least the following two modes of authorization: >> >> o Configured home address(es) for each mobile node. >> In this mode, the home agent or infrastructure nodes >> behind it know what addresses a specific mobile node >> is authorized to use. The mobile node is allowed to >> request these addresses, or if the mobile node requests >> any home address, these addresses are returned to it. >> >> o First-come-first-served (FCFS). In this mode, the home agent >> maintains a pool of "used" addresses, and allows mobile >> nodes to request any address, as long as it is not used by >> another mobile node. >> >> Addresses MUST be marked as used for at least as long as >> the binding exists, and are associated with the identity >> of the mobile node that made the allocation. >> >> In addition, the home agent MUST ensure that the requested >> address is not the authorized address of any other mobile >> node, if both FCFS and configured modes use the same >> address space." >> > > Text is fine with me. The original idea is that we need to add an > authorization step in order to check if the MN can or cannot > auto-configure the Home Address. I think your text resolves this > issue, giving also more details. > >> > Mobile IPv6 bootstrapping recommends the Home Agent to update the >> > Mobile Node's FQDN with a dynamically assigned home address rather >> > than have the Mobile Node itself do it (see Section 6 above). This >> > choice was motivated by a concern for preventing redirection-based >> > flooding attacks (see draft-ietf-mip6-ro-sec [21] for more >> > information about redirection-based flooding attacks and the role >> > preventing them played in the design of Mobile IPv6 route >> > optimization security). Exactly as for route optimization, it is >> > possible for a node that is the legitimate owner of a DNS FQDN - >> > in the sense that it has a security association with the DNS >> > server allowing it to perform dynamic DNS update of its FQDN - to >> > bind its FQDN to the address of a victim, then redirect large >> > volumes of traffic at the victim. The attack may be propagated >> > without the owner's knowledge, for example, if the node is >> > compromised by malware, or it may be intentional if the node >> > itself is the attacker. >> > >> > While it is possible to prevent redirection attacks through >> > ingress filtering on access routers, ISPs have little or no >> > incentive to deploy ingress filtering. In some cases, if an attack >> > could result in substantial financial gain, it is even possible >> > that a corrupt ISP may have an incentive not to deploy ingress >> > filters such as has been the case for spam. Consequently, the >> > security for dynamic Mobile Node FQDN update has been assigned to >> > the Home Agent, where active network administration and vigilant >> > defense measures are more likely to (but are not assured of) >> > mitigating problems, and the owner of the Mobile Node is more >> > likely to detect a problem if it occurs. >> There are good reasons why using a proxy to do the >> DynDNS update from your behalf makes sense. But I >> don't think the above is such a good reason. The >> route optimization redirect problem assumes that >> traffic from an ongoing session is suddenly moved >> to a new address. If you just change the DNS information, >> ongoing sessions are not affected, and all new sessions >> go through the usual TCP slow start etc. >> >> (A good reason why it makes sense to use a proxy >> is that then you just need a secret between the >> DNS server and the home agent, not between the >> DNS server and every mobile node.) Agree. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 23 15:50:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhN9-00088U-DZ; Fri, 23 Feb 2007 15:50:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhMh-0006bh-S3; Fri, 23 Feb 2007 15:50:03 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKhMg-0006QM-F3; Fri, 23 Feb 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 68AEC3296C; Fri, 23 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HKhMg-0006zc-9p; Fri, 23 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 23 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-experimental-messages-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 Experimental Messages Author(s) : V. Devarapalli Filename : draft-ietf-mip6-experimental-messages-01.txt Pages : 7 Date : 2007-2-23 This document defines a new experimental Mobility header message and a mobility option that can be used for experimental extensions to the Mobile IPv6 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-experimental-messages-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-experimental-messages-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-experimental-messages-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-23100010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-experimental-messages-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-experimental-messages-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-23100010.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Sat Feb 24 10:20:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKyev-0007ck-AS; Sat, 24 Feb 2007 10:18:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKyeu-0007bx-0H for mip6@ietf.org; Sat, 24 Feb 2007 10:18:00 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKyet-000293-1B for mip6@ietf.org; Sat, 24 Feb 2007 10:17:59 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 312C9198775; Sat, 24 Feb 2007 17:17:58 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7D4AE1986AF; Sat, 24 Feb 2007 17:17:54 +0200 (EET) Message-ID: <45E00DD3.1010701@piuha.net> Date: Sat, 24 Feb 2007 12:05:07 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Mip6] AD review of draft-ietf-mip6-bootstrapping-split References: <459A5A6C.5070602@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 Cc: Mobile IPv6 Mailing List , James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Gerardo, >> > Additionally, the ability to provide a mobile node with a >> > localized home agent (e.g. on the visited link) can help to >> > optimize handover signaling and improve routing efficiency in bi- >> > directional tunneling mode. There are a variety of ways this can >> > be achieved in an interoperable way. One way is to provision the >> > mobile node with an FQDN for a local home agent when it configures >> > for the local link. Another way is to specify an interoperable >> > naming convention for constructing home agent FQDNs based on >> > location. For example, an operator might assign the FQDN >> > "ha.locationA.operator.com" to the Home Agent located in "location >> > A" and the FQDN "ha.locationB.operator.com" to the Home Agent >> > located in "location B". If the Mobile Node wants to use a Home >> > Agent located in "location A", it will set the QNAME to >> > "ha.locationA.operator.com" in the DNS request. The exact way in >> > which localized Home Agents are configured is out of scope for >> > this draft. >> This part is rather handwavy. I could not implement anything >> interoperable based on it. >> >> I realize that we debated this in 2005, based on my earlier >> review of the same document. From the mailing list discussion >> that I went through, it seemed that there was some support >> in the WG for keeping the local assignments out of scope. >> > > Yes, and this is what is stated in last sentence of the paragraph; the > naming convention was just to give an example or a hint of how we may > do that. I'm reading on... > >> Here's a suggested rewrite: >> >> Note that the configuration of a fixed home agent FQDN does >> allow dynamic assignment of a localized home agent. Such >> dynamic assignment would be useful, however, for instance >> from the point of view of improving routing efficiency in >> bidirectional >> tunneling mode. Enhancements or conventions for dynamic >> assignment are possible, but are outside the scope of this >> specification. >> > > I guess your text proposal is "Note that the configuration of a fixed > home agent FQDN does not allow dynamic assignment of a localized home > agent..." > Yes. > If so, I'm ok with this text. As mentioned earlier, the naming > convention was just an example provided by Vijay. Vijay: do you agree > to replace the paragraph with the text provided by Jari? > >> > If an anycast address is returned in response to DNS resolution of >> > an FQDN, the IKEv2 transaction between the Mobile Node and Home >> > Agent is slightly modified. The Mobile Node sends the IKE_SA_INIT >> > request to the anycast address. The node which has the anycast >> > address assigned to one of its network interfaces selects a Home >> > Agent address from the set of Home Agents managed by the node, and >> > forwards the IKE_SA_INIT. If the set of Home Agents is empnty, the >> > node simply drops the packet. The Home Agent answers using its own >> > address, and includes an "under attack" cookie, in accordance with >> > RFC 4306 [7]. The Mobile Node notes the Home Agent address and >> > resends the IKE_SA_INIT message to the Home Agent, along with the >> > cookie. >> There are several issues in this. First, I think I understand >> at least one reason why the cookie exchange makes sense, >> but is that something that has to be mandated? What if the >> home network simply figures out what HA should be used and >> responds in the usual IKEv2 way? >> >> Secondly, responding with the home agent's own address >> is in violation of a MUST in RFC 4306, Section 2.11. I talked >> to one of the IKEv2 designers about this and his advice >> was that the MUST may have been a mistake. Or at least it >> should be limited to unicast addresses, and leave the behaviour >> for anycast addresses for future documents. In any case, >> this deviation from RFC 4306 should be highlighted and >> justified in the document. >> >> The third issue is the above notion of a node that owns an >> anycast address. How does this relate to the usual arrangement >> where the routing system handles the delivery of the anycast >> packets to the "closest" place that advertises that address? >> When you say "forwards", do you mean that the packet is >> forwarded unmodified, or that the particular home agent's >> address replaces the destination address? Do you allow >> each home agent to configure the same anycast address? >> >> Four: What happens when the IKE SA dies or is >> deleted, but a binding for the mobile node remains >> in the selected home agent? Will the mobile node >> re-establish the IKE SA using the anycast address, >> or the address of the selected home agent? >> >> Finally, I wonder how useful the anycast part of >> this spec is given that DNS can already provide >> a set of addresses. >> > > I will leave other authors (James, Francis and Kilian in particular) > to handle the specific issues on anycast. One comment from my side, > though: this mechanism was included in the document in order to > respond to a request from several WG members to define a HA assignment > mechanism in split scenario. The DNS mechanism provides just a > discovery mechanism and based on this the network provider is not able > to assign a specific HA to a specific UE. The mechanism based on > anycast and IKEv2 should fill this gap and provide means to have HA > assignment also in the split scenario, as we have HA assignment in the > integrated scenario based on DHCP. I understand the need, but if we include this functionality the spec needs to be very clear about it. You could either work on the details or leave it out. > >> > o MN identity - the identity of the Mobile Node to be used by the >> > Home Agent to send a Dynamic DNS update. It is a variable >> > length field. >> What format is this in? Please specify. >> > > It's a FQDN format. I'll fix it. > Ok. >> > The Home Agent MUST set up authorization by linking the home >> > address to the identity of the IPsec SAs used to authenticate the >> > Binding Update message. The linking MUST be done either during the >> > IKE_AUTH phase or CREATE_CHILD_SA phase when the IPsec SAs are >> > constructed. >> > >> > If the address is auto-configured, RFC 3775 requires the Home >> > Agent to proxy-defend the address on the home link after the >> > Mobile Node performs the initial Binding Update. Since it is not >> > currently possible to securely proxy CGAs using SEND, attacks on >> > address resolution for Neighbor Discovery listed in RFC 3756 are >> > possible on dynamically assigned home addresses that are proxied >> > by the Home Agent. >> I do not know what to implement based on the above >> description. Its clear that a link must be established between >> the IKE identity and the requested home address. But how? >> What should be done with the information about the link? >> > > Isn't this described also in MIP6-IKEv2 draft? VIjay? > A reference would suffice, if it is described in the reference. >> By the way, why does the text say "identity of the IPsec SAs"? >> I believe you should talk about the identity used in the IKEv2 >> authentication process. >> > > Yes, that's right. The identity is the IKEv2 identity. Ok. > >> There are other reasons beyond lack of SEND proxy mode >> that make the use of DAD for authorization bad. Its not >> reliable, not all nodes may be on or reachable at all times, >> etc. >> >> Here's a possible rewrite of the text. Let me know if this >> is what you intended to do: >> >> "The home agent MUST authorize each home address >> allocation and use. This authorization is based on linking >> the mobile node identity used in the IKEv2 authentication >> process and the home address. Home agents MUST support >> at least the following two modes of authorization: >> >> o Configured home address(es) for each mobile node. >> In this mode, the home agent or infrastructure nodes >> behind it know what addresses a specific mobile node >> is authorized to use. The mobile node is allowed to >> request these addresses, or if the mobile node requests >> any home address, these addresses are returned to it. >> >> o First-come-first-served (FCFS). In this mode, the home agent >> maintains a pool of "used" addresses, and allows mobile >> nodes to request any address, as long as it is not used by >> another mobile node. >> >> Addresses MUST be marked as used for at least as long as >> the binding exists, and are associated with the identity >> of the mobile node that made the allocation. >> >> In addition, the home agent MUST ensure that the requested >> address is not the authorized address of any other mobile >> node, if both FCFS and configured modes use the same >> address space." >> > > Text is fine with me. The original idea is that we need to add an > authorization step in order to check if the MN can or cannot > auto-configure the Home Address. I think your text resolves this > issue, giving also more details. Ok. > >> > Mobile IPv6 bootstrapping recommends the Home Agent to update the >> > Mobile Node's FQDN with a dynamically assigned home address rather >> > than have the Mobile Node itself do it (see Section 6 above). This >> > choice was motivated by a concern for preventing redirection-based >> > flooding attacks (see draft-ietf-mip6-ro-sec [21] for more >> > information about redirection-based flooding attacks and the role >> > preventing them played in the design of Mobile IPv6 route >> > optimization security). Exactly as for route optimization, it is >> > possible for a node that is the legitimate owner of a DNS FQDN - >> > in the sense that it has a security association with the DNS >> > server allowing it to perform dynamic DNS update of its FQDN - to >> > bind its FQDN to the address of a victim, then redirect large >> > volumes of traffic at the victim. The attack may be propagated >> > without the owner's knowledge, for example, if the node is >> > compromised by malware, or it may be intentional if the node >> > itself is the attacker. >> > >> > While it is possible to prevent redirection attacks through >> > ingress filtering on access routers, ISPs have little or no >> > incentive to deploy ingress filtering. In some cases, if an attack >> > could result in substantial financial gain, it is even possible >> > that a corrupt ISP may have an incentive not to deploy ingress >> > filters such as has been the case for spam. Consequently, the >> > security for dynamic Mobile Node FQDN update has been assigned to >> > the Home Agent, where active network administration and vigilant >> > defense measures are more likely to (but are not assured of) >> > mitigating problems, and the owner of the Mobile Node is more >> > likely to detect a problem if it occurs. >> There are good reasons why using a proxy to do the >> DynDNS update from your behalf makes sense. But I >> don't think the above is such a good reason. The >> route optimization redirect problem assumes that >> traffic from an ongoing session is suddenly moved >> to a new address. If you just change the DNS information, >> ongoing sessions are not affected, and all new sessions >> go through the usual TCP slow start etc. >> >> (A good reason why it makes sense to use a proxy >> is that then you just need a secret between the >> DNS server and the home agent, not between the >> DNS server and every mobile node.) >> > > I'm fine with removing that text. However, I would like to hear > thoughts from James, since he has been very active in that part of the > draft. Ok. > >> > Notice that if certificates are used in >> > IKEv2, the authorization information about the FQDN for DNS update >> > MUST be present in the certificate provided by the Mobile Node. >> Yes -- but can you write this in more explicit >> form? For instance, I assume that you meant >> the FQDN must appear in some specific field >> in the certificate. >> > > Yes, this is certainly one option. Again I would leave to James the > proposed text on this. > Ok. James? >> > Regardless of whether the AAA server or Home Agent performs DNS >> > update, the authorization of the Mobile Node to update a FQDN MUST >> > be checked prior to the performance of the update. It is an >> > implementation issue as to how authorization is determined. >> > However, in order to allow this authorization step, the Mobile >> > Node MUST use a FQDN as the IDi in IKE_AUTH step of the IKEv2 >> > exchange. The FQDN MUST be the same that will be provided by the >> > Mobile Node in the DNS Update Option. This allows the Home Agent >> > to get authorization information about the Mobile Node's FQDN via >> > the AAA back end communication performed during IKEv2 exchange. >> > The outcome of this step will give the Home Agent the necessary >> > information to authorize the DNS update request of the Mobile >> > Node. See draft-ietf-mip6-aaa-ha-goals [14] for details about the >> > communication between the AAA server and the Home Agent needed to >> > perform the authorization. Notice that if certificates are used in >> > IKEv2, the authorization information about the FQDN for DNS update >> > MUST be present in the certificate provided by the Mobile Node. >> This is another case where I believe the important >> authorization step is underspecified, and needs to be >> specified in more detail to make sure people actually >> can implement it. And that they will get it right. >> > > ok, are you suggesting to have the same text here and above about FQDN > in certificates? I think so, but you are of course free to provide something else, too, as long the details are there. > >> Also, I am unsure if the requirement to use the >> FQDN in the IKEv2 exchange is helpful. If an >> FQDN X is used in the IKEv2 exchange, but the >> actual authentication employs IKEv2/EAP with >> a method that does its own identity exchange >> with FQDN Y, what happens? Also, you are >> preventing privacy NAI usage in the IKEv2 >> exchange. And if you use a FQDN (no "@", i.e., >> not a NAI) in the IKEv2 identity, how will the >> gateway be able to route the AAA request? >> >> One alternative approach would be to require >> the following: >> >> - If certificates are used, then the FQDN must >> appear there (but see my previous comment). >> >> - Otherwise, the mobile node's identity is >> taken as asserted in the EAP method >> where available and otherwise from the >> IKEv2 exchange. >> >> - Home agent must be able to match >> mobile node identities to allowed FQDNs. >> For certs, step 1 above suffices. In other >> cases its basically configured information. >> >> - The division of work between the home >> agent and AAA is outside the scope of >> this document. Note that there may be >> non-trivial issues, such as when the >> actual identity is end-to-end hidden >> between the mobile node and the AAA >> server. >> > > In case the FQDN is known by the AAA server via EAP, I see two > possible approaches: > > - the AAA server provides the HA with the MN's FQDN received via EAP > (e.g. during Diameter EAP application) and the HA stores the > "authorized" FQDN. This would require a change in current Diameter > application Yes. Or a new AVP, at least. CUI might apply here, but it might not have exactly the semantics you want. > > - the HA performs a AAA exchange when it receives a BU with a DNS > Update mobility option; this AAA exchange should be part of the Mobile > IPv6 Diameter application (work in progress in DIME WG) and should be > used by the HA to get the authorized FQDN from the AAA server in order > to update the DNS This sounds preliminarily better. > > The draft should leave the actual definition of either mechanism as > out of scope (as you suggested), but we should put a reference to the > solution. > > As a summary, in this draft, I think it is enough to clarify the need > of the FQDN in the cert for the certificates scenario. For the AAA/EAP > scenario, we should provide a reference for the HA-AAA coordination > needed in case EAP is used, but we should at least include some text > on one of the two alternatives described above. What do you think? > Ok. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Feb 24 10:20:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKyf0-0007om-L8; Sat, 24 Feb 2007 10:18:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKyez-0007jp-G4 for mip6@ietf.org; Sat, 24 Feb 2007 10:18:05 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKyey-00029x-Nq for mip6@ietf.org; Sat, 24 Feb 2007 10:18:05 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E485C198775; Sat, 24 Feb 2007 17:18:03 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 12E481986AF; Sat, 24 Feb 2007 17:18:00 +0200 (EET) Message-ID: <45E00DD7.70701@piuha.net> Date: Sat, 24 Feb 2007 12:05:11 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] AD review of draft-ietf-mip6-bootstrapping-split References: <459A5A6C.5070602@piuha.net> <45DF3F77.7070203@azairenet.com> In-Reply-To: <45DF3F77.7070203@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: Mobile IPv6 Mailing List , James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay, > > There was an explicit requirement to support local HA > assignment using DNS. IMO, local HA assignment is > required for any HA discovery/assignment mechanism. So > I would like to keep the text instead of saying it is > out of scope. > > The example is trying to describe how a particular > operator may "name" the home agents, what entries appear > in the DNS servers, and what FQDNs are provisioned in > the mobile node. > > This particular paragraph underwent multiple changes. > I can re-write the text to better explain how it can be > done or to address any specific concern. The reason that I am reacting on this is that we should either explain, fully, how to do it or otherwise declare it out of scope. I see several holes in the example text, including, for instance, how the mobile nodes determine the locations, how changes in the available locations are managed between the MN and HA implementations, etc. > >>> > If an anycast address is returned in response to DNS resolution of >>> > an FQDN, the IKEv2 transaction between the Mobile Node and Home >>> > Agent is slightly modified. The Mobile Node sends the IKE_SA_INIT >>> > request to the anycast address. The node which has the anycast >>> > address assigned to one of its network interfaces selects a Home >>> > Agent address from the set of Home Agents managed by the node, and >>> > forwards the IKE_SA_INIT. If the set of Home Agents is empnty, the >>> > node simply drops the packet. The Home Agent answers using its own >>> > address, and includes an "under attack" cookie, in accordance with >>> > RFC 4306 [7]. The Mobile Node notes the Home Agent address and >>> > resends the IKE_SA_INIT message to the Home Agent, along with the >>> > cookie. >>> There are several issues in this. First, I think I understand >>> at least one reason why the cookie exchange makes sense, >>> but is that something that has to be mandated? What if the >>> home network simply figures out what HA should be used and >>> responds in the usual IKEv2 way? > > I don't think the IKE SA can be setup if the destination > address on the IKE_SA_INIT request is an anycast address > and the source address on the IKE_SA_INIT response is a > unicast address of a particular responder. Why? There is nothing special about anycast addresses, syntactically... > >>> Secondly, responding with the home agent's own address >>> is in violation of a MUST in RFC 4306, Section 2.11. I talked >>> to one of the IKEv2 designers about this and his advice >>> was that the MUST may have been a mistake. Or at least it >>> should be limited to unicast addresses, and leave the behaviour >>> for anycast addresses for future documents. In any case, >>> this deviation from RFC 4306 should be highlighted and >>> justified in the document. > > Sure. It is obvious that if the packet was sent to an > anycast address, the response comes back from an unicast > address. Any host that sends an IP packet to an anycast > address should except this irrespective of what protocol > is used. We can mention that the "MUST" in section 2.11 > is violated in this case. Ok. Do you have a text proposal? > >>> The third issue is the above notion of a node that owns an >>> anycast address. How does this relate to the usual arrangement >>> where the routing system handles the delivery of the anycast >>> packets to the "closest" place that advertises that address? >>> When you say "forwards", do you mean that the packet is >>> forwarded unmodified, or that the particular home agent's >>> address replaces the destination address? Do you allow >>> each home agent to configure the same anycast address? > > When the home agents are part of the anycast group, they > all configure the same anycast address on one of their > interfaces. The current text is confusing since it says > that one node is configured with the anycast address and > it decides which home agent the request should be > forwarded to. This needs to be fixed to say that one of > the home agents gets the request and based on the load > conditions forwards the request to another home agent > that is part of the anycast group. > > By "forwarding", we meant the packet can be sent to another > home agent unmodified if the home agents are all on the > same link. Ok, sounds good. But we need text. >>> Four: What happens when the IKE SA dies or is >>> deleted, but a binding for the mobile node remains >>> in the selected home agent? Will the mobile node >>> re-establish the IKE SA using the anycast address, >>> or the address of the selected home agent? > > If the mobile node has a binding with a particular home > agent it must send the IKE_SA_INIT request to the same > home agent and not use the anycast address. I guess this > needs to be said explicitly. Ok. > >>> Finally, I wonder how useful the anycast part of >>> this spec is given that DNS can already provide >>> a set of addresses. > > This mechanism was added because some folks wanted a > mechanism that can return home agents based on the load > on the home agents instead of just returning a set of > addresses. But it is a pretty special way to use anycast. Anycast deliveries are essentially driven by the routing system, not application state. Here you do deliver it via routing, but then you re-deliver it based on application logic. Architecturally, it might be better have "application" (Mobile IP in this case) signaling to deal with this. But perhaps the IKEv2 signaling to refer to another node can be seen as such... > >>> > The Home Agent MUST set up authorization by linking the home >>> > address to the identity of the IPsec SAs used to authenticate the >>> > Binding Update message. The linking MUST be done either during the >>> > IKE_AUTH phase or CREATE_CHILD_SA phase when the IPsec SAs are >>> > constructed. >>> > >>> > If the address is auto-configured, RFC 3775 requires the Home >>> > Agent to proxy-defend the address on the home link after the >>> > Mobile Node performs the initial Binding Update. Since it is not >>> > currently possible to securely proxy CGAs using SEND, attacks on >>> > address resolution for Neighbor Discovery listed in RFC 3756 are >>> > possible on dynamically assigned home addresses that are proxied >>> > by the Home Agent. >>> I do not know what to implement based on the above >>> description. Its clear that a link must be established between >>> the IKE identity and the requested home address. But how? >>> What should be done with the information about the link? >>> >> >> Isn't this described also in MIP6-IKEv2 draft? VIjay? > > draft-ietf-mip6-ikev2-ipsec only deals with home address > assignment. The HA always gives out an 128 bit home address > to the mobile node. Jari's text below looks good to me. Great. > >>> "The home agent MUST authorize each home address >>> allocation and use. This authorization is based on linking >>> the mobile node identity used in the IKEv2 authentication >>> process and the home address. Home agents MUST support >>> at least the following two modes of authorization: >>> >>> o Configured home address(es) for each mobile node. >>> In this mode, the home agent or infrastructure nodes >>> behind it know what addresses a specific mobile node >>> is authorized to use. The mobile node is allowed to >>> request these addresses, or if the mobile node requests >>> any home address, these addresses are returned to it. >>> >>> o First-come-first-served (FCFS). In this mode, the home agent >>> maintains a pool of "used" addresses, and allows mobile >>> nodes to request any address, as long as it is not used by >>> another mobile node. >>> >>> Addresses MUST be marked as used for at least as long as >>> the binding exists, and are associated with the identity >>> of the mobile node that made the allocation. >>> >>> In addition, the home agent MUST ensure that the requested >>> address is not the authorized address of any other mobile >>> node, if both FCFS and configured modes use the same >>> address space." >>> >> >> Text is fine with me. The original idea is that we need to add an >> authorization step in order to check if the MN can or cannot >> auto-configure the Home Address. I think your text resolves this >> issue, giving also more details. >> Ok. >>> > Mobile IPv6 bootstrapping recommends the Home Agent to update the >>> > Mobile Node's FQDN with a dynamically assigned home address rather >>> > than have the Mobile Node itself do it (see Section 6 above). This >>> > choice was motivated by a concern for preventing redirection-based >>> > flooding attacks (see draft-ietf-mip6-ro-sec [21] for more >>> > information about redirection-based flooding attacks and the role >>> > preventing them played in the design of Mobile IPv6 route >>> > optimization security). Exactly as for route optimization, it is >>> > possible for a node that is the legitimate owner of a DNS FQDN - >>> > in the sense that it has a security association with the DNS >>> > server allowing it to perform dynamic DNS update of its FQDN - to >>> > bind its FQDN to the address of a victim, then redirect large >>> > volumes of traffic at the victim. The attack may be propagated >>> > without the owner's knowledge, for example, if the node is >>> > compromised by malware, or it may be intentional if the node >>> > itself is the attacker. >>> > >>> > While it is possible to prevent redirection attacks through >>> > ingress filtering on access routers, ISPs have little or no >>> > incentive to deploy ingress filtering. In some cases, if an attack >>> > could result in substantial financial gain, it is even possible >>> > that a corrupt ISP may have an incentive not to deploy ingress >>> > filters such as has been the case for spam. Consequently, the >>> > security for dynamic Mobile Node FQDN update has been assigned to >>> > the Home Agent, where active network administration and vigilant >>> > defense measures are more likely to (but are not assured of) >>> > mitigating problems, and the owner of the Mobile Node is more >>> > likely to detect a problem if it occurs. >>> There are good reasons why using a proxy to do the >>> DynDNS update from your behalf makes sense. But I >>> don't think the above is such a good reason. The >>> route optimization redirect problem assumes that >>> traffic from an ongoing session is suddenly moved >>> to a new address. If you just change the DNS information, >>> ongoing sessions are not affected, and all new sessions >>> go through the usual TCP slow start etc. >>> >>> (A good reason why it makes sense to use a proxy >>> is that then you just need a secret between the >>> DNS server and the home agent, not between the >>> DNS server and every mobile node.) > > Agree. > Great, thanks for the responses. Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Feb 25 21:46:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVrK-0002aK-H8; Sun, 25 Feb 2007 21:45:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLVrI-0002Y6-In for mip6@ietf.org; Sun, 25 Feb 2007 21:45:00 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLVrF-0007Y2-9K for mip6@ietf.org; Sun, 25 Feb 2007 21:45:00 -0500 Received: from ep_ms5_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JE100AJFUAV8V@mailout2.samsung.com> for mip6@ietf.org; Mon, 26 Feb 2007 11:44:55 +0900 (KST) Received: from ep_spt02 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JE100M07UAVFH@ms5.samsung.com> for mip6@ietf.org; Mon, 26 Feb 2007 11:44:55 +0900 (KST) Content-return: prohibited Date: Mon, 26 Feb 2007 02:44:55 +0000 (GMT) From: Heejin Jang Subject: Re: RE: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 To: Kilian Weniger Message-id: <0JE100M08UAVFH@ms5.samsung.com> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20070226024455424@heejin.jang X-MTR: 20070226024455424@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-Generator: NamoMIME 6.0.0.8 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d Cc: "mip6@ietf.org" , Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1885375848==" Errors-To: mip6-bounces@ietf.org --===============1885375848== Content-return: prohibited Content-type: text/html; charset=windows-1252 Content-transfer-encoding: base64 PEhUTUw+PEhFQUQ+CjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9J3RleHQv aHRtbDsgY2hhcnNldD13aW5kb3dzLTEyNTInPgo8dGl0bGU+U2Ftc3VuZyBFbnRlcnByaXNlIFBv cnRhbCBteVNpbmdsZTwvdGl0bGU+CjxzdHlsZT4gUCwgdGQsIGxpIHtmb250LWZhbWlseTpBcmlh bCwgYXJpYWw7IGZvbnQtc2l6ZTo5cHQ7IG1hcmdpbi10b3A6NXB4O21hcmdpbi1ib3R0b206NXB4 O30gYm9keXtmb250LWZhbWlseTpBcmlhbCwgYXJpYWw7IGZvbnQtc2l6ZTo5cHQ7fTwvc3R5bGU+ CjwvSEVBRD48Qk9EWT5IaSwgS2lsaWFuLg0KPHA+VGhhbmtzIGZvciB0aGUgY29tbWVudHMuIDwv cD4NCjxwPiZuYnNwOzwvcD4NCjxwPlJlZ2FyZGluZyB0aGUgdXNlIG9mIHRlcm0sIHRoZSBkcmFm dChoaW9wdCkmbmJzcDtzdXBwb3J0cyBhbGwgdGhlIHRocmVlIGZvbGxvd2luZyANCm5ldHdvcmtz IGFzIHRhcmdldCBuZXR3b3JrczwvcD4NCjxwPjEpIEFTUCAoTU4ncyBjdXJyZW50bHkgdmlzaXRl ZCBuZXR3b3JrKTwvcD4NCjxwPjIpIEhvbWUgTVNQICg9IE1TQSk8L3A+DQo8cD4zKSBNU1AgKG5l dHdvcmsgd2hpY2ggaXMgbmV0aGVyICZuYnNwO0FTUCBub3IgSG9tZSBNU1AgYnV0IGhhcyB0cnVz dCByZWxhdGlvbnNoaXAgDQp3aXRoIE1OJ3MgTVNBKTwvcD4NCjxwPiZuYnNwOzwvcD4NCjxwPlRo ZSZuYnNwO3Rlcm0gJ2hvbWUgTVNQJyBjYW4gYmUgYW1iaWd1b3VzIHNpbmNlIGl0IGRvZXMgbm90 IGluY2x1ZGUgMyksIDwvcD4NCjxwPnNvIHdlIHdpbGwgbW9kaWZ5IGl0IHRvICdNU1Agd2l0aCBy b2FtaW5nICZuYnNwO3JlbGF0aW9uc2hpcCB3aXRoIE1OJ3MgTVNBJyANCmZvciBtb3JlIGNsYXJp ZmljYXRpb24uPC9wPg0KPHA+VGhhbmtzLjwvcD4NCjxwPiZuYnNwOzwvcD4NCjxwPlJlZ2FyZHMs IDwvcD4NCjxwPkhlZWppbi48L3A+DQo8cD48YnI+LS0tLS0tIDxiPk9yaWdpbmFsIE1lc3NhZ2U8 L2I+IC0tLS0tLS08YnI+PGI+U2VuZGVyPC9iPiA6IEtpbGlhbiBXZW5pZ2VyJmx0O0tpbGlhbi5X ZW5pZ2VyQGV1LnBhbmFzb25pYy5jb20mZ3Q7PGJyPjxiPkRhdGU8L2I+ICAgOiAyMDA3LTAyLTIy IDIzOjAwPGJyPjxiPlRpdGxlPC9iPiAgOiBSRTogUkU6IFtNaXA2XSBXR0xDOiBkcmFmdC1pZXRm LW1pcDYtYm9vdHN0cmFwcGluZy1pbnRlZ3JhdGVkLTAyPGJyPjxicj5IaSZuYnNwO0hlZWppbiwN Cjxicj4NCjxicj50aGFua3MmbmJzcDtmb3ImbmJzcDt5b3VyJm5ic3A7Y29tbWVudHMsJm5ic3A7 c2VlJm5ic3A7bXkmbmJzcDtyZXBsaWVzJm5ic3A7aW5saW5lLiZuYnNwOw0KPGJyPg0KPGJyPlBs ZWFzZSZuYnNwO25vdGUmbmJzcDt0aGF0Jm5ic3A7dGhlJm5ic3A7Y29tbWVudHMmbmJzcDtpbiZu YnNwO215Jm5ic3A7bWFpbCZuYnNwO3dlcmUmbmJzcDtyZWZlcnJpbmcmbmJzcDt0bw0KPGJyPmRy YWZ0LWlldGYtbWlwNi1ib290c3RyYXBwaW5nLWludGVncmF0ZWQtMDIuJm5ic3A7QW5kJm5ic3A7 c2luY2UmbmJzcDt0aGUmbmJzcDtyZWZlcmVuY2UNCjxicj5bSElPUFRdJm5ic3A7aW4mbmJzcDtk cmFmdC1pZXRmLW1pcDYtYm9vdHN0cmFwcGluZy1pbnRlZ3JhdGVkLTAyJm5ic3A7aXMmbmJzcDto aW9wdC0wMSwmbmJzcDtJDQo8YnI+ZGlkbiYjMzk7dCZuYnNwO2NvbnNpZGVyJm5ic3A7aGlvcHQt MDIuJm5ic3A7DQo8YnI+DQo8YnI+Jmd0OyZuYnNwOy0tLS0tT3JpZ2luYWwmbmJzcDtNZXNzYWdl LS0tLS0NCjxicj4mZ3Q7Jm5ic3A7RnJvbTombmJzcDtIZWVqaW4mbmJzcDtKYW5nJm5ic3A7W21h aWx0bzpoZWVqaW4uamFuZ0BzYW1zdW5nLmNvbV0mbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7U2VudDom bmJzcDtEaWVuc3RhZywmbmJzcDsyMC4mbmJzcDtGZWJydWFyJm5ic3A7MjAwNyZuYnNwOzA4OjMx DQo8YnI+Jmd0OyZuYnNwO1RvOiZuYnNwO0tpbGlhbiZuYnNwO1dlbmlnZXINCjxicj4mZ3Q7Jm5i c3A7Q2M6Jm5ic3A7QmFzYXZhcmFqJm5ic3A7UGF0aWw7Jm5ic3A7bWlwNkBpZXRmLm9yZw0KPGJy PiZndDsmbmJzcDtTdWJqZWN0OiZuYnNwO1JlOiZuYnNwO1JFOiZuYnNwO1tNaXA2XSZuYnNwO1dH TEM6Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwO2RyYWZ0LWlldGYtbWlwNi1ib290c3RyYXBwaW5nLWlu dGVncmF0ZWQtMDINCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwO0hpLCZuYnNwOyZuYnNw O0tpbGlhbiZuYnNwO1dlbmlnZXIuJm5ic3A7DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJz cDtUaGFua3MmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtkZXRhaWxlZGwmbmJzcDtjb21tZW50cy4m bmJzcDsNCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwO1BsZWFzZSZuYnNwO3NlZSZuYnNw O3RoZSZuYnNwO2lubGluZSZuYnNwO2NvbW1lbnRzJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7SElP UFQmbmJzcDtkcmFmdC4NCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsm bmJzcDstLS0tLS0tJm5ic3A7T3JpZ2luYWwmbmJzcDtNZXNzYWdlJm5ic3A7LS0tLS0tLQ0KPGJy PiZndDsmbmJzcDtTZW5kZXImbmJzcDs6Jm5ic3A7S2lsaWFuJm5ic3A7V2VuaWdlciZsdDtLaWxp YW4uV2VuaWdlckBldS5wYW5hc29uaWMuY29tJmd0Ow0KPGJyPiZndDsmbmJzcDtEYXRlJm5ic3A7 OiZuYnNwOzIwMDctMDItMTYmbmJzcDsxNzozMQ0KPGJyPiZndDsmbmJzcDtUaXRsZSZuYnNwOzom bmJzcDtSRTombmJzcDtbTWlwNl0mbmJzcDtXR0xDOiZuYnNwO2RyYWZ0LWlldGYtbWlwNi1ib290 c3RyYXBwaW5nLWludGVncmF0ZWQtMDINCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwO0hp LCZuYnNwOw0KPGJyPiZndDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7cGxlYXNlJm5ic3A7ZmluZCZu YnNwO2JlbG93Jm5ic3A7c29tZSZuYnNwO2NvbW1lbnRzJm5ic3A7YWJvdXQmbmJzcDsmbmJzcDsN Cjxicj4mZ3Q7Jm5ic3A7ZHJhZnQtaWV0Zi1taXA2LWJvb3RzdHJhcHBpbmctaW50ZWdyYXRlZC0w Mi4mbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwO1RoZSZuYnNwO2RyYWZ0Jm5i c3A7aXMmbmJzcDt3ZWxsJm5ic3A7d3JpdHRlbiZuYnNwO2FuZCZuYnNwO2Vhc3kmbmJzcDt0byZu YnNwO3VuZGVyc3RhbmQmbmJzcDsodGhhbmtzJm5ic3A7dG8mbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7 ZmlndXJlcyZuYnNwO2FuZCZuYnNwOw0KPGJyPiZndDsmbmJzcDttZXNzYWdlJm5ic3A7c2VxdWVu Y2UmbmJzcDt0ZXh0KS4mbmJzcDtIb3dldmVyLCZuYnNwO3NvbWUmbmJzcDtkZXRhaWxzJm5ic3A7 YW5kJm5ic3A7Y29ybmVyJm5ic3A7DQo8YnI+Jmd0OyZuYnNwO2Nhc2VzJm5ic3A7YXJlJm5ic3A7 bm90Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwO2FkZHJlc3NlZCwmbmJzcDt3aGljaCZuYnNwO21heSZu YnNwO25lZWQmbmJzcDt0byZuYnNwO2JlJm5ic3A7c3BlY2lmaWVkLCZuYnNwO2UuZy46Jm5ic3A7 DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDstJm5ic3A7SG93Jm5ic3A7ZG9lcyZuYnNw O3RoZSZuYnNwO05BUy9yZWxheSZuYnNwO21hcCZuYnNwO2EmbmJzcDtESENQJm5ic3A7cmVxdWVz dCZuYnNwO3JlY2VpdmVkJm5ic3A7ZnJvbSZuYnNwO2EmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7c3Bl Y2lmaWMmbmJzcDtNTiZuYnNwOyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDt0byZu YnNwO3RoZSZuYnNwO2NhY2hlZCZuYnNwO2hvbWUmbmJzcDtuZXR3b3JrJm5ic3A7aW5mb3JtYXRp b24mbmJzcDtwcmV2aW91c2x5Jm5ic3A7cmVjZWl2ZWQmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7ZnJv bSZuYnNwO0FBQUgmbmJzcDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Zm9yJm5i c3A7dGhpcyZuYnNwO01OLCZuYnNwO3NvJm5ic3A7dGhhdCZuYnNwO2l0Jm5ic3A7Y2FuJm5ic3A7 aW5jbHVkZSZuYnNwO3RoZSZuYnNwO2NvcnJlY3QmbmJzcDtob21lJm5ic3A7bmV0d29yayZuYnNw OyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2luJm5i c3A7YSZuYnNwO3JlY2VpdmVkJm5ic3A7REhDUCZuYnNwO3JlcXVlc3Q/Jm5ic3A7DQo8YnI+Jmd0 OyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZu YnNwO0hpb3B0Jmd0OyZndDsmbmJzcDtUaGUmbmJzcDttYXBwaW5nJm5ic3A7bWVjaGFuaXNtJm5i c3A7aXMmbmJzcDthZGRlZCZuYnNwO2luJm5ic3A7c2VjdGlvbiZuYnNwOzQuMyZuYnNwO29mJm5i c3A7dGhlJm5ic3A7DQo8YnI+Jmd0OyZuYnNwO2xhdGVzdCZuYnNwO3ZlcnNpb24mbmJzcDtvZiZu YnNwO3RoZSZuYnNwO2RvY3VtZW50Jm5ic3A7KGhpb3B0LTAyKS4NCjxicj4NCjxicj5JdCZuYnNw O3Nob3VsZCZuYnNwO2JlJm5ic3A7aW4mbmJzcDtzZWN0aW9uJm5ic3A7NC4yLCZuYnNwO3NpbmNl Jm5ic3A7bXkmbmJzcDtxdWVzdGlvbiZuYnNwO3dhcyZuYnNwO3JlbGF0ZWQmbmJzcDt0byZuYnNw O3RoZSZuYnNwO0RIQ1ANCjxicj5yZWxheSZuYnNwO2JlaGF2aW91ci4mbmJzcDtNYXliZSZuYnNw O0kmbmJzcDttaXNzZWQmbmJzcDtpdCwmbmJzcDtidXQmbmJzcDtJJm5ic3A7Y2FuJiMzOTt0Jm5i c3A7c2VlJm5ic3A7YW55Jm5ic3A7cmVsYXRlZCZuYnNwO3RleHQmbmJzcDtpbg0KPGJyPnNlY3Rp b24mbmJzcDs0LjImbmJzcDtvZiZuYnNwO2hpb3B0LTAyJm5ic3A7YWJvdXQmbmJzcDttYXBwaW5n Jm5ic3A7b2YmbmJzcDtob21lJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtyZWNlaXZlZCZuYnNwO2Zy b20NCjxicj5BQUEmbmJzcDtzZXJ2ZXImbmJzcDt0byZuYnNwO0RIQ1AmbmJzcDtyZXF1ZXN0Jm5i c3A7cmVjZWl2ZWQmbmJzcDtmcm9tJm5ic3A7TU4uJm5ic3A7QnV0Jm5ic3A7S3VudGFsJm5ic3A7 YW5zd2VyZWQmbmJzcDt0byZuYnNwO215DQo8YnI+cXVlc3Rpb24mbmJzcDtpbiZuYnNwO2hpcyZu YnNwO3JlcGx5Jm5ic3A7ZW1haWwuJm5ic3A7DQo8YnI+DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZn dDsmbmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2lzJm5ic3A7bWFwcGVkJm5ic3A7YmFz ZWQmbmJzcDtvbiZuYnNwO05BSSZuYnNwO25vdCZuYnNwO2J5Jm5ic3A7TkFTJm5ic3A7YnV0Jm5i c3A7YnkmbmJzcDtESENQJm5ic3A7DQo8YnI+Jmd0OyZuYnNwO3NlcnZlci4mbmJzcDtScmVmZXIm bmJzcDt0byZuYnNwO2hpb3B0LTAyJm5ic3A7Zm9yJm5ic3A7bW9yZSZuYnNwO2RldGFpbHMuDQo8 YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7LSZuYnNwO1doYXQm bmJzcDtpcyZuYnNwO3RoZSZuYnNwO2NvbmNlcHR1YWwmbmJzcDtkYXRhJm5ic3A7c3RydWN0dXJl Jm5ic3A7bmVlZGVkJm5ic3A7Zm9yJm5ic3A7dGhpcyZuYnNwO2luJm5ic3A7DQo8YnI+Jmd0OyZu YnNwO3RoZSZuYnNwO05BUy9ESENQJm5ic3A7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwO3JlbGF5PyZuYnNwOw0KPGJyPiZndDsmbmJzcDstJm5ic3A7QW55Jm5ic3A7ZGVmYXVsdCZu YnNwO3ZhbHVlJm5ic3A7Zm9yJm5ic3A7aG93Jm5ic3A7bG9uZyZuYnNwO05BUyZuYnNwO3Nob3Vs ZCZuYnNwO2NhY2hlJm5ic3A7aG9tZSZuYnNwO25ldHdvcmsmbmJzcDsmbmJzcDsNCjxicj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7aW5mb3JtYXRpb24mbmJzcDtyZWNlaXZlZCZuYnNwO2Zyb20mbmJz cDtBQUEmbmJzcDtmb3ImbmJzcDthJm5ic3A7c3BlY2lmaWMmbmJzcDtNTiZuYnNwOyhpLmUuLCZu YnNwO3doZW4mbmJzcDtpcyZuYnNwO05BUyZuYnNwOyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJz cDsmbmJzcDthbGxvd2VkJm5ic3A7dG8mbmJzcDtkZWxldGUmbmJzcDtjYWNoZSZuYnNwO2VudHJ5 Pyk/Jm5ic3A7SWYmbmJzcDt0aGlzJm5ic3A7aXMmbmJzcDtzcGVjaWZpZWQmbmJzcDtpbiZuYnNw Ow0KPGJyPiZndDsmbmJzcDtbTUlQNi1EaW1lXSZuYnNwOyZuYnNwOw0KPGJyPiZndDsmbmJzcDsm bmJzcDsmbmJzcDtvciZuYnNwO1tNSVA2LVJBRElVU10mbmJzcDtpdCZuYnNwO3Nob3VsZCZuYnNw O2JlJm5ic3A7bWVudGlvbmVkJm5ic3A7YW5kJm5ic3A7cmVmZXJlbmNlZC4mbmJzcDsmbmJzcDsN Cjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwO0hpb3B0Jmd0OyZndDsmbmJzcDtUaGlzJm5i c3A7aXMmbmJzcDtpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYy4mbmJzcDtJJiMzOTttJm5ic3A7bm90 Jm5ic3A7c3VyZSZuYnNwO3dlJm5ic3A7bmVlZCZuYnNwOw0KPGJyPiZndDsmbmJzcDt0byZuYnNw O2Rlc2NyaWJlJm5ic3A7ZG93biZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7c21hbGxlc3QmbmJzcDtk ZXRhaWwuJm5ic3A7DQo8YnI+DQo8YnI+QSZuYnNwO3ZhbHVlJm5ic3A7ZG9lc24mIzM5O3QmbmJz cDtuZWVkJm5ic3A7dG8mbmJzcDtiZSZuYnNwO21hbmRhdGVkLCZuYnNwO2J1dCZuYnNwO0kmbmJz cDt0aGluayZuYnNwO3NvbWUmbmJzcDtndWlkYW5jZSZuYnNwO3RvJm5ic3A7dGhlDQo8YnI+aW1w bGVtZW50b3ImbmJzcDt3b3VsZCZuYnNwO2JlJm5ic3A7Z29vZC4NCjxicj4NCjxicj4mZ3Q7Jm5i c3A7DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDstJm5ic3A7V2hhdCZuYnNwO3Nob3Vs ZCZuYnNwO05BUyZuYnNwO2RvJm5ic3A7aWYmbmJzcDtESENQJm5ic3A7cmVxdWVzdCZuYnNwO3dp dGgmbmJzcDtIb21lJm5ic3A7bmV0d29yayZuYnNwO2lkZW50aWZpZXImbmJzcDsmbmJzcDsNCjxi cj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7b3B0aW9uJm5ic3A7aXMmbmJzcDtyZWNlaXZlZCZuYnNw O2Zyb20mbmJzcDthJm5ic3A7TU4mbmJzcDthbmQmbmJzcDtOQVMmbmJzcDtkb2VzbiYjMzk7dCZu YnNwO2ZpbmQmbmJzcDt2YWxpZCZuYnNwOw0KPGJyPiZndDsmbmJzcDtob21lJm5ic3A7bmV0d29y ayZuYnNwOyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDtpbmZvcm1hdGlvbiZuYnNw O2ZvciZuYnNwO3RoaXMmbmJzcDtNTiZuYnNwO2luJm5ic3A7aXRzJm5ic3A7Y2FjaGUmbmJzcDso ZS5nLiwmbmJzcDtzaW5jZSZuYnNwO3RoZSZuYnNwO2NhY2hlJm5ic3A7ZW50cnkmbmJzcDsmbmJz cDsNCjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7aGFzJm5ic3A7ZXhwaXJlZCk/Jm5ic3A7DQo8 YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+ Jmd0OyZuYnNwO0hpb3B0Jmd0OyZndDtJbiZuYnNwO3RoYXQmbmJzcDtjYXNlLCZuYnNwO3RoZXJl Jm5ic3A7aXMmbmJzcDtub3RoaW5nJm5ic3A7TkFTJm5ic3A7Y2FuJm5ic3A7ZG8uJm5ic3A7SWYm bmJzcDt0aGUmbmJzcDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Y29ycmVzcG9uZGluZyZuYnNwO2lu Zm9ybWF0aW9uJm5ic3A7DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDtpcyZuYnNwO2Nv bmZpZ3VyZWQmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO0RIQ1AmbmJzcDtzZXJ2ZXImbmJzcDsoZm9y Jm5ic3A7ZS5nLiwmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7cHJlLWNvbmZpZ3VyYXRpb24pLCZuYnNw O3RoZSZuYnNwO3NlcnZlciZuYnNwO3dpbGwNCjxicj4mZ3Q7Jm5ic3A7cHJvdmlkZSZuYnNwO2l0 LiZuYnNwO090aGVyd2lzZSwmbmJzcDtpdCZuYnNwO3dpbGwmbmJzcDtyZXBseSZuYnNwO3dpdGgm bmJzcDswLWxlbmdoJm5ic3A7b3B0aW9uLg0KPGJyPg0KPGJyPm9rLiZuYnNwO015Jm5ic3A7Y29t bWVudCZuYnNwO3dhcyZuYnNwO3RoYXQmbmJzcDt0aGlzJm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJz cDtkb2N1bWVudGVkJm5ic3A7KGkuZS4sJm5ic3A7REhDUCZuYnNwO3NlcnZlcg0KPGJyPm11c3Qm bmJzcDtyZXBseSZuYnNwO3dpdGgmbmJzcDswLWxlbmdoJm5ic3A7b3B0aW9uJm5ic3A7aW4mbmJz cDt0aGlzJm5ic3A7Y2FzZSkNCjxicj4NCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOw0K PGJyPiZndDsmbmJzcDstJm5ic3A7V2hhdCZuYnNwO3Nob3VsZCZuYnNwO0RIQ1AmbmJzcDtyZWxh eS9zZXJ2ZXImbmJzcDtkbyZuYnNwO2lmJm5ic3A7dGhlJm5ic3A7TU4mbmJzcDtkb2VzJm5ic3A7 bm90Jm5ic3A7aW5jbHVkZSZuYnNwO3RoZSZuYnNwOyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJz cDsmbmJzcDtPUFRJT05fQ0xJRU5USUQmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO0RIQ1AmbmJzcDty ZXF1ZXN0Jm5ic3A7b3ImbmJzcDtpZiZuYnNwO09QVElPTl9NSVA2LVJFTEFZLU9wdGlvbiZuYnNw OyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDtpcyZuYnNwO21pc3NpbmcmbmJzcDtp biZuYnNwO3JlcXVlc3Q/Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDsNCjxi cj4mZ3Q7Jm5ic3A7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDtIaW9wdCZn dDsmZ3Q7Jm5ic3A7VGhlJm5ic3A7ZXhpc3RpbmcmbmJzcDtESENQJm5ic3A7b3B0aW9ucyZuYnNw O2FyZSZuYnNwO2hhbmRsZWQmbmJzcDthY2NvcmRpbmcmbmJzcDt0byZuYnNwO1tSRkMmbmJzcDsz MzE1XS4NCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwO1RoZSZuYnNwO3JlcXVlc3QmbmJz cDtub3QmbmJzcDtpbmNsdWRpbmcmbmJzcDtPUFRJT05fQ0xJRU5USUQmbmJzcDtpcyZuYnNwO2Rp c2NhcmRlZCZuYnNwO2luJm5ic3A7dGhlJm5ic3A7DQo8YnI+Jmd0OyZuYnNwO3JlbGF5L3NlcnZl cg0KPGJyPiZndDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7YXMmbmJzcDtkZXNjcmliZWQmbmJzcDtp biZuYnNwOzE1LjQmbmJzcDtvZiZuYnNwO1tSRkMmbmJzcDszMzE1XS4mbmJzcDsNCjxicj4NCjxi cj5vay4NCjxicj4NCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJz cDtUaGUmbmJzcDtkcmFmdCZuYnNwO21heSZuYnNwO25lZWQmbmJzcDtiZXR0ZXImbmJzcDthbGln bmVkJm5ic3A7d2l0aCZuYnNwO1tISU9QVF0uJm5ic3A7Rm9yJm5ic3A7aW5zdGFuY2UsJm5ic3A7 DQo8YnI+Jmd0OyZuYnNwO2l0Jm5ic3A7aXMmbmJzcDtub3QmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7 Y2xlYXImbmJzcDt0byZuYnNwO21lJm5ic3A7aG93Jm5ic3A7ZXhhY3RseSZuYnNwO3RoZSZuYnNw O2hvbWUmbmJzcDtuZXR3b3JrJm5ic3A7aWRlbnRpZmllciZuYnNwO29wdGlvbiZuYnNwOw0KPGJy PiZndDsmbmJzcDthbmQmbmJzcDt0aGUmbmJzcDtob21lJm5ic3A7Jm5ic3A7DQo8YnI+Jmd0OyZu YnNwO25ldHdvcmsmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO29wdGlvbiZuYnNwO3NwZWNpZmllZCZu YnNwO2luJm5ic3A7W0hJT1BUXSZuYnNwO2FyZSZuYnNwO2FsbG93ZWQmbmJzcDsNCjxicj4mZ3Q7 Jm5ic3A7dG8mbmJzcDtiZSZuYnNwO3VzZWQmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7aW4mbmJzcDtk cmFmdC1pZXRmLW1pcDYtYm9vdHN0cmFwcGluZy1pbnRlZ3JhdGVkLTAyOiZuYnNwOyZuYnNwOw0K PGJyPiZndDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7LSZuYnNwO1tISU9QVF0mbmJzcDtzdXBwb3J0 cyZuYnNwO2hvbWUmbmJzcDthZGRyZXNzJm5ic3A7YWxsb2NhdGlvbi4mbmJzcDtUaGlzJm5ic3A7 aXMmbmJzcDtub3QmbmJzcDttZW50aW9uZWQmbmJzcDtpbiZuYnNwOyZuYnNwOw0KPGJyPiZndDsm bmJzcDsmbmJzcDsmbmJzcDtkcmFmdC1pZXRmLW1pcDYtYm9vdHN0cmFwcGluZy1pbnRlZ3JhdGVk LTAyLiZuYnNwO0lzJm5ic3A7dGhpcyZuYnNwO2ZvcmJpZGRlbiZuYnNwO29yJm5ic3A7Jm5ic3A7 DQo8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwO2FsbG93ZWQmbmJzcDtvciZuYnNwO291dC1vZi1z Y29wZT8mbmJzcDtJZiZuYnNwO2FsbG93ZWQsJm5ic3A7d2hlbiZuYnNwO2RvZXMmbmJzcDtOQVMm bmJzcDtzZXQmbmJzcDt0aGUmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7QS1mbGFnJm5ic3A7aW4mbmJz cDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlJm5ic3A7aG9tZSZuYnNwO25l dHdvcmsmbmJzcDtpZGVudGlmaWVyJm5ic3A7b3B0aW9uPyZuYnNwOw0KPGJyPiZndDsmbmJzcDsN Cjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDtIaW9w dCZndDsmZ3Q7Jm5ic3A7TkFTJm5ic3A7U0hPVUxEJm5ic3A7bm90Jm5ic3A7bW9kaWZ5Jm5ic3A7 dGhlJm5ic3A7SG9tZSZuYnNwO05ldHdvcmsmbmJzcDtJZGVudGlmaWVyJm5ic3A7b3B0aW9uLiZu YnNwOw0KPGJyPiZndDsmbmJzcDtUaGUmbmJzcDtBLWZsYWcmbmJzcDtpcyZuYnNwO3NldCZuYnNw O3RvJm5ic3A7MC8xJm5ic3A7b25seSZuYnNwO2J5Jm5ic3A7dGhlJm5ic3A7bW9iaWxlJm5ic3A7 bm9kZS4mbmJzcDtJZiZuYnNwO3RoZXJlJm5ic3A7aXMmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7aG9t ZSZuYnNwO2FkZHJlc3MNCjxicj4mZ3Q7Jm5ic3A7aW5mb3JtYXRpb24mbmJzcDthdCZuYnNwO05B UyZuYnNwO3RoYXQmbmJzcDt3YXMmbmJzcDthY3F1aXJlZCZuYnNwO2R1cmluZyZuYnNwO0FBQSZu YnNwO3RyYW5zYWN0aW9uLCZuYnNwOw0KPGJyPiZndDsmbmJzcDtpdCZuYnNwO2lzJm5ic3A7ZGVs aXZlcmVkDQo8YnI+Jmd0OyZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7REhDUCZuYnNwO3NlcnZlciZu YnNwO3dpdGgmbmJzcDtNSVA2LVJlbGF5Jm5ic3A7b3B0aW9uLiZuYnNwOyhSZWZlciZuYnNwO2hp b3B0LTAyLnR4dCkNCjxicj4NCjxicj5JJm5ic3A7d2FzJm5ic3A7YXdhcmUmbmJzcDtvZiZuYnNw O0hvQSZuYnNwO2FsbG9jYXRpb24mbmJzcDtzdXBwb3J0Jm5ic3A7aW4mbmJzcDtbSElPUFRdLiZu YnNwO015Jm5ic3A7cXVlc3Rpb24mbmJzcDt3YXMNCjxicj53aGV0aGVyJm5ic3A7aXQmbmJzcDtp cyZuYnNwO3N1cHBvcnRlZCZuYnNwO2luJm5ic3A7ZHJhZnQtaWV0Zi1taXA2LWJvb3RzdHJhcHBp bmctaW50ZWdyYXRlZC0wMg0KPGJyPmFzJm5ic3A7d2VsbCwmbmJzcDtzaW5jZSZuYnNwO0hvQSZu YnNwO2FsbG9jYXRpb24mbmJzcDtpcyZuYnNwO25vdCZuYnNwO21lbnRpb25lZCZuYnNwO3RoZXJl Lg0KPGJyPg0KPGJyPiZndDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOy0m bmJzcDtJcyZuYnNwO2l0Jm5ic3A7YWxsb3dlZCZuYnNwO3RoYXQmbmJzcDttdWx0aXBsZSZuYnNw O0hBJm5ic3A7YWRkcmVzc2VzJm5ic3A7YXJlJm5ic3A7cmV0dXJuZWQmbmJzcDtpbiZuYnNwO3Ro ZSZuYnNwO2hvbWUmbmJzcDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7bmV0d29y ayZuYnNwO2luZm9ybWF0aW9uJm5ic3A7b3B0aW9uPyZuYnNwOw0KPGJyPiZndDsmbmJzcDsNCjxi cj4mZ3Q7Jm5ic3A7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDtIaW9wdCZn dDsmZ3Q7Jm5ic3A7SXQmbmJzcDtpcyZuYnNwO2FsbG93ZWQmbmJzcDtieSZuYnNwO3VzaW5nJm5i c3A7bXVsdGlwbGUmbmJzcDtob21lJm5ic3A7bmV0d29yayZuYnNwOw0KPGJyPiZndDsmbmJzcDtp bmZvcm1hdGlvbiZuYnNwO29wdGlvbi4NCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZxdW90O011bHRpcGxlJm5ic3A7c3ViLW9wdGlvbnMmbmJzcDttYXkmbmJzcDtl eGlzdCZuYnNwO2luJm5ic3A7YSZuYnNwO0hvbWUmbmJzcDtOZXR3b3JrJm5ic3A7SW5mb3JtYXRp b24mbmJzcDtvcHRpb24NCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO3RvJm5ic3A7Y2FycnkmbmJzcDttb3JlJm5ic3A7dGhhbiZuYnNwO29uZSZuYnNwO2hv bWUmbmJzcDtpbmZvcm1hdGlvbi4mcXVvdDsmbmJzcDsoaW4mbmJzcDtzZWN0aW9uJm5ic3A7My4z LjEpDQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7LSZuYnNw O1tISU9QVF0mbmJzcDthbGxvd3MmbmJzcDt0aGF0Jm5ic3A7dGhlJm5ic3A7aG9tZSZuYnNwO25l dHdvcmsmbmJzcDtpZGVudGlmaWVyJm5ic3A7b3B0aW9uJm5ic3A7aW5jbHVkZXMmbmJzcDthbiZu YnNwOyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDtpZGVudGlmaWVyJm5ic3A7b2Ym bmJzcDthJm5ic3A7dGFyZ2V0Jm5ic3A7bmV0d29yaywmbmJzcDt3aGljaCZuYnNwO2lzJm5ic3A7 ZGlmZmVyZW50Jm5ic3A7ZnJvbSZuYnNwO2hvbWUmbmJzcDtvciZuYnNwOyZuYnNwOw0KPGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDt2aXNpdGVkJm5ic3A7bmV0d29yayZuYnNwO29mJm5ic3A7TU4u Jm5ic3A7VGhpcyZuYnNwO2lzJm5ic3A7bm90Jm5ic3A7bWVudGlvbmVkJm5ic3A7aW4mbmJzcDsm bmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZHJhZnQtaWV0Zi1taXA2LWJvb3RzdHJh cHBpbmctaW50ZWdyYXRlZC0wMi4mbmJzcDtJcyZuYnNwO3RoaXMmbmJzcDthbGxvd2VkJm5ic3A7 b3ImbmJzcDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Zm9yYmlkZGVuPyZuYnNw Ow0KPGJyPiZndDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOw0K PGJyPiZndDsmbmJzcDtIaW9wdCZndDsmZ3Q7Jm5ic3A7QSZuYnNwO3RhcmdldCZuYnNwO25ldHdv cmsmbmJzcDttYXkmbmJzcDtvciZuYnNwO21heSZuYnNwO25vdCZuYnNwO2JlJm5ic3A7aG9tZSZu YnNwO25ldHdvcmsmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO01OLiZuYnNwOyZuYnNwOw0KPGJyPg0K PGJyPmdvb2QuJm5ic3A7SSZuYnNwO2d1ZXNzJm5ic3A7JnF1b3Q7aG9tZSZuYnNwO25ldHdvcmsm cXVvdDsmbmJzcDttZWFucyZuYnNwOyZxdW90O2hvbWUmbmJzcDtNU1AmcXVvdDsmbmJzcDtpbiZu YnNwO3RoaXMmbmJzcDtjYXNlLCZuYnNwO3JpZ2h0Pw0KPGJyPkFjY29yZGluZyZuYnNwO3RvJm5i c3A7UkZDNDY0MCwmbmJzcDt0aGUmbmJzcDsmcXVvdDtob21lJm5ic3A7TVNQJnF1b3Q7Jm5ic3A7 aXMmbmJzcDtNTiYjMzk7cyZuYnNwO01TQSZuYnNwO3Byb3ZpZGluZyZuYnNwO21vYmlsaXR5DQo8 YnI+c2VydmljZSZuYnNwO3RvJm5ic3A7TU4uJm5ic3A7DQo8YnI+QWNjb3JkaW5nJm5ic3A7dG8m bmJzcDtLdW50YWwmIzM5O3MmbmJzcDtjb21tZW50LCZuYnNwO2Fsc28mbmJzcDtNU1BzJm5ic3A7 b3RoZXImbmJzcDt0aGFuJm5ic3A7TVNBJm5ic3A7KG9yJm5ic3A7JnF1b3Q7aG9tZSZuYnNwO01T UCZxdW90OykNCjxicj5hbmQmbmJzcDtBU1AmbmJzcDthcmUmbmJzcDtzdXBwb3J0ZWQmbmJzcDth cyZuYnNwO3RhcmdldCZuYnNwO25ldHdvcmtzLiZuYnNwO0lmJm5ic3A7dGhpcyZuYnNwO2lzJm5i c3A7dHJ1ZSZuYnNwO2ZvciZuYnNwO2hpb3B0Jm5ic3A7KGFuZA0KPGJyPml0Jm5ic3A7c2hvdWxk Jm5ic3A7YmUmbmJzcDtpZiZuYnNwO2l0Jm5ic3A7aXMmbmJzcDt0cnVlJm5ic3A7Zm9yDQo8YnI+ ZHJhZnQtaWV0Zi1taXA2LWJvb3RzdHJhcHBpbmctaW50ZWdyYXRlZC0wMiksJm5ic3A7dGhlbiZu YnNwO2l0Jm5ic3A7c2VlbXMmbmJzcDt0aGF0Jm5ic3A7dGhlDQo8YnI+aGlvcHQmbmJzcDtkcmFm dCZuYnNwO2Fsc28mbmJzcDt1c2VzJm5ic3A7dGhlJm5ic3A7dGVybSZuYnNwOyZxdW90O2hvbWUm bmJzcDtNU1AmcXVvdDsmbmJzcDtkaWZmZXJlbnRseSZuYnNwO3RoYW4mbmJzcDtkZWZpbmVkJm5i c3A7aW4NCjxicj5SRkM0NjQwLiZuYnNwO0ZvciZuYnNwO2luc3RhbmNlLCZuYnNwO3NlY3Rpb24m bmJzcDs0LjMsJm5ic3A7Y2FzZSZuYnNwO0MmbmJzcDsoaWQtdHlwZSZuYnNwOzIpJm5ic3A7c2F5 cyZuYnNwOw0KPGJyPg0KPGJyPiZxdW90O0luJm5ic3A7Y2FzZSZuYnNwO3RoZSZuYnNwO3NlcnZl ciZuYnNwO2Nhbm5vdCZuYnNwO25vdCZuYnNwO2ZpbmQmbmJzcDthbnkmbmJzcDtob21lJm5ic3A7 aW5mb3JtYXRpb24mbmJzcDtuZWl0aGVyJm5ic3A7Zm9yDQo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 dGhlJm5ic3A7bG9jYWwmbmJzcDtuZXR3b3JrJm5ic3A7bm9yJm5ic3A7Zm9yJm5ic3A7dGhlJm5i c3A7KmhvbWUmbmJzcDtNU1AqLCZuYnNwO2l0Jm5ic3A7TVVTVCZuYnNwO3JldHVybiZuYnNwO2Em bmJzcDtIb21lDQo8YnI+TmV0d29yaw0KPGJyPiZuYnNwOyZuYnNwOyZuYnNwO0luZm9ybWF0aW9u Jm5ic3A7b3B0aW9uJm5ic3A7d2l0aCZuYnNwO3RoZSZuYnNwOzAtbGVuZ3RoJm5ic3A7ZGF0YS4m cXVvdDsNCjxicj4NCjxicj5UaGlzJm5ic3A7d291bGQmbmJzcDtyZXN0cmljdCZuYnNwO0hBL0hv QSZuYnNwO2FsbG9jYXRpb24mbmJzcDtmcm9tJm5ic3A7QVNQJm5ic3A7YW5kJm5ic3A7TVNBJm5i c3A7KD1ob21lJm5ic3A7TVNQKS4mbmJzcDtJDQo8YnI+Z3Vlc3MmbmJzcDt5b3UmbmJzcDthbHNv Jm5ic3A7d2FudCZuYnNwO3RvJm5ic3A7c3VwcG9ydCZuYnNwO2FsbG9jYXRpb24mbmJzcDtmcm9t Jm5ic3A7TVNQcyZuYnNwO290aGVyJm5ic3A7dGhhbiZuYnNwO0FTUCZuYnNwO2FuZA0KPGJyPk1T QSwmbmJzcDtubz8mbmJzcDtTbyZuYnNwO3Nob3VsZG4mIzM5O3QmbmJzcDsmcXVvdDtob21lJm5i c3A7TVNQJnF1b3Q7Jm5ic3A7YmUmbmJzcDtyZXBsYWNlZCZuYnNwO2J5Jm5ic3A7JnF1b3Q7YW55 Jm5ic3A7b3RoZXImbmJzcDtNU1AmbmJzcDt3aXRoDQo8YnI+cm9hbWluZyZuYnNwO3JlbGF0aW9u c2hpcCZuYnNwO3RvJm5ic3A7TU4mIzM5O3MmbmJzcDtNU0EmcXVvdDs/DQo8YnI+DQo8YnI+U2Ft ZSZuYnNwO2ZvciZuYnNwO2lkLXR5cGUmbmJzcDsxOiZuYnNwO3NlY3Rpb24mbmJzcDszLjEmbmJz cDtzYXlzJm5ic3A7DQo8YnI+DQo8YnI+DQo8YnI+JnF1b3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aWQtdHlwZQ0KPGJyPg0KPGJy PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSZuYnNwO3R5cGUmbmJzcDtvZiZuYnNwO0hvbWUmbmJz cDtOZXR3b3JrJm5ic3A7SWRlbnRpZmllcjoNCjxicj4NCjxicj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDswJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7VmlzaXRlZCZuYnNwO2RvbWFpbiZuYnNwOyhsb2NhbCZuYnNwO0FT UCkNCjxicj4NCjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SG9tZSZu YnNwO2RvbWFpbiZuYnNwOyhob21lJm5ic3A7TVNQKQ0KPGJyPi4uLi4NCjxicj4mbmJzcDsmbmJz cDsmbmJzcDtJZC10eXBlJm5ic3A7MSZuYnNwO2luZGljYXRlcyZuYnNwO3RoZSZuYnNwO21vYmls ZSZuYnNwO25vZGUmbmJzcDtpcyZuYnNwO2ludGVyZXN0ZWQmbmJzcDtpbiZuYnNwO2xlYXJuaW5n Jm5ic3A7dGhlDQo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7aG9tZSZuYnNwO25ldHdvcmsmbmJzcDtp bmZvcm1hdGlvbiZuYnNwO3RoYXQmbmJzcDtwZXJ0YWlucyZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7 Z2l2ZW4mbmJzcDtyZWFsbS4mbmJzcDsmbmJzcDtUaGlzJm5ic3A7dHlwZQ0KPGJyPiZuYnNwOyZu YnNwOyZuYnNwO2NhbiZuYnNwO2JlJm5ic3A7dXNlZCZuYnNwO3RvJm5ic3A7ZGlzY292ZXImbmJz cDtob21lJm5ic3A7YWdlbnRzJm5ic3A7dGhhdCZuYnNwO2FyZSZuYnNwO2hvc3RlZCZuYnNwO2J5 Jm5ic3A7YSZuYnNwO3VzZXImIzM5O3MmbmJzcDtob21lDQo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ZG9tYWluJm5ic3A7KGFzJm5ic3A7aW5kaWNhdGVkJm5ic3A7YnkmbmJzcDtoaXMvaGVyJm5ic3A7 TkFJLWJhc2VkJm5ic3A7dXNlcm5hbWUmbmJzcDstLSZuYnNwO3VzZXJADQo8YnI+Jm5ic3A7Jm5i c3A7Jm5ic3A7SG9tZVJlYWxtKS4mbmJzcDsmbmJzcDtUaGUmbmJzcDtIb21lJm5ic3A7TmV0d29y ayZuYnNwO0lkZW50aWZpZXImbmJzcDtmaWVsZCZuYnNwO01VU1QmbmJzcDtiZSZuYnNwO3NldCZu YnNwO3RvJm5ic3A7dGhlDQo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7dGFyZ2V0Jm5ic3A7aG9tZSZu YnNwO01TUC4mbmJzcDsmbmJzcDsmcXVvdDsNCjxicj4NCjxicj5UaGlzJm5ic3A7dGV4dCZuYnNw O2ltcGxpZXMmbmJzcDt0aGF0Jm5ic3A7SEEvSG9BJm5ic3A7YWxsb2NhdGlvbiZuYnNwO2Zyb20m bmJzcDtvdGhlciZuYnNwO01TUHMmbmJzcDt0aGFuJm5ic3A7aG9tZSZuYnNwO01TUA0KPGJyPih3 aGljaCZuYnNwO2lzJm5ic3A7ZXF1YWwmbmJzcDt0byZuYnNwO01TQSkmbmJzcDtpcyZuYnNwO25v dCZuYnNwO3N1cHBvcnRlZCZuYnNwO3dpdGgmbmJzcDtpZC10eXBlJm5ic3A7MSwmbmJzcDtldmVu Jm5ic3A7aWYmbmJzcDt0aG9zZQ0KPGJyPk1TUHMmbmJzcDtoYXZlJm5ic3A7YSZuYnNwO3JvYW1p bmcmbmJzcDtyZWxhdGlvbnNoaXAmbmJzcDt3aXRoJm5ic3A7dGhlJm5ic3A7TU4mIzM5O3MmbmJz cDtNU0EuJm5ic3A7SXMmbmJzcDt0aGlzJm5ic3A7dHJ1ZT8mbmJzcDsNCjxicj4NCjxicj5SZWdh cmRzLA0KPGJyPg0KPGJyPktpbGlhbg0KPGJyPg0KPGJyPiZndDsmbmJzcDsNCjxicj4mZ3Q7Jm5i c3A7SW4mbmJzcDtjdXJyZW50Jm5ic3A7ZHJhZnQsJm5ic3A7dGhlJm5ic3A7c2VydmVyJm5ic3A7 aXMmbmJzcDtzdXBwb3NlZCZuYnNwO3RvJm5ic3A7cHJvdmlkZSZuYnNwO3RoZSZuYnNwO0hBJm5i c3A7DQo8YnI+Jmd0OyZuYnNwO2luZm9ybWF0aW9uJm5ic3A7aWYmbmJzcDtpdCZuYnNwO2hhcw0K PGJyPiZndDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7dGhlJm5ic3A7Y29ycmVzcG9uZGluZyZuYnNw O2luZm9ybWF0aW9uLiZuYnNwO0lmJm5ic3A7dGhlJm5ic3A7Z2l2ZW4mbmJzcDtIQSZuYnNwO2Rv ZXMmbmJzcDtub3QmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7ZnVuY3Rpb24mbmJzcDthcyZuYnNwO0hB Jm5ic3A7Zm9yDQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDt0aGUmbmJzcDtyZXF1ZXN0 aW5nJm5ic3A7TU4sJm5ic3A7aXQmbmJzcDt3aWxsJm5ic3A7cmVwbHkmbmJzcDt3aXRoJm5ic3A7 dGhlJm5ic3A7QkEmbmJzcDtzdGF0dXMmbmJzcDs9Jm5ic3A7MTMyJm5ic3A7b3ImbmJzcDsxMzMm bmJzcDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyhOb3QmbmJzcDtob21l Jm5ic3A7c3VibmV0Jm5ic3A7LyZuYnNwO2hvbWUmbmJzcDthZ2VudCZuYnNwO2ZvciZuYnNwO3Ro aXMmbmJzcDttb2JpbGUmbmJzcDtub2RlKSZuYnNwO2R1cmluZyZuYnNwOw0KPGJyPiZndDsmbmJz cDtNTiYjMzk7cyZuYnNwO3JlZ2lzdHJhdGlvbi4NCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZu YnNwOw0KPGJyPiZndDsmbmJzcDstJm5ic3A7V2hpY2gmbmJzcDtIQSZuYnNwO2luZm9ybWF0aW9u Jm5ic3A7c2hvdWxkJm5ic3A7dGhlJm5ic3A7TU4mbmJzcDt1c2UmbmJzcDtpZiZuYnNwO2l0Jm5i c3A7cmVjZWl2ZXMsJm5ic3A7DQo8YnI+Jmd0OyZuYnNwO2UuZy4sJm5ic3A7YW4mbmJzcDtGUURO Jm5ic3A7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwO2FuZCZuYnNwO2EmbmJzcDtI QSZuYnNwO2FkZHJlc3MmbmJzcDtpbiZuYnNwO0RIQ1AmbmJzcDtyZXBseT8mbmJzcDtbSElPUFRd Jm5ic3A7cmVmZXJzJm5ic3A7dG8mbmJzcDtzZWN0aW9uJm5ic3A7My42Jm5ic3A7b2YmbmJzcDsm bmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZHJhZnQtaWV0Zi1taXA2LWJvb3RzdHJh cHBpbmctaW50ZWdyYXRlZC0wMSwmbmJzcDtidXQmbmJzcDt0aGlzJm5ic3A7DQo8YnI+Jmd0OyZu YnNwO3NlY3Rpb24mbmJzcDtkb2VzbiYjMzk7dCZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJzcDsm bmJzcDtleGlzdCZuYnNwO2luJm5ic3A7ZHJhZnQtaWV0Zi1taXA2LWJvb3RzdHJhcHBpbmctaW50 ZWdyYXRlZC0wMiZuYnNwO2FueW1vcmUuLi4mbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0 OyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZu YnNwO0hpb3B0Jmd0OyZndDsmbmJzcDtJdCZuYnNwO2lzJm5ic3A7d2l0aGluJm5ic3A7dGhlJm5i c3A7TU4mIzM5O3MmbmJzcDtvd24mbmJzcDtkaXNjcmV0aW9uJm5ic3A7YXMmbmJzcDtmb2xsb3dz LiZuYnNwOw0KPGJyPiZndDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7SSZuYnNwO2RvbiYjMzk7dCZu YnNwO3RoaW5rJm5ic3A7aXQmbmJzcDtzaG91bGQmbmJzcDtiZSZuYnNwO3N0YW5kYXJkaXplZCZu YnNwO2luJm5ic3A7SElPUFQmbmJzcDtkb2N1bWVudC4mbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7DQo8 YnI+Jmd0OyZuYnNwOyZxdW90O0ZvciZuYnNwO2V4YW1wbGUsJm5ic3A7aWYmbmJzcDt0aGUmbmJz cDttb2JpbGUmbmJzcDtub2RlJm5ic3A7YWNxdWlyZXMmbmJzcDtib3RoJm5ic3A7SVB2NiZuYnNw Ow0KPGJyPiZndDsmbmJzcDthZGRyZXNzKGVzKSZuYnNwO2FuZCZuYnNwO0ZRRE4ocykNCjxicj4m Z3Q7Jm5ic3A7Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtob21lJm5ic3A7YWdlbnRzLCZuYnNwO2l0 Jm5ic3A7bWF5Jm5ic3A7dHJ5Jm5ic3A7dG8mbmJzcDt1c2UmbmJzcDt0aGUmbmJzcDthZGRyZXNz Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwO2luZm9ybWF0aW9uJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDto b21lJm5ic3A7YWdlbnQocykmbmJzcDtmaXJzdC4mcXVvdDsNCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+ Jmd0OyZuYnNwOyZuYnNwOw0KPGJyPiZndDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0 OyZuYnNwO1NvbWUmbmJzcDtvdGhlciZuYnNwO2NvbW1lbnRzOiZuYnNwOw0KPGJyPiZndDsmbmJz cDsNCjxicj4mZ3Q7Jm5ic3A7LSZuYnNwO0l0Jm5ic3A7d291bGQmbmJzcDtiZSZuYnNwO2dvb2Qm bmJzcDt0byZuYnNwO2hhdmUmbmJzcDthJm5ic3A7c2VjdGlvbiwmbmJzcDt3aGljaCZuYnNwO2V4 cGxpY2l0bHkmbmJzcDtzdGF0ZXMmbmJzcDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7YXNzdW1wdGlvbnMmbmJzcDthbmQmbmJzcDthcHBsaWNhYmlsaXR5Jm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtwcm90b2NvbC4mbmJzcDtUaGlzJm5ic3A7c2hvdWxkJm5ic3A7aW5jbHVkZTombmJz cDsNCjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LSZuYnNwO01TQSZuYnNw O2FuZCZuYnNwO0FTQSZuYnNwO211c3QmbmJzcDtiZSZuYnNwO2NvLWxvY2F0ZWQmbmJzcDsoaS5l LiwmbmJzcDtpbnRlZ3JhdGVkJm5ic3A7c2NlbmFyaW8pJm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0mbmJzcDtBQUEmbmJzcDtpbmZyYXN0cnVjdHVyZSZuYnNw O2Fzc3VtZWQmbmJzcDthbmQmbmJzcDtzb21lJm5ic3A7a2luZCZuYnNwO29mJm5ic3A7cm9hbWlu ZyZuYnNwOyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtyZWxhdGlvbnNoaXAmbmJzcDtiZXR3ZWVuJm5ic3A7QVNQJm5i c3A7YW5kJm5ic3A7TVNBL0FTQSZuYnNwO2lzJm5ic3A7cmVxdWlyZWQmbmJzcDsNCjxicj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LSZuYnNwO01TUCZuYnNwO2lzJm5ic3A7ZWl0 aGVyJm5ic3A7Y28tbG9jYXRlZCZuYnNwO3dpdGgmbmJzcDtBU1AmbmJzcDtvciZuYnNwO01TQSZu YnNwO29yJm5ic3A7Ym90aCZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsoT3ImbmJzcDthcmUmbmJzcDtvdGhlciZuYnNw O3RhcmdldCZuYnNwO25ldHdvcmtzJm5ic3A7YWxsb3dlZDsmbmJzcDtzZWUmbmJzcDthYm92ZSk/ Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0mbmJzcDtESENQ Jm5ic3A7cmVsYXkmbmJzcDthbmQmbmJzcDtOQVMmbmJzcDttdXN0Jm5ic3A7YmUmbmJzcDtjby1s b2NhdGVkJm5ic3A7DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDstJm5ic3A7QXQmbmJz cDtzb21lJm5ic3A7cGxhY2VzJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDt0ZXh0Jm5ic3A7dGhlJm5i c3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDt0ZXJtJm5ic3A7JnF1b3Q7TVNQJnF1b3Q7Jm5i c3A7aXMmbmJzcDthbWJpZ3VvdXMsJm5ic3A7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwO3NpbmNlJm5ic3A7TVNQJm5ic3A7Y2FuJm5ic3A7cmVmZXImbmJzcDt0byZuYnNwO2F0Jm5i c3A7bGVhc3QmbmJzcDtob21lJm5ic3A7YW5kJm5ic3A7dmlzaXRlZCZuYnNwO25ldHdvcmsuJm5i c3A7QmV0dGVyJm5ic3A7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwO3VzZSZuYnNw OyZxdW90O2hvbWUmbmJzcDtNU1AmcXVvdDsmbmJzcDtmb3ImbmJzcDtNU1AmbmJzcDtpbiZuYnNw O2hvbWUmbmJzcDtuZXR3b3JrLiZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDstJm5ic3A7ZS5nLiwmbmJzcDtzZWN0aW9uJm5ic3A7My4xOiZuYnNwOw0KPGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVvdDtOb3RlJm5ic3A7dGhhdCZuYnNwO2EmbmJzcDtob21l Jm5ic3A7YWdlbnQmbmJzcDtmb3ImbmJzcDt1c2FnZSZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDt3aXRoJm5ic3A7dGhlJm5ic3A7bW9iaWxlJm5ic3A7bm9kZSZuYnNwO21p Z2h0Jm5ic3A7YmUmbmJzcDtzZWxlY3RlZCZuYnNwO2luJm5ic3A7dGhlJm5ic3A7YWNjZXNzJm5i c3A7c2VydmljZSZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwcm92aWRl ciYjMzk7cyZuYnNwO25ldHdvcmsmbmJzcDtvciZuYnNwO2FsdGVybmF0aXZlbHkmbmJzcDtpbiZu YnNwO3RoZSZuYnNwOypob21lKiZuYnNwO21vYmlsaXR5Jm5ic3A7c2VydmljZSZuYnNwOw0KPGJy PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwcm92aWRlciYjMzk7cyZuYnNwO25ldHdvcmsu JnF1b3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0mbmJz cDtvciZuYnNwO2luJm5ic3A7c2VjdGlvbiZuYnNwOzMuMjombmJzcDsNCjxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7JnF1b3Q7VGhlJm5ic3A7bWVzc2FnZSZuYnNwO2Zsb3dzJm5ic3A7Zm9yJm5i c3A7aG9tZSZuYnNwO2FnZW50Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O2FsbG9jYXRpb24mbmJzcDtpbiZuYnNwO3RoZSZuYnNwO0FTUCZuYnNwO2FuZCZuYnNwO3RoZSZu YnNwOypob21lKiZuYnNwO01TUCZuYnNwO2FyZSZuYnNwO2lsbHVzdHJhdGVkJm5ic3A7YmVsb3cu Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Oy0mbmJzcDtvciZuYnNwO2luJm5ic3A7c2VjdGlvbiZuYnNwOzMuMi4xOiZuYnNwOw0KPGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVvdDszLjIuMS4mbmJzcDsmbmJzcDtIb21lJm5ic3A7QWdl bnQmbmJzcDthbGxvY2F0aW9uJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDsqaG9tZSombmJzcDtNU1Am cXVvdDssJm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90Oyg0KS4uLiZuYnNw O21vYmlsZSZuYnNwO25vZGUmbmJzcDtpcyZuYnNwO3JlcXVlc3RpbmcmbmJzcDtob21lJm5ic3A7 YWdlbnQmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2luJm5ic3A7dGhlJm5ic3A7Jm5ic3A7DQo8YnI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOypob21lKiZuYnNwO01TUC4uLiZxdW90OyZuYnNwOw0KPGJy PiZndDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7LSZuYnNwO1NlY3Rpb24mbmJzcDszLjMmbmJzcDtj dXJyZW50bHkmbmJzcDttZW50aW9ucyZuYnNwO0ROUy1iYXNlZCZuYnNwO0hBJm5ic3A7YWRkcmVz cyZuYnNwOw0KPGJyPiZndDsmbmJzcDtkaXNjb3ZlcnkmbmJzcDttZXRob2QmbmJzcDsNCjxicj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7b25seSwmbmJzcDtidXQmbmJzcDtbQk9PVC1TUExJVF0mbmJz cDthbHNvJm5ic3A7c3BlY2lmaWVzJm5ic3A7YW4mbmJzcDthbnljYXN0LWJhc2VkJm5ic3A7SEEm bmJzcDthZGRyZXNzJm5ic3A7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwO2Rpc2Nv dmVyeSZuYnNwO21ldGhvZC4mbmJzcDtFaXRoZXImbmJzcDtib3RoJm5ic3A7b3ImbmJzcDtub25l Jm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDttZW50aW9uZWQuJm5ic3A7DQo8YnI+Jmd0OyZuYnNw Ow0KPGJyPiZndDsmbmJzcDstJm5ic3A7VGhlJm5ic3A7dGl0bGUmbmJzcDtvZiZuYnNwO2RyYWZ0 LWlldGYtbWlwNi1ib290c3RyYXBwaW5nLWludGVncmF0ZWQtMDImbmJzcDtjYW4mbmJzcDtjYXVz ZSZuYnNwOyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUmbmJzcDtpbXByZXNz aW9uJm5ic3A7dGhhdCZuYnNwO3RoZSZuYnNwO2RyYWZ0Jm5ic3A7ZGVmaW5lcyZuYnNwO2EmbmJz cDtjb21wbGV0ZSZuYnNwO2Jvb3RzdHJhcHBpbmcmbmJzcDsmbmJzcDsmbmJzcDsNCjxicj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7cHJvY2VkdXJlLiZuYnNwO0J1dCZuYnNwO2RyYWZ0LWlldGYtbWlw Ni1ib290c3RyYXBwaW5nLWludGVncmF0ZWQtMDImbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7ZGVmaW5l cyZuYnNwO2EmbmJzcDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7bWV0aG9kJm5i c3A7Zm9yJm5ic3A7SEEmbmJzcDthZGRyZXNzJm5ic3A7YXNzaWdubWVudCZuYnNwO29ubHkuJm5i c3A7SSZuYnNwO3RoaW5rJm5ic3A7dGhpcyZuYnNwO2lzJm5ic3A7bWlzbGVhZGluZy4mbmJzcDsm bmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7V2h5Jm5ic3A7bm90Jm5ic3A7bmFtZSZu YnNwO3RoZSZuYnNwO2RyYWZ0Jm5ic3A7YWNjb3JkaW5nJm5ic3A7dG8mbmJzcDt3aGF0Jm5ic3A7 aXQmbmJzcDtzcGVjaWZpZXMmbmJzcDsoZS5nLiwmbmJzcDsmcXVvdDtIQSZuYnNwOyZuYnNwOw0K PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDthZGRyZXNzJm5ic3A7YXNzaWdubWVudCZuYnNwO3Vz aW5nJm5ic3A7REhDUCZuYnNwO2FuZCZuYnNwO0FBQSZxdW90OyZuYnNwO29yJm5ic3A7JnF1b3Q7 SEEmbmJzcDthZGRyZXNzJm5ic3A7DQo8YnI+Jmd0OyZuYnNwO2Fzc2lnbm1lbnQmbmJzcDtmb3Im bmJzcDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlJm5ic3A7aW50ZWdyYXRl ZCZuYnNwO3NjZW5hcmlvJm5ic3A7dXNpbmcmbmJzcDtESENQJm5ic3A7YW5kJm5ic3A7QUFBJnF1 b3Q7Jm5ic3A7aW5zdGVhZCZuYnNwO29mJm5ic3A7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZxdW90O01JUDYtYm9vdHN0cmFwcGluZyZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO2lu dGVncmF0ZWQmbmJzcDtzY2VuYXJpbyZxdW90Oyk/Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOw0KPGJy PiZndDsmbmJzcDtSZWdhcmRzLCZuYnNwOw0KPGJyPiZndDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7 S2lsaWFuJm5ic3A7DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7LS0t LS1PcmlnaW5hbCZuYnNwO01lc3NhZ2UtLS0tLSZuYnNwOw0KPGJyPiZndDsmbmJzcDsmZ3Q7Jm5i c3A7RnJvbTombmJzcDtCYXNhdmFyYWombmJzcDtQYXRpbCZuYnNwO1ttYWlsdG86YmFzYXZhcmFq LnBhdGlsQG5va2lhLmNvbV0mbmJzcDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO1Nl bnQ6Jm5ic3A7TWl0dHdvY2gsJm5ic3A7MTQuJm5ic3A7RmVicnVhciZuYnNwOzIwMDcmbmJzcDsx OToxMCZuYnNwOw0KPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7VG86Jm5ic3A7bWlwNkBpZXRmLm9y ZyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7U3ViamVjdDombmJzcDtbTWlwNl0mbmJz cDtXR0xDOiZuYnNwO2RyYWZ0LWlldGYtbWlwNi1ib290c3RyYXBwaW5nLWludGVncmF0ZWQtMDIm bmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmZ3Q7 Jm5ic3A7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDtIZWxsbywmbmJzcDsNCjxicj4m Z3Q7Jm5ic3A7Jmd0OyZuYnNwOyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7VGhpcyZu YnNwO2lzJm5ic3A7YSZuYnNwO01JUDYmbmJzcDtXb3JraW5nJm5ic3A7Z3JvdXAmbmJzcDtsYXN0 Jm5ic3A7Y2FsbCZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO1dHJm5ic3A7SS1EOiZuYnNwOw0KPGJy PiZndDsmbmJzcDsmZ3Q7Jm5ic3A7JnF1b3Q7TUlQNi1ib290c3RyYXBwaW5nJm5ic3A7Zm9yJm5i c3A7dGhlJm5ic3A7SW50ZWdyYXRlZCZuYnNwO1NjZW5hcmlvJnF1b3Q7LCZuYnNwOw0KPGJyPiZn dDsmbmJzcDsmZ3Q7Jm5ic3A7ZHJhZnQtaWV0Zi1taXA2LWJvb3RzdHJhcHBpbmctaW50ZWdyYXRl ZC0wMi50eHQmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOyZuYnNwOw0KPGJyPiZndDsm bmJzcDsmZ3Q7Jm5ic3A7SS1EOiZuYnNwOyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7 aHR0cDovL2lldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1pcDYtYm9vdHN0cmFw cGluZy0mbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO2ludGVncmF0ZWQtZGhjJm5ic3A7 DQo8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDstMDIudHh0Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZn dDsmbmJzcDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO1BsZWFzZSZuYnNwO3Jldmll dyZuYnNwO2FuZCZuYnNwO3N1Ym1pdCZuYnNwO3lvdXImbmJzcDtjb21tZW50cyZuYnNwO3RvJm5i c3A7dGhlJm5ic3A7YXV0aG9ycyZuYnNwO29yJm5ic3A7DQo8YnI+Jmd0OyZuYnNwO3RoZSZuYnNw O21haWxpbmcmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO2xpc3QuJm5ic3A7VGhlJm5i c3A7V0dMQyZuYnNwO3dpbGwmbmJzcDtleHBpcmUmbmJzcDtvbiZuYnNwO01hcmNoJm5ic3A7MXN0 LCZuYnNwOzA3LiZuYnNwOw0KPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jm5ic3A7DQo8YnI+Jmd0 OyZuYnNwOyZndDsmbmJzcDstQ2hhaXJzJm5ic3A7DQo8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDsm bmJzcDsNCjxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOyZuYnNwOw0KPGJyPiZndDsmbmJzcDsmZ3Q7 Jm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18mbmJz cDsNCjxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO01pcDYmbmJzcDttYWlsaW5nJm5ic3A7bGlzdCZu YnNwOw0KPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7TWlwNkBpZXRmLm9yZyZuYnNwOw0KPGJyPiZn dDsmbmJzcDsmZ3Q7Jm5ic3A7aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bWlwNiZuYnNwOw0KPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNw OyZndDsmbmJzcDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZn dDsmbmJzcDtQYW5hc29uaWMmbmJzcDtSJmFtcDtEJm5ic3A7Q2VudGVyJm5ic3A7R2VybWFueSZu YnNwO0dtYkgmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7NjMyMjUmbmJzcDtMYW5nZW4sJm5ic3A7SGVz c2VuLCZuYnNwO0dlcm1hbnkmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7UmVnOiZuYnNwO0FHJm5ic3A7 T2ZmZW5iYWNoJm5ic3A7KEhlc3NlbikmbmJzcDtIUkImbmJzcDszMzk3NCZuYnNwOw0KPGJyPiZn dDsmbmJzcDtNYW5hZ2luZyZuYnNwO0RpcmVjdG9yOiZuYnNwO1Rob21hcyZuYnNwO01pY2tlJm5i c3A7DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+ Jmd0OyZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwO01pcDYmbmJzcDttYWlsaW5nJm5ic3A7bGlzdCZuYnNwOw0K PGJyPiZndDsmbmJzcDtNaXA2QGlldGYub3JnJm5ic3A7DQo8YnI+Jmd0OyZuYnNwO2h0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pcDYmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7 DQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDsNCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0 OyZuYnNwOw0KPGJyPg0KPGJyPg0KPGJyPlBhbmFzb25pYyZuYnNwO1ImYW1wO0QmbmJzcDtDZW50 ZXImbmJzcDtHZXJtYW55Jm5ic3A7R21iSA0KPGJyPjYzMjI1Jm5ic3A7TGFuZ2VuLCZuYnNwO0hl c3NlbiwmbmJzcDtHZXJtYW55DQo8YnI+UmVnOiZuYnNwO0FHJm5ic3A7T2ZmZW5iYWNoJm5ic3A7 KEhlc3NlbikmbmJzcDtIUkImbmJzcDszMzk3NA0KPGJyPk1hbmFnaW5nJm5ic3A7RGlyZWN0b3I6 Jm5ic3A7VGhvbWFzJm5ic3A7TWlja2UNCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj48L3A+ DQo8L0JPRFk+PC9IVE1MPg== --===============1885375848== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1885375848==-- From mip6-bounces@ietf.org Sun Feb 25 22:08:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLWCw-0005jl-Tw; Sun, 25 Feb 2007 22:07:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLWCv-0005jc-Fq for mip6@ietf.org; Sun, 25 Feb 2007 22:07:21 -0500 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLWCr-0001nY-C8 for mip6@ietf.org; Sun, 25 Feb 2007 22:07:21 -0500 Received: from PC20005 ([124.191.178.123]) by omta05ps.mx.bigpond.com with ESMTP id <20070226030713.OARH19269.omta05ps.mx.bigpond.com@PC20005> for ; Mon, 26 Feb 2007 03:07:13 +0000 From: "Hesham Soliman" To: "'Mobile IPv6 Mailing List'" Date: Mon, 26 Feb 2007 14:07:09 +1100 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: AcdZUzO7RDE7DPKoQVCVJFNJXgP5xA== x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070226030713.OARH19269.omta05ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: [Mip6] Issue 73: v4 mapped address in IPv6 header X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Folks, This is the final issue listed on the tracker. This one is a bit long. Issue Text: ----------- the IPv4 mapped address has a special meaning by RFC 2553 API. It is not preferable to use the mapped address in IPv6 headers (See the following the drafts) draft-itojun-v6ops-v4mapped-harmful draft-cmetz-v6ops-v4mapped-api-harmful In our code based on KAME, the IPv6 implementation discard a IPv6 header which has the v4 mapped address for sanity at ip6_input() and ip6_rthadr2(). We also need to add the mapped address in an address list (the list of all addresses which the node has) to receive the header. This is somehow uncomfortable because the mapped address is actually not routable. >From Hesham: => No one suggested that it should/would be routable. It's simply used to keep the packet format. There is no routing based on this information. >From Koshiro: => I am not sure whether it's just an implementation issues. But putting the mapped address in the address list in order to process the DSMIP IPv6 header means the mapped address may be chosen as a source address even the address is actually not routable. To avoid this, we need e.g. an additional flag to distinguish the mapped address from others. I think some implementers will not accept this. The above is not only the reason again the mapped address in the IPv6 header. Please refer the draft-*-harmful. So, my idea is to put HoA in IPv6 header and kind of IPv4 CoA option to idicate it's IPv4 CoA. BTW, if you just want to keep the packer format, I think it's better to use compatible address, or 6to4 address, or newly-defined address for this purpose. Analysis: --------- The resons listed in the issue text (and other reasons discussed in the DT) as well as their rebuttal are listed in this section. The first reason for using a different address format was that the use of mapped address was not recommended. The issue text refers to two drafts above. Those two drafts were discussed several years ago in 2002 (first v6ops meeting). The only issue that was agreed on in those drafts was that the mapped address should not be used as a routable address. Therefore, the issue misinterprets the agreement in the community. Also, the mapped address is not used as a routable address in DSMIP. The drafts referred to above did suggest the removal of the v4 mapped address altogether from IPv6, but this suggestion was rejected and the drafts were not adopted. Mapped addresses are supported in all major OSs (with the exception of KAME). The issue text also suggests the use of a different address format (compatible address, 6-to-4, or a new address format). The compatible address format was deprecated from the IPv6 address architecture and the mapped format is the recommended format for embedding IPv4 addresses in IPv6. 6-to-4 addresses imply a specific tunnelling behaviour (tunnelling to the v4 address), which is not useful for our purposes. A new address format will be no different from the mapped address, which is designed for this purpose. Another concern that was raised against the use of the mapped address was that they are "implicit" in nature ad do not explicitly show the IPv4 address. However, IP stacks must check the src address in the packet to insure that is in fact a legal address (e.g. not multicast) in ip6_input. Recommendation: -------------- My recommendation is to reject this issue for several reasons: a. There is no clear problem with the current format, i.e. what breaks? b. We've already removed the alt-CoA option in a previous issue, so if we accept this issue we'd have to introduce a new address format for DSMIP. This can take a long time and will yield the same result. Although, if there is something specific in the mapped address format that will cause problems, and a new address format will solve this problem then I'm personally ok with the new address format. However, we need to understand what that problem is. Regards, Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 26 01:43:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLZYl-00004s-4f; Mon, 26 Feb 2007 01:42:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLZYj-0008WQ-CO for mip6@ietf.org; Mon, 26 Feb 2007 01:42:05 -0500 Received: from mail.sfc.wide.ad.jp ([2001:200:0:8803:203:47ff:fedf:73a6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLZYi-000573-6S for mip6@ietf.org; Mon, 26 Feb 2007 01:42:05 -0500 Received: from [IPv6:2001:200::8801:214:51ff:fe2f:1580] (unknown [IPv6:2001:200:0:8801:214:51ff:fe2f:1580]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 8C4754DA23; Mon, 26 Feb 2007 15:41:46 +0900 (JST) In-Reply-To: <20070226030713.OARH19269.omta05ps.mx.bigpond.com@PC20005> References: <20070226030713.OARH19269.omta05ps.mx.bigpond.com@PC20005> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0D220B8E-A516-461B-A1B0-028CF8FB574B@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Koshiro MITSUYA Subject: Re: [Mip6] Issue 73: v4 mapped address in IPv6 header Date: Mon, 26 Feb 2007 15:42:02 +0900 To: Hesham Soliman X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.8 (--) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: 'Mobile IPv6 Mailing List' , Koshiro MITSUYA X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello Hesham, > Mapped addresses are supported in all major OSs (with the exception > of KAME) Can you please explain what do you mean by "supported"? We can use mapped addresses inside a node with KAME, but KAME rejects a packet which has a mapped address as the source or destination address. regards, Koshiro On 2007/02/26, at 12:07, Hesham Soliman wrote: > > Folks, > > This is the final issue listed on the tracker. This one is a bit long. > > Issue Text: > ----------- > > the IPv4 mapped address has a special meaning by RFC > 2553 API. It is not preferable to use the mapped address in IPv6 > headers (See the following the drafts) > draft-itojun-v6ops-v4mapped-harmful > draft-cmetz-v6ops-v4mapped-api-harmful > > In our code based on KAME, the IPv6 implementation discard a IPv6 > header which has the v4 mapped address for sanity at ip6_input() and > ip6_rthadr2(). We also need to add the mapped address in an address > list (the list of all addresses which the node has) to receive the > header. This is somehow uncomfortable because the mapped address is > actually not routable. > >> From Hesham: > => No one suggested that it should/would be routable. It's simply > used to keep the packet format. There is no routing based on this > information. > >> From Koshiro: > => I am not sure whether it's just an implementation issues. But > putting > the mapped address in the address list in order to process the DSMIP > IPv6 header means the mapped address may be chosen as a source address > even the address is actually not routable. To avoid this, we need > e.g. an additional flag to distinguish the mapped address from others. > I think some implementers will not accept this. > > The above is not only the reason again the mapped address in the IPv6 > header. Please refer the draft-*-harmful. So, my idea is to put HoA > in IPv6 header and kind of IPv4 CoA option to idicate it's IPv4 CoA. > > BTW, if you just want to keep the packer format, I think it's better > to use compatible address, or 6to4 address, or newly-defined address > for this purpose. > > Analysis: > --------- > > The resons listed in the issue text (and other reasons discussed in > the DT) > as well as their rebuttal are listed in this section. The first > reason for > using a different address format was that the use of mapped address > was not > recommended. The issue text refers to two drafts above. Those two > drafts > were discussed several years ago in 2002 (first v6ops meeting). The > only > issue that was agreed on in those drafts was that the mapped > address should > not be used as a routable address. Therefore, the issue > misinterprets the > agreement in the community. Also, the mapped address is not used as a > routable address in DSMIP. The drafts referred to above did suggest > the > removal of the v4 mapped address altogether from IPv6, but this > suggestion > was rejected and the drafts were not adopted. Mapped addresses are > supported > in all major OSs (with the exception of KAME). > > The issue text also suggests the use of a different address format > (compatible address, 6-to-4, or a new address format). The compatible > address format was deprecated from the IPv6 address architecture > and the > mapped format is the recommended format for embedding IPv4 > addresses in > IPv6. 6-to-4 addresses imply a specific tunnelling behaviour > (tunnelling to > the v4 address), which is not useful for our purposes. A new > address format > will be no different from the mapped address, which is designed for > this > purpose. > > Another concern that was raised against the use of the mapped > address was > that they are "implicit" in nature ad do not explicitly show the IPv4 > address. However, IP stacks must check the src address in the > packet to > insure that is in fact a legal address (e.g. not multicast) in > ip6_input. > > > Recommendation: > -------------- > > My recommendation is to reject this issue for several reasons: > a. There is no clear problem with the current format, i.e. what > breaks? > b. We've already removed the alt-CoA option in a previous issue, so > if we > accept this issue we'd have to introduce a new address format for > DSMIP. > This can take a long time and will yield the same result. Although, > if there > is something specific in the mapped address format that will cause > problems, > and a new address format will solve this problem then I'm > personally ok with > the new address format. However, we need to understand what that > problem is. > > > > Regards, > Hesham > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 26 02:14:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLa42-0000ph-QJ; Mon, 26 Feb 2007 02:14:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLa41-0000pC-Jr for mip6@ietf.org; Mon, 26 Feb 2007 02:14:25 -0500 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLa3z-0008WV-Qb for mip6@ietf.org; Mon, 26 Feb 2007 02:14:25 -0500 Received: from PC20005 ([124.191.178.123]) by omta05ps.mx.bigpond.com with ESMTP id <20070226071408.BQZL19269.omta05ps.mx.bigpond.com@PC20005>; Mon, 26 Feb 2007 07:14:08 +0000 From: "Hesham Soliman" To: "'Koshiro MITSUYA'" Subject: RE: [Mip6] Issue 73: v4 mapped address in IPv6 header Date: Mon, 26 Feb 2007 18:14:03 +1100 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: <0D220B8E-A516-461B-A1B0-028CF8FB574B@sfc.wide.ad.jp> Thread-Index: AcdZcUXE8oPTIXYNTc+coO5QdPlzjwAA5pag x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070226071408.BQZL19269.omta05ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Koshiro, > > Mapped addresses are supported in all major OSs (with the > exception > > of KAME) > > Can you please explain what do you mean by "supported"? > > We can use mapped addresses inside a node with KAME, => I meant at least what you describe above. So by my meaning I guess KAME supports it too. but > KAME rejects > a packet > which has a mapped address as the source or destination address. => Right, but as I mentioned below, I understand the reason for doing that in general because it implies that there is no return address (in the case of the src address), but this is not the case in DSMIP. Hesham > > regards, > Koshiro > > > > On 2007/02/26, at 12:07, Hesham Soliman wrote: > > > > > Folks, > > > > This is the final issue listed on the tracker. This one is > a bit long. > > > > Issue Text: > > ----------- > > > > the IPv4 mapped address has a special meaning by RFC > > 2553 API. It is not preferable to use the mapped address in IPv6 > > headers (See the following the drafts) > > draft-itojun-v6ops-v4mapped-harmful > > draft-cmetz-v6ops-v4mapped-api-harmful > > > > In our code based on KAME, the IPv6 implementation discard a IPv6 > > header which has the v4 mapped address for sanity at > ip6_input() and > > ip6_rthadr2(). We also need to add the mapped address in > an address > > list (the list of all addresses which the node has) to receive the > > header. This is somehow uncomfortable because the mapped > address is > > actually not routable. > > > >> From Hesham: > > => No one suggested that it should/would be routable. It's simply > > used to keep the packet format. There is no routing based on this > > information. > > > >> From Koshiro: > > => I am not sure whether it's just an implementation issues. But > > putting > > the mapped address in the address list in order to process > the DSMIP > > IPv6 header means the mapped address may be chosen as a > source address > > even the address is actually not routable. To avoid this, we need > > e.g. an additional flag to distinguish the mapped address > from others. > > I think some implementers will not accept this. > > > > The above is not only the reason again the mapped address > in the IPv6 > > header. Please refer the draft-*-harmful. So, my idea is > to put HoA > > in IPv6 header and kind of IPv4 CoA option to idicate it's > IPv4 CoA. > > > > BTW, if you just want to keep the packer format, I think > it's better > > to use compatible address, or 6to4 address, or > newly-defined address > > for this purpose. > > > > Analysis: > > --------- > > > > The resons listed in the issue text (and other reasons > discussed in > > the DT) > > as well as their rebuttal are listed in this section. The first > > reason for > > using a different address format was that the use of > mapped address > > was not > > recommended. The issue text refers to two drafts above. Those two > > drafts > > were discussed several years ago in 2002 (first v6ops > meeting). The > > only > > issue that was agreed on in those drafts was that the mapped > > address should > > not be used as a routable address. Therefore, the issue > > misinterprets the > > agreement in the community. Also, the mapped address is > not used as a > > routable address in DSMIP. The drafts referred to above > did suggest > > the > > removal of the v4 mapped address altogether from IPv6, but this > > suggestion > > was rejected and the drafts were not adopted. Mapped > addresses are > > supported > > in all major OSs (with the exception of KAME). > > > > The issue text also suggests the use of a different address format > > (compatible address, 6-to-4, or a new address format). The > compatible > > address format was deprecated from the IPv6 address architecture > > and the > > mapped format is the recommended format for embedding IPv4 > > addresses in > > IPv6. 6-to-4 addresses imply a specific tunnelling behaviour > > (tunnelling to > > the v4 address), which is not useful for our purposes. A new > > address format > > will be no different from the mapped address, which is > designed for > > this > > purpose. > > > > Another concern that was raised against the use of the mapped > > address was > > that they are "implicit" in nature ad do not explicitly > show the IPv4 > > address. However, IP stacks must check the src address in the > > packet to > > insure that is in fact a legal address (e.g. not multicast) in > > ip6_input. > > > > > > Recommendation: > > -------------- > > > > My recommendation is to reject this issue for several reasons: > > a. There is no clear problem with the current format, i.e. what > > breaks? > > b. We've already removed the alt-CoA option in a previous > issue, so > > if we > > accept this issue we'd have to introduce a new address format for > > DSMIP. > > This can take a long time and will yield the same result. > Although, > > if there > > is something specific in the mapped address format that > will cause > > problems, > > and a new address format will solve this problem then I'm > > personally ok with > > the new address format. However, we need to understand what that > > problem is. > > > > > > > > Regards, > > Hesham > > > > > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 26 02:22:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLaBS-0004Xt-T4; Mon, 26 Feb 2007 02:22:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLaBQ-0004XP-PK for mip6@ietf.org; Mon, 26 Feb 2007 02:22:04 -0500 Received: from mail.sfc.wide.ad.jp ([2001:200:0:8803:203:47ff:fedf:73a6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLaBP-0001Bc-FJ for mip6@ietf.org; Mon, 26 Feb 2007 02:22:04 -0500 Received: from [IPv6:2001:200::8801:214:51ff:fe2f:1580] (unknown [IPv6:2001:200:0:8801:214:51ff:fe2f:1580]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 828A74DA12; Mon, 26 Feb 2007 16:22:02 +0900 (JST) In-Reply-To: <20070226071408.BQZL19269.omta05ps.mx.bigpond.com@PC20005> References: <20070226071408.BQZL19269.omta05ps.mx.bigpond.com@PC20005> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <513C01B6-C133-4935-B373-DF4CC24BF8AB@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Koshiro MITSUYA Subject: Re: [Mip6] Issue 73: v4 mapped address in IPv6 header Date: Mon, 26 Feb 2007 16:22:19 +0900 To: "Hesham Soliman" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.8 (--) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: 'Mobile IPv6 Mailing List' , Koshiro MITSUYA X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham, Yes, KAME support it too with your meaning. Can you revise this point? I basically understand the analysis. Thank you for the effort. Koshiro On 2007/02/26, at 16:14, Hesham Soliman wrote: > Hi Koshiro, > >>> Mapped addresses are supported in all major OSs (with the >> exception >>> of KAME) >> >> Can you please explain what do you mean by "supported"? >> >> We can use mapped addresses inside a node with KAME, > > => I meant at least what you describe above. So by my meaning I > guess KAME > supports it too. > > but >> KAME rejects >> a packet >> which has a mapped address as the source or destination address. > > => Right, but as I mentioned below, I understand the reason for > doing that > in general because it implies that there is no return address (in > the case > of the src address), but this is not the case in DSMIP. > > Hesham > >> >> regards, >> Koshiro >> >> >> >> On 2007/02/26, at 12:07, Hesham Soliman wrote: >> >>> >>> Folks, >>> >>> This is the final issue listed on the tracker. This one is >> a bit long. >>> >>> Issue Text: >>> ----------- >>> >>> the IPv4 mapped address has a special meaning by RFC >>> 2553 API. It is not preferable to use the mapped address in IPv6 >>> headers (See the following the drafts) >>> draft-itojun-v6ops-v4mapped-harmful >>> draft-cmetz-v6ops-v4mapped-api-harmful >>> >>> In our code based on KAME, the IPv6 implementation discard a IPv6 >>> header which has the v4 mapped address for sanity at >> ip6_input() and >>> ip6_rthadr2(). We also need to add the mapped address in >> an address >>> list (the list of all addresses which the node has) to receive the >>> header. This is somehow uncomfortable because the mapped >> address is >>> actually not routable. >>> >>>> From Hesham: >>> => No one suggested that it should/would be routable. It's simply >>> used to keep the packet format. There is no routing based on this >>> information. >>> >>>> From Koshiro: >>> => I am not sure whether it's just an implementation issues. But >>> putting >>> the mapped address in the address list in order to process >> the DSMIP >>> IPv6 header means the mapped address may be chosen as a >> source address >>> even the address is actually not routable. To avoid this, we need >>> e.g. an additional flag to distinguish the mapped address >> from others. >>> I think some implementers will not accept this. >>> >>> The above is not only the reason again the mapped address >> in the IPv6 >>> header. Please refer the draft-*-harmful. So, my idea is >> to put HoA >>> in IPv6 header and kind of IPv4 CoA option to idicate it's >> IPv4 CoA. >>> >>> BTW, if you just want to keep the packer format, I think >> it's better >>> to use compatible address, or 6to4 address, or >> newly-defined address >>> for this purpose. >>> >>> Analysis: >>> --------- >>> >>> The resons listed in the issue text (and other reasons >> discussed in >>> the DT) >>> as well as their rebuttal are listed in this section. The first >>> reason for >>> using a different address format was that the use of >> mapped address >>> was not >>> recommended. The issue text refers to two drafts above. Those two >>> drafts >>> were discussed several years ago in 2002 (first v6ops >> meeting). The >>> only >>> issue that was agreed on in those drafts was that the mapped >>> address should >>> not be used as a routable address. Therefore, the issue >>> misinterprets the >>> agreement in the community. Also, the mapped address is >> not used as a >>> routable address in DSMIP. The drafts referred to above >> did suggest >>> the >>> removal of the v4 mapped address altogether from IPv6, but this >>> suggestion >>> was rejected and the drafts were not adopted. Mapped >> addresses are >>> supported >>> in all major OSs (with the exception of KAME). >>> >>> The issue text also suggests the use of a different address format >>> (compatible address, 6-to-4, or a new address format). The >> compatible >>> address format was deprecated from the IPv6 address architecture >>> and the >>> mapped format is the recommended format for embedding IPv4 >>> addresses in >>> IPv6. 6-to-4 addresses imply a specific tunnelling behaviour >>> (tunnelling to >>> the v4 address), which is not useful for our purposes. A new >>> address format >>> will be no different from the mapped address, which is >> designed for >>> this >>> purpose. >>> >>> Another concern that was raised against the use of the mapped >>> address was >>> that they are "implicit" in nature ad do not explicitly >> show the IPv4 >>> address. However, IP stacks must check the src address in the >>> packet to >>> insure that is in fact a legal address (e.g. not multicast) in >>> ip6_input. >>> >>> >>> Recommendation: >>> -------------- >>> >>> My recommendation is to reject this issue for several reasons: >>> a. There is no clear problem with the current format, i.e. what >>> breaks? >>> b. We've already removed the alt-CoA option in a previous >> issue, so >>> if we >>> accept this issue we'd have to introduce a new address format for >>> DSMIP. >>> This can take a long time and will yield the same result. >> Although, >>> if there >>> is something specific in the mapped address format that >> will cause >>> problems, >>> and a new address format will solve this problem then I'm >>> personally ok with >>> the new address format. However, we need to understand what that >>> problem is. >>> >>> >>> >>> Regards, >>> Hesham >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >> >> > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 26 02:38:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLaQp-0001Tp-8g; Mon, 26 Feb 2007 02:37:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLaQn-0001SU-RH for mip6@ietf.org; Mon, 26 Feb 2007 02:37:57 -0500 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLaQm-0003V5-1O for mip6@ietf.org; Mon, 26 Feb 2007 02:37:57 -0500 Received: from PC20005 ([124.191.178.123]) by omta05ps.mx.bigpond.com with ESMTP id <20070226073753.CQFS19269.omta05ps.mx.bigpond.com@PC20005>; Mon, 26 Feb 2007 07:37:53 +0000 From: "Hesham Soliman" To: "'Koshiro MITSUYA'" Subject: RE: [Mip6] Issue 73: v4 mapped address in IPv6 header Date: Mon, 26 Feb 2007 18:37:48 +1100 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: <513C01B6-C133-4935-B373-DF4CC24BF8AB@sfc.wide.ad.jp> Thread-Index: AcdZdtNWI4Myfw+wT3muknk97Rqp5wAAh2AA x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070226073753.CQFS19269.omta05ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Yes, KAME support it too with your meaning. > Can you revise this point? => Sure, apologies for misprepresenting KAME's implementation. Hesham > > I basically understand the analysis. > Thank you for the effort. > > Koshiro > > > > On 2007/02/26, at 16:14, Hesham Soliman wrote: > > > Hi Koshiro, > > > >>> Mapped addresses are supported in all major OSs (with the > >> exception > >>> of KAME) > >> > >> Can you please explain what do you mean by "supported"? > >> > >> We can use mapped addresses inside a node with KAME, > > > > => I meant at least what you describe above. So by my meaning I > > guess KAME > > supports it too. > > > > but > >> KAME rejects > >> a packet > >> which has a mapped address as the source or destination address. > > > > => Right, but as I mentioned below, I understand the reason for > > doing that > > in general because it implies that there is no return address (in > > the case > > of the src address), but this is not the case in DSMIP. > > > > Hesham > > > >> > >> regards, > >> Koshiro > >> > >> > >> > >> On 2007/02/26, at 12:07, Hesham Soliman wrote: > >> > >>> > >>> Folks, > >>> > >>> This is the final issue listed on the tracker. This one is > >> a bit long. > >>> > >>> Issue Text: > >>> ----------- > >>> > >>> the IPv4 mapped address has a special meaning by RFC > >>> 2553 API. It is not preferable to use the mapped address in IPv6 > >>> headers (See the following the drafts) > >>> draft-itojun-v6ops-v4mapped-harmful > >>> draft-cmetz-v6ops-v4mapped-api-harmful > >>> > >>> In our code based on KAME, the IPv6 implementation discard a IPv6 > >>> header which has the v4 mapped address for sanity at > >> ip6_input() and > >>> ip6_rthadr2(). We also need to add the mapped address in > >> an address > >>> list (the list of all addresses which the node has) to > receive the > >>> header. This is somehow uncomfortable because the mapped > >> address is > >>> actually not routable. > >>> > >>>> From Hesham: > >>> => No one suggested that it should/would be routable. It's simply > >>> used to keep the packet format. There is no routing based on this > >>> information. > >>> > >>>> From Koshiro: > >>> => I am not sure whether it's just an implementation issues. But > >>> putting > >>> the mapped address in the address list in order to process > >> the DSMIP > >>> IPv6 header means the mapped address may be chosen as a > >> source address > >>> even the address is actually not routable. To avoid > this, we need > >>> e.g. an additional flag to distinguish the mapped address > >> from others. > >>> I think some implementers will not accept this. > >>> > >>> The above is not only the reason again the mapped address > >> in the IPv6 > >>> header. Please refer the draft-*-harmful. So, my idea is > >> to put HoA > >>> in IPv6 header and kind of IPv4 CoA option to idicate it's > >> IPv4 CoA. > >>> > >>> BTW, if you just want to keep the packer format, I think > >> it's better > >>> to use compatible address, or 6to4 address, or > >> newly-defined address > >>> for this purpose. > >>> > >>> Analysis: > >>> --------- > >>> > >>> The resons listed in the issue text (and other reasons > >> discussed in > >>> the DT) > >>> as well as their rebuttal are listed in this section. The first > >>> reason for > >>> using a different address format was that the use of > >> mapped address > >>> was not > >>> recommended. The issue text refers to two drafts above. Those two > >>> drafts > >>> were discussed several years ago in 2002 (first v6ops > >> meeting). The > >>> only > >>> issue that was agreed on in those drafts was that the mapped > >>> address should > >>> not be used as a routable address. Therefore, the issue > >>> misinterprets the > >>> agreement in the community. Also, the mapped address is > >> not used as a > >>> routable address in DSMIP. The drafts referred to above > >> did suggest > >>> the > >>> removal of the v4 mapped address altogether from IPv6, but this > >>> suggestion > >>> was rejected and the drafts were not adopted. Mapped > >> addresses are > >>> supported > >>> in all major OSs (with the exception of KAME). > >>> > >>> The issue text also suggests the use of a different > address format > >>> (compatible address, 6-to-4, or a new address format). The > >> compatible > >>> address format was deprecated from the IPv6 address architecture > >>> and the > >>> mapped format is the recommended format for embedding IPv4 > >>> addresses in > >>> IPv6. 6-to-4 addresses imply a specific tunnelling behaviour > >>> (tunnelling to > >>> the v4 address), which is not useful for our purposes. A new > >>> address format > >>> will be no different from the mapped address, which is > >> designed for > >>> this > >>> purpose. > >>> > >>> Another concern that was raised against the use of the mapped > >>> address was > >>> that they are "implicit" in nature ad do not explicitly > >> show the IPv4 > >>> address. However, IP stacks must check the src address in the > >>> packet to > >>> insure that is in fact a legal address (e.g. not multicast) in > >>> ip6_input. > >>> > >>> > >>> Recommendation: > >>> -------------- > >>> > >>> My recommendation is to reject this issue for several reasons: > >>> a. There is no clear problem with the current format, i.e. what > >>> breaks? > >>> b. We've already removed the alt-CoA option in a previous > >> issue, so > >>> if we > >>> accept this issue we'd have to introduce a new address format for > >>> DSMIP. > >>> This can take a long time and will yield the same result. > >> Although, > >>> if there > >>> is something specific in the mapped address format that > >> will cause > >>> problems, > >>> and a new address format will solve this problem then I'm > >>> personally ok with > >>> the new address format. However, we need to understand what that > >>> problem is. > >>> > >>> > >>> > >>> Regards, > >>> Hesham > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Mip6 mailing list > >>> Mip6@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mip6 > >> > >> > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 26 03:10:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLavf-0000Dt-8B; Mon, 26 Feb 2007 03:09:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLavd-0000Di-De for mip6@ietf.org; Mon, 26 Feb 2007 03:09:49 -0500 Received: from wr-out-0506.google.com ([64.233.184.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLavc-0007ba-6j for mip6@ietf.org; Mon, 26 Feb 2007 03:09:49 -0500 Received: by wr-out-0506.google.com with SMTP id 58so1403932wri for ; Mon, 26 Feb 2007 00:09:48 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FrlL/KnS3NgqsWaSQXUeIokQcbBy0ke9eUJGrEpws48juU6WLigIsNKOzX+9Cc0dvRj2Epc8Z6J54/0Kp1i50w2dbO2SGchIIQ2cx071a6FozyX2Bfk7+qROgRe56Z7zvVu0jB/7XsJwN6KYZO3w/Gl63NNPbi43dZmOwsPz9XY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qaN45jFOr8Us6WZyOiIW1obOBr/a447DoR2qDW96zC45kQ7sKZE3M3j2ART1D5ysvQVdhBPzJPtvy3EHSL82Vno/dcRV/D4LuXY86ax7/byEzvtgwmC5OB4SPTDtCHMbJe3luexUzpmTF2A5MZR9QVakYyMlBQ3DinVirCIe8As= Received: by 10.114.174.2 with SMTP id w2mr1981076wae.1172477386863; Mon, 26 Feb 2007 00:09:46 -0800 (PST) Received: by 10.114.241.17 with HTTP; Mon, 26 Feb 2007 00:09:46 -0800 (PST) Message-ID: <5e2406980702260009o300504e4x3038365b62e026c5@mail.gmail.com> Date: Mon, 26 Feb 2007 09:09:46 +0100 From: "Julien Bournelle" To: "Chowdhury, Kuntal" Subject: Re: [Mip6] draft-ietf-mip6-radius-01.txt In-Reply-To: <7CCD07160348804497EF29E9EA5560D7FBD973$0001@exchtewks2.starentnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7CCD07160348804497EF29E9EA5560D7FBD973$0001@exchtewks2.starentnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: mip6@ietf.org, Avi Lior X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Kuntal, Avi, all, thanks for the reply, one more comment inline, On 2/23/07, Chowdhury, Kuntal wrote: > Regarding your question: > > > I have one general question: > > > > In the split scenario, how does the RADIUS server know that it is > > performing AAA for mip6 service and not for network access ? > > > > (FYI, we encounter this problem in the DiME WG and we'll solve this by > > > using a different Application ID.) > > In RADIUS we don't have an application id therefore the AAA server > determines the context of the packet it receives by examining the > attributes. > > For example: > > The presence of an attribute in an Access-Request packet that only an HA > or even more specifically a MIPv6 HA would provide in this case: MIP6-HA > Attribute. But this attribute is not a required attribute. > > NAS-Port-Type: can be set to a value such as HA-IPv6. This is the most > reliable attribute but we need IANA to assign the attribute. > > The AAA may also know the context by using the NAS-IP and/or the > NAS-Ids, that is, it will know that a particular NAS-IP is an HA vs a > NAS. This obivously doesn't scale to large deployments. > > I think we need to update the draft to cover this discussion and request > IANA for a NAS-Port-Type. I agree with that. Moreover, I think the Diameter considerations section should also be updated to reflect what's going on in DiME. I think the section is ok for the NAS-to-AAAH part but should reflect what we will do for the HA-to-AAAH. At this point, it is not yet clear how we will use Diameter for HA-to-AAAH (cf. the long thread on the DiME ML) but this should be decided before or at the next IETF. I let you inform. Regards, Julien _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 26 10:31:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLhol-00047H-Qj; Mon, 26 Feb 2007 10:31:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLhok-000478-8D for mip6@ietf.org; Mon, 26 Feb 2007 10:31:10 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HLhoi-0000GN-NS for mip6@ietf.org; Mon, 26 Feb 2007 10:31:10 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1172503466!8597848!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 12240 invoked from network); 26 Feb 2007 15:24:26 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-12.tower-128.messagelabs.com with SMTP; 26 Feb 2007 15:24:26 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l1QFOAb4014416; Mon, 26 Feb 2007 09:24:11 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l1QFO7MO009264; Mon, 26 Feb 2007 09:24:09 -0600 (CST) Message-ID: <45E2FB97.4030707@motorola.com> Date: Mon, 26 Feb 2007 16:24:07 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Issue 73: v4 mapped address in IPv6 header References: <20070226073753.CQFS19269.omta05ps.mx.bigpond.com@PC20005> In-Reply-To: <20070226073753.CQFS19269.omta05ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: 'Mobile IPv6 Mailing List' , 'Koshiro MITSUYA' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Is the IPv6 Home Address a v4-mapped address? Can I still use a EUI64-derived IPv6 Home Address when I use DS-MIPv6? Will the MN have three Home Addresses when using DS-MIPv6? (a v4-mapped IPv6 address, a EUI64-derived IPv6 address and a IPv4 address). Alex Hesham Soliman wrote: > > > Yes, KAME support it too with your meaning. > > Can you revise this point? > > => Sure, apologies for misprepresenting KAME's implementation. > > Hesham > > > > > I basically understand the analysis. > > Thank you for the effort. > > > > Koshiro > > > > > > > > On 2007/02/26, at 16:14, Hesham Soliman wrote: > > > > > Hi Koshiro, > > > > > >>> Mapped addresses are supported in all major OSs (with the > > >> exception > > >>> of KAME) > > >> > > >> Can you please explain what do you mean by "supported"? > > >> > > >> We can use mapped addresses inside a node with KAME, > > > > > > => I meant at least what you describe above. So by my meaning I > > > guess KAME > > > supports it too. > > > > > > but > > >> KAME rejects > > >> a packet > > >> which has a mapped address as the source or destination address. > > > > > > => Right, but as I mentioned below, I understand the reason for > > > doing that > > > in general because it implies that there is no return address (in > > > the case > > > of the src address), but this is not the case in DSMIP. > > > > > > Hesham > > > > > >> > > >> regards, > > >> Koshiro > > >> > > >> > > >> > > >> On 2007/02/26, at 12:07, Hesham Soliman wrote: > > >> > > >>> > > >>> Folks, > > >>> > > >>> This is the final issue listed on the tracker. This one is > > >> a bit long. > > >>> > > >>> Issue Text: > > >>> ----------- > > >>> > > >>> the IPv4 mapped address has a special meaning by RFC > > >>> 2553 API. It is not preferable to use the mapped address in IPv6 > > >>> headers (See the following the drafts) > > >>> draft-itojun-v6ops-v4mapped-harmful > > >>> draft-cmetz-v6ops-v4mapped-api-harmful > > >>> > > >>> In our code based on KAME, the IPv6 implementation discard a IPv6 > > >>> header which has the v4 mapped address for sanity at > > >> ip6_input() and > > >>> ip6_rthadr2(). We also need to add the mapped address in > > >> an address > > >>> list (the list of all addresses which the node has) to > > receive the > > >>> header. This is somehow uncomfortable because the mapped > > >> address is > > >>> actually not routable. > > >>> > > >>>> From Hesham: > > >>> => No one suggested that it should/would be routable. It's simply > > >>> used to keep the packet format. There is no routing based on this > > >>> information. > > >>> > > >>>> From Koshiro: > > >>> => I am not sure whether it's just an implementation issues. But > > >>> putting > > >>> the mapped address in the address list in order to process > > >> the DSMIP > > >>> IPv6 header means the mapped address may be chosen as a > > >> source address > > >>> even the address is actually not routable. To avoid > > this, we need > > >>> e.g. an additional flag to distinguish the mapped address > > >> from others. > > >>> I think some implementers will not accept this. > > >>> > > >>> The above is not only the reason again the mapped address > > >> in the IPv6 > > >>> header. Please refer the draft-*-harmful. So, my idea is > > >> to put HoA > > >>> in IPv6 header and kind of IPv4 CoA option to idicate it's > > >> IPv4 CoA. > > >>> > > >>> BTW, if you just want to keep the packer format, I think > > >> it's better > > >>> to use compatible address, or 6to4 address, or > > >> newly-defined address > > >>> for this purpose. > > >>> > > >>> Analysis: > > >>> --------- > > >>> > > >>> The resons listed in the issue text (and other reasons > > >> discussed in > > >>> the DT) > > >>> as well as their rebuttal are listed in this section. The first > > >>> reason for > > >>> using a different address format was that the use of > > >> mapped address > > >>> was not > > >>> recommended. The issue text refers to two drafts above. Those two > > >>> drafts > > >>> were discussed several years ago in 2002 (first v6ops > > >> meeting). The > > >>> only > > >>> issue that was agreed on in those drafts was that the mapped > > >>> address should > > >>> not be used as a routable address. Therefore, the issue > > >>> misinterprets the > > >>> agreement in the community. Also, the mapped address is > > >> not used as a > > >>> routable address in DSMIP. The drafts referred to above > > >> did suggest > > >>> the > > >>> removal of the v4 mapped address altogether from IPv6, but this > > >>> suggestion > > >>> was rejected and the drafts were not adopted. Mapped > > >> addresses are > > >>> supported > > >>> in all major OSs (with the exception of KAME). > > >>> > > >>> The issue text also suggests the use of a different > > address format > > >>> (compatible address, 6-to-4, or a new address format). The > > >> compatible > > >>> address format was deprecated from the IPv6 address architecture > > >>> and the > > >>> mapped format is the recommended format for embedding IPv4 > > >>> addresses in > > >>> IPv6. 6-to-4 addresses imply a specific tunnelling behaviour > > >>> (tunnelling to > > >>> the v4 address), which is not useful for our purposes. A new > > >>> address format > > >>> will be no different from the mapped address, which is > > >> designed for > > >>> this > > >>> purpose. > > >>> > > >>> Another concern that was raised against the use of the mapped > > >>> address was > > >>> that they are "implicit" in nature ad do not explicitly > > >> show the IPv4 > > >>> address. However, IP stacks must check the src address in the > > >>> packet to > > >>> insure that is in fact a legal address (e.g. not multicast) in > > >>> ip6_input. > > >>> > > >>> > > >>> Recommendation: > > >>> -------------- > > >>> > > >>> My recommendation is to reject this issue for several reasons: > > >>> a. There is no clear problem with the current format, i.e. what > > >>> breaks? > > >>> b. We've already removed the alt-CoA option in a previous > > >> issue, so > > >>> if we > > >>> accept this issue we'd have to introduce a new address format for > > >>> DSMIP. > > >>> This can take a long time and will yield the same result. > > >> Although, > > >>> if there > > >>> is something specific in the mapped address format that > > >> will cause > > >>> problems, > > >>> and a new address format will solve this problem then I'm > > >>> personally ok with > > >>> the new address format. However, we need to understand what that > > >>> problem is. > > >>> > > >>> > > >>> > > >>> Regards, > > >>> Hesham > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> Mip6 mailing list > > >>> Mip6@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/mip6 > > >> > > >> > > > > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 26 13:48:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLksX-0005Od-ME; Mon, 26 Feb 2007 13:47:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLksV-0005Hi-UP for mip6@ietf.org; Mon, 26 Feb 2007 13:47:15 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HLksU-00051P-Cs for mip6@ietf.org; Mon, 26 Feb 2007 13:47:15 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 10:47:06 -0800 Message-ID: <45E32B26.7050702@azairenet.com> Date: Mon, 26 Feb 2007 10:47:02 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip6] AD review of draft-ietf-mip6-bootstrapping-split References: <459A5A6C.5070602@piuha.net> <45E00DD3.1010701@piuha.net> In-Reply-To: <45E00DD3.1010701@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 18:47:06.0666 (UTC) FILETIME=[837450A0:01C759D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Mobile IPv6 Mailing List , James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Jari Arkko wrote: >> In case the FQDN is known by the AAA server via EAP, I see two >> possible approaches: >> >> - the AAA server provides the HA with the MN's FQDN received via EAP >> (e.g. during Diameter EAP application) and the HA stores the >> "authorized" FQDN. This would require a change in current Diameter >> application > > Yes. Or a new AVP, at least. CUI might apply here, but it might > not have exactly the semantics you want. > >> - the HA performs a AAA exchange when it receives a BU with a DNS >> Update mobility option; this AAA exchange should be part of the Mobile >> IPv6 Diameter application (work in progress in DIME WG) and should be >> used by the HA to get the authorized FQDN from the AAA server in order >> to update the DNS > > This sounds preliminarily better. I don't like this additional AAA exchange just for the DNS update. We should go with the solution where the AAA server sends the mobile node's true FQDN (the one that appears in the DNS) to the home agent in the AA Answer message or the Diameter EAP Answer message, depending on whether authentication and authorization is done separately or together. (I haven't followed the work in Dime for a while. So I don't know what the current thinking is). >> The draft should leave the actual definition of either mechanism as >> out of scope (as you suggested), but we should put a reference to the >> solution. >> >> As a summary, in this draft, I think it is enough to clarify the need >> of the FQDN in the cert for the certificates scenario. For the AAA/EAP >> scenario, we should provide a reference for the HA-AAA coordination >> needed in case EAP is used, IMO, whenever the mobile nodes uses different identities in the IDi field and in EAP payloads, we should require the AAA server to send the mobile node's identity to the Home Agent. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 26 14:33:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLlab-0002Uf-JM; Mon, 26 Feb 2007 14:32:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLlaW-0002L6-LI for mip6@ietf.org; Mon, 26 Feb 2007 14:32:44 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLlYS-0001Nm-JN for mip6@ietf.org; Mon, 26 Feb 2007 14:30:38 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 11:30:36 -0800 Message-ID: <45E33559.1080404@azairenet.com> Date: Mon, 26 Feb 2007 11:30:33 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Hesham Soliman , 'Mobile IPv6 Mailing List' Subject: Re: [Mip6] Issue 73: v4 mapped address in IPv6 header References: <20070226030713.OARH19269.omta05ps.mx.bigpond.com@PC20005> In-Reply-To: <20070226030713.OARH19269.omta05ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 19:30:36.0119 (UTC) FILETIME=[96CF3E70:01C759DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, There were some more concerns/issues raised regarding the use of a mapped address instead of an explicit mobility option for the IPv4 care-of address. I prefer the use of an explicit IPv4 CoA option in the binding update to carry the IPv4 care-of address of the mobile node. Here are some reasons. 1. Many implementations don't support mapped addresses. 2. The IPv4 CoA is indicated explicitly through the use of a mobility option. I prefer this explicit indication for the IPv4 CoA. The binding update processing on the home agent becomes easier to parse the IPv4 care-of address and compare it with the IPv4 source address on the outermost IPv4 header for NAT detection. 3. In case there is no NAT on the path, ESP protection is provided for the IPv4 CoA since it is a mobility option which comes after the ESP header. 4. It enables one to send a binding update in the tunneled format. IPv4 header (src = V4ADDR, dst = HA_V4ADDr) UDP header ESP header in tunnel mode IPv6 header (src = IPv6 HoA, dst = HA_V6ADDR) Mobility header Binding Update IPv4 CoA option (IPv4 CoA) Of course one can always send a BU in transport format, but the IPv4 CoA option enables one to also send a BU in the tunneled format in an optimized manner. Without the use of IPv4 CoA option, the tunneled BU will have too much overhead. There are many reasons why you would want to send a tunneled BU. One is privacy. The other is to enable an implementation to use just one tunnel mode ESP SA to protect all MIPv6 signaling messages and payload traffic. Hope this helps. Vijay Hesham Soliman wrote: > Folks, > > This is the final issue listed on the tracker. This one is a bit long. > > Issue Text: > ----------- > > the IPv4 mapped address has a special meaning by RFC > 2553 API. It is not preferable to use the mapped address in IPv6 > headers (See the following the drafts) > draft-itojun-v6ops-v4mapped-harmful > draft-cmetz-v6ops-v4mapped-api-harmful > > In our code based on KAME, the IPv6 implementation discard a IPv6 > header which has the v4 mapped address for sanity at ip6_input() and > ip6_rthadr2(). We also need to add the mapped address in an address > list (the list of all addresses which the node has) to receive the > header. This is somehow uncomfortable because the mapped address is > actually not routable. > >>From Hesham: > => No one suggested that it should/would be routable. It's simply > used to keep the packet format. There is no routing based on this > information. > >>From Koshiro: > => I am not sure whether it's just an implementation issues. But putting > the mapped address in the address list in order to process the DSMIP > IPv6 header means the mapped address may be chosen as a source address > even the address is actually not routable. To avoid this, we need > e.g. an additional flag to distinguish the mapped address from others. > I think some implementers will not accept this. > > The above is not only the reason again the mapped address in the IPv6 > header. Please refer the draft-*-harmful. So, my idea is to put HoA > in IPv6 header and kind of IPv4 CoA option to idicate it's IPv4 CoA. > > BTW, if you just want to keep the packer format, I think it's better > to use compatible address, or 6to4 address, or newly-defined address > for this purpose. > > Analysis: > --------- > > The resons listed in the issue text (and other reasons discussed in the DT) > as well as their rebuttal are listed in this section. The first reason for > using a different address format was that the use of mapped address was not > recommended. The issue text refers to two drafts above. Those two drafts > were discussed several years ago in 2002 (first v6ops meeting). The only > issue that was agreed on in those drafts was that the mapped address should > not be used as a routable address. Therefore, the issue misinterprets the > agreement in the community. Also, the mapped address is not used as a > routable address in DSMIP. The drafts referred to above did suggest the > removal of the v4 mapped address altogether from IPv6, but this suggestion > was rejected and the drafts were not adopted. Mapped addresses are supported > in all major OSs (with the exception of KAME). > > The issue text also suggests the use of a different address format > (compatible address, 6-to-4, or a new address format). The compatible > address format was deprecated from the IPv6 address architecture and the > mapped format is the recommended format for embedding IPv4 addresses in > IPv6. 6-to-4 addresses imply a specific tunnelling behaviour (tunnelling to > the v4 address), which is not useful for our purposes. A new address format > will be no different from the mapped address, which is designed for this > purpose. > > Another concern that was raised against the use of the mapped address was > that they are "implicit" in nature ad do not explicitly show the IPv4 > address. However, IP stacks must check the src address in the packet to > insure that is in fact a legal address (e.g. not multicast) in ip6_input. > > > Recommendation: > -------------- > > My recommendation is to reject this issue for several reasons: > a. There is no clear problem with the current format, i.e. what breaks? > b. We've already removed the alt-CoA option in a previous issue, so if we > accept this issue we'd have to introduce a new address format for DSMIP. > This can take a long time and will yield the same result. Although, if there > is something specific in the mapped address format that will cause problems, > and a new address format will solve this problem then I'm personally ok with > the new address format. However, we need to understand what that problem is. > > > > Regards, > Hesham > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 26 14:33:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLlam-0002fk-D6; Mon, 26 Feb 2007 14:33:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLlal-0002ff-6F for mip6@ietf.org; Mon, 26 Feb 2007 14:32:59 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLlak-0001oo-LA for mip6@ietf.org; Mon, 26 Feb 2007 14:32:59 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 11:32:58 -0800 Message-ID: <45E335E9.70102@azairenet.com> Date: Mon, 26 Feb 2007 11:32:57 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] Issue 73: v4 mapped address in IPv6 header References: <20070226073753.CQFS19269.omta05ps.mx.bigpond.com@PC20005> <45E2FB97.4030707@motorola.com> In-Reply-To: <45E2FB97.4030707@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 19:32:58.0166 (UTC) FILETIME=[EB79E560:01C759DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: 'Mobile IPv6 Mailing List' , 'Koshiro MITSUYA' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > Is the IPv6 Home Address a v4-mapped address? No. Just the care-of address. > Can I still use a EUI64-derived IPv6 Home Address when I use DS-MIPv6? yes. > Will the MN have three Home Addresses when using DS-MIPv6? (a v4-mapped > IPv6 address, a EUI64-derived IPv6 address and a IPv4 address). The most common case would be one IPv6 home address and one IPv4 home address (for IPv4 sessions). Vijay > > Alex > > Hesham Soliman wrote: >> >> > Yes, KAME support it too with your meaning. >> > Can you revise this point? >> >> => Sure, apologies for misprepresenting KAME's implementation. >> Hesham >> >> > > I basically understand the analysis. >> > Thank you for the effort. >> > > Koshiro >> > > > > On 2007/02/26, at 16:14, Hesham Soliman wrote: >> > > > Hi Koshiro, >> > > >> > >>> Mapped addresses are supported in all major OSs (with the >> > >> exception >> > >>> of KAME) >> > >> >> > >> Can you please explain what do you mean by "supported"? >> > >> >> > >> We can use mapped addresses inside a node with KAME, >> > > >> > > => I meant at least what you describe above. So by my meaning I >> > > guess KAME >> > > supports it too. >> > > >> > > but >> > >> KAME rejects >> > >> a packet >> > >> which has a mapped address as the source or destination address. >> > > >> > > => Right, but as I mentioned below, I understand the reason for >> > > doing that >> > > in general because it implies that there is no return address >> (in > > the case >> > > of the src address), but this is not the case in DSMIP. >> > > >> > > Hesham >> > > >> > >> >> > >> regards, >> > >> Koshiro >> > >> >> > >> >> > >> >> > >> On 2007/02/26, at 12:07, Hesham Soliman wrote: >> > >> >> > >>> >> > >>> Folks, >> > >>> >> > >>> This is the final issue listed on the tracker. This one is >> > >> a bit long. >> > >>> >> > >>> Issue Text: >> > >>> ----------- >> > >>> >> > >>> the IPv4 mapped address has a special meaning by RFC >> > >>> 2553 API. It is not preferable to use the mapped address in IPv6 >> > >>> headers (See the following the drafts) >> > >>> draft-itojun-v6ops-v4mapped-harmful >> > >>> draft-cmetz-v6ops-v4mapped-api-harmful >> > >>> >> > >>> In our code based on KAME, the IPv6 implementation discard a IPv6 >> > >>> header which has the v4 mapped address for sanity at >> > >> ip6_input() and >> > >>> ip6_rthadr2(). We also need to add the mapped address in >> > >> an address >> > >>> list (the list of all addresses which the node has) to > >> receive the >> > >>> header. This is somehow uncomfortable because the mapped >> > >> address is >> > >>> actually not routable. >> > >>> >> > >>>> From Hesham: >> > >>> => No one suggested that it should/would be routable. It's simply >> > >>> used to keep the packet format. There is no routing based on this >> > >>> information. >> > >>> >> > >>>> From Koshiro: >> > >>> => I am not sure whether it's just an implementation issues. But >> > >>> putting >> > >>> the mapped address in the address list in order to process >> > >> the DSMIP >> > >>> IPv6 header means the mapped address may be chosen as a >> > >> source address >> > >>> even the address is actually not routable. To avoid > this, >> we need >> > >>> e.g. an additional flag to distinguish the mapped address >> > >> from others. >> > >>> I think some implementers will not accept this. >> > >>> >> > >>> The above is not only the reason again the mapped address >> > >> in the IPv6 >> > >>> header. Please refer the draft-*-harmful. So, my idea is >> > >> to put HoA >> > >>> in IPv6 header and kind of IPv4 CoA option to idicate it's >> > >> IPv4 CoA. >> > >>> >> > >>> BTW, if you just want to keep the packer format, I think >> > >> it's better >> > >>> to use compatible address, or 6to4 address, or >> > >> newly-defined address >> > >>> for this purpose. >> > >>> >> > >>> Analysis: >> > >>> --------- >> > >>> >> > >>> The resons listed in the issue text (and other reasons >> > >> discussed in >> > >>> the DT) >> > >>> as well as their rebuttal are listed in this section. The first >> > >>> reason for >> > >>> using a different address format was that the use of >> > >> mapped address >> > >>> was not >> > >>> recommended. The issue text refers to two drafts above. Those two >> > >>> drafts >> > >>> were discussed several years ago in 2002 (first v6ops >> > >> meeting). The >> > >>> only >> > >>> issue that was agreed on in those drafts was that the mapped >> > >>> address should >> > >>> not be used as a routable address. Therefore, the issue >> > >>> misinterprets the >> > >>> agreement in the community. Also, the mapped address is >> > >> not used as a >> > >>> routable address in DSMIP. The drafts referred to above >> > >> did suggest >> > >>> the >> > >>> removal of the v4 mapped address altogether from IPv6, but this >> > >>> suggestion >> > >>> was rejected and the drafts were not adopted. Mapped >> > >> addresses are >> > >>> supported >> > >>> in all major OSs (with the exception of KAME). >> > >>> >> > >>> The issue text also suggests the use of a different > address >> format >> > >>> (compatible address, 6-to-4, or a new address format). The >> > >> compatible >> > >>> address format was deprecated from the IPv6 address architecture >> > >>> and the >> > >>> mapped format is the recommended format for embedding IPv4 >> > >>> addresses in >> > >>> IPv6. 6-to-4 addresses imply a specific tunnelling behaviour >> > >>> (tunnelling to >> > >>> the v4 address), which is not useful for our purposes. A new >> > >>> address format >> > >>> will be no different from the mapped address, which is >> > >> designed for >> > >>> this >> > >>> purpose. >> > >>> >> > >>> Another concern that was raised against the use of the mapped >> > >>> address was >> > >>> that they are "implicit" in nature ad do not explicitly >> > >> show the IPv4 >> > >>> address. However, IP stacks must check the src address in the >> > >>> packet to >> > >>> insure that is in fact a legal address (e.g. not multicast) in >> > >>> ip6_input. >> > >>> >> > >>> >> > >>> Recommendation: >> > >>> -------------- >> > >>> >> > >>> My recommendation is to reject this issue for several reasons: >> > >>> a. There is no clear problem with the current format, i.e. what >> > >>> breaks? >> > >>> b. We've already removed the alt-CoA option in a previous >> > >> issue, so >> > >>> if we >> > >>> accept this issue we'd have to introduce a new address format for >> > >>> DSMIP. >> > >>> This can take a long time and will yield the same result. >> > >> Although, >> > >>> if there >> > >>> is something specific in the mapped address format that >> > >> will cause >> > >>> problems, >> > >>> and a new address format will solve this problem then I'm >> > >>> personally ok with >> > >>> the new address format. However, we need to understand what that >> > >>> problem is. >> > >>> >> > >>> >> > >>> >> > >>> Regards, >> > >>> Hesham >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> _______________________________________________ >> > >>> Mip6 mailing list >> > >>> Mip6@ietf.org >> > >>> https://www1.ietf.org/mailman/listinfo/mip6 >> > >> >> > >> >> > > >> > > >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 26 15:34:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmXV-0003Po-6R; Mon, 26 Feb 2007 15:33:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmXT-0003Ol-Gg for mip6@ietf.org; Mon, 26 Feb 2007 15:33:39 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HLmXI-000303-FF for mip6@ietf.org; Mon, 26 Feb 2007 15:33:39 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1172522007!15811085!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 16464 invoked from network); 26 Feb 2007 20:33:27 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-11.tower-119.messagelabs.com with SMTP; 26 Feb 2007 20:33:27 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l1QKXQRc019862; Mon, 26 Feb 2007 13:33:27 -0700 (MST) Received: from [10.129.41.5] ([10.129.41.5]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l1QKXNqh028933; Mon, 26 Feb 2007 14:33:24 -0600 (CST) Message-ID: <45E34414.4030808@motorola.com> Date: Mon, 26 Feb 2007 21:33:24 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Issue 73: v4 mapped address in IPv6 header References: <20070226073753.CQFS19269.omta05ps.mx.bigpond.com@PC20005> <45E2FB97.4030707@motorola.com> <45E335E9.70102@azairenet.com> In-Reply-To: <45E335E9.70102@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: 'Mobile IPv6 Mailing List' , 'Koshiro MITSUYA' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Is the IPv6 Home Address a v4-mapped address? > > No. Just the care-of address. > >> Can I still use a EUI64-derived IPv6 Home Address when I use DS-MIPv6? > > yes. > >> Will the MN have three Home Addresses when using DS-MIPv6? (a >> v4-mapped IPv6 address, a EUI64-derived IPv6 address and a IPv4 address). > > The most common case would be one IPv6 home address > and one IPv4 home address (for IPv4 sessions). That is fine, thanks. Alex > > Vijay > >> >> Alex >> >> Hesham Soliman wrote: >>> >>> > Yes, KAME support it too with your meaning. >>> > Can you revise this point? >>> >>> => Sure, apologies for misprepresenting KAME's implementation. >>> Hesham >>> >>> > > I basically understand the analysis. >>> > Thank you for the effort. >>> > > Koshiro >>> > > > > On 2007/02/26, at 16:14, Hesham Soliman wrote: >>> > > > Hi Koshiro, >>> > > >>> > >>> Mapped addresses are supported in all major OSs (with the >>> > >> exception >>> > >>> of KAME) >>> > >> >>> > >> Can you please explain what do you mean by "supported"? >>> > >> >>> > >> We can use mapped addresses inside a node with KAME, >>> > > >>> > > => I meant at least what you describe above. So by my meaning I >>> > > guess KAME >>> > > supports it too. >>> > > >>> > > but >>> > >> KAME rejects >>> > >> a packet >>> > >> which has a mapped address as the source or destination address. >>> > > >>> > > => Right, but as I mentioned below, I understand the reason for >>> > > doing that >>> > > in general because it implies that there is no return address >>> (in > > the case >>> > > of the src address), but this is not the case in DSMIP. >>> > > >>> > > Hesham >>> > > >>> > >> >>> > >> regards, >>> > >> Koshiro >>> > >> >>> > >> >>> > >> >>> > >> On 2007/02/26, at 12:07, Hesham Soliman wrote: >>> > >> >>> > >>> >>> > >>> Folks, >>> > >>> >>> > >>> This is the final issue listed on the tracker. This one is >>> > >> a bit long. >>> > >>> >>> > >>> Issue Text: >>> > >>> ----------- >>> > >>> >>> > >>> the IPv4 mapped address has a special meaning by RFC >>> > >>> 2553 API. It is not preferable to use the mapped address in IPv6 >>> > >>> headers (See the following the drafts) >>> > >>> draft-itojun-v6ops-v4mapped-harmful >>> > >>> draft-cmetz-v6ops-v4mapped-api-harmful >>> > >>> >>> > >>> In our code based on KAME, the IPv6 implementation discard a IPv6 >>> > >>> header which has the v4 mapped address for sanity at >>> > >> ip6_input() and >>> > >>> ip6_rthadr2(). We also need to add the mapped address in >>> > >> an address >>> > >>> list (the list of all addresses which the node has) to > >>> receive the >>> > >>> header. This is somehow uncomfortable because the mapped >>> > >> address is >>> > >>> actually not routable. >>> > >>> >>> > >>>> From Hesham: >>> > >>> => No one suggested that it should/would be routable. It's simply >>> > >>> used to keep the packet format. There is no routing based on this >>> > >>> information. >>> > >>> >>> > >>>> From Koshiro: >>> > >>> => I am not sure whether it's just an implementation issues. But >>> > >>> putting >>> > >>> the mapped address in the address list in order to process >>> > >> the DSMIP >>> > >>> IPv6 header means the mapped address may be chosen as a >>> > >> source address >>> > >>> even the address is actually not routable. To avoid > this, >>> we need >>> > >>> e.g. an additional flag to distinguish the mapped address >>> > >> from others. >>> > >>> I think some implementers will not accept this. >>> > >>> >>> > >>> The above is not only the reason again the mapped address >>> > >> in the IPv6 >>> > >>> header. Please refer the draft-*-harmful. So, my idea is >>> > >> to put HoA >>> > >>> in IPv6 header and kind of IPv4 CoA option to idicate it's >>> > >> IPv4 CoA. >>> > >>> >>> > >>> BTW, if you just want to keep the packer format, I think >>> > >> it's better >>> > >>> to use compatible address, or 6to4 address, or >>> > >> newly-defined address >>> > >>> for this purpose. >>> > >>> >>> > >>> Analysis: >>> > >>> --------- >>> > >>> >>> > >>> The resons listed in the issue text (and other reasons >>> > >> discussed in >>> > >>> the DT) >>> > >>> as well as their rebuttal are listed in this section. The first >>> > >>> reason for >>> > >>> using a different address format was that the use of >>> > >> mapped address >>> > >>> was not >>> > >>> recommended. The issue text refers to two drafts above. Those two >>> > >>> drafts >>> > >>> were discussed several years ago in 2002 (first v6ops >>> > >> meeting). The >>> > >>> only >>> > >>> issue that was agreed on in those drafts was that the mapped >>> > >>> address should >>> > >>> not be used as a routable address. Therefore, the issue >>> > >>> misinterprets the >>> > >>> agreement in the community. Also, the mapped address is >>> > >> not used as a >>> > >>> routable address in DSMIP. The drafts referred to above >>> > >> did suggest >>> > >>> the >>> > >>> removal of the v4 mapped address altogether from IPv6, but this >>> > >>> suggestion >>> > >>> was rejected and the drafts were not adopted. Mapped >>> > >> addresses are >>> > >>> supported >>> > >>> in all major OSs (with the exception of KAME). >>> > >>> >>> > >>> The issue text also suggests the use of a different > address >>> format >>> > >>> (compatible address, 6-to-4, or a new address format). The >>> > >> compatible >>> > >>> address format was deprecated from the IPv6 address architecture >>> > >>> and the >>> > >>> mapped format is the recommended format for embedding IPv4 >>> > >>> addresses in >>> > >>> IPv6. 6-to-4 addresses imply a specific tunnelling behaviour >>> > >>> (tunnelling to >>> > >>> the v4 address), which is not useful for our purposes. A new >>> > >>> address format >>> > >>> will be no different from the mapped address, which is >>> > >> designed for >>> > >>> this >>> > >>> purpose. >>> > >>> >>> > >>> Another concern that was raised against the use of the mapped >>> > >>> address was >>> > >>> that they are "implicit" in nature ad do not explicitly >>> > >> show the IPv4 >>> > >>> address. However, IP stacks must check the src address in the >>> > >>> packet to >>> > >>> insure that is in fact a legal address (e.g. not multicast) in >>> > >>> ip6_input. >>> > >>> >>> > >>> >>> > >>> Recommendation: >>> > >>> -------------- >>> > >>> >>> > >>> My recommendation is to reject this issue for several reasons: >>> > >>> a. There is no clear problem with the current format, i.e. what >>> > >>> breaks? >>> > >>> b. We've already removed the alt-CoA option in a previous >>> > >> issue, so >>> > >>> if we >>> > >>> accept this issue we'd have to introduce a new address format for >>> > >>> DSMIP. >>> > >>> This can take a long time and will yield the same result. >>> > >> Although, >>> > >>> if there >>> > >>> is something specific in the mapped address format that >>> > >> will cause >>> > >>> problems, >>> > >>> and a new address format will solve this problem then I'm >>> > >>> personally ok with >>> > >>> the new address format. However, we need to understand what that >>> > >>> problem is. >>> > >>> >>> > >>> >>> > >>> >>> > >>> Regards, >>> > >>> Hesham >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> _______________________________________________ >>> > >>> Mip6 mailing list >>> > >>> Mip6@ietf.org >>> > >>> https://www1.ietf.org/mailman/listinfo/mip6 >>> > >> >>> > >> >>> > > >>> > > >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 26 16:54:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLnnN-00078j-Kg; Mon, 26 Feb 2007 16:54:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmrB-0003aR-5M for mip6@ietf.org; Mon, 26 Feb 2007 15:54:01 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLmqj-0006gc-2o for mip6@ietf.org; Mon, 26 Feb 2007 15:54:01 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1QKnSOX029229; Mon, 26 Feb 2007 22:49:32 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 22:53:21 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 14:53:10 -0600 Received: from 172.19.244.130 ([172.19.244.130]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 26 Feb 2007 20:53:10 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 26 Feb 2007 14:53:15 -0600 Subject: Re: [Mip6] caps or lowercase? From: Basavaraj Patil To: ext Francis Dupont , Message-ID: Thread-Topic: [Mip6] caps or lowercase? Thread-Index: AcdZ6CKIYTBgscXbEduopQARJNUNiA== In-Reply-To: <200702231507.l1NF7QxC007880@tao.fdupont.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 20:53:10.0211 (UTC) FILETIME=[1FADB130:01C759E8] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Use the same as done in RFC3775. -Raj On 2/23/07 9:07 AM, "ext Francis Dupont" wrote: > For draft-ietf-mip6-cn-ipsec I-D we have the choice between to put > "binding update" or "Binding Update". The first is the rule in English > (i.e., not in German) for common names, the second makes the promote > the term as it was done in RFC 3775. What is your advice? > > Regards > > Francis.Dupont@fdupont.fr > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 26 18:37:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLpOY-0006wn-Ul; Mon, 26 Feb 2007 18:36:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLpNW-0002qw-Um for mip6@ietf.org; Mon, 26 Feb 2007 18:35:34 -0500 Received: from web60313.mail.yahoo.com ([209.73.178.136]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HLpNU-0004vT-Go for mip6@ietf.org; Mon, 26 Feb 2007 18:35:34 -0500 Received: (qmail 49235 invoked by uid 60001); 26 Feb 2007 23:35:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=r1zSQ49JWAxoCd6epirHMX/BniwKuq1earaVxdEgmL56yDT0PkuWfRrDce1RAhSGSUuRgGucK5xxuYtUsvUosp3aObPSr8EFFH0gn2MwS3GSYazblG5ilt2XwG/GwSdUetgE9hajx3jXXI/MukFW9ct4Tg1Uis3YkA1Zta4e0MA=; X-YMail-OSG: er040aAVM1moI.VstMsXsTtmGLVOt9dGeIeupI1JeY86dV92ETz4NuuwC.zSV6oh27SpEKdV_ZTYTxhM.eLwlANWpVWCNEl1U.tXvdajwNbTUiYREJbHbJotP3JlOmaEly.QQiB6d9QF44FsENxuz4Z.4xA- Received: from [206.16.17.212] by web60313.mail.yahoo.com via HTTP; Mon, 26 Feb 2007 15:35:32 PST X-Mailer: YahooMailRC/368.8 YahooMailWebService/0.6.132.8 Date: Mon, 26 Feb 2007 15:35:32 -0800 (PST) From: Behcet Sarikaya Subject: [Mip6] hiopt-02 To: heejin.jang@samsung.com MIME-Version: 1.0 Message-ID: <268146.48501.qm@web60313.mail.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "mip6@ietf.org" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0510829226==" Errors-To: mip6-bounces@ietf.org --===============0510829226== Content-Type: multipart/alternative; boundary="0-348605797-1172532932=:48501" --0-348605797-1172532932=:48501 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Heejin,=0A In hiopt-02 you are referring in [4] to 3315, does this mean= that HoA MN gets bootstrapped has a DHCP lifetime to be refreshed by DHCP = server?=0A I am confused about this because you are not referencing 3736.= =0A =0ARegards,=0A =0ABehcet=0A=0A=0A----- Original Message ----=0AFrom: He= ejin Jang =0ATo: Kilian Weniger =0ACc: "mip6@ietf.org" ; Basavaraj Patil =0ASent: Sunday, February 25, 2007 8:44:55 PM=0ASubj= ect: Re: RE: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02= =0A=0AHi, Kilian. =0AThanks for the comments. =0A =0ARegarding the use of t= erm, the draft(hiopt) supports all the three following networks as target n= etworks=0A1) ASP (MN's currently visited network)=0A2) Home MSP (=3D MSA)= =0A3) MSP (network which is nether ASP nor Home MSP but has trust relation= ship with MN's MSA)=0A =0AThe term 'home MSP' can be ambiguous since it doe= s not include 3), =0Aso we will modify it to 'MSP with roaming relationshi= p with MN's MSA' for more clarification.=0AThanks.=0A =0ARegards, =0AHeejin= . --0-348605797-1172532932=:48501 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Heejin,
=0A
  In hiopt-02 y= ou are referring in [4] to 3315, does this mean that HoA MN gets bootstrapp= ed has a DHCP lifetime to be refreshed by DHCP server?
=0A
=   I am confused about this because you are not referencing 3736.
= =0A
 
=0A
Regards,
=0A
 =0A
Behcet

=0A
----- Original Message ----=
From: Heejin Jang <heejin.jang@samsung.com>
To: Kilian Weniger= <Kilian.Weniger@eu.panasonic.com>
Cc: "mip6@ietf.org" <mip6@ie= tf.org>; Basavaraj Patil <basavaraj.patil@nokia.com>
Sent: Sund= ay, February 25, 2007 8:44:55 PM
Subject: Re: RE: RE: [Mip6] WGLC: draft= -ietf-mip6-bootstrapping-integrated-02

=0A=0AHi, Kilian. =0A

Thanks for = the comments.

=0A

 

=0A

Regarding the use of term, the draf= t(hiopt) supports all the three following networks as target networks<= /P>=0A

1) ASP (MN's currently visited network)

=0A

2) Home MSP (=3D = MSA)

=0A

3) MSP (network which is nether  ASP nor Home MSP but ha= s trust relationship with MN's MSA)

=0A

 

=0A

The term = 'home MSP' can be ambiguous since it does not include 3),

=0A

so we w= ill modify it to 'MSP with roaming  relationship with MN's MSA' for mo= re clarification.

=0A

Thanks.

=0A

 

=0A

Regards,

= =0A

Heejin.

=0A


 

--0-348605797-1172532932=:48501-- --===============0510829226== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0510829226==-- From mip6-bounces@ietf.org Mon Feb 26 23:32:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLtzo-00063I-Qj; Mon, 26 Feb 2007 23:31:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLtzn-0005xK-42 for mip6@ietf.org; Mon, 26 Feb 2007 23:31:23 -0500 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 1HLtzk-0002rb-Kt for mip6@ietf.org; Mon, 26 Feb 2007 23:31:23 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Feb 2007 20:31:20 -0800 X-IronPort-AV: i="4.14,223,1170662400"; d="scan'208"; a="764617500:sNHT43247404" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l1R4VKAp011404; Mon, 26 Feb 2007 20:31:20 -0800 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1R4VJDl003889; Mon, 26 Feb 2007 20:31:19 -0800 (PST) Date: Mon, 26 Feb 2007 20:31:19 -0800 (PST) From: Sri Gundavelli To: Hesham Soliman In-Reply-To: <20070226073753.CQFS19269.omta05ps.mx.bigpond.com@PC20005> Message-ID: References: <20070226073753.CQFS19269.omta05ps.mx.bigpond.com@PC20005> 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=1490; t=1172550680; x=1173414680; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20Encapsulation=20modes=20-=20draft-ietf-mip6-nemo-v4traversal- 03.txt |Sender:=20; bh=1g1DYKtabIRJb5U4c+oTQ3P+9IbPUyM4JJumFtFSC7k=; b=URIt/VarOO54PyGKUwbf0mQ64FpAd7sb5dauZjAs2Ijk5AqQ+gMNf5HKTluTAv5OA6qCBJsd bAJ/0JS46GHhjVS+3gbQ/SECDUrUUe6tbgCgvRtqNVimZZRNjsVXiSBG; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: 'Mobile IPv6 Mailing List' Subject: [Mip6] Encapsulation modes - draft-ietf-mip6-nemo-v4traversal-03.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham and other authors, Reference to section 4.3.1 and 4.4.1. For the IPv4 transport and with NAT in path, the opaque encapsulation mode of IPv4-UDP for both IPv4 and IPv6 payload packets i.e IPv6/IPv4-UDP or IPv4/IPv4-UDP is being recommended by the draft. With out a payload qualifier in the UDP header, I wonder how the tunnel peer handles the packet after decapsulation ? How would it know, if it is an IPv4 payload packet or an IPv6 packet ? Do you expect some packet inspection after decapsulation ? Thanks Sri Section 4.3.1 When the mobile node is located in an IPv4 only network, it will send IPv6 packets to its home agent according to the following format: IPv4 header (src=V4ADDR, dst=HA_V4ADDR) [UDP header] IPv6 header (src=V6HoA, dst=CN) Upper layer protocols Where the UDP header is only used if a NAT were detected between the mobile node and the home agent, or if the home agent forced UDP encapsulation. Similarly, IPv4 packets are sent according to the following format: IPv4 header (src=V4ADDR, dst=HA_V4ADDR) [UDP header] IPv4 header (src=V4HoA, dst=V4CN) Upper layer protocols Where the UDP header is only used if a NAT were detected between the mobile node and the home agent, or if the home agent forced UDP encapsulation. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 27 00:18:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLuib-0002Bl-4Q; Tue, 27 Feb 2007 00:17:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLuiZ-00021X-Jx for mip6@ietf.org; Tue, 27 Feb 2007 00:17:39 -0500 Received: from otm-mgo01.iij.ad.jp ([210.138.20.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLuiY-0007IR-Nh for mip6@ietf.org; Tue, 27 Feb 2007 00:17:39 -0500 Received: OTM-MO(otm-mgo01) id l1R5HHnP043527; Tue, 27 Feb 2007 14:17:17 +0900 (JST) Received: OTM-MIX(otm-mix00) id l1R5HHhS073088; Tue, 27 Feb 2007 14:17:17 +0900 (JST) Received: from [127.0.0.1] (keiichi00-4.osaka.iij.ad.jp [192.168.64.45]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp01) id l1R5H45X062360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Feb 2007 14:17:05 +0900 (JST) In-Reply-To: <45E33559.1080404@azairenet.com> References: <20070226030713.OARH19269.omta05ps.mx.bigpond.com@PC20005> <45E33559.1080404@azairenet.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <3E1F37AC-1DD2-4040-84C2-74BF8562FF17@iijlab.net> From: Keiichi SHIMA Subject: Re: [Mip6] Issue 73: v4 mapped address in IPv6 header Date: Tue, 27 Feb 2007 14:17:23 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0708331083==" Errors-To: mip6-bounces@ietf.org --===============0708331083== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6-972714910; protocol="application/pkcs7-signature" --Apple-Mail-6-972714910 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello all, I agree with Vijay. IPv4 mapped address is defined as the interface between applications and IP stack, if I understand correctly. I guess most of the IP stack don't handle IPv4 mapped address at IP level, even though the OS provides the IPv4 mapped address interface to its applications. I think processing the IPv4 care-of address option is similar to that of the alternate care-of address option, and simpler to implement than adding IPv4 mapped address care-of address support. Regards, --- Keiichi SHIMA IIJ Research Laboratory WIDE Project On 2007/02/27, at 4:30, Vijay Devarapalli wrote: > Hello, > > There were some more concerns/issues raised regarding the use > of a mapped address instead of an explicit mobility option for > the IPv4 care-of address. > > I prefer the use of an explicit IPv4 CoA option in the binding > update to carry the IPv4 care-of address of the mobile node. > Here are some reasons. > > 1. Many implementations don't support mapped addresses. > 2. The IPv4 CoA is indicated explicitly through the use of a > mobility option. I prefer this explicit indication for the > IPv4 CoA. The binding update processing on the home agent > becomes easier to parse the IPv4 care-of address and compare > it with the IPv4 source address on the outermost IPv4 header > for NAT detection. > 3. In case there is no NAT on the path, ESP protection is > provided for the IPv4 CoA since it is a mobility option > which comes after the ESP header. > 4. It enables one to send a binding update in the tunneled > format. > > IPv4 header (src = V4ADDR, dst = HA_V4ADDr) > UDP header > ESP header in tunnel mode > IPv6 header (src = IPv6 HoA, dst = HA_V6ADDR) > Mobility header > Binding Update > IPv4 CoA option (IPv4 CoA) > > Of course one can always send a BU in transport format, but > the IPv4 CoA option enables one to also send a BU in the > tunneled format in an optimized manner. Without the use of > IPv4 CoA option, the tunneled BU will have too much overhead. > > There are many reasons why you would want to send a tunneled > BU. One is privacy. The other is to enable an implementation > to use just one tunnel mode ESP SA to protect all MIPv6 > signaling messages and payload traffic. > > Hope this helps. > Vijay > > Hesham Soliman wrote: >> Folks, This is the final issue listed on the tracker. This one is >> a bit long. >> Issue Text: >> ----------- >> the IPv4 mapped address has a special meaning by RFC >> 2553 API. It is not preferable to use the mapped address in IPv6 >> headers (See the following the drafts) >> draft-itojun-v6ops-v4mapped-harmful >> draft-cmetz-v6ops-v4mapped-api-harmful >> In our code based on KAME, the IPv6 implementation discard a IPv6 >> header which has the v4 mapped address for sanity at ip6_input() and >> ip6_rthadr2(). We also need to add the mapped address in an address >> list (the list of all addresses which the node has) to receive the >> header. This is somehow uncomfortable because the mapped address is >> actually not routable. >>> From Hesham: >> => No one suggested that it should/would be routable. It's simply >> used to keep the packet format. There is no routing based on this >> information. >>> From Koshiro: >> => I am not sure whether it's just an implementation issues. But >> putting >> the mapped address in the address list in order to process the DSMIP >> IPv6 header means the mapped address may be chosen as a source >> address >> even the address is actually not routable. To avoid this, we need >> e.g. an additional flag to distinguish the mapped address from >> others. >> I think some implementers will not accept this. >> The above is not only the reason again the mapped address in the IPv6 >> header. Please refer the draft-*-harmful. So, my idea is to put HoA >> in IPv6 header and kind of IPv4 CoA option to idicate it's IPv4 CoA. >> BTW, if you just want to keep the packer format, I think it's better >> to use compatible address, or 6to4 address, or newly-defined address >> for this purpose. >> Analysis: >> --------- >> The resons listed in the issue text (and other reasons discussed >> in the DT) >> as well as their rebuttal are listed in this section. The first >> reason for >> using a different address format was that the use of mapped >> address was not >> recommended. The issue text refers to two drafts above. Those two >> drafts >> were discussed several years ago in 2002 (first v6ops meeting). >> The only >> issue that was agreed on in those drafts was that the mapped >> address should >> not be used as a routable address. Therefore, the issue >> misinterprets the >> agreement in the community. Also, the mapped address is not used as a >> routable address in DSMIP. The drafts referred to above did >> suggest the >> removal of the v4 mapped address altogether from IPv6, but this >> suggestion >> was rejected and the drafts were not adopted. Mapped addresses are >> supported >> in all major OSs (with the exception of KAME). The issue text also >> suggests the use of a different address format >> (compatible address, 6-to-4, or a new address format). The compatible >> address format was deprecated from the IPv6 address architecture >> and the >> mapped format is the recommended format for embedding IPv4 >> addresses in >> IPv6. 6-to-4 addresses imply a specific tunnelling behaviour >> (tunnelling to >> the v4 address), which is not useful for our purposes. A new >> address format >> will be no different from the mapped address, which is designed >> for this >> purpose. Another concern that was raised against the use of the >> mapped address was >> that they are "implicit" in nature ad do not explicitly show the IPv4 >> address. However, IP stacks must check the src address in the >> packet to >> insure that is in fact a legal address (e.g. not multicast) in >> ip6_input. Recommendation: >> -------------- >> My recommendation is to reject this issue for several reasons: >> a. There is no clear problem with the current format, i.e. what >> breaks? >> b. We've already removed the alt-CoA option in a previous issue, >> so if we >> accept this issue we'd have to introduce a new address format for >> DSMIP. >> This can take a long time and will yield the same result. >> Although, if there >> is something specific in the mapped address format that will cause >> problems, >> and a new address format will solve this problem then I'm >> personally ok with >> the new address format. However, we need to understand what that >> problem is. >> Regards, >> Hesham >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 --Apple-Mail-6-972714910 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKbjCCBF8w ggJHoAMCAQICAhIQMA0GCSqGSIb3DQEBBQUAMEUxCzAJBgNVBAYTAkpQMRUwEwYDVQQKEwxXSURF IFByb2plY3QxHzAdBgNVBAMTFm1lbWJlcnMgb3JpZW50ZWQgQ0EgMDIwHhcNMDYwNjEyMDQ1NTA5 WhcNMDcwNjMwMjM1OTU5WjBkMQswCQYDVQQGFAJKUDEVMBMGA1UEChQMV0lERSBQcm9qZWN0MRsw GQYDVQQDFBIwMzI4IEtlaWljaGkgU2hpbWExITAfBgkqhkiG9w0BCQEUEmtlaWljaGlAaWlqbGFi Lm5ldDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu6pTSPQTKzeSygFymRWYipFcZRaePRSU nruo6RtpQuNgDyUKvaMOa1KuNWRPYHp28hoWYe0YBrGj5SdHH2A3wbJ2zP5cXQFgMJMxJXhcWuSu +Foo7n9T1+yFjuc37Us9N4LoXZaM3krFqBHz2XSUCSigzTstdkIXWPwxDg+db4MCAwEAAaOBvTCB ujAOBgNVHQ8BAQAEBAMCBLAwIAYDVR0RAQEABBYwFIESa2VpaWNoaUBpaWpsYWIubmV0MDYGA1Ud HwEBAAQsMCowKKAmoCSGImh0dHA6Ly93d3cubW9jYS53aWRlLmFkLmpwL2NybC5jcmwwIgYDVR0j AQEABBgwFoAUOM7FCTrTDVTyVXHmSMda90Tf6bowKgYDVR0lAQEABCAwHgYIKwYBBQUHAwQGCCsG AQUFBwMDBggrBgEFBQcDAjANBgkqhkiG9w0BAQUFAAOCAgEAlB3DdeJJZ1gJh4sszEgoUg9DIHRG eaotuAi5FfGkd+KmzEARKYvgfh1A8AVAoHISFvavv0OD9w9dmzGyAmNUTBUsSMeH/5XiLuWJPbjU 3bVK467oyDEFaA+XFJurRY6RuPb4afHoi+aCHtY/pmcGCCSQPKnOuN8BviNLp/haDQyPVVwA+9it s7PwUArSkPnkBo1GXk4FSFDkijbw6zzJkXePBLHkE3QcFBYIo0woy6P2NFFYz8nPmd8M8qyT0Yh8 A9g0UVxvcWk4gUaJP0AeZ8/raNCr7eXBMByhDx5FSvparc21zEmQ5MnCVduDuM9eM8Qc8zFqzTzg mmZza69jiiq98kL1yFqjfL4+Nu7+N9D8Q/NuaIYLd9E++s20X9Kb7dW1xqMS1E30I8ZZnIwu2Fox ZRziQnKHkatDFBI+zuNY3+nIcE8bvzm/Y36xwk2GhN8p707CsT5i17ZCzkvriCdkE13riXNhXDOe qGR6Kj1aZLLBxHeLvFUa72q65+ShesszO6lOxf66auFbXYsOfzIUhG3z5YmM6Lk5NtJom6F7Drob jPjyDv2zZoGNGdIqbDbOaFkmBEYchuToVMNzYk6v6d+v4A/MrnGlexgQbzfgC0Ld32NwPlDDGFnO LPjaEZ19bFK65rWjWwEyLsO15GD7jotBrDU5yngkhu15RKowggYHMIID76ADAgECAgIJFjANBgkq hkiG9w0BAQUFADA+MQswCQYDVQQGEwJKUDEVMBMGA1UEChMMV0lERSBQcm9qZWN0MRgwFgYDVQQD Ew9XSURFIFJPT1QgQ0EgMDIwHhcNMDYwNTE4MTMzNTM2WhcNMTYwNjMwMjM1OTU5WjBFMQswCQYD VQQGEwJKUDEVMBMGA1UEChMMV0lERSBQcm9qZWN0MR8wHQYDVQQDExZtZW1iZXJzIG9yaWVudGVk IENBIDAyMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA4BYQZ8z3YdyJUt0ZbDh0+rVf fpf/Aw2J2GKNLy4fMIGpEhjS+OhAPC9TUH6rNVV2AR6myr94stzWhGY++bZjd7/oYYRLa+tCtUKa Om49ibS8CHSqfeR/Yb0YHKTrHCaAu2PUw6kENGZ3bDCiMbuDPkPLVkYuN3rSRp3qHd1XJ8DZ2bTX DbW3cwVqHFxKjVf6mdBInlL8pMs9z4T9GNpcqQO1i7Uk467KLZYbi1W1d5m23Jodr/7/y08bc078 ppWE3dP9eNEysmRxdIvKMgTHfTjtYN3ZhnfUEsYoJ6W9flc9Qoe+5UqdBt+O5ruJM3m1viWf+Rs8 xvvs9ZnodrqaxAIDwgmgpHePLCV2Qc/Fix3vkLY2Rt9KXeRCjLOzgdCYhtuJI42hY/l9dJjrRRK/ Qo5jABzbRRJzCavDlqS25q1OXenrO64nU+7T92PfFeOv1ORg5PcCSoY0dIzN9lcL51yb2PLn3cUx ya4itIYV9MHFXaIDM4inLLmBUR/0xD4Q+Ju1Zqd5n+uK5lCrQ48+kMPKbrDyrDyvqHYTo8XRuyAU Z1F56NJFv6umd+/m0ADC1M7Q9HNXwt8dRZyvVgH8l4teYu9We32NtZ7H8dyNaa34R2zs1bP2ftDT Au//Bi/3u47JTSJ6M1zE6lsc7OwP6c32okaCRCwayxVYi+FgNdUCAwEAAaOCAQYwggECMA8GA1Ud EwEB/wQFMAMBAf8wDgYDVR0PAQEABAQDAgH+MFsGA1UdIAEBAARRME8wTQYJKoMIjJwYAQECMEAw PgYIKwYBBQUHAgEWMmh0dHA6Ly9tb2NhLndpZGUuYWQuanAvbW9jYV9ndWlkZS9tb2NhX3BvbGlj eS5odG1sMDwGA1UdHwEBAAQyMDAwLqAsoCqGKGh0dHA6Ly93d3cud2lkZS5hZC5qcC9jYS93aWRl cm9vdGNybC5jcmwwIAYDVR0OAQEABBYEFDjOxQk60w1U8lVx5kjHWvdE3+m6MCIGA1UdIwEBAAQY MBaAFAzMoku5z7HsuNTr5KwJl0+xojExMA0GCSqGSIb3DQEBBQUAA4ICAQAKZpGub2X1UG9aXuAS P1MsRJtlgcataxapi6Lbox+8/5nrLXA6M5+FSD/3wjO96KEdv+KGK4WIE6AAsGKdH0dFE8jgzGVw uyoyXZg+UWhFrCMB3lbNfY9UsTBJfVx1TlMC1BXaT5qKCgp2N5dF6s2yeNa1kgGvR+xDkxNGDf6q 3xcN3QiC9ofyUyeRaZEacTjUp7bo4VREFtv3txyocbT6B961inhUS3PZNx6nIzJqiZA2CX/QGrlg 7uE1EoXgSJ+N77MdasX5Tl69Cb+fJCAdlbji1LAgWLEPXM0kHyYnfsLHfEXo4bCRdpN+GpPvqyhW DOk8ZEmrzYglsK38KIIG4Mp0tUoj25nzXhHnkNt0OCLSvzPcTopabRaPl4MnvQQ1tGsKbSafUBR5 gzdjA/f/o9bQKYwZC+fP8Gu50Ib4sYc5BbXEZdUx0Pjc/1nbIuM0t1YFrfLOiWP+Ar0x/WuPrtLZ gUyRnVBVyHm73be8T9wfE31aJw9E+2a92cjrp0lyCfWoCKjHGxdsPFvPIg1gKVG/IlgKeKEnKu1N O4PmD//LW/7p6A5V/W1vGZn8jI9ErwVz2cMiyJJfRVaviV5TcC58vrREH6qB9LfJwA7jy4CRu1oP GsaQRg5ZTMaV1JZ5cFBNHKcJiSDPTqVdKPkjmSUVUlYvEN+08pPGK/4KcTGCAgwwggIIAgEBMEsw RTELMAkGA1UEBhMCSlAxFTATBgNVBAoTDFdJREUgUHJvamVjdDEfMB0GA1UEAxMWbWVtYmVycyBv cmllbnRlZCBDQSAwMgICEhAwCQYFKw4DAhoFAKCCARcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwMjI3MDUxNzIzWjAjBgkqhkiG9w0BCQQxFgQUsUsv8vkeV1pZ 41/8dEGVbyH8BO8wWgYJKwYBBAGCNxAEMU0wSzBFMQswCQYDVQQGEwJKUDEVMBMGA1UEChMMV0lE RSBQcm9qZWN0MR8wHQYDVQQDExZtZW1iZXJzIG9yaWVudGVkIENBIDAyAgISEDBcBgsqhkiG9w0B CRACCzFNoEswRTELMAkGA1UEBhMCSlAxFTATBgNVBAoTDFdJREUgUHJvamVjdDEfMB0GA1UEAxMW bWVtYmVycyBvcmllbnRlZCBDQSAwMgICEhAwDQYJKoZIhvcNAQEBBQAEgYBxwwfZwh8+ZyY73YaG WZBcThfg2sLkZrZ/XlAG3TRR2hdcBUEpnK6XKidQsvwzYVdUhssejtdFhC1DuVQF/CVPVnVGJx4F N6P6kYh59lMoGCq1mTNvlj0456PrgDRupLaUFh3JSa6SVi0pSolVfTZqHkadlBcjduJyCg6p/oYl RgAAAAAAAA== --Apple-Mail-6-972714910-- --===============0708331083== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0708331083==-- From mip6-bounces@ietf.org Tue Feb 27 01:01:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLvOi-0008GB-7l; Tue, 27 Feb 2007 01:01:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLvOg-0008G5-Tw for mip6@ietf.org; Tue, 27 Feb 2007 01:01:10 -0500 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLvOc-0005Ev-2Q for mip6@ietf.org; Tue, 27 Feb 2007 01:01:10 -0500 Received: from PC20005 ([124.191.178.123]) by omta05ps.mx.bigpond.com with ESMTP id <20070227060051.GXCG9388.omta05ps.mx.bigpond.com@PC20005>; Tue, 27 Feb 2007 06:00:51 +0000 From: "Hesham Soliman" To: "'Vijay Devarapalli'" , "'Mobile IPv6 Mailing List'" Subject: RE: [Mip6] Issue 73: v4 mapped address in IPv6 header Date: Tue, 27 Feb 2007 17:00:46 +1100 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: <45E33559.1080404@azairenet.com> Thread-Index: AcdZ3KRyhF3jHBjmRwmstuAy0+wDkQAVsSNg x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070227060051.GXCG9388.omta05ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > 1. Many implementations don't support mapped addresses. => Can you elaborate on this? like which implementations? > 2. The IPv4 CoA is indicated explicitly through the use of a > mobility option. I prefer this explicit indication for the > IPv4 CoA. The binding update processing on the home agent > becomes easier to parse the IPv4 care-of address and compare > it with the IPv4 source address on the outermost IPv4 header > for NAT detection. => I think I answered this in the original email. The storage issue is another issue that we don't mandate in the draft. You can store it in any format you want. > 3. In case there is no NAT on the path, ESP protection is > provided for the IPv4 CoA since it is a mobility option > which comes after the ESP header. => Again, we discussed this before in the Alt-CoA discussion, we never know if there is a NAT in the path, hence the alt-CoA discussion and resolution. It is of course easier to compare two outer headers than something burried deep in the packet under IPsec. > 4. It enables one to send a binding update in the tunneled > format. > > IPv4 header (src = V4ADDR, dst = HA_V4ADDr) > UDP header > ESP header in tunnel mode > IPv6 header (src = IPv6 HoA, dst = HA_V6ADDR) > Mobility header > Binding Update > IPv4 CoA option (IPv4 CoA) > > Of course one can always send a BU in transport format, but > the IPv4 CoA option enables one to also send a BU in the > tunneled format in an optimized manner. Without the use of > IPv4 CoA option, the tunneled BU will have too much overhead. > > There are many reasons why you would want to send a tunneled > BU. One is privacy. The other is to enable an implementation > to use just one tunnel mode ESP SA to protect all MIPv6 > signaling messages and payload traffic. => Let's dissect this last point more to pin point the exact difference: - Both formats (mapped address or not) allow the packet format you mentioned above. Therefore the privacy argument is not relevant since it's suppported in both cases. - The second argument you make is about protecting all packets with one SA. Again, in the IPv4 case it doesn't matter because you can do the above format for all traffic. - The third argument is that one SA in tunnel mode is more efficient than two SAs. We don't disagree on this point but both formats can do this. - The final argument is that there is less bytes in this scenario. The difference in bytes is the difference between the IPv4 and the IPv6 address. This is true, but I want to clarify that this is the only difference between the two formats. Now, on the flip side, with this format you need to define a new option, parse it ..etc, whereas with the other format you use the same BU that is used today. So there is no change in the BU with the mapped address. Hesham > > Hope this helps. > Vijay > > Hesham Soliman wrote: > > Folks, > > > > This is the final issue listed on the tracker. This one is > a bit long. > > > > Issue Text: > > ----------- > > > > the IPv4 mapped address has a special meaning by RFC > > 2553 API. It is not preferable to use the mapped address in IPv6 > > headers (See the following the drafts) > > draft-itojun-v6ops-v4mapped-harmful > > draft-cmetz-v6ops-v4mapped-api-harmful > > > > In our code based on KAME, the IPv6 implementation discard a IPv6 > > header which has the v4 mapped address for sanity at > ip6_input() and > > ip6_rthadr2(). We also need to add the mapped address in > an address > > list (the list of all addresses which the node has) to receive the > > header. This is somehow uncomfortable because the mapped > address is > > actually not routable. > > > >>From Hesham: > > => No one suggested that it should/would be routable. It's simply > > used to keep the packet format. There is no routing based on this > > information. > > > >>From Koshiro: > > => I am not sure whether it's just an implementation > issues. But putting > > the mapped address in the address list in order to process > the DSMIP > > IPv6 header means the mapped address may be chosen as a > source address > > even the address is actually not routable. To avoid this, we need > > e.g. an additional flag to distinguish the mapped address > from others. > > I think some implementers will not accept this. > > > > The above is not only the reason again the mapped address > in the IPv6 > > header. Please refer the draft-*-harmful. So, my idea is > to put HoA > > in IPv6 header and kind of IPv4 CoA option to idicate it's > IPv4 CoA. > > > > BTW, if you just want to keep the packer format, I think > it's better > > to use compatible address, or 6to4 address, or > newly-defined address > > for this purpose. > > > > Analysis: > > --------- > > > > The resons listed in the issue text (and other reasons > discussed in the DT) > > as well as their rebuttal are listed in this section. The > first reason for > > using a different address format was that the use of > mapped address was not > > recommended. The issue text refers to two drafts above. > Those two drafts > > were discussed several years ago in 2002 (first v6ops > meeting). The only > > issue that was agreed on in those drafts was that the > mapped address should > > not be used as a routable address. Therefore, the issue > misinterprets the > > agreement in the community. Also, the mapped address is > not used as a > > routable address in DSMIP. The drafts referred to above > did suggest the > > removal of the v4 mapped address altogether from IPv6, but > this suggestion > > was rejected and the drafts were not adopted. Mapped > addresses are supported > > in all major OSs (with the exception of KAME). > > > > The issue text also suggests the use of a different address format > > (compatible address, 6-to-4, or a new address format). The > compatible > > address format was deprecated from the IPv6 address > architecture and the > > mapped format is the recommended format for embedding IPv4 > addresses in > > IPv6. 6-to-4 addresses imply a specific tunnelling > behaviour (tunnelling to > > the v4 address), which is not useful for our purposes. A > new address format > > will be no different from the mapped address, which is > designed for this > > purpose. > > > > Another concern that was raised against the use of the > mapped address was > > that they are "implicit" in nature ad do not explicitly > show the IPv4 > > address. However, IP stacks must check the src address in > the packet to > > insure that is in fact a legal address (e.g. not > multicast) in ip6_input. > > > > > > Recommendation: > > -------------- > > > > My recommendation is to reject this issue for several reasons: > > a. There is no clear problem with the current format, i.e. > what breaks? > > b. We've already removed the alt-CoA option in a previous > issue, so if we > > accept this issue we'd have to introduce a new address > format for DSMIP. > > This can take a long time and will yield the same result. > Although, if there > > is something specific in the mapped address format that > will cause problems, > > and a new address format will solve this problem then I'm > personally ok with > > the new address format. However, we need to understand > what that problem is. > > > > > > > > Regards, > > Hesham > > > > > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 27 04:34:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLyj9-0005TY-QT; Tue, 27 Feb 2007 04:34:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLyj8-0005T5-3v for mip6@ietf.org; Tue, 27 Feb 2007 04:34:30 -0500 Received: from cluster-j.mailcontrol.com ([86.111.223.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLyj6-00085V-G1 for mip6@ietf.org; Tue, 27 Feb 2007 04:34:30 -0500 Received: from rly30j.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly30j.srv.mailcontrol.com (MailControl) with ESMTP id l1R9YDPM011158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Feb 2007 09:34:14 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly30j.srv.mailcontrol.com (MailControl) id l1R9XNhk008887 for mip6@ietf.org; Tue, 27 Feb 2007 09:33:23 GMT Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly30j-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l1R9XJp5008652; Tue, 27 Feb 2007 09:33:23 +0000 (GMT) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 6ed7_a2600ad0_c642_11db_8249_0030482aac25; Tue, 27 Feb 2007 10:12:22 +0100 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007022710331302-890711 ; Tue, 27 Feb 2007 10:33:13 +0100 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: -0.157,BAYES_00: -1.665,TOTAL_SCORE: -1.822 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Tue, 27 Feb 2007 10:38:07 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: Re: [Mip6] AD review of draft-ietf-mip6-bootstrapping-split In-Reply-To: <459A5A6C.5070602@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] AD review of draft-ietf-mip6-bootstrapping-split Thread-Index: AccucYeGDP5ufkyVTkumRjylIUDr3AGKLDEQ To: "Jari Arkko" Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F01278236@lan-ex-01.panasonic.de> Date: Tue, 27 Feb 2007 10:30:14 +0100 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-06-00-00 (www.mailcontrol.com) on 10.74.1.140 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Mobile IPv6 Mailing List , James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Jari, sorry for the late reply. As Gerardo said, the anycast HA assignment was contributed my Francis and me, so please find below my comments about the anycast HA assignment.=20 > > If an anycast address is returned in response to DNS=20 > resolution of > > an FQDN, the IKEv2 transaction between the Mobile Node and Home > > Agent is slightly modified. The Mobile Node sends the IKE_SA_INIT > > request to the anycast address. The node which has the anycast > > address assigned to one of its network interfaces selects a Home > > Agent address from the set of Home Agents managed by the=20 > node, and > > forwards the IKE_SA_INIT. If the set of Home Agents is=20 > empnty, the > > node simply drops the packet. The Home Agent answers=20 > using its own > > address, and includes an "under attack" cookie, in=20 > accordance with > > RFC 4306 [7]. The Mobile Node notes the Home Agent address and > > resends the IKE_SA_INIT message to the Home Agent, along with the > > cookie.=20 > There are several issues in this. First, I think I understand > at least one reason why the cookie exchange makes sense, > but is that something that has to be mandated? What if the There were two reasons for mandating the cookie exchange: 1. anycast HA address is typically a single well-known and public address, which makes it a possible target of DoS attacks.=20 2. less impact on IKEv2 exchange, since the complete IKEv2 exchange is done with unicast address. If nobody sees a big issue with an anycasted IKE_SA_INIT followed by a unicast IKE_SA_INIT response without cookie, I'm fine with "SHOULD" instead of "MUST" for the cookie (Vijay, from your reply it seems you have concerns?). Using the cookie due to reason 1 can be left to operator's decision IMHO. > home network simply figures out what HA should be used and > responds in the usual IKEv2 way? yes, IMHO we can relax this and it can be left to HA configuration/operator's decision whether HA always includes cookie or not (see above).=20 > Secondly, responding with the home agent's own address > is in violation of a MUST in RFC 4306, Section 2.11. I talked > to one of the IKEv2 designers about this and his advice > was that the MUST may have been a mistake. Or at least it > should be limited to unicast addresses, and leave the behaviour > for anycast addresses for future documents. In any case, > this deviation from RFC 4306 should be highlighted and > justified in the document. we could add something like "the MUST in RFC4306 refers to unicast only".=20 > The third issue is the above notion of a node that owns an > anycast address. How does this relate to the usual arrangement > where the routing system handles the delivery of the anycast > packets to the "closest" place that advertises that address? all HAs on home link should have same distance in hops from MN, so there shouldn't be any impact on the notion of delivery of anycast packets by the routing system. This forwarding allows the operator to control the assignment of a HA on the home link on a per-case basis based on parameters defined by operator(e.g., load). > When you say "forwards", do you mean that the packet is > forwarded unmodified, or that the particular home agent's > address replaces the destination address?=20 good question. Some options for forwarding are=20 1. MAC address replacement,=20 2. IP tunneling, 3. IP address replacement.=20 The first (and maybe the second) option have the issue that the receiver of a unmodified packet has no way to determine whether the packet was already forwarded by another HA or comes from the MN. Hence, it would apply the same mechanism to forwarded packets as to packets received directly from the MN. This means that unmodified packets may be forwarded many times, if the considered parameters (e.g., load) have changed since the last forwarding or are not the same at all HAs. This could be prevented by modifying forwarded packets somehow, so that the HA is able to identify those and doesn't apply the forwarding mechanism to already forwarded packets. This is not needed if the third option is used. > Do you allow each home agent to configure the same anycast address? yes. I assume that all HAs have at least one anycast address and one unicast address. All HAs can have the same anycast addresses or different anycast addresses if there are multiple anycast groups (i.e., some HAs have anycast address x, other anycast address y etc). > Four: What happens when the IKE SA dies or is > deleted, but a binding for the mobile node remains > in the selected home agent? Will the mobile node > re-establish the IKE SA using the anycast address, > or the address of the selected home agent? Yes, some text should be added about that. The MN could first try to re-establish the SA with the current HA's unicast address, as Vijay said. But if this fails, the MN should try to find a new HA, e.g., by using the anycast HA assignment.=20 > Finally, I wonder how useful the anycast part of > this spec is given that DNS can already provide > a set of addresses. The anycast mechanism enables initial HA assignment on per-case basis, e.g., based on current load. This allows more fine-grained load balancing than DNS-based HA discovery and may save an additional HA switch for moving the MN to a less loaded HA after bootstrapping. The anycast mechanism may also be superior in case of DDos attack on certain HAs (due to more fine-grained load balancing). Finally, the operator has more control about which HAs will be used by MNs. Regards, Kilian Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 27 08:17:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM2BV-0004dA-Fi; Tue, 27 Feb 2007 08:16:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM2BU-0004d1-IK for mip6@ietf.org; Tue, 27 Feb 2007 08:16:00 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM2BT-0004mL-82 for mip6@ietf.org; Tue, 27 Feb 2007 08:16:00 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1021856ugd for ; Tue, 27 Feb 2007 05:15:58 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=M7uauzmHwN/WW+QeGC+gEJhUwqQcAzaUOkGZAL1hkrksnURuv4bH1Wu6PCvJo7vZB+HxhlRbRQWMFdgBYlPkx7ANZtfzpc7PKDLTaz57JxYuJoSJiN2fh+DluRJfUZCPyI80itj4xbp6Zx6C66aCthimfk+0n7HYezDbYmsJK0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WrpmwCBNPTjJd8nTcG9bBJ82dcnhd1uYC9g/0aTXP/RJmbD8w5Iz8Bnyk9F6AqtFSsRZ3EF+p/12l0TEua+gi3CFEjQz7QWu57u6yEwLD21EejXUoK3PWy2cFiioR96pbKQesKvOQ5q0LcBb99CvSe+Ek5pdwac1zo8t6n9vcUY= Received: by 10.66.225.1 with SMTP id x1mr5148087ugg.1172582158343; Tue, 27 Feb 2007 05:15:58 -0800 (PST) Received: by 10.66.238.6 with HTTP; Tue, 27 Feb 2007 05:15:52 -0800 (PST) Message-ID: Date: Tue, 27 Feb 2007 14:15:52 +0100 From: "Gerardo Giaretta" To: "Vijay Devarapalli" Subject: Re: [Mip6] AD review of draft-ietf-mip6-bootstrapping-split In-Reply-To: <45E32B26.7050702@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <459A5A6C.5070602@piuha.net> <45E00DD3.1010701@piuha.net> <45E32B26.7050702@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Mobile IPv6 Mailing List , James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, one comment inline... On 2/26/07, Vijay Devarapalli wrote: > Jari Arkko wrote: > > >> In case the FQDN is known by the AAA server via EAP, I see two > >> possible approaches: > >> > >> - the AAA server provides the HA with the MN's FQDN received via EAP > >> (e.g. during Diameter EAP application) and the HA stores the > >> "authorized" FQDN. This would require a change in current Diameter > >> application > > > > Yes. Or a new AVP, at least. CUI might apply here, but it might > > not have exactly the semantics you want. > > > >> - the HA performs a AAA exchange when it receives a BU with a DNS > >> Update mobility option; this AAA exchange should be part of the Mobile > >> IPv6 Diameter application (work in progress in DIME WG) and should be > >> used by the HA to get the authorized FQDN from the AAA server in order > >> to update the DNS > > > > This sounds preliminarily better. > > I don't like this additional AAA exchange just for the > DNS update. We should go with the solution where the > AAA server sends the mobile node's true FQDN (the one > that appears in the DNS) to the home agent in the AA > Answer message or the Diameter EAP Answer message, > depending on whether authentication and authorization > is done separately or together. > > (I haven't followed the work in Dime for a while. So > I don't know what the current thinking is). > The AAA exchange may not be an additional one. Currently we are discussing this issue in DIME WG (please, it would be great if you take part on that discussion too); there are two options under discussion, depending if the authorization for MIPv6 bootstrapping is performed during the bootstrapping or after the first BU. The latter option derives from the consideration that the MN is actually using the MIP service only after the first BU. > >> The draft should leave the actual definition of either mechanism as > >> out of scope (as you suggested), but we should put a reference to the > >> solution. > >> > >> As a summary, in this draft, I think it is enough to clarify the need > >> of the FQDN in the cert for the certificates scenario. For the AAA/EAP > >> scenario, we should provide a reference for the HA-AAA coordination > >> needed in case EAP is used, > > IMO, whenever the mobile nodes uses different identities > in the IDi field and in EAP payloads, we should require > the AAA server to send the mobile node's identity to > the Home Agent. > That is the first option I described, isn't it? --Gerardo > Vijay > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 27 15:52:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM9IN-0002eG-D5; Tue, 27 Feb 2007 15:51:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM9HR-0001GA-Qe for mip6@ietf.org; Tue, 27 Feb 2007 15:50:37 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM9HQ-00085H-Iq for mip6@ietf.org; Tue, 27 Feb 2007 15:50:37 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id A5C2E90075 for ; Tue, 27 Feb 2007 15:50:32 -0500 (EST) 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 23767-06 for ; Tue, 27 Feb 2007 15:50:28 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 27 Feb 2007 15:50:28 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 15:50:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Date: Tue, 27 Feb 2007 15:50:26 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD9B9@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Thread-Index: AcdQY1dNlaD6hLxWEduSnQARJNUNiAAgF6FwARg2mFAARgirYAETqRlg From: "Chowdhury, Kuntal" To: "Kilian Weniger" X-OriginalArrivalTime: 27 Feb 2007 20:50:26.0759 (UTC) FILETIME=[E8AAA570:01C75AB0] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 1.1 (+) X-Scan-Signature: 5d99cba2a085c3987933aa34e30e85ab Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Kilian, Please see inline.... I will start updating the I-D with your comments after the WGLC is over. Regards, Kuntal > -----Original Message----- > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > Sent: Thursday, February 22, 2007 5:06 AM > To: Chowdhury, Kuntal > Cc: mip6@ietf.org; Basavaraj Patil > Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 >=20 > Hi Kuntal, >=20 > thanks for you comments. See my comments inline. >=20 > > -----Original Message----- > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > Sent: Mittwoch, 21. Februar 2007 19:49 > > To: Kilian Weniger; Basavaraj Patil; mip6@ietf.org > > Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 > > > > Hi Killian, > > > > Thanks for reviewing the draft. I see that Heejin already responded to > > you. Let me add some of my comments...please see inline. >=20 > I will reply to Heejin in a separate mail. >=20 > > > > Regards, > > Kuntal > > > > > > > -----Original Message----- > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > > Sent: Friday, February 16, 2007 2:31 AM > > > To: Basavaraj Patil; mip6@ietf.org > > > Subject: RE: [Mip6] WGLC: > > draft-ietf-mip6-bootstrapping-integrated-02 > > > > > > Hi, > > > > > > please find below some comments about > > > draft-ietf-mip6-bootstrapping-integrated-02. > > > > > > The draft is well written and easy to understand (thanks to figures > > and > > > message sequence text). However, some details and corner > > cases are not > > > addressed, which may need to be specified, e.g.: > > > > > > - How does the NAS/relay map a DHCP request received from a specific > > MN > > > to the cached home network information previously > > received from AAAH > > > for this MN, so that it can include the correct home network > > > information in a received DHCP request? > > > > [KC>] Normally NAS maintain session states along with lower layer > > identifiers such as tunnel ID, MAC address etc. These identifiers help > > NAS in locating the correct cached info for the MN. >=20 > ok, I was expecting that. Maybe this could be clarified in the draft for > better understanding (without mandating a specific lower layer > identifier of course). >=20 [KC>] OK. I will try to clarify this in the next revision. > > > > > - What is the conceptual data structure needed for this in the > > NAS/DHCP > > > relay? > > > - Any default value for how long NAS should cache home network > > > information received from AAA for a specific MN (i.e., when is NAS > > > allowed to delete cache entry?)? If this is specified in > > [MIP6-Dime] > > > or [MIP6-RADIUS] it should be mentioned and referenced. > > > > [KC>] As Heejin mentioned, I think these are implementation specific > > details. >=20 > yes, but I think some guidance with respect to values that make sense > might be helpful for implementors. >=20 [KC>] We can say: how long the NAS caches the received mip6 bootstrap information for a MN should be configurable. > > > > > > > - What should NAS do if DHCP request with Home network identifier > > > option is received from a MN and NAS doesn't find valid > > home network > > > information for this MN in its cache (e.g., since the cache entry > > > has expired)? > > > > [KC>] If a NAS implementation does not store the home network > > information as long as the MN's session remains in the ASP, this > > scenario may happen if the MN delays sending DHCP request. In > > such case, > > the NAS/DHCP relay won't include the OPTION_MIP6-RELAY-Option in the > > Relay Forward message. >=20 > ok. Shouldn't the draft specify this behaviour? >=20 [KC>] OK. I will clarify this. > > > > > - What should DHCP relay/server do if the MN does not include the > > > OPTION_CLIENTID in the DHCP request or if OPTION_MIP6-RELAY-Option > > > is missing in request? > > > > > > > [KC>] I think Heejin already clarified this with you. > > > > > The draft may need better aligned with [HIOPT]. For instance, it is > > not > > > clear to me how exactly the home network identifier option and the > > home > > > network information option specified in [HIOPT] are allowed > > to be used > > > in draft-ietf-mip6-bootstrapping-integrated-02: > > > > > [KC>] This part was in this I-D. However, based on the > > consensus we had > > in the WG, we decided to move all the DHCP related behavior to HIOT. > > Please look at section 4 in HIOT. >=20 > ok. So the split is that HIOPT specifies all the DHCP related behaviour > and defines the DHCP messages/options and > draft-ietf-mip6-bootstrapping-integrated-02 defines how this interworks > with AAA and gives the overall picture? Is this correct? I think > draft-ietf-mip6-bootstrapping-integrated-02 should clearly say what its > scope is and how the split is with respect to HIOPT (and the reference > should be updated to new HIOPT-version). >=20 [KC>] OK. I will see how to clarify this in the next revision. Of course, feel free to provide text to me if you like. > > > > > - [HIOPT] supports home address allocation. This is not mentioned in > > > draft-ietf-mip6-bootstrapping-integrated-02. Is this forbidden or > > > allowed or out-of-scope? If allowed, when does NAS set > > the A-flag in > > > the home network identifier option? > > > > [KC>] Please see Heejin's clarification. > > > > > - Is it allowed that multiple HA addresses are returned in the home > > > network information option? > > [KC>] yes, it is allowed. >=20 > ok. In general, I think all the supported features should be mentioned > in draft-ietf-mip6-bootstrapping-integrated-02. >=20 [KC>] OK. I will mention that the AAAH may return more than one home agent for each of the MSPs. > > > > > - [HIOPT] allows that the home network identifier option includes an > > > identifier of a target network, which is different from home or > > > visited network of MN. This is not mentioned in > > > draft-ietf-mip6-bootstrapping-integrated-02. Is this allowed or > > > forbidden? > > [KC>] the main assumption in integrated scenario is ASA =3D=3D MSA. = It is > > the MSA that authorizes the MN for mobility service and assigns > > appropriate number of Home Agents (in each MSPs if there are multiple > > MSPs) for the MN. If the MN sends DHCP request with home network > > identifier option set to one of the authorized MSPs and there is a HA > > assignment for that MSP by the MSA, the MN will get that HA's address. > > If the MN sends anything else (i.e. a domain that is not part of the > > authorized list of MSPs by the MSA), the MN may not get any Home Agent > > address in the reply. >=20 > I see. So every realm of any MSP that has a trust relationship to the > MN's MSA and that is supported by the MSA's allocation policy can be > included as target network in the home network identifier option, right? > (That's what I meant by "a target network, which is different from home > or visited network of MN".) >=20 [KC>] Yes. > Hmm, after checking RFC4640, it seems that there is a mismatch between > your comment and what the draft says: >=20 > - Section 3.2.1 of draft-ietf-mip6-bootstrapping-integrated-02 says > "This section describes a scenario where the home agent is allocated in > the mobile node's *home MSP* network." > - RFC 4640 says in section 6: "A network operator providing Mobile IPv6 > service is called a mobility service provider (MSP). ...A network > operator that authenticates a mobile node and authorizes mobility > service is called a mobility service authorizer (MSA). If both types of > operation are performed by the same operator, that operator is called a > *home mobility service provider*.". >=20 > So according to RFC4640 the home MSP is always the MSA. Since you said > HA allocation from other networks is supported, I think the use of "home > MSP" in the section 3.2.1 is not correct. Or am I missing something > here? >=20 [KC>] Your interpretation of home MSP is correct. However, it is quite possible that the home MSP/MSA can also assign (or authorize) Home Agent in a different MSP e.g. local Home Agent assignment in the visited domain (ASP). This is possible based on roaming agreements between the home MSP and the ASP (ref section 3.2.2).=20 I do understand the source of your confusion though. I think step 1 in section 3.2.2 needs to be updated to show that the home MSP actually authorizes the MN to get an HA address in the visited domain (ASP). The NAS needs to indicate it's capability for local HA assignment. The NAS will optionally indicate the HA address in the ASP that will be assigned to the MN in case that option is authorized by the home MSP. These clarifications will be added in the AAA drafts: draft-ietf-dime-mip6-integrated-02.txt and draft-ietf-mip6-radius-01.txt.=20 > And I think the support of the feature of HA allocation from MSP !=3D MSA > and !=3D ASP should be mentioned in the draft. >=20 [KC>] OK. I will add some text around that topic. > > > > > - Which HA information should the MN use if it receives, > > e.g., an FQDN > > > and a HA address in DHCP reply? [HIOPT] refers to section 3.6 of > > > draft-ietf-mip6-bootstrapping-integrated-01, but this section > > doesn't > > > exist in draft-ietf-mip6-bootstrapping-integrated-02 anymore... > > > > > [KC>] This text was exported to HIOT draft. > > > > > Some other comments: > > > > > > - It would be good to have a section, which explicitly states > > > assumptions and applicability of the protocol. This > > should include: > > > - MSA and ASA must be co-located (i.e., integrated scenario) > > > > [KC>] The definition of integrated scenario exists in RFC 4640. > > > > > - AAA infrastructure assumed and some kind of roaming > > > relationship between ASP and MSA/ASA is required > > > > [KC>] We have ample references to AAA infrastructure for ASA and MSA. > > However, we can still add a sentence about the use of AAA > > infrastructure > > to authenticate and authorize the MN. Regarding roaming, I think your > > comment is valid. ASP <-> ASA/MSA and MSP <-> ASA/MSA roaming > > relationships are basic requirements for any access auth/authz for the > > MN. However, I think it is a generic requirement. Even in > > case of split > > scenario, ASP <-> ASA and MSP <-> MSA roaming relationships are > > necessary. Look at section 6 in RFC 4640 and let me know what > > you think. >=20 > ASP <-> ASA is general requirement for network access in roaming > scenarios, I agree. But the required MSP <-> ASA roaming relationship is > specific to this draft and it would be worth mentioning IMHO. > You are right, the reader could deduced it to some extent from RFC4640, > which says that MSA <-> MSP roaming relationship is *supported* (not > required) for MIP bootstrapping and MSA =3D ASA is an assumption in > integrated scenario. I prefer to make a clear statement about > assumptions/requirements of solutions in the draft. >=20 [KC>] OK. Could you please suggest some text on this? > > > > > - MSP is either co-located with ASP or MSA or both > > > (Or are other target networks allowed; see above)? > > > > [KC>] Why we need to mandate collocation of MSP with ASA or MSA? The > > draft HIOT allows any target network, but that does not mean > > that in the > > integrated scenario, the MSA can bootstrap the MN for any (random) > > target network. >=20 > This requirements comes from the misunderstanding about the home MSP > explained above. Since you clarified that target network !=3D MSA and = !=3D > ASP is supported, you are right that this requirement is not valid > anymore... >=20 > > > > > - DHCP relay and NAS must be co-located > > > > > [KC>] I think it is already mentioned in the draft: > > " > > Also, the mechanism defined in this document requires the NAS > > to support > > Mobile IPv6 specific AAA attributes and a collocated DHCP relay agent. > > " >=20 > yes, it is somewhat redundant. I just prefer it if the applicability and > all the requirements for the solution are clearly stated (preferably in > a separate section, as opposed to hidden in the text). >=20 [KC>] OK, I will add a section to state the assumptions. > > > > > - At some places in the text the use of the term "MSP" is ambiguous, > > > since MSP can refer to at least home and visited network. Better > > > use "home MSP" for MSP in home network. > > > - e.g., section 3.1: > > > "Note that a home agent for usage > > > with the mobile node might be selected in the access service > > > provider's network or alternatively in the *home* > > mobility service > > > provider's network." > > > > [KC>] I understand your point. We can clarify by saying that: > > > > " > > Note that a home agent for usage with the mobile node might > > be selected > > in the access service provider's network (ASP is the visited > > MSP in this > > case) or alternatively in the *home* mobility service > > provider's network > > (home MSP). > > " > > What do you think? If you agree, I will ensure that this is clarified > > elsewhere in the document. >=20 > Hmm, after having read your comments, "home MSP" might not be correct > here, since MSP can be !=3D MSA (i.e., !=3D home MSP) in this section. = How > about "MSP different from ASP" instead of "home MSP"? >=20 [KC>] OK. In that case, I will keep the existing text and modify it as follows: "Note that a Home Agent for usage with the MN might be selected in the Access Service Provider's network (ASP =3D=3D MSP) or in a different = network (ASP !=3D MSP)" > > > > > - or in section 3.2: > > > "The message flows for home agent > > > allocation in the ASP and the *home* MSP are illustrated below. > > > > [KC>] Similarly we can clarify: > > > > " > > The message flows for home agent allocation in the ASP (ASP is the > > visited MSP in this case) and the *home* MSP are illustrated below. > > " >=20 > Home MSP might not be correct (see above). How about >=20 > "The message flows for home agent allocation in the MSP for the cases > that the MSP is equal to the ASP and different from the ASP are > illustrated below." >=20 >=20 [KC>] OK. > > > > > - or in section 3.2.1: > > > "3.2.1. Home Agent allocation in the *home* MSP", > > > "(4)... mobile node is requesting home agent information in the > > > *home* MSP..." > > > > > > - Section 3.3 currently mentions DNS-based HA address > > discovery method > > > only, but [BOOT-SPLIT] also specifies an anycast-based HA address > > > discovery method. Either both or none should be mentioned. > > > > > [KC>] I see your point. May be we just need to say that > > incase the DHCP > > reply comes back with no Home Agent address, the MN may fallback to > > other methods for Home Agent bootstrapping. Some of those methods are > > mentioned in [BOOT-SPLIT]. >=20 > sounds good. >=20 > > > > > > > - The title of draft-ietf-mip6-bootstrapping-integrated-02 can cause > > > the impression that the draft defines a complete bootstrapping > > > procedure. But > > draft-ietf-mip6-bootstrapping-integrated-02 defines a > > > method for HA address assignment only. I think this is misleading. > > > Why not name the draft according to what it specifies (e.g., "HA > > > address assignment using DHCP and AAA" or "HA address > > assignment for > > > the integrated scenario using DHCP and AAA" instead of > > > "MIP6-bootstrapping for the integrated scenario")? > > > > > [KC>] I agree with you that the Home Agent assignment is the focus of > > the integrated scenario solution I-D. But, the suggested title change > > will be misleading too. One of the primary assumption in the > > integrated > > scenario for mip6 bootstrapping is ASA =3D=3D MSA. This is the main reason > > why the MSA can authorize the MN to have mobility service at > > the time of > > access auth/authz at the ASA. As per this assumption, the MSA assigns > > Home Agent info to the MN at the time of access auth. The MSA can > > potentially assign the HoA as well (in some deployments that may very > > well be the case), but we stayed away from mentioning that in > > the draft > > based on consensus. Another reason was to reuse text from other drafts > > as much possible. > > > > That said, the scope and focus of this I-D is to address mip6 > > bootstrapping solution for the "Integrated ASP Network Scenario" as > > defined by RFC 4640. So, the current title is fine, IMHO. >=20 > Since the introduction says "This document defines a mechanism for home > agent address discovery. For the rest of components, please refer to > [BOOT-SPLIT].", I think the title is still ok. >=20 > However, you mentioned that HoA allocation can be done by the MSA > (probably by using the method specified in HIOPT). If this shall be > supported in the integrated scenario, I think the draft has to mention > it. Currently, the draft clearly says that HoA allocation is according > to [BOOT-SPLIT]... >=20 [KC>] I agree. I am OK to include HoA assignment in the I-D to utilize the full potential of HIOPT. I will include it unless there are objections from the members. > Regards, >=20 > Kilian >=20 > > > > > > > > > Regards, > > > > > > Kilian > > > > > > > -----Original Message----- > > > > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > > > > Sent: Mittwoch, 14. Februar 2007 19:10 > > > > To: mip6@ietf.org > > > > Subject: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 > > > > > > > > > > > > Hello, > > > > > > > > This is a MIP6 Working group last call for the WG I-D: > > > > "MIP6-bootstrapping for the Integrated Scenario", > > > > draft-ietf-mip6-bootstrapping-integrated-02.txt > > > > > > > > I-D: > > > > http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping- > > > > integrated-dhc > > > > -02.txt > > > > > > > > Please review and submit your comments to the authors or > > the mailing > > > > list. The WGLC will expire on March 1st, 07. > > > > > > > > -Chairs > > > > > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > > Panasonic R&D Center Germany GmbH > > > 63225 Langen, Hessen, Germany > > > Reg: AG Offenbach (Hessen) HRB 33974 > > > Managing Director: Thomas Micke > > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > "This email message and any attachments are confidential > > information of Starent Networks, Corp. The information > > transmitted may not be used to create or change any > > contractual obligations of Starent Networks, Corp. Any > > review, retransmission, dissemination or other use of, or > > taking of any action in reliance upon this e-mail and its > > attachments by persons or entities other than the intended > > recipient is prohibited. If you are not the intended > > recipient, please notify the sender immediately -- by > > replying to this message or by sending an email to > > postmaster@starentnetworks.com -- and destroy all copies of > > this message and any attachments without reading or > > disclosing their contents. Thank you." > > > > >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 27 17:31:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMAqW-0001k6-8C; Tue, 27 Feb 2007 17:30:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMADq-0003Au-6F for mip6@ietf.org; Tue, 27 Feb 2007 16:50:58 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM9jx-00046g-J7 for mip6@ietf.org; Tue, 27 Feb 2007 16:20:25 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 5A5EE90075 for ; Tue, 27 Feb 2007 16:20:01 -0500 (EST) 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 23727-08 for ; Tue, 27 Feb 2007 16:19:56 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 27 Feb 2007 16:19:56 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 16:19:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Date: Tue, 27 Feb 2007 16:19:56 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD9BB@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Thread-Index: AcdUwMUyhF+tuBaFTgu1pTm7wLnJ/QCci1HgAN+TN9A= From: "Chowdhury, Kuntal" To: "Kilian Weniger" , "Heejin Jang" X-OriginalArrivalTime: 27 Feb 2007 21:19:56.0801 (UTC) FILETIME=[07B19F10:01C75AB5] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 1.1 (+) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Kilian, Please see inline... > -----Original Message----- > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > Sent: Friday, February 23, 2007 5:00 AM > To: Heejin Jang; Chowdhury, Kuntal > Cc: mip6@ietf.org; Basavaraj Patil > Subject: RE: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 >=20 > Hi Kuntal, Heejin, >=20 > I have another comments wrt draft-ietf-mip6-bootstrapping-integrated-02 > and draft-ietf-mip6-hiopt-02.txt: it seems service-based HA address > assignment is currently not supported. What I mean is, for instance, > that in case the MN wants to use DS-MIPv6 HA service, the network is > able to allocate a different HA to the MN than in case the MN wants to > use MIPv6 (RFC3775) HA service. >=20 [KC>] The Home Network Identifier (FQDN) in OPTION_MIP6-HNID can be used to indicate the specific service the MN is requesting the HA information for. Do we have to do anything else in the HIOPT I-D? May be this can be explicitly mentioned. > I heard at least one operator requesting such feature (and note that > this is in principle possible with the HA discovery/assignment > mechanisms defined in the split scenario bootstrapping draft). A simple > way to support this in the integrated scenario would be to add something > like a "type of requested HA service" field in the Home Network > Identifier Option of the DHCP information request sent by the MN. The > new field would encode the type of service, e.g., 0=3DMIPv6, = 1=3DDS-MIPv6, > 2=3DNEMO,...). Similarly, the Home Network Information Sub-option = could > include a "type of HA service" field to inform the MN about the type of > service supported by the HA offered in this option. However, since the > AAAH wouldn't know the HA service requested by the MN, AAAH would need > to send at least one HA address per supported service to the NAS. >=20 [KC>] Alternatively, we can encode the Home Network Identifier (FQDN) as ha.dsmip6.domain, ha.mip6.domain. This is possible with the current HIOPT I-D, no? From the AAAH perspective, it (AAAH) needs to send the HA address - Service pair. The service can be indicated by the FQDN AVP. We have the following AVPs in draft-ietf-dime-mip6-integrated-03.txt: [ MIP6-Home-Agent-Address ] [ MIP6-Home-Agent-FQDN ] Perhaps we can group them under a new AVP for service, e.g. MIP6-Home-Agent-Info AVP. For RADIUS we can perhaps link the MIP6-HA Attribute and MIP6-HA-FQDN Attribute. > What do you think? >=20 > Cheers, >=20 > Kilian >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 27 17:54:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMBDI-0008Cq-UT; Tue, 27 Feb 2007 17:54:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMACZ-0002zC-TK for mip6@ietf.org; Tue, 27 Feb 2007 16:49:39 -0500 Received: from av9-2-sn3.vrr.skanova.net ([81.228.9.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMA1j-0007DY-Fs for mip6@ietf.org; Tue, 27 Feb 2007 16:38:50 -0500 Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 4C1DF37F08; Tue, 27 Feb 2007 22:38:16 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 2AF2837EF2 for ; Tue, 27 Feb 2007 22:38:16 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 1B68637E42 for ; Tue, 27 Feb 2007 22:38:15 +0100 (CET) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz.levkowetz.com) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1HMA1R-000701-6D for mip6@ietf.org; Tue, 27 Feb 2007 22:38:15 +0100 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: Sri Gundavelli Date: Tue, 27 Feb 2007 21:38:08 +0000 MIME-Version: 1.0 Message-Id: <1172612288.22.0.0310637271414.issue93@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Rcpt-To: mip6@ietf.org X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-104.4 required=2.5 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.7-deb X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Mip6] [issue93] Payload Qualifiers when using IPv4-UDP transport for both IPv4 and IPv6 payloads X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org New submission from Sri Gundavelli : Reference to section 4.3.1 and 4.4.1. For the IPv4 transport and with NAT in path, the opaque encapsulation mode of IPv4-UDP for both IPv4 and IPv6 payload packets i.e IPv6/IPv4-UDP or IPv4/IPv4-UDP is being recommended by the draft. With out a payload qualifier in the UDP header, I wonder how the tunnel peer handles the packet after decapsulation ? How would it know, if it is an IPv4 payload packet or an IPv6 packet ? Do you expect some packet inspection after decapsulation ? One option is to have thin header such as the MIP Tunnel Data Message from RFC-3519, as suggested by Kent Leung. MIP Tunnel Data Message =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Next Header | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We want a quick resolution on this. draft-sgundave-mip6-proxymip6-02.txt has normative reference to the DSMIP6 spec. Thanks Sri ---------- category: Technical draft: draft-ietf-mip6-nemo-v4traversal messages: 330 nosy: sri priority: Must fix status: No discussion title: Payload Qualifiers when using IPv4-UDP transport for both IPv4 and I= Pv6 payloads _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 27 17:59:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMBHx-00012u-5E; Tue, 27 Feb 2007 17:59:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMAJ9-00047B-Mk for mip6@ietf.org; Tue, 27 Feb 2007 16:56:27 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HM9TA-0002A6-SO for mip6@ietf.org; Tue, 27 Feb 2007 16:03:55 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 987C190073 for ; Tue, 27 Feb 2007 16:02:34 -0500 (EST) 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 23974-08 for ; Tue, 27 Feb 2007 16:02:29 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 27 Feb 2007 16:02:29 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 16:02:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Date: Tue, 27 Feb 2007 16:02:29 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD9BA@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Thread-Index: AcdZUPl3RCOZHB9nQb6+3hPvBup2ywBYXBGg From: "Chowdhury, Kuntal" To: , "Kilian Weniger" X-OriginalArrivalTime: 27 Feb 2007 21:02:29.0709 (UTC) FILETIME=[97940FD0:01C75AB2] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 1.1 (+) X-Scan-Signature: 303e29529f30c23b95ea718537067fd5 Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Thanks Heejin. I think your suggested clarification # 3 is good.=20 -Kuntal ________________________________________ From: Heejin Jang [mailto:heejin.jang@samsung.com]=20 Sent: Sunday, February 25, 2007 8:45 PM To: Kilian Weniger Cc: mip6@ietf.org; Basavaraj Patil Subject: Re: RE: RE: [Mip6] WGLC: = draft-ietf-mip6-bootstrapping-integrated-02 Hi, Kilian.=20 Thanks for the comments.=20 =A0 Regarding the use of term, the draft(hiopt)=A0supports all the three = following networks as target networks 1) ASP (MN's currently visited network) 2) Home MSP (=3D MSA) 3) MSP (network which is nether =A0ASP nor Home MSP but has trust = relationship with MN's MSA) =A0 The=A0term 'home MSP' can be ambiguous since it does not include 3),=20 so we will modify it to 'MSP with roaming =A0relationship with MN's MSA' = for more clarification. Thanks. =A0 Regards,=20 Heejin. ------ Original Message ------- Sender : Kilian Weniger Date : 2007-02-22 23:00 Title : RE: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Hi=A0Heejin,=20 thanks=A0for=A0your=A0comments,=A0see=A0my=A0replies=A0inline.=A0=20 Please=A0note=A0that=A0the=A0comments=A0in=A0my=A0mail=A0were=A0referring= =A0to=20 draft-ietf-mip6-bootstrapping-integrated-02.=A0And=A0since=A0the=A0refere= nce=20 [HIOPT]=A0in=A0draft-ietf-mip6-bootstrapping-integrated-02=A0is=A0hiopt-0= 1,=A0I=20 didn't=A0consider=A0hiopt-02.=A0=20 >=A0-----Original=A0Message-----=20 >=A0From:=A0Heejin=A0Jang=A0[mailto:heejin.jang@samsung.com]=A0=20 >=A0Sent:=A0Dienstag,=A020.=A0Februar=A02007=A008:31=20 >=A0To:=A0Kilian=A0Weniger=20 >=A0Cc:=A0Basavaraj=A0Patil;=A0mip6@ietf.org=20 >=A0Subject:=A0Re:=A0RE:=A0[Mip6]=A0WGLC:=A0=20 >=A0draft-ietf-mip6-bootstrapping-integrated-02=20 >=A0=20 >=A0Hi,=A0=A0Kilian=A0Weniger.=A0=20 >=A0=20 >=A0Thanks=A0for=A0the=A0detailedl=A0comments.=A0=20 >=A0=20 >=A0Please=A0see=A0the=A0inline=A0comments=A0for=A0the=A0HIOPT=A0draft.=20 >=A0=20 >=A0=20 >=A0-------=A0Original=A0Message=A0-------=20 >=A0Sender=A0:=A0Kilian=A0Weniger=20 >=A0Date=A0:=A02007-02-16=A017:31=20 >=A0Title=A0:=A0RE:=A0[Mip6]=A0WGLC:=A0draft-ietf-mip6-bootstrapping-inte= grated-02=20 >=A0=20 >=A0Hi,=A0=20 >=A0=20 >=A0please=A0find=A0below=A0some=A0comments=A0about=A0=A0=20 >=A0draft-ietf-mip6-bootstrapping-integrated-02.=A0=20 >=A0=20 >=A0The=A0draft=A0is=A0well=A0written=A0and=A0easy=A0to=A0understand=A0(t= hanks=A0to=A0=20 >=A0figures=A0and=A0=20 >=A0message=A0sequence=A0text).=A0However,=A0some=A0details=A0and=A0corne= r=A0=20 >=A0cases=A0are=A0not=A0=20 >=A0addressed,=A0which=A0may=A0need=A0to=A0be=A0specified,=A0e.g.:=A0=20 >=A0=20 >=A0-=A0How=A0does=A0the=A0NAS/relay=A0map=A0a=A0DHCP=A0request=A0receive= d=A0from=A0a=A0=20 >=A0specific=A0MN=A0=A0=20 >=A0=A0=A0to=A0the=A0cached=A0home=A0network=A0information=A0previously=A0= received=A0=20 >=A0from=A0AAAH=A0=A0=20 >=A0=A0=A0for=A0this=A0MN,=A0so=A0that=A0it=A0can=A0include=A0the=A0corre= ct=A0home=A0network=A0=A0=20 >=A0=A0=A0information=A0in=A0a=A0received=A0DHCP=A0request?=A0=20 >=A0=20 >=A0=A0=20 >=A0=20 >=A0Hiopt>>=A0The=A0mapping=A0mechanism=A0is=A0added=A0in=A0section=A04.3= =A0of=A0the=A0=20 >=A0latest=A0version=A0of=A0the=A0document=A0(hiopt-02).=20 It=A0should=A0be=A0in=A0section=A04.2,=A0since=A0my=A0question=A0was=A0re= lated=A0to=A0the=A0DHCP=20 relay=A0behaviour.=A0Maybe=A0I=A0missed=A0it,=A0but=A0I=A0can't=A0see=A0a= ny=A0related=A0text=A0in=20 section=A04.2=A0of=A0hiopt-02=A0about=A0mapping=A0of=A0home=A0information= =A0received=A0from=20 AAA=A0server=A0to=A0DHCP=A0request=A0received=A0from=A0MN.=A0But=A0Kuntal= =A0answered=A0to=A0my=20 question=A0in=A0his=A0reply=A0email.=A0=20 >=A0=20 >=A0The=A0information=A0is=A0mapped=A0based=A0on=A0NAI=A0not=A0by=A0NAS=A0= but=A0by=A0DHCP=A0=20 >=A0server.=A0Rrefer=A0to=A0hiopt-02=A0for=A0more=A0details.=20 >=A0=20 >=A0=20 >=A0-=A0What=A0is=A0the=A0conceptual=A0data=A0structure=A0needed=A0for=A0= this=A0in=A0=20 >=A0the=A0NAS/DHCP=A0=A0=20 >=A0=A0=A0relay?=A0=20 >=A0-=A0Any=A0default=A0value=A0for=A0how=A0long=A0NAS=A0should=A0cache=A0= home=A0network=A0=A0=20 >=A0=A0=A0information=A0received=A0from=A0AAA=A0for=A0a=A0specific=A0MN=A0= (i.e.,=A0when=A0is=A0NAS=A0=A0=20 >=A0=A0=A0allowed=A0to=A0delete=A0cache=A0entry?)?=A0If=A0this=A0is=A0spe= cified=A0in=A0=20 >=A0[MIP6-Dime]=A0=A0=20 >=A0=A0=A0or=A0[MIP6-RADIUS]=A0it=A0should=A0be=A0mentioned=A0and=A0refer= enced.=A0=A0=20 >=A0=20 >=A0Hiopt>>=A0This=A0is=A0implementation-specific.=A0I'm=A0not=A0sure=A0w= e=A0need=A0=20 >=A0to=A0describe=A0down=A0to=A0the=A0smallest=A0detail.=A0=20 A=A0value=A0doesn't=A0need=A0to=A0be=A0mandated,=A0but=A0I=A0think=A0some= =A0guidance=A0to=A0the=20 implementor=A0would=A0be=A0good.=20 >=A0=20 >=A0=20 >=A0-=A0What=A0should=A0NAS=A0do=A0if=A0DHCP=A0request=A0with=A0Home=A0ne= twork=A0identifier=A0=A0=20 >=A0=A0=A0option=A0is=A0received=A0from=A0a=A0MN=A0and=A0NAS=A0doesn't=A0= find=A0valid=A0=20 >=A0home=A0network=A0=A0=20 >=A0=A0=A0information=A0for=A0this=A0MN=A0in=A0its=A0cache=A0(e.g.,=A0sin= ce=A0the=A0cache=A0entry=A0=A0=20 >=A0=A0=A0has=A0expired)?=A0=20 >=A0=20 >=A0=A0=20 >=A0=20 >=A0Hiopt>>In=A0that=A0case,=A0there=A0is=A0nothing=A0NAS=A0can=A0do.=A0I= f=A0the=A0=A0=20 >=A0corresponding=A0information=A0=20 >=A0=20 >=A0is=A0configured=A0on=A0the=A0DHCP=A0server=A0(for=A0e.g.,=A0=20 >=A0pre-configuration),=A0the=A0server=A0will=20 >=A0provide=A0it.=A0Otherwise,=A0it=A0will=A0reply=A0with=A00-lengh=A0opt= ion.=20 ok.=A0My=A0comment=A0was=A0that=A0this=A0should=A0be=A0documented=A0(i.e.= ,=A0DHCP=A0server=20 must=A0reply=A0with=A00-lengh=A0option=A0in=A0this=A0case)=20 >=A0=20 >=A0=20 >=A0-=A0What=A0should=A0DHCP=A0relay/server=A0do=A0if=A0the=A0MN=A0does=A0= not=A0include=A0the=A0=A0=20 >=A0=A0=A0OPTION_CLIENTID=A0in=A0the=A0DHCP=A0request=A0or=A0if=A0OPTION_= MIP6-RELAY-Option=A0=A0=20 >=A0=A0=A0is=A0missing=A0in=A0request?=A0=20 >=A0=20 >=A0=20 >=A0=A0=20 >=A0=20 >=A0Hiopt>>=A0The=A0existing=A0DHCP=A0options=A0are=A0handled=A0according= =A0to=A0[RFC=A03315].=20 >=A0=20 >=A0The=A0request=A0not=A0including=A0OPTION_CLIENTID=A0is=A0discarded=A0= in=A0the=A0=20 >=A0relay/server=20 >=A0=20 >=A0as=A0described=A0in=A015.4=A0of=A0[RFC=A03315].=A0=20 ok.=20 >=A0=20 >=A0=20 >=A0The=A0draft=A0may=A0need=A0better=A0aligned=A0with=A0[HIOPT].=A0For=A0= instance,=A0=20 >=A0it=A0is=A0not=A0=20 >=A0clear=A0to=A0me=A0how=A0exactly=A0the=A0home=A0network=A0identifier=A0= option=A0=20 >=A0and=A0the=A0home=A0=A0=20 >=A0network=A0information=A0option=A0specified=A0in=A0[HIOPT]=A0are=A0all= owed=A0=20 >=A0to=A0be=A0used=A0=20 >=A0in=A0draft-ietf-mip6-bootstrapping-integrated-02:=A0=A0=20 >=A0=20 >=A0-=A0[HIOPT]=A0supports=A0home=A0address=A0allocation.=A0This=A0is=A0n= ot=A0mentioned=A0in=A0=A0=20 >=A0=A0=A0draft-ietf-mip6-bootstrapping-integrated-02.=A0Is=A0this=A0forb= idden=A0or=A0=A0=20 >=A0=A0=A0allowed=A0or=A0out-of-scope?=A0If=A0allowed,=A0when=A0does=A0NA= S=A0set=A0the=A0=20 >=A0A-flag=A0in=A0=A0=20 >=A0=A0=A0the=A0home=A0network=A0identifier=A0option?=A0=20 >=A0=20 >=A0=A0=20 >=A0=20 >=A0Hiopt>>=A0NAS=A0SHOULD=A0not=A0modify=A0the=A0Home=A0Network=A0Identi= fier=A0option.=A0=20 >=A0The=A0A-flag=A0is=A0set=A0to=A00/1=A0only=A0by=A0the=A0mobile=A0node.= =A0If=A0there=A0is=A0=20 >=A0home=A0address=20 >=A0information=A0at=A0NAS=A0that=A0was=A0acquired=A0during=A0AAA=A0trans= action,=A0=20 >=A0it=A0is=A0delivered=20 >=A0to=A0the=A0DHCP=A0server=A0with=A0MIP6-Relay=A0option.=A0(Refer=A0hio= pt-02.txt)=20 I=A0was=A0aware=A0of=A0HoA=A0allocation=A0support=A0in=A0[HIOPT].=A0My=A0= question=A0was=20 whether=A0it=A0is=A0supported=A0in=A0draft-ietf-mip6-bootstrapping-integr= ated-02=20 as=A0well,=A0since=A0HoA=A0allocation=A0is=A0not=A0mentioned=A0there.=20 >=A0=20 >=A0=20 >=A0-=A0Is=A0it=A0allowed=A0that=A0multiple=A0HA=A0addresses=A0are=A0retu= rned=A0in=A0the=A0home=A0=A0=20 >=A0=A0=A0network=A0information=A0option?=A0=20 >=A0=20 >=A0=A0=20 >=A0=20 >=A0Hiopt>>=A0It=A0is=A0allowed=A0by=A0using=A0multiple=A0home=A0network=A0= =20 >=A0information=A0option.=20 >=A0=20 >=A0=A0=A0"Multiple=A0sub-options=A0may=A0exist=A0in=A0a=A0Home=A0Network= =A0Information=A0option=20 >=A0=20 >=A0=A0=A0=A0to=A0carry=A0more=A0than=A0one=A0home=A0information."=A0(in=A0= section=A03.3.1)=20 >=A0=20 >=A0=20 >=A0-=A0[HIOPT]=A0allows=A0that=A0the=A0home=A0network=A0identifier=A0opt= ion=A0includes=A0an=A0=A0=20 >=A0=A0=A0identifier=A0of=A0a=A0target=A0network,=A0which=A0is=A0differen= t=A0from=A0home=A0or=A0=A0=20 >=A0=A0=A0visited=A0network=A0of=A0MN.=A0This=A0is=A0not=A0mentioned=A0in= =A0=A0=20 >=A0=A0=A0draft-ietf-mip6-bootstrapping-integrated-02.=A0Is=A0this=A0allo= wed=A0or=A0=A0=20 >=A0=A0=A0forbidden?=A0=20 >=A0=20 >=A0=A0=20 >=A0=20 >=A0Hiopt>>=A0A=A0target=A0network=A0may=A0or=A0may=A0not=A0be=A0home=A0n= etwork=A0of=A0the=A0MN.=A0=A0=20 good.=A0I=A0guess=A0"home=A0network"=A0means=A0"home=A0MSP"=A0in=A0this=A0= case,=A0right?=20 According=A0to=A0RFC4640,=A0the=A0"home=A0MSP"=A0is=A0MN's=A0MSA=A0provid= ing=A0mobility=20 service=A0to=A0MN.=A0=20 According=A0to=A0Kuntal's=A0comment,=A0also=A0MSPs=A0other=A0than=A0MSA=A0= (or=A0"home=A0MSP")=20 and=A0ASP=A0are=A0supported=A0as=A0target=A0networks.=A0If=A0this=A0is=A0= true=A0for=A0hiopt=A0(and=20 it=A0should=A0be=A0if=A0it=A0is=A0true=A0for=20 draft-ietf-mip6-bootstrapping-integrated-02),=A0then=A0it=A0seems=A0that=A0= the=20 hiopt=A0draft=A0also=A0uses=A0the=A0term=A0"home=A0MSP"=A0differently=A0t= han=A0defined=A0in=20 RFC4640.=A0For=A0instance,=A0section=A04.3,=A0case=A0C=A0(id-type=A02)=A0= says=A0=20 "In=A0case=A0the=A0server=A0cannot=A0not=A0find=A0any=A0home=A0informatio= n=A0neither=A0for=20 =A0=A0=A0the=A0local=A0network=A0nor=A0for=A0the=A0*home=A0MSP*,=A0it=A0M= UST=A0return=A0a=A0Home=20 Network=20 =A0=A0=A0Information=A0option=A0with=A0the=A00-length=A0data."=20 This=A0would=A0restrict=A0HA/HoA=A0allocation=A0from=A0ASP=A0and=A0MSA=A0= (=3Dhome=A0MSP).=A0I=20 guess=A0you=A0also=A0want=A0to=A0support=A0allocation=A0from=A0MSPs=A0oth= er=A0than=A0ASP=A0and=20 MSA,=A0no?=A0So=A0shouldn't=A0"home=A0MSP"=A0be=A0replaced=A0by=A0"any=A0= other=A0MSP=A0with=20 roaming=A0relationship=A0to=A0MN's=A0MSA"?=20 Same=A0for=A0id-type=A01:=A0section=A03.1=A0says=A0=20 "=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0id-type=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0The=A0type=A0of=A0Home=A0Network=A0= Identifier:=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A00=A0=A0=A0= =A0Visited=A0domain=A0(local=A0ASP)=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A01=A0=A0=A0= =A0Home=A0domain=A0(home=A0MSP)=20 ....=20 =A0=A0=A0Id-type=A01=A0indicates=A0the=A0mobile=A0node=A0is=A0interested=A0= in=A0learning=A0the=20 =A0=A0=A0home=A0network=A0information=A0that=A0pertains=A0to=A0the=A0give= n=A0realm.=A0=A0This=A0type=20 =A0=A0=A0can=A0be=A0used=A0to=A0discover=A0home=A0agents=A0that=A0are=A0h= osted=A0by=A0a=A0user's=A0home=20 =A0=A0=A0domain=A0(as=A0indicated=A0by=A0his/her=A0NAI-based=A0username=A0= --=A0user@=20 =A0=A0=A0HomeRealm).=A0=A0The=A0Home=A0Network=A0Identifier=A0field=A0MUS= T=A0be=A0set=A0to=A0the=20 =A0=A0=A0target=A0home=A0MSP.=A0=A0"=20 This=A0text=A0implies=A0that=A0HA/HoA=A0allocation=A0from=A0other=A0MSPs=A0= than=A0home=A0MSP=20 (which=A0is=A0equal=A0to=A0MSA)=A0is=A0not=A0supported=A0with=A0id-type=A0= 1,=A0even=A0if=A0those=20 MSPs=A0have=A0a=A0roaming=A0relationship=A0with=A0the=A0MN's=A0MSA.=A0Is=A0= this=A0true?=A0=20 Regards,=20 Kilian=20 >=A0=20 >=A0In=A0current=A0draft,=A0the=A0server=A0is=A0supposed=A0to=A0provide=A0= the=A0HA=A0=20 >=A0information=A0if=A0it=A0has=20 >=A0=20 >=A0the=A0corresponding=A0information.=A0If=A0the=A0given=A0HA=A0does=A0n= ot=A0=20 >=A0function=A0as=A0HA=A0for=20 >=A0=20 >=A0the=A0requesting=A0MN,=A0it=A0will=A0reply=A0with=A0the=A0BA=A0status= =A0=3D=A0132=A0or=A0133=A0=A0=20 >=A0=20 >=A0(Not=A0home=A0subnet=A0/=A0home=A0agent=A0for=A0this=A0mobile=A0node)= =A0during=A0=20 >=A0MN's=A0registration.=20 >=A0=20 >=A0=20 >=A0-=A0Which=A0HA=A0information=A0should=A0the=A0MN=A0use=A0if=A0it=A0re= ceives,=A0=20 >=A0e.g.,=A0an=A0FQDN=A0=A0=20 >=A0=A0=A0and=A0a=A0HA=A0address=A0in=A0DHCP=A0reply?=A0[HIOPT]=A0refers=A0= to=A0section=A03.6=A0of=A0=A0=20 >=A0=A0=A0draft-ietf-mip6-bootstrapping-integrated-01,=A0but=A0this=A0=20 >=A0section=A0doesn't=A0=20 >=A0=A0=A0exist=A0in=A0draft-ietf-mip6-bootstrapping-integrated-02=A0anym= ore...=A0=20 >=A0=20 >=A0=20 >=A0=A0=20 >=A0=20 >=A0Hiopt>>=A0It=A0is=A0within=A0the=A0MN's=A0own=A0discretion=A0as=A0fol= lows.=A0=20 >=A0=20 >=A0I=A0don't=A0think=A0it=A0should=A0be=A0standardized=A0in=A0HIOPT=A0do= cument.=A0=20 >=A0=20 >=A0"For=A0example,=A0if=A0the=A0mobile=A0node=A0acquires=A0both=A0IPv6=A0= =20 >=A0address(es)=A0and=A0FQDN(s)=20 >=A0=A0of=A0the=A0home=A0agents,=A0it=A0may=A0try=A0to=A0use=A0the=A0addr= ess=A0=20 >=A0information=A0of=A0the=A0home=A0agent(s)=A0first."=20 >=A0=20 >=A0=A0=20 >=A0=20 >=A0=20 >=A0Some=A0other=A0comments:=A0=20 >=A0=20 >=A0-=A0It=A0would=A0be=A0good=A0to=A0have=A0a=A0section,=A0which=A0expli= citly=A0states=A0=A0=20 >=A0=A0=A0assumptions=A0and=A0applicability=A0of=A0the=A0protocol.=A0This= =A0should=A0include:=A0=20 >=A0=A0=A0=A0=A0-=A0MSA=A0and=A0ASA=A0must=A0be=A0co-located=A0(i.e.,=A0i= ntegrated=A0scenario)=A0=20 >=A0=A0=A0=A0=A0-=A0AAA=A0infrastructure=A0assumed=A0and=A0some=A0kind=A0= of=A0roaming=A0=A0=20 >=A0=A0=A0=A0=A0=A0=A0=A0=A0relationship=A0between=A0ASP=A0and=A0MSA/ASA=A0= is=A0required=A0=20 >=A0=A0=A0=A0=A0-=A0MSP=A0is=A0either=A0co-located=A0with=A0ASP=A0or=A0MS= A=A0or=A0both=A0=20 >=A0=A0=A0=A0=A0=A0=A0=A0=A0(Or=A0are=A0other=A0target=A0networks=A0allow= ed;=A0see=A0above)?=A0=20 >=A0=A0=A0=A0=A0-=A0DHCP=A0relay=A0and=A0NAS=A0must=A0be=A0co-located=A0 = >=A0=20 >=A0-=A0At=A0some=A0places=A0in=A0the=A0text=A0the=A0use=A0of=A0the=A0ter= m=A0"MSP"=A0is=A0ambiguous,=A0=A0=20 >=A0=A0=A0since=A0MSP=A0can=A0refer=A0to=A0at=A0least=A0home=A0and=A0visi= ted=A0network.=A0Better=A0=A0=20 >=A0=A0=A0use=A0"home=A0MSP"=A0for=A0MSP=A0in=A0home=A0network.=A0=20 >=A0=A0=A0=A0=A0-=A0e.g.,=A0section=A03.1:=A0=20 >=A0=A0=A0"Note=A0that=A0a=A0home=A0agent=A0for=A0usage=A0=20 >=A0=A0=A0=A0with=A0the=A0mobile=A0node=A0might=A0be=A0selected=A0in=A0th= e=A0access=A0service=A0=20 >=A0=A0=A0=A0provider's=A0network=A0or=A0alternatively=A0in=A0the=A0*home= *=A0mobility=A0service=A0=20 >=A0=A0=A0=A0provider's=A0network."=A0=20 >=A0=A0=A0=A0=A0-=A0or=A0in=A0section=A03.2:=A0=20 >=A0=A0=A0"The=A0message=A0flows=A0for=A0home=A0agent=A0=20 >=A0=A0=A0=A0allocation=A0in=A0the=A0ASP=A0and=A0the=A0*home*=A0MSP=A0are= =A0illustrated=A0below.=A0=A0=A0=20 >=A0=A0=A0=A0=A0-=A0or=A0in=A0section=A03.2.1:=A0=20 >=A0=A0=A0"3.2.1.=A0=A0Home=A0Agent=A0allocation=A0in=A0the=A0*home*=A0MS= P",=A0=20 >=A0=A0=A0"(4)...=A0mobile=A0node=A0is=A0requesting=A0home=A0agent=A0info= rmation=A0in=A0the=A0=A0=20 >=A0=A0=A0*home*=A0MSP..."=A0=20 >=A0=20 >=A0-=A0Section=A03.3=A0currently=A0mentions=A0DNS-based=A0HA=A0address=A0= =20 >=A0discovery=A0method=A0=20 >=A0=A0=A0only,=A0but=A0[BOOT-SPLIT]=A0also=A0specifies=A0an=A0anycast-ba= sed=A0HA=A0address=A0=A0=20 >=A0=A0=A0discovery=A0method.=A0Either=A0both=A0or=A0none=A0should=A0be=A0= mentioned.=A0=20 >=A0=20 >=A0-=A0The=A0title=A0of=A0draft-ietf-mip6-bootstrapping-integrated-02=A0= can=A0cause=A0=A0=20 >=A0=A0=A0the=A0impression=A0that=A0the=A0draft=A0defines=A0a=A0complete=A0= bootstrapping=A0=A0=A0=20 >=A0=A0=A0procedure.=A0But=A0draft-ietf-mip6-bootstrapping-integrated-02=A0= =20 >=A0defines=A0a=A0=A0=20 >=A0=A0=A0method=A0for=A0HA=A0address=A0assignment=A0only.=A0I=A0think=A0= this=A0is=A0misleading.=A0=A0=20 >=A0=A0=A0Why=A0not=A0name=A0the=A0draft=A0according=A0to=A0what=A0it=A0s= pecifies=A0(e.g.,=A0"HA=A0=A0=20 >=A0=A0=A0address=A0assignment=A0using=A0DHCP=A0and=A0AAA"=A0or=A0"HA=A0a= ddress=A0=20 >=A0assignment=A0for=A0=A0=20 >=A0=A0=A0the=A0integrated=A0scenario=A0using=A0DHCP=A0and=A0AAA"=A0inste= ad=A0of=A0=A0=20 >=A0=A0=A0"MIP6-bootstrapping=A0for=A0the=A0integrated=A0scenario")?=A0=20 >=A0=20 >=A0Regards,=A0=20 >=A0=20 >=A0Kilian=A0=20 >=A0=20 >=A0>=A0-----Original=A0Message-----=A0=20 >=A0>=A0From:=A0Basavaraj=A0Patil=A0[mailto:basavaraj.patil@nokia.com]=A0= =A0=20 >=A0>=A0Sent:=A0Mittwoch,=A014.=A0Februar=A02007=A019:10=A0=20 >=A0>=A0To:=A0mip6@ietf.org=A0=20 >=A0>=A0Subject:=A0[Mip6]=A0WGLC:=A0draft-ietf-mip6-bootstrapping-integra= ted-02=A0=20 >=A0>=A0=A0=20 >=A0>=A0=A0=20 >=A0>=A0Hello,=A0=20 >=A0>=A0=A0=20 >=A0>=A0This=A0is=A0a=A0MIP6=A0Working=A0group=A0last=A0call=A0for=A0the=A0= WG=A0I-D:=A0=20 >=A0>=A0"MIP6-bootstrapping=A0for=A0the=A0Integrated=A0Scenario",=A0=20 >=A0>=A0draft-ietf-mip6-bootstrapping-integrated-02.txt=A0=20 >=A0>=A0=A0=20 >=A0>=A0I-D:=A0=A0=20 >=A0>=A0http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-=A0= =20 >=A0>=A0integrated-dhc=A0=20 >=A0>=A0-02.txt=A0=20 >=A0>=A0=A0=20 >=A0>=A0Please=A0review=A0and=A0submit=A0your=A0comments=A0to=A0the=A0aut= hors=A0or=A0=20 >=A0the=A0mailing=A0=20 >=A0>=A0list.=A0The=A0WGLC=A0will=A0expire=A0on=A0March=A01st,=A007.=A0=20 >=A0>=A0=A0=20 >=A0>=A0-Chairs=A0=20 >=A0>=A0=A0=20 >=A0>=A0=A0=20 >=A0>=A0_______________________________________________=A0=20 >=A0>=A0Mip6=A0mailing=A0list=A0=20 >=A0>=A0Mip6@ietf.org=A0=20 >=A0>=A0https://www1.ietf.org/mailman/listinfo/mip6=A0=20 >=A0>=A0=A0=20 >=A0>=A0=A0=20 >=A0=20 >=A0=20 >=A0Panasonic=A0R&D=A0Center=A0Germany=A0GmbH=A0=20 >=A063225=A0Langen,=A0Hessen,=A0Germany=A0=20 >=A0Reg:=A0AG=A0Offenbach=A0(Hessen)=A0HRB=A033974=A0=20 >=A0Managing=A0Director:=A0Thomas=A0Micke=A0=20 >=A0=20 >=A0=20 >=A0=20 >=A0_______________________________________________=A0=20 >=A0Mip6=A0mailing=A0list=A0=20 >=A0Mip6@ietf.org=A0=20 >=A0https://www1.ietf.org/mailman/listinfo/mip6=A0=20 >=A0=20 >=A0=20 >=A0=20 >=A0=20 >=A0=20 Panasonic=A0R&D=A0Center=A0Germany=A0GmbH=20 63225=A0Langen,=A0Hessen,=A0Germany=20 Reg:=A0AG=A0Offenbach=A0(Hessen)=A0HRB=A033974=20 Managing=A0Director:=A0Thomas=A0Micke=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 27 20:01:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMDAu-0007am-SC; Tue, 27 Feb 2007 20:00:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMDAt-0007S8-4v for mip6@ietf.org; Tue, 27 Feb 2007 20:00:07 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMDAr-0005tE-Qo for mip6@ietf.org; Tue, 27 Feb 2007 20:00:07 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 16:59:53 -0800 Message-ID: <45E4D408.8050709@azairenet.com> Date: Tue, 27 Feb 2007 16:59:52 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Mip6] AD review of draft-ietf-mip6-bootstrapping-split References: <459A5A6C.5070602@piuha.net> <45E00DD3.1010701@piuha.net> <45E32B26.7050702@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2007 00:59:53.0598 (UTC) FILETIME=[C19909E0:01C75AD3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Mobile IPv6 Mailing List , James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Gerardo Giaretta wrote: >> >> In case the FQDN is known by the AAA server via EAP, I see two >> >> possible approaches: >> >> >> >> - the AAA server provides the HA with the MN's FQDN received via EAP >> >> (e.g. during Diameter EAP application) and the HA stores the >> >> "authorized" FQDN. This would require a change in current Diameter >> >> application >> > >> > Yes. Or a new AVP, at least. CUI might apply here, but it might >> > not have exactly the semantics you want. >> > >> >> - the HA performs a AAA exchange when it receives a BU with a DNS >> >> Update mobility option; this AAA exchange should be part of the Mobile >> >> IPv6 Diameter application (work in progress in DIME WG) and should be >> >> used by the HA to get the authorized FQDN from the AAA server in order >> >> to update the DNS >> > >> > This sounds preliminarily better. >> >> I don't like this additional AAA exchange just for the >> DNS update. We should go with the solution where the >> AAA server sends the mobile node's true FQDN (the one >> that appears in the DNS) to the home agent in the AA >> Answer message or the Diameter EAP Answer message, >> depending on whether authentication and authorization >> is done separately or together. >> >> (I haven't followed the work in Dime for a while. So >> I don't know what the current thinking is). >> > > The AAA exchange may not be an additional one. Currently we are > discussing this issue in DIME WG (please, it would be great if you > take part on that discussion too); there are two options under > discussion, depending if the authorization for MIPv6 bootstrapping is > performed during the bootstrapping or after the first BU. The latter > option derives from the consideration that the MN is actually using > the MIP service only after the first BU. Why would a mobile node setup security associations with a home agent or send a BU to the home agent if not for mobility service? >> >> The draft should leave the actual definition of either mechanism as >> >> out of scope (as you suggested), but we should put a reference to the >> >> solution. >> >> >> >> As a summary, in this draft, I think it is enough to clarify the need >> >> of the FQDN in the cert for the certificates scenario. For the AAA/EAP >> >> scenario, we should provide a reference for the HA-AAA coordination >> >> needed in case EAP is used, >> >> IMO, whenever the mobile nodes uses different identities >> in the IDi field and in EAP payloads, we should require >> the AAA server to send the mobile node's identity to >> the Home Agent. >> > > That is the first option I described, isn't it? Yes. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 27 20:56:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HME38-0001m7-Gf; Tue, 27 Feb 2007 20:56:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HME36-0001lH-3L for mip6@ietf.org; Tue, 27 Feb 2007 20:56:08 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HME34-0006rl-LG for mip6@ietf.org; Tue, 27 Feb 2007 20:56:08 -0500 Received: from ep_ms5_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JE500MAIHD219@mailout2.samsung.com> for mip6@ietf.org; Wed, 28 Feb 2007 10:55:50 +0900 (KST) Received: from ep_spt03 (ms5.samsung.com [203.254.225.113]) by ms5.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JE500F00HD2ZQ@ms5.samsung.com> for mip6@ietf.org; Wed, 28 Feb 2007 10:55:50 +0900 (KST) Content-return: prohibited Date: Wed, 28 Feb 2007 01:55:50 +0000 (GMT) From: Heejin Jang Subject: Re: [Mip6] hiopt-02 To: Behcet Sarikaya Message-id: <0JE500F01HD2ZQ@ms5.samsung.com> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20070228015550610@heejin.jang X-MTR: 20070228015550610@heejin.jang X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-Generator: NamoMIME 6.0.0.8 X-Spam-Score: 4.0 (++++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "mip6@ietf.org" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: heejin.jang@samsung.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0468261314==" Errors-To: mip6-bounces@ietf.org --===============0468261314== Content-return: prohibited Content-type: text/html; charset=windows-1252 Content-transfer-encoding: base64 PEhUTUw+PEhFQUQ+CjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9J3RleHQv aHRtbDsgY2hhcnNldD13aW5kb3dzLTEyNTInPgo8dGl0bGU+U2Ftc3VuZyBFbnRlcnByaXNlIFBv cnRhbCBteVNpbmdsZTwvdGl0bGU+CjxzdHlsZT4gUCwgdGQsIGxpIHtmb250LWZhbWlseTpBcmlh bCwgYXJpYWw7IGZvbnQtc2l6ZTo5cHQ7IG1hcmdpbi10b3A6NXB4O21hcmdpbi1ib3R0b206NXB4 O30gYm9keXtmb250LWZhbWlseTpBcmlhbCwgYXJpYWw7IGZvbnQtc2l6ZTo5cHQ7fTwvc3R5bGU+ CjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+PCEtLSBESVYge21hcmdpbjowcHg7fSAtLT48L3N0eWxl PjxTVFlMRT5QLCB0ZCwgbGkge2ZvbnQtZmFtaWx5OkFyaWFsLCBhcmlhbDtmb250LXNpemU6OXB0 O21hcmdpbi10b3A6NXB4O21hcmdpbi1ib3R0b206NXB4O31ib2R5e2ZvbnQtZmFtaWx5OkFyaWFs LCBhcmlhbDtmb250LXNpemU6OXB0O308L1NUWUxFPg0KPC9IRUFEPjxCT0RZPjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OnRpbWVzIG5ldyByb21hbiwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZjtmb250 LXNpemU6MTJwdCI+PERJViBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogdGlt ZXMgbmV3IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNlcmlmIj5IaSwgDQogICAgICAgIEJlaGNl dC48L0RJVj4NCjwvZGl2Pg0KPHA+SXQncyBhIGdvb2QgY29tbWVudCBhbmQgbmVlZHMgdG8gY29u c2lkZXIgbW9yZS48L3A+DQo8cD4mbmJzcDs8L3A+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTp0 aW1lcyBuZXcgcm9tYW4sIG5ldyB5b3JrLCB0aW1lcywgc2VyaWY7Zm9udC1zaXplOjEycHQiPjxE SVYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbiwg bmV3IHlvcmssIHRpbWVzLCBzZXJpZiI+IFRob3VnaCANCiAgICAgICAgdGhlJm5ic3A7REhDUCBs aWZldGltZSBpcyByZWZyZXNoZWQgYnkgREhDUCBzZXJ2ZXIgZmluYWxseSwgdGhlIGluZm9ybWF0 aW9uIA0KICAgICAgICBmb3IgcmVmcmVzaG1lbnQtPC9ESVY+DQo8L2Rpdj4NCjxwPmZvciwgZS5n Liwgd2hldGhlciBvciBub3QgdG8gYWxsb3cgcmVmcmVzaG1lbnQgb2YgdGhlIGxpZmV0aW1lLCB0 aGUgcmVmcmVzaG1lbnQgDQpsaWZldGltZSwuLmV0Yy08L3A+DQo8cD5zaG91bGQgYmUgbGVhcm5l ZCBmcm9tIHRoZSBOQVMgKGludGVyYWN0aW5nIHdpdGggdGhlIEFBQUggJm5ic3A7ZHVyaW5nIG5l dHdvcmsgDQphY2Nlc3MgYXV0aGVudGljYXRpb24pIDwvcD4NCjxwPmJlZm9yZSB0aGUgcmVmcmVz aG1lbnQuPC9wPg0KPHA+VGhpcyBtZWFucyB0aGF0IG5vdCBvbmx5IHRoZSBob21lIGluZm9ybWF0 aW9uIGJ1dCBhbHNvIHRoZSBjb3JyZXNwb25kaW5nIA0KbWFuYWdlbWVudCBwb2xpY3k8L3A+DQo8 cD5uZWVkcyB0byBiZSB0cmFuc2ZlcnJlZCB0b2dldGhlciB0byB0aGUgTkFTLCBmaWFubGx5IHRv IHRoZSBESENQIHNlcnZlci4gDQo8L3A+DQo8cD5XZSdsbCB0aGluayBhYm91dCZuYnNwO2l0IHNp bmNlIGl0IHJlcXVpcmVzIHNvbWUgY2hhbmdlcyBvZiBESENQIHJlbGF5IGFnbmV0IA0KYW5kIG1l c3NhZ2VzLjwvcD4NCjxwPiZuYnNwOzwvcD4NCjxwPlJlZ2FyZHM8L3A+DQo8cD5IZWVqaW4uPC9w Pg0KPHA+Jm5ic3A7PC9wPg0KPHA+Jm5ic3A7PC9wPg0KPHA+Jm5ic3A7PC9wPg0KPHA+Jm5ic3A7 PC9wPg0KPHA+Jm5ic3A7PC9wPg0KPHA+PGJyPjxicj4tLS0tLS0tIDxiPk9yaWdpbmFsIE1lc3Nh Z2U8L2I+IC0tLS0tLS08YnI+PGI+U2VuZGVyPC9iPiA6IEJlaGNldCBTYXJpa2F5YSZsdDtiZWhj ZXRzYXJpa2F5YUB5YWhvby5jb20mZ3Q7PGJyPjxiPkRhdGU8L2I+ICAgOiAyMDA3LTAyLTI3IDA4 OjM1PGJyPjxiPlRpdGxlPC9iPiAgOiBbTWlwNl0gaGlvcHQtMDI8YnI+PGJyPjwhQk9EWT48L3A+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTp0aW1lcyBuZXcgcm9tYW4sIG5ldyB5b3JrLCB0aW1l cywgc2VyaWY7Zm9udC1zaXplOjEycHQiPjxESVYgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9O VC1GQU1JTFk6IHRpbWVzIG5ldyByb21hbiwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZiI+SGkgSGVl amluLA0KICAgICAgICA8cD4mbmJzcDsgSW4gaGlvcHQtMDIgeW91IGFyZSByZWZlcnJpbmcgaW4g WzRdIHRvIDMzMTUsIGRvZXMgdGhpcyBtZWFuIHRoYXQgSG9BIE1OIGdldHMgYm9vdHN0cmFwcGVk IGhhcyBhIERIQ1AgbGlmZXRpbWUgdG8gYmUgcmVmcmVzaGVkIGJ5IERIQ1Agc2VydmVyPw0KICAg ICAgICA8cD4mbmJzcDsgSSBhbSBjb25mdXNlZCBhYm91dCB0aGlzIGJlY2F1c2UgeW91IGFyZSBu b3QgcmVmZXJlbmNpbmcgMzczNi4NCiAgICAgICAgPHA+Jm5ic3A7DQogICAgICAgIDxwPlJlZ2Fy ZHMsDQogICAgICAgIDxwPiZuYnNwOw0KICAgICAgICA8cD5CZWhjZXQ8QlI+PEJSPjwvRElWPg0K PC9kaXY+PC9CT0RZPjwvSFRNTD4= --===============0468261314== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0468261314==-- From mip6-bounces@ietf.org Tue Feb 27 21:15:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMEL4-0008BD-BP; Tue, 27 Feb 2007 21:14:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMEL3-00089A-B7 for mip6@ietf.org; Tue, 27 Feb 2007 21:14:41 -0500 Received: from omta02ps.mx.bigpond.com ([144.140.83.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMEL1-0000PN-Qy for mip6@ietf.org; Tue, 27 Feb 2007 21:14:41 -0500 Received: from oaamta02ps.mx.bigpond.com ([124.191.178.123]) by omta02ps.mx.bigpond.com with ESMTP id <20070228021416.SAHG19913.omta02ps.mx.bigpond.com@oaamta02ps.mx.bigpond.com>; Wed, 28 Feb 2007 02:14:16 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta02ps.mx.bigpond.com with ESMTP id <20070228021416.YYSG17816.oaamta02ps.mx.bigpond.com@PC20005>; Wed, 28 Feb 2007 02:14:16 +0000 From: "Hesham Soliman" To: "'Mip6 issue tracker'" , Subject: RE: [Mip6] [issue93] Payload Qualifiers when using IPv4-UDP transportfor both IPv4 and IPv6 payloads Date: Wed, 28 Feb 2007 13:14:10 +1100 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: <1172612288.22.0.0310637271414.issue93@mip4.org> Thread-Index: AcdawpoqJzN2bJKcQmaTePAzvjzD6AAGzwxA x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070228021416.YYSG17816.oaamta02ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Sri, Why can't the receiver do the switch on the version field? I mean, how does the receiver of any encapsulated packet know the version of the inner header? Hesham > -----Original Message----- > From: Sri Gundavelli [mailto:tracker-mip6@mip4.org] > Sent: Wednesday, February 28, 2007 8:38 AM > To: mip6@ietf.org > Subject: [Mip6] [issue93] Payload Qualifiers when using > IPv4-UDP transportfor both IPv4 and IPv6 payloads > > > New submission from Sri Gundavelli : > > Reference to section 4.3.1 and 4.4.1. > > For the IPv4 transport and with NAT in path, the opaque > encapsulation mode of IPv4-UDP for both IPv4 and IPv6 > payload packets i.e IPv6/IPv4-UDP or IPv4/IPv4-UDP is being > recommended by the draft. With out a payload qualifier > in the UDP header, I wonder how the tunnel peer handles > the packet after decapsulation ? How would it know, if it > is an IPv4 payload packet or an IPv6 packet ? Do you expect > some packet inspection after decapsulation ? > > One option is to have thin header such as the MIP Tunnel > Data Message from RFC-3519, as suggested by Kent Leung. > > > MIP Tunnel Data Message > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Next Header | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > We want a quick resolution on this. > draft-sgundave-mip6-proxymip6-02.txt > has normative reference to the DSMIP6 spec. > > Thanks > Sri > > ---------- > category: Technical > draft: draft-ietf-mip6-nemo-v4traversal > messages: 330 > nosy: sri > priority: Must fix > status: No discussion > title: Payload Qualifiers when using IPv4-UDP transport for > both IPv4 and IPv6 payloads > > _________________________________________________ > Mip6 issue tracker > > _________________________________________________ > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 27 21:53:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMEvt-0001z9-Sq; Tue, 27 Feb 2007 21:52:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMEvr-0001yz-Nm for mip6@ietf.org; Tue, 27 Feb 2007 21:52:43 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMEvp-00048P-Az for mip6@ietf.org; Tue, 27 Feb 2007 21:52:43 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 Feb 2007 18:52:41 -0800 X-IronPort-AV: i="4.14,227,1170662400"; d="scan'208"; a="116654031:sNHT51071787" 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 l1S2qeDr001704; Tue, 27 Feb 2007 18:52:40 -0800 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1S2qeGl024905; Tue, 27 Feb 2007 18:52:40 -0800 (PST) Date: Tue, 27 Feb 2007 18:52:39 -0800 (PST) From: Sri Gundavelli To: Hesham Soliman Subject: RE: [Mip6] [issue93] Payload Qualifiers when using IPv4-UDP transportfor both IPv4 and IPv6 payloads In-Reply-To: <20070228021416.YYSG17816.oaamta02ps.mx.bigpond.com@PC20005> Message-ID: References: <20070228021416.YYSG17816.oaamta02ps.mx.bigpond.com@PC20005> 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=3282; t=1172631160; x=1173495160; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[Mip6]=20[issue93]=20Payload=20Qualifiers=20when=20us ing=20IPv4-UDP=20transportfor=0A=20both=20IPv4=20and=20IPv6=20payloads |Sender:=20; bh=jeIf4LWq5lSWN0mDBViJAc7Q6C3jYK+9gHQz8UBwZSM=; b=GvoYAdpVULpNhFGy20qJh255u1qJjWAdbkjpxTS+L2RCiQ72w707zgtSaOnLc8z1c+Y5lcGp 0+RXz2W6REli2PSYXrX/8qx5LOnx/zSc6GREOcpSGi9Y1uvmnXu0RHsh; 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: 5011df3e2a27abcc044eaa15befcaa87 Cc: 'Mip6 issue tracker' , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham, Version field can be used to distinguish that. But, when a packet is encapsulated in any application header, it needs to be wrapped in a TLV format. Example: RFC-3519. If there is no wrapper, application would not even know the size of that packet, or the type of the packet, unless its derived from the IP header. That adds some complexity w.r.t the way applications use the socket interface ..options etc. Having a wrapper would be usefull. The normal encapsulation modes in L3 such as IP/IP, IPv6/IPv6, GRE, all have the type field and so when we wrap a packet in L4, we need an identifier some where, IMO. Thanks Sri On Wed, 28 Feb 2007, Hesham Soliman wrote: > Hi Sri, > > Why can't the receiver do the switch on the version field? > I mean, how does the receiver of any encapsulated packet know the version of > the inner header? > > Hesham > > > -----Original Message----- > > From: Sri Gundavelli [mailto:tracker-mip6@mip4.org] > > Sent: Wednesday, February 28, 2007 8:38 AM > > To: mip6@ietf.org > > Subject: [Mip6] [issue93] Payload Qualifiers when using > > IPv4-UDP transportfor both IPv4 and IPv6 payloads > > > > > > New submission from Sri Gundavelli : > > > > Reference to section 4.3.1 and 4.4.1. > > > > For the IPv4 transport and with NAT in path, the opaque > > encapsulation mode of IPv4-UDP for both IPv4 and IPv6 > > payload packets i.e IPv6/IPv4-UDP or IPv4/IPv4-UDP is being > > recommended by the draft. With out a payload qualifier > > in the UDP header, I wonder how the tunnel peer handles > > the packet after decapsulation ? How would it know, if it > > is an IPv4 payload packet or an IPv6 packet ? Do you expect > > some packet inspection after decapsulation ? > > > > One option is to have thin header such as the MIP Tunnel > > Data Message from RFC-3519, as suggested by Kent Leung. > > > > > > MIP Tunnel Data Message > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Next Header | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > We want a quick resolution on this. > > draft-sgundave-mip6-proxymip6-02.txt > > has normative reference to the DSMIP6 spec. > > > > Thanks > > Sri > > > > ---------- > > category: Technical > > draft: draft-ietf-mip6-nemo-v4traversal > > messages: 330 > > nosy: sri > > priority: Must fix > > status: No discussion > > title: Payload Qualifiers when using IPv4-UDP transport for > > both IPv4 and IPv6 payloads > > > > _________________________________________________ > > Mip6 issue tracker > > > > _________________________________________________ > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 27 21:58:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMF1H-0004z0-BW; Tue, 27 Feb 2007 21:58:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMF1F-0004yt-Uf for mip6@ietf.org; Tue, 27 Feb 2007 21:58:17 -0500 Received: from omta02ps.mx.bigpond.com ([144.140.83.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMF1E-0004vC-D4 for mip6@ietf.org; Tue, 27 Feb 2007 21:58:17 -0500 Received: from oaamta02ps.mx.bigpond.com ([124.191.178.123]) by omta02ps.mx.bigpond.com with ESMTP id <20070228025802.UEKT19913.omta02ps.mx.bigpond.com@oaamta02ps.mx.bigpond.com>; Wed, 28 Feb 2007 02:58:02 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta02ps.mx.bigpond.com with ESMTP id <20070228025801.ZXHR17816.oaamta02ps.mx.bigpond.com@PC20005>; Wed, 28 Feb 2007 02:58:01 +0000 From: "Hesham Soliman" To: "'Sri Gundavelli'" Subject: RE: [Mip6] [issue93] Payload Qualifiers when using IPv4-UDP transportfor both IPv4 and IPv6 payloads Date: Wed, 28 Feb 2007 13:57:56 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: Acda44R5Cvn17ezBRqmhZ6yJNa2VJgAAEEEg x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070228025801.ZXHR17816.oaamta02ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: 'Mip6 issue tracker' , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Version field can be used to distinguish that. But, when > a packet is encapsulated in any application header, > it needs to be wrapped in a TLV format. Example: RFC-3519. > If there is no wrapper, application would not even know the > size of that packet, or the type of the packet, unless its > derived from the IP header. That adds some complexity w.r.t > the way applications use the socket interface ..options etc. > Having a wrapper would be usefull. The normal encapsulation > modes in L3 such as IP/IP, IPv6/IPv6, GRE, all have the type > field and so when we wrap a packet in L4, we need an identifier > some where, IMO. => I know the following question is not necessarily the crux of your issue but does anyone implement MIPv6 as an application? I know it's possible to do that but no one seemed to make that choice to my knowledge, but I could be wrong. I'd love to hear what others think, I think it's a good point to discuss. Hesham > > Thanks > Sri > > > On Wed, 28 Feb 2007, Hesham Soliman wrote: > > > Hi Sri, > > > > Why can't the receiver do the switch on the version field? > > I mean, how does the receiver of any encapsulated packet > know the version of > > the inner header? > > > > Hesham > > > > > -----Original Message----- > > > From: Sri Gundavelli [mailto:tracker-mip6@mip4.org] > > > Sent: Wednesday, February 28, 2007 8:38 AM > > > To: mip6@ietf.org > > > Subject: [Mip6] [issue93] Payload Qualifiers when using > > > IPv4-UDP transportfor both IPv4 and IPv6 payloads > > > > > > > > > New submission from Sri Gundavelli : > > > > > > Reference to section 4.3.1 and 4.4.1. > > > > > > For the IPv4 transport and with NAT in path, the opaque > > > encapsulation mode of IPv4-UDP for both IPv4 and IPv6 > > > payload packets i.e IPv6/IPv4-UDP or IPv4/IPv4-UDP is being > > > recommended by the draft. With out a payload qualifier > > > in the UDP header, I wonder how the tunnel peer handles > > > the packet after decapsulation ? How would it know, if it > > > is an IPv4 payload packet or an IPv6 packet ? Do you expect > > > some packet inspection after decapsulation ? > > > > > > One option is to have thin header such as the MIP Tunnel > > > Data Message from RFC-3519, as suggested by Kent Leung. > > > > > > > > > MIP Tunnel Data Message > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Type | Next Header | Reserved > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > We want a quick resolution on this. > > > draft-sgundave-mip6-proxymip6-02.txt > > > has normative reference to the DSMIP6 spec. > > > > > > Thanks > > > Sri > > > > > > ---------- > > > category: Technical > > > draft: draft-ietf-mip6-nemo-v4traversal > > > messages: 330 > > > nosy: sri > > > priority: Must fix > > > status: No discussion > > > title: Payload Qualifiers when using IPv4-UDP transport for > > > both IPv4 and IPv6 payloads > > > > > > _________________________________________________ > > > Mip6 issue tracker > > > > > > _________________________________________________ > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 27 22:30:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMFUh-0006Bw-Ef; Tue, 27 Feb 2007 22:28:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMFUg-0006Bq-4N for mip6@ietf.org; Tue, 27 Feb 2007 22:28:42 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMFUe-0001yQ-L2 for mip6@ietf.org; Tue, 27 Feb 2007 22:28:42 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 Feb 2007 19:28:40 -0800 X-IronPort-AV: i="4.14,227,1170662400"; d="scan'208"; a="116661333:sNHT48369348" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1S3Sedk023774; Tue, 27 Feb 2007 19:28:40 -0800 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1S3SdUx012343; Tue, 27 Feb 2007 19:28:39 -0800 (PST) Date: Tue, 27 Feb 2007 19:28:39 -0800 (PST) From: Sri Gundavelli To: Hesham Soliman Subject: RE: [Mip6] [issue93] Payload Qualifiers when using IPv4-UDP transportfor both IPv4 and IPv6 payloads In-Reply-To: <20070228025801.ZXHR17816.oaamta02ps.mx.bigpond.com@PC20005> Message-ID: References: <20070228025801.ZXHR17816.oaamta02ps.mx.bigpond.com@PC20005> 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=4730; t=1172633320; x=1173497320; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20 |Subject:=20RE=3A=20[Mip6]=20[issue93]=20Payload=20Qualifiers=20when=20us ing=20IPv4-UDP=20transportfor=0A=20both=20IPv4=20and=20IPv6=20payloads |Sender:=20; bh=aAeBVMcMA77GHMznuZcJlowtj9TDgqa5mfrtrV66dno=; b=YGc6SDciQNWOzMfc5S16hUZF2qFnATbzcQ+ghhG+XfUtdHFmgMx/FxDvvBToncC7y9G4XpKv VqPkcdp04TKOV8DZ9ZbdbawcR0upMgwxuv1Ov899tKlPFzIIzXXI8Vhb; 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: 36b1f8810cb91289d885dc8ab4fc8172 Cc: 'Mip6 issue tracker' , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On Wed, 28 Feb 2007, Hesham Soliman wrote: > > > > Version field can be used to distinguish that. But, when > > a packet is encapsulated in any application header, > > it needs to be wrapped in a TLV format. Example: RFC-3519. > > If there is no wrapper, application would not even know the > > size of that packet, or the type of the packet, unless its > > derived from the IP header. That adds some complexity w.r.t > > the way applications use the socket interface ..options etc. > > Having a wrapper would be usefull. The normal encapsulation > > modes in L3 such as IP/IP, IPv6/IPv6, GRE, all have the type > > field and so when we wrap a packet in L4, we need an identifier > > some where, IMO. > > => I know the following question is not necessarily the crux of your issue > but does anyone implement MIPv6 as an application? I know it's possible to > do that but no one seemed to make that choice to my knowledge, but I could > be wrong. It depends on the OS and the available tunneling semantics ...etc But, on a normal unix derivative, I'd implement it as: - Application for control layer - Kernel module for data handling or a simple route setup So, for normal encap modes, IP/IP ..etc, this will be handled in the kernel mode, as the filter rule such as in netfilter is a simple ptype. But, when the packet is in L4 header and if we have to look for version field, not sure, if we can specify such complex filter rules and so it needs to received as an application payload and routed properly. But, it all depends. Some guy might implement it in a better way. Sri > > I'd love to hear what others think, I think it's a good point to discuss. > > Hesham > > > > > Thanks > > Sri > > > > > > On Wed, 28 Feb 2007, Hesham Soliman wrote: > > > > > Hi Sri, > > > > > > Why can't the receiver do the switch on the version field? > > > I mean, how does the receiver of any encapsulated packet > > know the version of > > > the inner header? > > > > > > Hesham > > > > > > > -----Original Message----- > > > > From: Sri Gundavelli [mailto:tracker-mip6@mip4.org] > > > > Sent: Wednesday, February 28, 2007 8:38 AM > > > > To: mip6@ietf.org > > > > Subject: [Mip6] [issue93] Payload Qualifiers when using > > > > IPv4-UDP transportfor both IPv4 and IPv6 payloads > > > > > > > > > > > > New submission from Sri Gundavelli : > > > > > > > > Reference to section 4.3.1 and 4.4.1. > > > > > > > > For the IPv4 transport and with NAT in path, the opaque > > > > encapsulation mode of IPv4-UDP for both IPv4 and IPv6 > > > > payload packets i.e IPv6/IPv4-UDP or IPv4/IPv4-UDP is being > > > > recommended by the draft. With out a payload qualifier > > > > in the UDP header, I wonder how the tunnel peer handles > > > > the packet after decapsulation ? How would it know, if it > > > > is an IPv4 payload packet or an IPv6 packet ? Do you expect > > > > some packet inspection after decapsulation ? > > > > > > > > One option is to have thin header such as the MIP Tunnel > > > > Data Message from RFC-3519, as suggested by Kent Leung. > > > > > > > > > > > > MIP Tunnel Data Message > > > > > > > > 0 1 2 3 > > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > > 6 7 8 9 0 1 > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | Type | Next Header | Reserved > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > > > We want a quick resolution on this. > > > > draft-sgundave-mip6-proxymip6-02.txt > > > > has normative reference to the DSMIP6 spec. > > > > > > > > Thanks > > > > Sri > > > > > > > > ---------- > > > > category: Technical > > > > draft: draft-ietf-mip6-nemo-v4traversal > > > > messages: 330 > > > > nosy: sri > > > > priority: Must fix > > > > status: No discussion > > > > title: Payload Qualifiers when using IPv4-UDP transport for > > > > both IPv4 and IPv6 payloads > > > > > > > > _________________________________________________ > > > > Mip6 issue tracker > > > > > > > > _________________________________________________ > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 00:30:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMHNn-0004mE-Lo; Wed, 28 Feb 2007 00:29:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMHNm-0004ki-OS for mip6@ietf.org; Wed, 28 Feb 2007 00:29:42 -0500 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMHNl-0006wE-IO for mip6@ietf.org; Wed, 28 Feb 2007 00:29:42 -0500 Received: by an-out-0708.google.com with SMTP id d30so15531and for ; Tue, 27 Feb 2007 21:29:41 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=leXHUxLdOxSA9qiM2grQBiOZRKdzB0MeKAk4Q6xU6OZ+8nwhSC2XHrKO0txX5kKA3UhJn/COmfxXRSsBfuIL8yQ2bC8kiXQdaZISPot4se0McC+sVmH91HZphTvViB9S0qmpGpXtf24fK8B5s/+ODld+K5tAYots5rS87qKq4vk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=K1CtuPUOVPL5bkbwsE7MqicuvexzdO+muSKcxNzDxljjXRgNm0LItiADlkflvytdahLW1MfZL+3PBVsdckTjuBqhoR0RKyauSsK5TMxyZgMg7c0tCMJg6EPdiMU1TFUWlTUJgYAN89MKredSgNMb/V9Y383YTUMnjT/MtiQYeZA= Received: by 10.114.52.1 with SMTP id z1mr741686waz.1172640580854; Tue, 27 Feb 2007 21:29:40 -0800 (PST) Received: by 10.114.194.4 with HTTP; Tue, 27 Feb 2007 21:29:40 -0800 (PST) Message-ID: <9c46321e0702272129o1b95bf43sa195822f79d72abf@mail.gmail.com> Date: Wed, 28 Feb 2007 05:29:40 +0000 From: "Hugo Santos" To: mip6@ietf.org Subject: Re: [Mip6] [issue93] Payload Qualifiers when using IPv4-UDP transportfor both IPv4 and IPv6 payloads In-Reply-To: <20070228025801.ZXHR17816.oaamta02ps.mx.bigpond.com@PC20005> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070228025801.ZXHR17816.oaamta02ps.mx.bigpond.com@PC20005> X-Google-Sender-Auth: 9471c0c124e3e9e8 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, On 2/28/07, Hesham Soliman wrote: > => I know the following question is not necessarily the crux of your issue > but does anyone implement MIPv6 as an application? I know it's possible to > do that but no one seemed to make that choice to my knowledge, but I could > be wrong. > > I'd love to hear what others think, I think it's a good point to discuss. To a point, yes. In my Linux-based approach, all of the MIPv6's control ended up in an user-space process for extra flexibility. Only data transformation, including binding cache handling for RO and IPSec (already existing) ended up in the kernel. Hugo _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 04:19:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMKxN-0001Kq-Ur; Wed, 28 Feb 2007 04:18:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMKxL-0001Kb-Um for mip6@ietf.org; Wed, 28 Feb 2007 04:18:39 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMKxJ-0004zx-K2 for mip6@ietf.org; Wed, 28 Feb 2007 04:18:39 -0500 Received: by ug-out-1314.google.com with SMTP id 72so57255ugd for ; Wed, 28 Feb 2007 01:18:37 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K9XGRdlvYBDaWbK51oGOToLR9E5CmD2lW2jJ7rd81ATc/vpokth0ofX/1ET0aWsoOs/FuHnzAmscHWdHnNqMjkFs6UCfjXws6tg8LE7Z1IUcWdsybV7ZaVNo4qMjYlg3ZVxjZkKBf42aVwPWXZdqFZAYOI82EiHJAw6dDpuYwkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YYX/z4YpO4a/sZM1AIYf5QF85Wd6q3N5N8TsUdx/RS/bRMAaWrnJcFogzde3JsHmXtWEJ7MJYnOigi/nlPYJZFRMiohNdewE8oJspp4577dA0BIhTc+TZou1qlrC5YudXxaToXeAxvsVA+HBOGlqHChx/I0UALC1uAPpnGj6gd0= Received: by 10.67.117.2 with SMTP id u2mr301367ugm.1172654316904; Wed, 28 Feb 2007 01:18:36 -0800 (PST) Received: by 10.66.238.6 with HTTP; Wed, 28 Feb 2007 01:18:36 -0800 (PST) Message-ID: Date: Wed, 28 Feb 2007 10:18:36 +0100 From: "Gerardo Giaretta" To: "Vijay Devarapalli" Subject: Re: [Mip6] AD review of draft-ietf-mip6-bootstrapping-split In-Reply-To: <45E4D408.8050709@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <459A5A6C.5070602@piuha.net> <45E00DD3.1010701@piuha.net> <45E32B26.7050702@azairenet.com> <45E4D408.8050709@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Mobile IPv6 Mailing List , James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On 2/28/07, Vijay Devarapalli wrote: > Gerardo Giaretta wrote: > > >> >> In case the FQDN is known by the AAA server via EAP, I see two > >> >> possible approaches: > >> >> > >> >> - the AAA server provides the HA with the MN's FQDN received via EAP > >> >> (e.g. during Diameter EAP application) and the HA stores the > >> >> "authorized" FQDN. This would require a change in current Diameter > >> >> application > >> > > >> > Yes. Or a new AVP, at least. CUI might apply here, but it might > >> > not have exactly the semantics you want. > >> > > >> >> - the HA performs a AAA exchange when it receives a BU with a DNS > >> >> Update mobility option; this AAA exchange should be part of the Mobile > >> >> IPv6 Diameter application (work in progress in DIME WG) and should be > >> >> used by the HA to get the authorized FQDN from the AAA server in order > >> >> to update the DNS > >> > > >> > This sounds preliminarily better. > >> > >> I don't like this additional AAA exchange just for the > >> DNS update. We should go with the solution where the > >> AAA server sends the mobile node's true FQDN (the one > >> that appears in the DNS) to the home agent in the AA > >> Answer message or the Diameter EAP Answer message, > >> depending on whether authentication and authorization > >> is done separately or together. > >> > >> (I haven't followed the work in Dime for a while. So > >> I don't know what the current thinking is). > >> > > > > The AAA exchange may not be an additional one. Currently we are > > discussing this issue in DIME WG (please, it would be great if you > > take part on that discussion too); there are two options under > > discussion, depending if the authorization for MIPv6 bootstrapping is > > performed during the bootstrapping or after the first BU. The latter > > option derives from the consideration that the MN is actually using > > the MIP service only after the first BU. > > Why would a mobile node setup security associations with > a home agent or send a BU to the home agent if not for > mobility service? > I agree for the BU. However, suppose the HA is acting also as VPN concentrator (or 3GPP PDG or similar): there may be cases where the MN sets up a SA with this box and then use it not for MIPv6. This is an issue in DIME design: we are discussing when the authorization for MIPv6 should be performed. --Gerardo > >> >> The draft should leave the actual definition of either mechanism as > >> >> out of scope (as you suggested), but we should put a reference to the > >> >> solution. > >> >> > >> >> As a summary, in this draft, I think it is enough to clarify the need > >> >> of the FQDN in the cert for the certificates scenario. For the AAA/EAP > >> >> scenario, we should provide a reference for the HA-AAA coordination > >> >> needed in case EAP is used, > >> > >> IMO, whenever the mobile nodes uses different identities > >> in the IDi field and in EAP payloads, we should require > >> the AAA server to send the mobile node's identity to > >> the Home Agent. > >> > > > > That is the first option I described, isn't it? > > Yes. > > Vijay > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 04:56:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMLWp-00034A-1X; Wed, 28 Feb 2007 04:55:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMLWo-000342-Ag for mip6@ietf.org; Wed, 28 Feb 2007 04:55:18 -0500 Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMLWm-0001yc-Pe for mip6@ietf.org; Wed, 28 Feb 2007 04:55:18 -0500 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id l1S9t4pF001399 for ; Wed, 28 Feb 2007 11:55:05 +0200 (EET) Received: from [131.177.37.116] (l50029133.pool.sonera.fi [131.177.37.116]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id l1S9ssu3001344; Wed, 28 Feb 2007 11:54:54 +0200 (EET) Message-ID: <45E55166.7070002@teliasonera.com> Date: Wed, 28 Feb 2007 11:54:46 +0200 From: Jouni Korhonen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Kilian Weniger Subject: Re: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 References: <7CCD07160348804497EF29E9EA5560D7FBD9BB@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7FBD9BB@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: mip6@ietf.org, Heejin Jang , Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Kilian, [snip] >> I heard at least one operator requesting such feature (and note that >> this is in principle possible with the HA discovery/assignment >> mechanisms defined in the split scenario bootstrapping draft). A > simple >> way to support this in the integrated scenario would be to add > something >> like a "type of requested HA service" field in the Home Network >> Identifier Option of the DHCP information request sent by the MN. The >> new field would encode the type of service, e.g., 0=MIPv6, 1=DS-MIPv6, >> 2=NEMO,...). Similarly, the Home Network Information Sub-option could >> include a "type of HA service" field to inform the MN about the type > of Good point imho. >> service supported by the HA offered in this option. However, since the >> AAAH wouldn't know the HA service requested by the MN, AAAH would need >> to send at least one HA address per supported service to the NAS. >> > [KC>] Alternatively, we can encode the Home Network Identifier (FQDN) as > ha.dsmip6.domain, ha.mip6.domain. This is possible with the current > HIOPT I-D, no? From the AAAH perspective, it (AAAH) needs to send the HA > address - Service pair. The service can be indicated by the FQDN AVP. We > have the following AVPs in draft-ietf-dime-mip6-integrated-03.txt: > > [ MIP6-Home-Agent-Address ] > [ MIP6-Home-Agent-FQDN ] Using different FQDNs under the same operator domain for differentiating between types of service nodes is already practised in some 'relevant' SDOs. In that sense I think it could be a good approach. Dime's I-D draft-ietf-dime-mip6-integrated allows a NAS to give hints already to the AAAH using AVPs mentioned above and since we are about to revise the Dime I-D this part could be clarified further. > Perhaps we can group them under a new AVP for service, e.g. > MIP6-Home-Agent-Info AVP. For RADIUS we can perhaps link the MIP6-HA > Attribute and MIP6-HA-FQDN Attribute. There was also some other SDO asking for more generic 'ASP info' AVP e.g. for local HA assignment. MAybe these could be combined. IMHO this discussion should be brought to Dime as well. Cheers, Jouni > > > >> What do you think? >> >> Cheers, >> >> Kilian >> >> >> Panasonic R&D Center Germany GmbH >> 63225 Langen, Hessen, Germany >> Reg: AG Offenbach (Hessen) HRB 33974 >> Managing Director: Thomas Micke >> > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 05:12:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMLn8-00072u-K3; Wed, 28 Feb 2007 05:12:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMLn6-0006qs-Uk for mip6@ietf.org; Wed, 28 Feb 2007 05:12:08 -0500 Received: from av6-2-sn3.vrr.skanova.net ([81.228.9.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMLn3-00041d-3J for mip6@ietf.org; Wed, 28 Feb 2007 05:12:08 -0500 Received: by av6-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 4381437F79; Wed, 28 Feb 2007 11:12:04 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 200DF37F78; Wed, 28 Feb 2007 11:12:04 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 7FCAB37E48; Wed, 28 Feb 2007 11:12:03 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1HMLn1-000632-4I; Wed, 28 Feb 2007 11:12:03 +0100 Message-ID: <45E55576.1040805@levkowetz.com> Date: Wed, 28 Feb 2007 11:12:06 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Issue 73: v4 mapped address in IPv6 header References: <20070226030713.OARH19269.omta05ps.mx.bigpond.com@PC20005> <45E33559.1080404@azairenet.com> In-Reply-To: <45E33559.1080404@azairenet.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: vijay.devarapalli@azairenet.com, Hesham@elevatemobile.com, mip6@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, on 2007-02-26 20:30 Vijay Devarapalli said the following: > Hello, > > There were some more concerns/issues raised regarding the use > of a mapped address instead of an explicit mobility option for > the IPv4 care-of address. > > I prefer the use of an explicit IPv4 CoA option in the binding > update to carry the IPv4 care-of address of the mobile node. Agreed. This is also my viewpoint. My original primary reason when discussing this long ago was Vijay's reason #2 below, but also the others make sense to me. Henrik > Here are some reasons. > > 1. Many implementations don't support mapped addresses. > 2. The IPv4 CoA is indicated explicitly through the use of a > mobility option. I prefer this explicit indication for the > IPv4 CoA. The binding update processing on the home agent > becomes easier to parse the IPv4 care-of address and compare > it with the IPv4 source address on the outermost IPv4 header > for NAT detection. > 3. In case there is no NAT on the path, ESP protection is > provided for the IPv4 CoA since it is a mobility option > which comes after the ESP header. > 4. It enables one to send a binding update in the tunneled > format. > > IPv4 header (src = V4ADDR, dst = HA_V4ADDr) > UDP header > ESP header in tunnel mode > IPv6 header (src = IPv6 HoA, dst = HA_V6ADDR) > Mobility header > Binding Update > IPv4 CoA option (IPv4 CoA) > > Of course one can always send a BU in transport format, but > the IPv4 CoA option enables one to also send a BU in the > tunneled format in an optimized manner. Without the use of > IPv4 CoA option, the tunneled BU will have too much overhead. > > There are many reasons why you would want to send a tunneled > BU. One is privacy. The other is to enable an implementation > to use just one tunnel mode ESP SA to protect all MIPv6 > signaling messages and payload traffic. > > Hope this helps. > Vijay > > Hesham Soliman wrote: >> Folks, >> >> This is the final issue listed on the tracker. This one is a bit long. >> >> Issue Text: >> ----------- >> >> the IPv4 mapped address has a special meaning by RFC >> 2553 API. It is not preferable to use the mapped address in IPv6 >> headers (See the following the drafts) >> draft-itojun-v6ops-v4mapped-harmful >> draft-cmetz-v6ops-v4mapped-api-harmful >> >> In our code based on KAME, the IPv6 implementation discard a IPv6 >> header which has the v4 mapped address for sanity at ip6_input() and >> ip6_rthadr2(). We also need to add the mapped address in an address >> list (the list of all addresses which the node has) to receive the >> header. This is somehow uncomfortable because the mapped address is >> actually not routable. >> >>>From Hesham: >> => No one suggested that it should/would be routable. It's simply >> used to keep the packet format. There is no routing based on this >> information. >> >>>From Koshiro: >> => I am not sure whether it's just an implementation issues. But putting >> the mapped address in the address list in order to process the DSMIP >> IPv6 header means the mapped address may be chosen as a source address >> even the address is actually not routable. To avoid this, we need >> e.g. an additional flag to distinguish the mapped address from others. >> I think some implementers will not accept this. >> >> The above is not only the reason again the mapped address in the IPv6 >> header. Please refer the draft-*-harmful. So, my idea is to put HoA >> in IPv6 header and kind of IPv4 CoA option to idicate it's IPv4 CoA. >> >> BTW, if you just want to keep the packer format, I think it's better >> to use compatible address, or 6to4 address, or newly-defined address >> for this purpose. >> >> Analysis: >> --------- >> >> The resons listed in the issue text (and other reasons discussed in the DT) >> as well as their rebuttal are listed in this section. The first reason for >> using a different address format was that the use of mapped address was not >> recommended. The issue text refers to two drafts above. Those two drafts >> were discussed several years ago in 2002 (first v6ops meeting). The only >> issue that was agreed on in those drafts was that the mapped address should >> not be used as a routable address. Therefore, the issue misinterprets the >> agreement in the community. Also, the mapped address is not used as a >> routable address in DSMIP. The drafts referred to above did suggest the >> removal of the v4 mapped address altogether from IPv6, but this suggestion >> was rejected and the drafts were not adopted. Mapped addresses are supported >> in all major OSs (with the exception of KAME). >> >> The issue text also suggests the use of a different address format >> (compatible address, 6-to-4, or a new address format). The compatible >> address format was deprecated from the IPv6 address architecture and the >> mapped format is the recommended format for embedding IPv4 addresses in >> IPv6. 6-to-4 addresses imply a specific tunnelling behaviour (tunnelling to >> the v4 address), which is not useful for our purposes. A new address format >> will be no different from the mapped address, which is designed for this >> purpose. >> >> Another concern that was raised against the use of the mapped address was >> that they are "implicit" in nature ad do not explicitly show the IPv4 >> address. However, IP stacks must check the src address in the packet to >> insure that is in fact a legal address (e.g. not multicast) in ip6_input. >> >> >> Recommendation: >> -------------- >> >> My recommendation is to reject this issue for several reasons: >> a. There is no clear problem with the current format, i.e. what breaks? >> b. We've already removed the alt-CoA option in a previous issue, so if we >> accept this issue we'd have to introduce a new address format for DSMIP. >> This can take a long time and will yield the same result. Although, if there >> is something specific in the mapped address format that will cause problems, >> and a new address format will solve this problem then I'm personally ok with >> the new address format. However, we need to understand what that problem is. >> >> >> >> Regards, >> Hesham >> >> >> >> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 05:19:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMLuO-0005x3-QY; Wed, 28 Feb 2007 05:19:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMLuM-0005wa-P4 for mip6@ietf.org; Wed, 28 Feb 2007 05:19:38 -0500 Received: from av11-2-sn2.hy.skanova.net ([81.228.8.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMLuL-0004sG-FM for mip6@ietf.org; Wed, 28 Feb 2007 05:19:38 -0500 Received: by av11-2-sn2.hy.skanova.net (Postfix, from userid 502) id 8FDBF37FC0; Wed, 28 Feb 2007 11:19:36 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-2-sn2.hy.skanova.net (Postfix) with ESMTP id 50A5737FA7; Wed, 28 Feb 2007 11:19:36 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id DF4C537E50; Wed, 28 Feb 2007 11:19:35 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1HMLuJ-0001Uy-8M; Wed, 28 Feb 2007 11:19:35 +0100 Message-ID: <45E55737.1060505@levkowetz.com> Date: Wed, 28 Feb 2007 11:19:35 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Issue 73: v4 mapped address in IPv6 header References: <20070227060051.GXCG9388.omta05ps.mx.bigpond.com@PC20005> In-Reply-To: <20070227060051.GXCG9388.omta05ps.mx.bigpond.com@PC20005> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: Hesham@elevatemobile.com, vijay.devarapalli@azairenet.com, mip6@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'Mobile IPv6 Mailing List' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, on 2007-02-27 07:00 Hesham Soliman said the following: [snipping some discussion] > > Now, on the flip side, with this format you need to define a new option, > parse it ..etc, whereas with the other format you use the same BU that is > used today. So there is no change in the BU with the mapped address. On this point in particular, it makes sense to squeeze new functionality into an old format if you're experimenting or hacking, but once we go into standard defining mode it's much cleaner, to my way of thinking, to define a new option. In this case, we don't yet have an option to carry an IPv4 CoA; the right thing is to define it, the wrong thing is to drop the v4 CoA into a field defined to hold an IPv6 address. Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 11:36:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMRmU-0003QI-O1; Wed, 28 Feb 2007 11:35:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMRmU-0003QD-Dx for mip6@ietf.org; Wed, 28 Feb 2007 11:35:54 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMRmR-000338-4z for mip6@ietf.org; Wed, 28 Feb 2007 11:35:54 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 92FC09000C for ; Wed, 28 Feb 2007 11:35:47 -0500 (EST) 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 15058-07 for ; Wed, 28 Feb 2007 11:35:42 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 28 Feb 2007 11:35:42 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 11:35:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Feb 2007 11:35:42 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD9C9@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DSMIP6 solution and integrated bootstrap scenario Thread-Index: AcdbVnhKF1b2JClGQ3GhowIpEnaXfA== From: "Chowdhury, Kuntal" To: X-OriginalArrivalTime: 28 Feb 2007 16:35:42.0841 (UTC) FILETIME=[7D279690:01C75B56] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Mip6] DSMIP6 solution and integrated bootstrap scenario X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, I see that in the DSMIP6 I-D (draft-ietf-mip6-nemo-v4traversal-03.txt) we have the following sentence in section 2.1 Home Agent Address Discover " The preferred solution for discovering the home agent's IPv4 address is through the Domain Name System (DNS). " The preferred solution for discovering Home Agent Address in the integrated bootstrap scenario is DHCP not DNS. We need to address this issue. -Kuntal _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 11:59:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMS9X-00059I-DQ; Wed, 28 Feb 2007 11:59:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMS9V-00058z-Ua for mip6@ietf.org; Wed, 28 Feb 2007 11:59:41 -0500 Received: from cluster-e.mailcontrol.com ([217.79.216.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMS9T-0006N7-OB for mip6@ietf.org; Wed, 28 Feb 2007 11:59:41 -0500 Received: from rly14e.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly14e.srv.mailcontrol.com (MailControl) with ESMTP id l1SGxUS8019532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Feb 2007 16:59:36 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly14e.srv.mailcontrol.com (MailControl) id l1SGxQU5019149 for mip6@ietf.org; Wed, 28 Feb 2007 16:59:26 GMT Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly14e-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l1SGxJTJ018598; Wed, 28 Feb 2007 16:59:26 +0000 (GMT) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 3c62_1e510768_c74a_11db_81ba_0030482aac25; Wed, 28 Feb 2007 17:38:28 +0100 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007022817590032-1004131 ; Wed, 28 Feb 2007 17:59:00 +0100 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: -0.156,BAYES_00: -1.665,TOTAL_SCORE: -1.821 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 28 Feb 2007 18:03:54 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 In-Reply-To: <7CCD07160348804497EF29E9EA5560D7FBD9B9$0001@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Thread-Index: AcdQY1dNlaD6hLxWEduSnQARJNUNiAAgF6FwARg2mFAARgirYAETqRlgABmMyrA= References: <7CCD07160348804497EF29E9EA5560D7FBD9B9$0001@exchtewks2.starentnetworks.com> To: "Chowdhury, Kuntal" Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F012783CB@lan-ex-01.panasonic.de> Date: Wed, 28 Feb 2007 17:56:00 +0100 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-06-00-00 (www.mailcontrol.com) on 10.69.1.124 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.2 (+) X-Scan-Signature: b148ead9c6581b10314b24a9438d3a5f Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Kuntal, Please see my comments inline. > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > Sent: Dienstag, 27. Februar 2007 21:50 > To: Kilian Weniger > Cc: mip6@ietf.org; Basavaraj Patil > Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 >=20 > Hi Kilian, >=20 > Please see inline.... >=20 > I will start updating the I-D with your comments after the=20 > WGLC is over. >=20 > Regards, > Kuntal >=20 >=20 > > -----Original Message----- > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > Sent: Thursday, February 22, 2007 5:06 AM > > To: Chowdhury, Kuntal > > Cc: mip6@ietf.org; Basavaraj Patil > > Subject: RE: [Mip6] WGLC:=20 > draft-ietf-mip6-bootstrapping-integrated-02 > >=20 > > Hi Kuntal, > >=20 > > thanks for you comments. See my comments inline. > >=20 > > > -----Original Message----- > > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > Sent: Mittwoch, 21. Februar 2007 19:49 > > > To: Kilian Weniger; Basavaraj Patil; mip6@ietf.org > > > Subject: RE: [Mip6] WGLC: > draft-ietf-mip6-bootstrapping-integrated-02 > > > > > > Hi Killian, > > > > > > Thanks for reviewing the draft. I see that Heejin already=20 > responded > to > > > you. Let me add some of my comments...please see inline. > >=20 > > I will reply to Heejin in a separate mail. > >=20 > > > > > > Regards, > > > Kuntal > > > > > > > > > > -----Original Message----- > > > > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com] > > > > Sent: Friday, February 16, 2007 2:31 AM > > > > To: Basavaraj Patil; mip6@ietf.org > > > > Subject: RE: [Mip6] WGLC: > > > draft-ietf-mip6-bootstrapping-integrated-02 > > > > > > > > Hi, > > > > > > > > please find below some comments about > > > > draft-ietf-mip6-bootstrapping-integrated-02. > > > > > > > > The draft is well written and easy to understand (thanks to > figures > > > and > > > > message sequence text). However, some details and corner > > > cases are not > > > > addressed, which may need to be specified, e.g.: > > > > > > > > - How does the NAS/relay map a DHCP request received from a > specific > > > MN > > > > to the cached home network information previously > > > received from AAAH > > > > for this MN, so that it can include the correct home network > > > > information in a received DHCP request? > > > > > > [KC>] Normally NAS maintain session states along with lower layer > > > identifiers such as tunnel ID, MAC address etc. These identifiers > help > > > NAS in locating the correct cached info for the MN. > >=20 > > ok, I was expecting that. Maybe this could be clarified in the draft > for > > better understanding (without mandating a specific lower layer > > identifier of course). > >=20 > [KC>] OK. I will try to clarify this in the next revision. >=20 > > > > > > > - What is the conceptual data structure needed for this in the > > > NAS/DHCP > > > > relay? > > > > - Any default value for how long NAS should cache home network > > > > information received from AAA for a specific MN (i.e., when is > NAS > > > > allowed to delete cache entry?)? If this is specified in > > > [MIP6-Dime] > > > > or [MIP6-RADIUS] it should be mentioned and referenced. > > > > > > [KC>] As Heejin mentioned, I think these are=20 > implementation specific > > > details. > >=20 > > yes, but I think some guidance with respect to values that=20 > make sense > > might be helpful for implementors. > >=20 > [KC>] We can say: how long the NAS caches the received mip6 bootstrap > information for a MN should be configurable. Ok. Additionally, we could say something like "The cache time should be at least as long as the maximum time it can take to receive a DHCP Information Request from a MN's DHCP client after a successful network authentication.". >=20 > > > > > > > > > > - What should NAS do if DHCP request with Home network=20 > identifier > > > > option is received from a MN and NAS doesn't find valid > > > home network > > > > information for this MN in its cache (e.g., since the cache > entry > > > > has expired)? > > > > > > [KC>] If a NAS implementation does not store the home network > > > information as long as the MN's session remains in the ASP, this > > > scenario may happen if the MN delays sending DHCP request. In > > > such case, > > > the NAS/DHCP relay won't include the=20 > OPTION_MIP6-RELAY-Option in the > > > Relay Forward message. > >=20 > > ok. Shouldn't the draft specify this behaviour? > >=20 > [KC>] OK. I will clarify this. >=20 > > > > > > > - What should DHCP relay/server do if the MN does not=20 > include the > > > > OPTION_CLIENTID in the DHCP request or if > OPTION_MIP6-RELAY-Option > > > > is missing in request? > > > > > > > > > > [KC>] I think Heejin already clarified this with you. > > > > > > > The draft may need better aligned with [HIOPT]. For instance, it > is > > > not > > > > clear to me how exactly the home network identifier=20 > option and the > > > home > > > > network information option specified in [HIOPT] are allowed > > > to be used > > > > in draft-ietf-mip6-bootstrapping-integrated-02: > > > > > > > [KC>] This part was in this I-D. However, based on the > > > consensus we had > > > in the WG, we decided to move all the DHCP related=20 > behavior to HIOT. > > > Please look at section 4 in HIOT. > >=20 > > ok. So the split is that HIOPT specifies all the DHCP related > behaviour > > and defines the DHCP messages/options and > > draft-ietf-mip6-bootstrapping-integrated-02 defines how this > interworks > > with AAA and gives the overall picture? Is this correct? I think > > draft-ietf-mip6-bootstrapping-integrated-02 should clearly say what > its > > scope is and how the split is with respect to HIOPT (and=20 > the reference > > should be updated to new HIOPT-version). > >=20 > [KC>] OK. I will see how to clarify this in the next revision. Of > course, feel free to provide text to me if you like. How about: "This draft enables HA and HoA assignment in the integrated scenario by utilizing DHCP and AAA protocols. The specification is split in two parts: Whereas [HIOPT] specifies the required DHCP protocol extensions and DHCP server behaviour, this draft specifies the interworking with AAA and gives an overview of the overall bootstrapping procedure in the integrated scenario." >=20 >=20 > > > > > > > - [HIOPT] supports home address allocation. This is not=20 > mentioned > in > > > > draft-ietf-mip6-bootstrapping-integrated-02. Is this forbidden > or > > > > allowed or out-of-scope? If allowed, when does NAS set > > > the A-flag in > > > > the home network identifier option? > > > > > > [KC>] Please see Heejin's clarification. > > > > > > > - Is it allowed that multiple HA addresses are returned in the > home > > > > network information option? > > > [KC>] yes, it is allowed. > >=20 > > ok. In general, I think all the supported features should=20 > be mentioned > > in draft-ietf-mip6-bootstrapping-integrated-02. > >=20 > [KC>] OK. I will mention that the AAAH may return more than one home > agent for each of the MSPs. >=20 > > > > > > > - [HIOPT] allows that the home network identifier=20 > option includes > an > > > > identifier of a target network, which is different=20 > from home or > > > > visited network of MN. This is not mentioned in > > > > draft-ietf-mip6-bootstrapping-integrated-02. Is this=20 > allowed or > > > > forbidden? > > > [KC>] the main assumption in integrated scenario is ASA =3D=3D = MSA. It > is > > > the MSA that authorizes the MN for mobility service and assigns > > > appropriate number of Home Agents (in each MSPs if there are > multiple > > > MSPs) for the MN. If the MN sends DHCP request with home network > > > identifier option set to one of the authorized MSPs and there is a > HA > > > assignment for that MSP by the MSA, the MN will get that HA's > address. > > > If the MN sends anything else (i.e. a domain that is not=20 > part of the > > > authorized list of MSPs by the MSA), the MN may not get any Home > Agent > > > address in the reply. > >=20 > > I see. So every realm of any MSP that has a trust=20 > relationship to the > > MN's MSA and that is supported by the MSA's allocation policy can be > > included as target network in the home network identifier option, > right? > > (That's what I meant by "a target network, which is different from > home > > or visited network of MN".) > >=20 > [KC>] Yes. >=20 > > Hmm, after checking RFC4640, it seems that there is a=20 > mismatch between > > your comment and what the draft says: > >=20 > > - Section 3.2.1 of draft-ietf-mip6-bootstrapping-integrated-02 says > > "This section describes a scenario where the home agent is allocated > in > > the mobile node's *home MSP* network." > > - RFC 4640 says in section 6: "A network operator providing Mobile > IPv6 > > service is called a mobility service provider (MSP). ...A network > > operator that authenticates a mobile node and authorizes mobility > > service is called a mobility service authorizer (MSA). If both types > of > > operation are performed by the same operator, that operator=20 > is called > a > > *home mobility service provider*.". > >=20 > > So according to RFC4640 the home MSP is always the MSA.=20 > Since you said > > HA allocation from other networks is supported, I think the use of > "home > > MSP" in the section 3.2.1 is not correct. Or am I missing something > > here? > >=20 > [KC>] Your interpretation of home MSP is correct. However, it is quite > possible that the home MSP/MSA can also assign (or authorize)=20 > Home Agent > in a different MSP e.g. local Home Agent assignment in the visited > domain (ASP). This is possible based on roaming agreements between the > home MSP and the ASP (ref section 3.2.2).=20 right. > I do understand the source of your confusion though. I think step 1 in > section 3.2.2 needs to be updated to show that the home MSP actually > authorizes the MN to get an HA address in the visited domain=20 > (ASP). The > NAS needs to indicate it's capability for local HA assignment. The NAS > will optionally indicate the HA address in the ASP that will=20 > be assigned > to the MN in case that option is authorized by the home MSP. These > clarifications will be added in the AAA drafts: > draft-ietf-dime-mip6-integrated-02.txt and > draft-ietf-mip6-radius-01.txt.=20 Ok >=20 > > And I think the support of the feature of HA allocation from MSP = !=3D > MSA > > and !=3D ASP should be mentioned in the draft. > >=20 > [KC>] OK. I will add some text around that topic. ok.=20 > > > > > > > - Which HA information should the MN use if it receives, > > > e.g., an FQDN > > > > and a HA address in DHCP reply? [HIOPT] refers to=20 > section 3.6 of > > > > draft-ietf-mip6-bootstrapping-integrated-01, but this section > > > doesn't > > > > exist in draft-ietf-mip6-bootstrapping-integrated-02=20 > anymore... > > > > > > > [KC>] This text was exported to HIOT draft. > > > > > > > Some other comments: > > > > > > > > - It would be good to have a section, which explicitly states > > > > assumptions and applicability of the protocol. This > > > should include: > > > > - MSA and ASA must be co-located (i.e.,=20 > integrated scenario) > > > > > > [KC>] The definition of integrated scenario exists in RFC 4640. > > > > > > > - AAA infrastructure assumed and some kind of roaming > > > > relationship between ASP and MSA/ASA is required > > > > > > [KC>] We have ample references to AAA infrastructure for ASA and > MSA. > > > However, we can still add a sentence about the use of AAA > > > infrastructure > > > to authenticate and authorize the MN. Regarding roaming, I think > your > > > comment is valid. ASP <-> ASA/MSA and MSP <-> ASA/MSA roaming > > > relationships are basic requirements for any access auth/authz for > the > > > MN. However, I think it is a generic requirement. Even in > > > case of split > > > scenario, ASP <-> ASA and MSP <-> MSA roaming relationships are > > > necessary. Look at section 6 in RFC 4640 and let me know what > > > you think. > >=20 > > ASP <-> ASA is general requirement for network access in roaming > > scenarios, I agree. But the required MSP <-> ASA roaming=20 > relationship > is > > specific to this draft and it would be worth mentioning IMHO. > > You are right, the reader could deduced it to some extent from > RFC4640, > > which says that MSA <-> MSP roaming relationship is *supported* (not > > required) for MIP bootstrapping and MSA =3D ASA is an assumption in > > integrated scenario. I prefer to make a clear statement about > > assumptions/requirements of solutions in the draft. > >=20 > [KC>] OK. Could you please suggest some text on this? How about: "The solution described in this draft is only applicable for the integrated scenario, which means that it is assumed that MSA and ASA are the same [boot-ps]. Further, it is assumed that the MSP is either equal to the MSA/ASA (i.e., it is a home MSP) or has a roaming relationship with the MSA/ASA. In the latter case, the MSP can be in the ASP or in any other network." >=20 > > > > > > > - MSP is either co-located with ASP or MSA or both > > > > (Or are other target networks allowed; see above)? > > > > > > [KC>] Why we need to mandate collocation of MSP with ASA=20 > or MSA? The > > > draft HIOT allows any target network, but that does not mean > > > that in the > > > integrated scenario, the MSA can bootstrap the MN for any (random) > > > target network. > >=20 > > This requirements comes from the misunderstanding about the home MSP > > explained above. Since you clarified that target network !=3D=20 > MSA and !=3D > > ASP is supported, you are right that this requirement is not valid > > anymore... > >=20 > > > > > > > - DHCP relay and NAS must be co-located > > > > > > > [KC>] I think it is already mentioned in the draft: > > > " > > > Also, the mechanism defined in this document requires the NAS > > > to support > > > Mobile IPv6 specific AAA attributes and a collocated DHCP relay > agent. > > > " > >=20 > > yes, it is somewhat redundant. I just prefer it if the applicability > and > > all the requirements for the solution are clearly stated (preferably > in > > a separate section, as opposed to hidden in the text). > >=20 > [KC>] OK, I will add a section to state the assumptions. Ok. See above for a text proposal. >=20 > > > > > > > - At some places in the text the use of the term "MSP" is > ambiguous, > > > > since MSP can refer to at least home and visited=20 > network. Better > > > > use "home MSP" for MSP in home network. > > > > - e.g., section 3.1: > > > > "Note that a home agent for usage > > > > with the mobile node might be selected in the access service > > > > provider's network or alternatively in the *home* > > > mobility service > > > > provider's network." > > > > > > [KC>] I understand your point. We can clarify by saying that: > > > > > > " > > > Note that a home agent for usage with the mobile node might > > > be selected > > > in the access service provider's network (ASP is the visited > > > MSP in this > > > case) or alternatively in the *home* mobility service > > > provider's network > > > (home MSP). > > > " > > > What do you think? If you agree, I will ensure that this is > clarified > > > elsewhere in the document. > >=20 > > Hmm, after having read your comments, "home MSP" might not=20 > be correct > > here, since MSP can be !=3D MSA (i.e., !=3D home MSP) in this=20 > section. How > > about "MSP different from ASP" instead of "home MSP"? > >=20 > [KC>] OK. In that case, I will keep the existing text and modify it as > follows: >=20 > "Note that a Home Agent for usage with the MN might be selected in the > Access Service Provider's network (ASP =3D=3D MSP) or in a=20 > different network > (ASP !=3D MSP)" ok. Furthermore, the term "home MSP" in section 3.2.1 must be replaced, e.g., by "MSP !=3D ASP" (i.e., any MSP with roaming relationship with = MSA, but different from ASP). >=20 > > > > > > > - or in section 3.2: > > > > "The message flows for home agent > > > > allocation in the ASP and the *home* MSP are=20 > illustrated below. > > > > > > [KC>] Similarly we can clarify: > > > > > > " > > > The message flows for home agent allocation in the ASP (ASP is the > > > visited MSP in this case) and the *home* MSP are=20 > illustrated below. > > > " > >=20 > > Home MSP might not be correct (see above). How about > >=20 > > "The message flows for home agent allocation in the MSP for=20 > the cases > > that the MSP is equal to the ASP and different from the ASP are > > illustrated below." > >=20 > >=20 > [KC>] OK. >=20 > > > > > > > - or in section 3.2.1: > > > > "3.2.1. Home Agent allocation in the *home* MSP", > > > > "(4)... mobile node is requesting home agent=20 > information in the > > > > *home* MSP..." > > > > > > > > - Section 3.3 currently mentions DNS-based HA address > > > discovery method > > > > only, but [BOOT-SPLIT] also specifies an anycast-based HA > address > > > > discovery method. Either both or none should be mentioned. > > > > > > > [KC>] I see your point. May be we just need to say that > > > incase the DHCP > > > reply comes back with no Home Agent address, the MN may=20 > fallback to > > > other methods for Home Agent bootstrapping. Some of those methods > are > > > mentioned in [BOOT-SPLIT]. > >=20 > > sounds good. > >=20 > > > > > > > > > > - The title of draft-ietf-mip6-bootstrapping-integrated-02 can > cause > > > > the impression that the draft defines a complete bootstrapping > > > > procedure. But > > > draft-ietf-mip6-bootstrapping-integrated-02 defines a > > > > method for HA address assignment only. I think this is > misleading. > > > > Why not name the draft according to what it specifies=20 > (e.g., "HA > > > > address assignment using DHCP and AAA" or "HA address > > > assignment for > > > > the integrated scenario using DHCP and AAA" instead of > > > > "MIP6-bootstrapping for the integrated scenario")? > > > > > > > [KC>] I agree with you that the Home Agent assignment is the focus > of > > > the integrated scenario solution I-D. But, the suggested title > change > > > will be misleading too. One of the primary assumption in the > > > integrated > > > scenario for mip6 bootstrapping is ASA =3D=3D MSA. This is the = main > reason > > > why the MSA can authorize the MN to have mobility service at > > > the time of > > > access auth/authz at the ASA. As per this assumption, the MSA > assigns > > > Home Agent info to the MN at the time of access auth. The MSA can > > > potentially assign the HoA as well (in some deployments that may > very > > > well be the case), but we stayed away from mentioning that in > > > the draft > > > based on consensus. Another reason was to reuse text from other > drafts > > > as much possible. > > > > > > That said, the scope and focus of this I-D is to address mip6 > > > bootstrapping solution for the "Integrated ASP Network=20 > Scenario" as > > > defined by RFC 4640. So, the current title is fine, IMHO. > >=20 > > Since the introduction says "This document defines a mechanism for > home > > agent address discovery. For the rest of components,=20 > please refer to > > [BOOT-SPLIT].", I think the title is still ok. > >=20 > > However, you mentioned that HoA allocation can be done by the MSA > > (probably by using the method specified in HIOPT). If this shall be > > supported in the integrated scenario, I think the draft has=20 > to mention > > it. Currently, the draft clearly says that HoA allocation=20 > is according > > to [BOOT-SPLIT]... > >=20 > [KC>] I agree. I am OK to include HoA assignment in the I-D to utilize > the full potential of HIOPT. I will include it unless there are > objections from the members. Ok. Thanks, Kilian >=20 >=20 > > Regards, > >=20 > > Kilian > >=20 > > > > > > > > > > > > > Regards, > > > > > > > > Kilian > > > > > > > > > -----Original Message----- > > > > > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > > > > > Sent: Mittwoch, 14. Februar 2007 19:10 > > > > > To: mip6@ietf.org > > > > > Subject: [Mip6] WGLC: > draft-ietf-mip6-bootstrapping-integrated-02 > > > > > > > > > > > > > > > Hello, > > > > > > > > > > This is a MIP6 Working group last call for the WG I-D: > > > > > "MIP6-bootstrapping for the Integrated Scenario", > > > > > draft-ietf-mip6-bootstrapping-integrated-02.txt > > > > > > > > > > I-D: > > > > > http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping- > > > > > integrated-dhc > > > > > -02.txt > > > > > > > > > > Please review and submit your comments to the authors or > > > the mailing > > > > > list. The WGLC will expire on March 1st, 07. > > > > > > > > > > -Chairs > > > > > > > > > > > > > > > _______________________________________________ > > > > > Mip6 mailing list > > > > > Mip6@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > > > > > > > Panasonic R&D Center Germany GmbH > > > > 63225 Langen, Hessen, Germany > > > > Reg: AG Offenbach (Hessen) HRB 33974 > > > > Managing Director: Thomas Micke > > > > > > > > > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > "This email message and any attachments are confidential > > > information of Starent Networks, Corp. The information > > > transmitted may not be used to create or change any > > > contractual obligations of Starent Networks, Corp. Any > > > review, retransmission, dissemination or other use of, or > > > taking of any action in reliance upon this e-mail and its > > > attachments by persons or entities other than the intended > > > recipient is prohibited. If you are not the intended > > > recipient, please notify the sender immediately -- by > > > replying to this message or by sending an email to > > > postmaster@starentnetworks.com -- and destroy all copies of > > > this message and any attachments without reading or > > > disclosing their contents. Thank you." > > > > > > > >=20 > >=20 > > Panasonic R&D Center Germany GmbH > > 63225 Langen, Hessen, Germany > > Reg: AG Offenbach (Hessen) HRB 33974 > > Managing Director: Thomas Micke > >=20 >=20 >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 12:00:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMSA7-0005WO-47; Wed, 28 Feb 2007 12:00:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMSA5-0005VT-JR for mip6@ietf.org; Wed, 28 Feb 2007 12:00:17 -0500 Received: from cluster-e.mailcontrol.com ([217.79.216.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMSA3-0006WL-6M for mip6@ietf.org; Wed, 28 Feb 2007 12:00:17 -0500 Received: from rly43e.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly43e.srv.mailcontrol.com (MailControl) with ESMTP id l1SGxqmT004197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Feb 2007 17:00:10 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly43e.srv.mailcontrol.com (MailControl) id l1SGxIDL002047 for mip6@ietf.org; Wed, 28 Feb 2007 16:59:18 GMT Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly43e-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id l1SGx40K000882; Wed, 28 Feb 2007 16:59:18 +0000 (GMT) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 3c1e_15f12abc_c74a_11db_8fac_0030482aac25; Wed, 28 Feb 2007 17:38:14 +0100 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2007022817590077-1004132 ; Wed, 28 Feb 2007 17:59:00 +0100 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: -0.156,BAYES_00: -1.665,TOTAL_SCORE: -1.821 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Wed, 28 Feb 2007 18:03:54 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 In-Reply-To: <45E55166.7070002@teliasonera.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Thread-Index: AcdbHjoLeiuXo3N2R5a7UKacFyd9gAAOMPHQ References: <7CCD07160348804497EF29E9EA5560D7FBD9BB@exchtewks2.starentnetworks.com> <45E55166.7070002@teliasonera.com> To: "Jouni Korhonen" Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F012783CC@lan-ex-01.panasonic.de> Date: Wed, 28 Feb 2007 17:55:18 +0100 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-07-06-90 (www.mailcontrol.com) on 10.69.1.153 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.2 (+) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: mip6@ietf.org, Heejin Jang , Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Kuntal, Jouni,=20 yes, encoding the service in the Home Network Identifier field would also be possible (probably with changes to [HIOPT]). However, this has the danger of overloading the semantics, since this would change the network identifier to something like a "network+service" identifier. And don't we need to standardize a format then, since the format for encoding the service into the FQDN must be understood by the MSA *and all ASPs*, right?=20 Cheers, Kilian > -----Original Message----- > From: Jouni Korhonen [mailto:jouni.korhonen@teliasonera.com]=20 > Sent: Mittwoch, 28. Februar 2007 10:55 > To: Kilian Weniger > Cc: Chowdhury, Kuntal; Heejin Jang; mip6@ietf.org; Basavaraj Patil > Subject: Re: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 >=20 > Hi Kilian, >=20 >=20 > [snip] >=20 > >> I heard at least one operator requesting such feature (and=20 > note that > >> this is in principle possible with the HA discovery/assignment > >> mechanisms defined in the split scenario bootstrapping draft). A > > simple > >> way to support this in the integrated scenario would be to add > > something > >> like a "type of requested HA service" field in the Home Network > >> Identifier Option of the DHCP information request sent by=20 > the MN. The > >> new field would encode the type of service, e.g., 0=3DMIPv6,=20 > 1=3DDS-MIPv6, > >> 2=3DNEMO,...). Similarly, the Home Network Information=20 > Sub-option could > >> include a "type of HA service" field to inform the MN=20 > about the type > > of >=20 > Good point imho. >=20 > >> service supported by the HA offered in this option.=20 > However, since the > >> AAAH wouldn't know the HA service requested by the MN,=20 > AAAH would need > >> to send at least one HA address per supported service to the NAS. > >> > > [KC>] Alternatively, we can encode the Home Network=20 > Identifier (FQDN) as > > ha.dsmip6.domain, ha.mip6.domain. This is possible with the current > > HIOPT I-D, no? From the AAAH perspective, it (AAAH) needs=20 > to send the HA > > address - Service pair. The service can be indicated by the=20 > FQDN AVP. We > > have the following AVPs in draft-ietf-dime-mip6-integrated-03.txt: > >=20 > > [ MIP6-Home-Agent-Address ] > > [ MIP6-Home-Agent-FQDN ] >=20 > Using different FQDNs under the same operator domain for=20 > differentiating > between types of service nodes is already practised in some=20 > 'relevant'=20 > SDOs. In that sense I think it could be a good approach. Dime's I-D=20 > draft-ietf-dime-mip6-integrated allows a NAS to give hints already to=20 > the AAAH using AVPs mentioned above and since we are about to=20 > revise the=20 > Dime I-D this part could be clarified further. >=20 > > Perhaps we can group them under a new AVP for service, e.g. > > MIP6-Home-Agent-Info AVP. For RADIUS we can perhaps link the MIP6-HA > > Attribute and MIP6-HA-FQDN Attribute. >=20 > There was also some other SDO asking for more generic 'ASP info' AVP=20 > e.g. for local HA assignment. MAybe these could be combined.=20 > IMHO this=20 > discussion should be brought to Dime as well. >=20 > Cheers, > Jouni >=20 > >=20 > >=20 > >=20 > >> What do you think? > >> > >> Cheers, > >> > >> Kilian > >> > >> > >> Panasonic R&D Center Germany GmbH > >> 63225 Langen, Hessen, Germany > >> Reg: AG Offenbach (Hessen) HRB 33974 > >> Managing Director: Thomas Micke > >> > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 12:19:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMSRl-0003Io-CE; Wed, 28 Feb 2007 12:18:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMSRj-0003HS-66 for mip6@ietf.org; Wed, 28 Feb 2007 12:18:31 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMSRh-00014o-UT for mip6@ietf.org; Wed, 28 Feb 2007 12:18:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 7184F90007 for ; Wed, 28 Feb 2007 12:18:26 -0500 (EST) 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 15011-17 for ; Wed, 28 Feb 2007 12:18:22 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 28 Feb 2007 12:18:22 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 12:18:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Feb 2007 12:18:22 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD9CB@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HIOPT clarification Thread-Index: AcdbXG28+AYg+Kb2RX25ism2EuF9QQ== From: "Chowdhury, Kuntal" To: "Heejin Jang" X-OriginalArrivalTime: 28 Feb 2007 17:18:22.0771 (UTC) FILETIME=[72FDE830:01C75B5C] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: mip6@ietf.org Subject: [Mip6] HIOPT clarification X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Heejin, all, Based on the comment from Kilian, I think we should clarify how the MN requests HA address for different service/protocol. My proposal is: In the HIOPT I-D, we include example encoding of the Home Network Identifier (FQDN) as follows: IPv6 address of MIP6 HA: ha.mip6.domain IPv6 address of DSMIP6 HA: ha.dsmip6.ip6.domain IPv4 address of DSMIP6 HA: ha.dsmip6.ip4.domain The sub-opt-code field in the MIP6 Relay Agent Sub-option and Home Network Information Sub-option should be encoded accordingly. Comments? -Kuntal _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 13:16:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMTLJ-0008L2-GG; Wed, 28 Feb 2007 13:15:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMTLI-0008Kw-7A for mip6@ietf.org; Wed, 28 Feb 2007 13:15:56 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMTLG-0001ST-Ny for mip6@ietf.org; Wed, 28 Feb 2007 13:15:56 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1SIBWch013564 for ; Wed, 28 Feb 2007 20:11:50 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 20:15:27 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 12:15:24 -0600 Received: from 172.19.244.102 ([172.19.244.102]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Feb 2007 18:15:24 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 28 Feb 2007 12:15:33 -0600 From: Basavaraj Patil To: Mobile IPv6 Mailing List Message-ID: Thread-Topic: Draft agenda for MIP6 meeting in Prague Thread-Index: AcdbZG+RrheR4MdXEdu8+AARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Feb 2007 18:15:24.0779 (UTC) FILETIME=[6AAAE3B0:01C75B64] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070228201150-30753BB0-78B66D81/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Mip6] Draft agenda for MIP6 meeting in Prague X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Draft agenda Mobility for IPv6 WG (mip6) TUESDAY, March 20, 2007 1520-1720 Afternoon Session II Chairs: Basavaraj Patil Gopal Dommety --------------------------------------------------- 1. Agenda review, Blue sheets and volunteers for taking notes and Jabber scribe 5 Mins 2. WG status and I-Ds update 5 Mins 3. MIP6 support for DS hosts/routers - Open issues and discussion I-D: draft-ietf-mip6-nemo-v4traversal-03 Hesham Soliman 15 Mins 4. DHCP Option for Home Information Discovery in MIPv6 I-D: draft-ietf-mip6-hiopt-02.txt Heejin Jang 10 Mins 5. Home agent reliability I-D: draft-ietf-mip6-hareliability-01.txt Ryuji Wakikawa 15 Mins 6. Discussion of open issues on I-Ds that are in WG LC 20 Mins a. draft-ietf-mip6-bootstrapping-integrated-02.txt b. draft-ietf-mip6-ha-switch-02.txt Tentative (Non WG I-Ds) Note: In case we need to allocate more time to discuss and resolve issues pertaining to WG docs, these agenda items are likely to be dropped. 1. Service Selection for Mobile IPv6 I-D: draft-korhonen-mip6-service-00.txt Jouni Korhonen 10 Mins 2. Link Characteristics Information for Mobile IP I-D: draft-daniel-mip-link-characteristic-03.txt Soohong Daniel Park 10 Mins For updates, please refer to: http://www3.ietf.org/proceedings/07mar/agenda/mip6.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 13:17:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMTMu-0000cH-N9; Wed, 28 Feb 2007 13:17:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMTMt-0000aJ-JA for mip6@ietf.org; Wed, 28 Feb 2007 13:17:35 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMTMr-0001do-RC for mip6@ietf.org; Wed, 28 Feb 2007 13:17:35 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1SICkia031378; Wed, 28 Feb 2007 20:13:39 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 20:17:07 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 12:16:56 -0600 Received: from 172.19.244.102 ([172.19.244.102]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Feb 2007 18:16:56 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 28 Feb 2007 12:17:05 -0600 Subject: Re: [Mip6] DSMIP6 solution and integrated bootstrap scenario From: Basavaraj Patil To: "Chowdhury, Kuntal" , Message-ID: Thread-Topic: [Mip6] DSMIP6 solution and integrated bootstrap scenario Thread-Index: AcdbVnhKF1b2JClGQ3GhowIpEnaXfAADi4ej In-Reply-To: <7CCD07160348804497EF29E9EA5560D7FBD9C9@exchtewks2.starentnetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Feb 2007 18:16:56.0732 (UTC) FILETIME=[A179CDC0:01C75B64] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070228201340-73633BB0-117D53FD/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org So are you saying that the DNS approach is invalid? Or the fact that we have two different mechanisms for HA discovery? We need to converge on a single approach. -Raj On 2/28/07 10:35 AM, "ext Chowdhury, Kuntal" wrote: > Hi all, > > I see that in the DSMIP6 I-D (draft-ietf-mip6-nemo-v4traversal-03.txt) > we have the following sentence in section 2.1 Home Agent Address > Discover > > " > The preferred solution for discovering the home agent's IPv4 address is > through the Domain Name System (DNS). > " > > The preferred solution for discovering Home Agent Address in the > integrated bootstrap scenario is DHCP not DNS. We need to address this > issue. > > -Kuntal > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 14:03:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMU4X-0008No-NH; Wed, 28 Feb 2007 14:02:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMU4W-0008Js-Hd for mip6@ietf.org; Wed, 28 Feb 2007 14:02:40 -0500 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMU4U-0000Pl-SD for mip6@ietf.org; Wed, 28 Feb 2007 14:02:40 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 20:02:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Date: Wed, 28 Feb 2007 20:02:31 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301A4014E@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 Thread-Index: AcdbHjoLeiuXo3N2R5a7UKacFyd9gAAOMPHQAAQ6KFA= From: To: X-OriginalArrivalTime: 28 Feb 2007 19:02:32.0090 (UTC) FILETIME=[FFE04FA0:01C75B6A] X-Spam-Score: 1.3 (+) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: mip6@ietf.org, heejin.jang@samsung.com, basavaraj.patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Kilian,=20 > -----Original Message----- > From: Kilian Weniger [mailto:Kilian.Weniger@eu.panasonic.com]=20 > Sent: 28. helmikuuta 2007 18:55 > To: Korhonen, Jouni /TeliaSonera Finland Oyj > Cc: Chowdhury, Kuntal; Heejin Jang; mip6@ietf.org; Basavaraj Patil > Subject: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02 >=20 > Hi Kuntal, Jouni,=20 >=20 > yes, encoding the service in the Home Network Identifier=20 > field would also be possible (probably with changes to=20 > [HIOPT]). However, this has the danger of overloading the=20 > semantics, since this would change the network identifier to=20 > something like a "network+service" identifier. And don't we=20 Hmmm.. lets be careful here. We are talking about only assigning different flavors of HA, nothing more. > need to standardize a format then, since the format for=20 > encoding the service into the FQDN must be understood by the=20 > MSA *and all ASPs*, right?=20 No. We cannot really mandate specific format as we probably do it wrong anyway for other SDOs in their architectures. Just state that FQDNs can be used to assign different flavors of HAs if an operator=20 or a SDO wishes to do so. Cheers, Jouni >=20 > Cheers, >=20 > Kilian >=20 > > -----Original Message----- > > From: Jouni Korhonen [mailto:jouni.korhonen@teliasonera.com] > > Sent: Mittwoch, 28. Februar 2007 10:55 > > To: Kilian Weniger > > Cc: Chowdhury, Kuntal; Heejin Jang; mip6@ietf.org; Basavaraj Patil > > Subject: Re: [Mip6] WGLC:=20 > draft-ietf-mip6-bootstrapping-integrated-02 > >=20 > > Hi Kilian, > >=20 > >=20 > > [snip] > >=20 > > >> I heard at least one operator requesting such feature (and > > note that > > >> this is in principle possible with the HA discovery/assignment=20 > > >> mechanisms defined in the split scenario bootstrapping draft). A > > > simple > > >> way to support this in the integrated scenario would be to add > > > something > > >> like a "type of requested HA service" field in the Home Network=20 > > >> Identifier Option of the DHCP information request sent by > > the MN. The > > >> new field would encode the type of service, e.g., 0=3DMIPv6, > > 1=3DDS-MIPv6, > > >> 2=3DNEMO,...). Similarly, the Home Network Information > > Sub-option could > > >> include a "type of HA service" field to inform the MN > > about the type > > > of > >=20 > > Good point imho. > >=20 > > >> service supported by the HA offered in this option.=20 > > However, since the > > >> AAAH wouldn't know the HA service requested by the MN, > > AAAH would need > > >> to send at least one HA address per supported service to the NAS. > > >> > > > [KC>] Alternatively, we can encode the Home Network > > Identifier (FQDN) as > > > ha.dsmip6.domain, ha.mip6.domain. This is possible with=20 > the current=20 > > > HIOPT I-D, no? From the AAAH perspective, it (AAAH) needs > > to send the HA > > > address - Service pair. The service can be indicated by the > > FQDN AVP. We > > > have the following AVPs in draft-ietf-dime-mip6-integrated-03.txt: > > >=20 > > > [ MIP6-Home-Agent-Address ] > > > [ MIP6-Home-Agent-FQDN ] > >=20 > > Using different FQDNs under the same operator domain for=20 > > differentiating between types of service nodes is already=20 > practised in=20 > > some 'relevant' > > SDOs. In that sense I think it could be a good approach. Dime's I-D=20 > > draft-ietf-dime-mip6-integrated allows a NAS to give hints=20 > already to=20 > > the AAAH using AVPs mentioned above and since we are about=20 > to revise=20 > > the Dime I-D this part could be clarified further. > >=20 > > > Perhaps we can group them under a new AVP for service, e.g. > > > MIP6-Home-Agent-Info AVP. For RADIUS we can perhaps link=20 > the MIP6-HA=20 > > > Attribute and MIP6-HA-FQDN Attribute. > >=20 > > There was also some other SDO asking for more generic 'ASP=20 > info' AVP=20 > > e.g. for local HA assignment. MAybe these could be combined. > > IMHO this > > discussion should be brought to Dime as well. > >=20 > > Cheers, > > Jouni > >=20 > > >=20 > > >=20 > > >=20 > > >> What do you think? > > >> > > >> Cheers, > > >> > > >> Kilian > > >> > > >> > > >> Panasonic R&D Center Germany GmbH > > >> 63225 Langen, Hessen, Germany > > >> Reg: AG Offenbach (Hessen) HRB 33974 Managing Director: Thomas=20 > > >> Micke > > >> > > >=20 > > >=20 > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > >=20 > >=20 > >=20 >=20 >=20 > Panasonic R&D Center Germany GmbH > 63225 Langen, Hessen, Germany > Reg: AG Offenbach (Hessen) HRB 33974 > Managing Director: Thomas Micke >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 14:18:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMUJ5-0003Ce-7H; Wed, 28 Feb 2007 14:17:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMUJ3-0003CR-UL for mip6@ietf.org; Wed, 28 Feb 2007 14:17:41 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMUJ0-0003WI-16 for mip6@ietf.org; Wed, 28 Feb 2007 14:17:41 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 920279003A for ; Wed, 28 Feb 2007 14:17:34 -0500 (EST) 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 19035-01 for ; Wed, 28 Feb 2007 14:17:30 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 28 Feb 2007 14:17:30 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 14:17:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DSMIP6 solution and integrated bootstrap scenario Date: Wed, 28 Feb 2007 14:17:29 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD9CF@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIP6 solution and integrated bootstrap scenario Thread-Index: AcdbVnhKF1b2JClGQ3GhowIpEnaXfAADi4ejAAGMP1A= From: "Chowdhury, Kuntal" To: "Basavaraj Patil" , X-OriginalArrivalTime: 28 Feb 2007 19:17:30.0738 (UTC) FILETIME=[17831D20:01C75B6D] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, Please see inline... > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > Sent: Wednesday, February 28, 2007 12:17 PM > To: Chowdhury, Kuntal; mip6@ietf.org > Subject: Re: [Mip6] DSMIP6 solution and integrated bootstrap scenario >=20 >=20 > So are you saying that the DNS approach is invalid? [KC>] No. The point is why DSMIP6 should say DNS is preferred way to do HA bootstrapping? There are two distinct scenarios for mip6 bootstrapping as per RFC 4640. DNS is preferred way for HA bootstrapping for only one of them i.e. split scenario. DHCP is preferred for the integrated scenario. The DSMIP6 I-D should just point to the mip6 bootstrapping solutions for split and integrated scenarios. At this time it only refers to the split I-D. That's the issue. > Or the fact that we have two different mechanisms for HA discovery? >=20 [KC>] To be precise there are three ways... DHCP, Anycast, DNS. > We need to converge on a single approach. >=20 [KC>] based on what? The DSMIP6 I-D clearly tries to ignore the integrated bootstrapping solution. > -Raj >=20 >=20 > On 2/28/07 10:35 AM, "ext Chowdhury, Kuntal" > wrote: >=20 > > Hi all, > > > > I see that in the DSMIP6 I-D (draft-ietf-mip6-nemo-v4traversal-03.txt) > > we have the following sentence in section 2.1 Home Agent Address > > Discover > > > > " > > The preferred solution for discovering the home agent's IPv4 address is > > through the Domain Name System (DNS). > > " > > > > The preferred solution for discovering Home Agent Address in the > > integrated bootstrap scenario is DHCP not DNS. We need to address this > > issue. > > > > -Kuntal > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 14:26:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMUR1-0001dh-HU; Wed, 28 Feb 2007 14:25:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMUQy-0001db-Ob for mip6@ietf.org; Wed, 28 Feb 2007 14:25:52 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMUQx-0004fu-7K for mip6@ietf.org; Wed, 28 Feb 2007 14:25:52 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1SJLVUE026077; Wed, 28 Feb 2007 21:21:57 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 21:25:34 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 13:25:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DSMIP6 solution and integrated bootstrap scenario Date: Wed, 28 Feb 2007 13:27:54 -0600 Message-ID: <456943D540CFC14A8D7138E64843F8530422DE30@daebe101.NOE.Nokia.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7FBD9CF$0001@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIP6 solution and integrated bootstrap scenario Thread-Index: AcdbVnhKF1b2JClGQ3GhowIpEnaXfAADi4ejAAGMP1AAANXosA== References: <7CCD07160348804497EF29E9EA5560D7FBD9CF$0001@exchtewks2.starentnetworks.com> From: To: X-OriginalArrivalTime: 28 Feb 2007 19:25:21.0580 (UTC) FILETIME=[3027E6C0:01C75B6E] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070228212157-63E14BB0-5371126C/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Okay.. I see your point now. I agree that the DS-MIP6 I-D could either refer or mention the methods by which the MN can discover the HA. -Raj >-----Original Message----- >From: ext Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 >Sent: Wednesday, February 28, 2007 1:17 PM >To: Patil Basavaraj (Nokia-NET/Dallas); mip6@ietf.org >Subject: RE: [Mip6] DSMIP6 solution and integrated bootstrap scenario > >Hi Raj, > >Please see inline... > >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] >> Sent: Wednesday, February 28, 2007 12:17 PM >> To: Chowdhury, Kuntal; mip6@ietf.org >> Subject: Re: [Mip6] DSMIP6 solution and integrated bootstrap scenario >>=20 >>=20 >> So are you saying that the DNS approach is invalid? >[KC>] No. The point is why DSMIP6 should say DNS is preferred way to do >HA bootstrapping? There are two distinct scenarios for mip6 >bootstrapping as per RFC 4640. DNS is preferred way for HA=20 >bootstrapping >for only one of them i.e. split scenario. DHCP is preferred for the >integrated scenario. The DSMIP6 I-D should just point to the mip6 >bootstrapping solutions for split and integrated scenarios. At=20 >this time >it only refers to the split I-D. That's the issue. > >> Or the fact that we have two different mechanisms for HA discovery? >>=20 >[KC>] To be precise there are three ways... DHCP, Anycast, DNS. > >> We need to converge on a single approach. >>=20 >[KC>] based on what? The DSMIP6 I-D clearly tries to ignore the >integrated bootstrapping solution. > >> -Raj >>=20 >>=20 >> On 2/28/07 10:35 AM, "ext Chowdhury, Kuntal" >> wrote: >>=20 >> > Hi all, >> > >> > I see that in the DSMIP6 I-D >(draft-ietf-mip6-nemo-v4traversal-03.txt) >> > we have the following sentence in section 2.1 Home Agent Address >> > Discover >> > >> > " >> > The preferred solution for discovering the home agent's=20 >IPv4 address >is >> > through the Domain Name System (DNS). >> > " >> > >> > The preferred solution for discovering Home Agent Address in the >> > integrated bootstrap scenario is DHCP not DNS. We need to address >this >> > issue. >> > >> > -Kuntal >> > >> > _______________________________________________ >> > Mip6 mailing list >> > Mip6@ietf.org >> > https://www1.ietf.org/mailman/listinfo/mip6 > > >"This email message and any attachments are confidential=20 >information of Starent Networks, Corp. The information=20 >transmitted may not be used to create or change any=20 >contractual obligations of Starent Networks, Corp. Any=20 >review, retransmission, dissemination or other use of, or=20 >taking of any action in reliance upon this e-mail and its=20 >attachments by persons or entities other than the intended=20 >recipient is prohibited. If you are not the intended=20 >recipient, please notify the sender immediately -- by replying=20 >to this message or by sending an email to=20 >postmaster@starentnetworks.com -- and destroy all copies of=20 >this message and any attachments without reading or disclosing=20 >their contents. Thank you." > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 14:45:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMUju-0006Yn-00; Wed, 28 Feb 2007 14:45:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMUjs-0006Ye-6G for mip6@ietf.org; Wed, 28 Feb 2007 14:45:24 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMUjq-0007D9-N3 for mip6@ietf.org; Wed, 28 Feb 2007 14:45:24 -0500 Received: from [127.0.0.1] ([207.47.15.7]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 11:45:11 -0800 Message-ID: <45E5DBC1.1020109@azairenet.com> Date: Wed, 28 Feb 2007 11:45:05 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] DSMIP6 solution and integrated bootstrap scenario References: <7CCD07160348804497EF29E9EA5560D7FBD9CF$0001@exchtewks2.starentnetworks.com> <456943D540CFC14A8D7138E64843F8530422DE30@daebe101.NOE.Nokia.com> In-Reply-To: <456943D540CFC14A8D7138E64843F8530422DE30@daebe101.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2007 19:45:11.0769 (UTC) FILETIME=[F5905490:01C75B70] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Basavaraj.Patil@nokia.com wrote: > Okay.. I see your point now. > I agree that the DS-MIP6 I-D could either refer or mention the methods > by which the MN can discover the HA. We can mention in the DS-MIPv6 spec, that if DS-MIPv6 is being used in the integrated scenario, DHCPv6 may also be used for HA bootstrapping. Thats not a big deal. But there is an issue. IPv4-access networks will not have DHCPv6 running on them. So the solution described in draft-ietf-mip6-bootstrapping-integrated-02.txt may not apply, since the draft assumes DCHPv6. Vijay > > -Raj > >> -----Original Message----- >> From: ext Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] >> Sent: Wednesday, February 28, 2007 1:17 PM >> To: Patil Basavaraj (Nokia-NET/Dallas); mip6@ietf.org >> Subject: RE: [Mip6] DSMIP6 solution and integrated bootstrap scenario >> >> Hi Raj, >> >> Please see inline... >> >>> -----Original Message----- >>> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] >>> Sent: Wednesday, February 28, 2007 12:17 PM >>> To: Chowdhury, Kuntal; mip6@ietf.org >>> Subject: Re: [Mip6] DSMIP6 solution and integrated bootstrap scenario >>> >>> >>> So are you saying that the DNS approach is invalid? >> [KC>] No. The point is why DSMIP6 should say DNS is preferred way to do >> HA bootstrapping? There are two distinct scenarios for mip6 >> bootstrapping as per RFC 4640. DNS is preferred way for HA >> bootstrapping >> for only one of them i.e. split scenario. DHCP is preferred for the >> integrated scenario. The DSMIP6 I-D should just point to the mip6 >> bootstrapping solutions for split and integrated scenarios. At >> this time >> it only refers to the split I-D. That's the issue. >> >>> Or the fact that we have two different mechanisms for HA discovery? >>> >> [KC>] To be precise there are three ways... DHCP, Anycast, DNS. >> >>> We need to converge on a single approach. >>> >> [KC>] based on what? The DSMIP6 I-D clearly tries to ignore the >> integrated bootstrapping solution. >> >>> -Raj >>> >>> >>> On 2/28/07 10:35 AM, "ext Chowdhury, Kuntal" >>> wrote: >>> >>>> Hi all, >>>> >>>> I see that in the DSMIP6 I-D >> (draft-ietf-mip6-nemo-v4traversal-03.txt) >>>> we have the following sentence in section 2.1 Home Agent Address >>>> Discover >>>> >>>> " >>>> The preferred solution for discovering the home agent's >> IPv4 address >> is >>>> through the Domain Name System (DNS). >>>> " >>>> >>>> The preferred solution for discovering Home Agent Address in the >>>> integrated bootstrap scenario is DHCP not DNS. We need to address >> this >>>> issue. >>>> >>>> -Kuntal >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >> >> "This email message and any attachments are confidential >> information of Starent Networks, Corp. The information >> transmitted may not be used to create or change any >> contractual obligations of Starent Networks, Corp. Any >> review, retransmission, dissemination or other use of, or >> taking of any action in reliance upon this e-mail and its >> attachments by persons or entities other than the intended >> recipient is prohibited. If you are not the intended >> recipient, please notify the sender immediately -- by replying >> to this message or by sending an email to >> postmaster@starentnetworks.com -- and destroy all copies of >> this message and any attachments without reading or disclosing >> their contents. Thank you." >> > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 14:50:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMUoM-0000Xy-PW; Wed, 28 Feb 2007 14:50:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMUoL-0000WG-2y for mip6@ietf.org; Wed, 28 Feb 2007 14:50:01 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMUoG-0007JI-7s for mip6@ietf.org; Wed, 28 Feb 2007 14:50:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id ADE169003A for ; Wed, 28 Feb 2007 14:49:52 -0500 (EST) 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 18677-16 for ; Wed, 28 Feb 2007 14:49:47 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 28 Feb 2007 14:49:47 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 14:49:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Feb 2007 14:49:47 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD9D2@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: host config options in MIP6 Thread-Index: AcdbcZTAYaJoz+i1Tgyp8rWNfNwb7A== From: "Chowdhury, Kuntal" To: X-OriginalArrivalTime: 28 Feb 2007 19:49:47.0811 (UTC) FILETIME=[9A18FF30:01C75B71] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Jayshree Bharatia Subject: [Mip6] host config options in MIP6 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, We submitted a draft to define how the MN can obtain configuration information via MIP6 signaling. The draft is available at: http://www.ietf.org/internet-drafts/draft-bharatia-mip6-gen-ext-01.txt Here is the abstract: This document describes the mechanism for providing the host configuration information during Mobile IPv6 Binding Update procedure. The Configuration Options extension may be included in the Mobile IPv6 Binding Update message for requesting the home agent to include configuration parameters needed for network service usage (e.g. DNS). The requested information is provided by the Home Agent in one or more Configuration Options extensions. Similar concept is being standardized in MIP4. We appreciate your review and comments. BR, Kuntal _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 16:24:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMWGo-0006NH-MM; Wed, 28 Feb 2007 16:23:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMWGn-0006Mn-Al for mip6@ietf.org; Wed, 28 Feb 2007 16:23:29 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMWGl-0007Yf-KY for mip6@ietf.org; Wed, 28 Feb 2007 16:23:29 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 23FED90096 for ; Wed, 28 Feb 2007 16:23:24 -0500 (EST) 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 21843-01 for ; Wed, 28 Feb 2007 16:23:19 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 28 Feb 2007 16:23:19 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 16:23:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DSMIP6 solution and integrated bootstrap scenario Date: Wed, 28 Feb 2007 16:23:18 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD9D4@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIP6 solution and integrated bootstrap scenario Thread-Index: AcdbcPor/QOKdzywQAWgkL/jq6feVAACeSQA From: "Chowdhury, Kuntal" To: "Vijay Devarapalli" , X-OriginalArrivalTime: 28 Feb 2007 21:23:18.0985 (UTC) FILETIME=[AA9E3390:01C75B7E] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay, Please see inline... > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Wednesday, February 28, 2007 1:45 PM > To: Basavaraj.Patil@nokia.com > Cc: Chowdhury, Kuntal; mip6@ietf.org > Subject: Re: [Mip6] DSMIP6 solution and integrated bootstrap scenario >=20 > Basavaraj.Patil@nokia.com wrote: > > Okay.. I see your point now. > > I agree that the DS-MIP6 I-D could either refer or mention the methods > > by which the MN can discover the HA. >=20 > We can mention in the DS-MIPv6 spec, that if DS-MIPv6 > is being used in the integrated scenario, DHCPv6 may > also be used for HA bootstrapping. Thats not a big > deal. >=20 [KC>] IMHO, section 2.1 should just point to the two bootstrapping solutions (i.e. split and integrated) so that deployments utilizing either of the bootstrapping solution can use DSMIP6.=20 > But there is an issue. IPv4-access networks will not > have DHCPv6 running on them. So the solution described > in draft-ietf-mip6-bootstrapping-integrated-02.txt may > not apply, since the draft assumes DCHPv6. >=20 [KC>] If the ASP is only IPv4 capable, the MN won't get any response to the DHCPv6 information request. So, the MN will use the fallback mechanism as specified in draft-ietf-mip6-bootstrapping-integrated-02.txt (which is DNS). For HA discovery, some type of fallback mechanism should be defined regardless; since there is no guarantee that the DNS servers in the MSP or in the ASP are configured to return HA information. Instead of restating the success and fallback cases for mip6 bootstrapping, the DSMIP6 document should refer to the two mip6 bootstrap solution documents. =20 > Vijay >=20 > > > > -Raj > > > >> -----Original Message----- > >> From: ext Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > >> Sent: Wednesday, February 28, 2007 1:17 PM > >> To: Patil Basavaraj (Nokia-NET/Dallas); mip6@ietf.org > >> Subject: RE: [Mip6] DSMIP6 solution and integrated bootstrap scenario > >> > >> Hi Raj, > >> > >> Please see inline... > >> > >>> -----Original Message----- > >>> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > >>> Sent: Wednesday, February 28, 2007 12:17 PM > >>> To: Chowdhury, Kuntal; mip6@ietf.org > >>> Subject: Re: [Mip6] DSMIP6 solution and integrated bootstrap scenario > >>> > >>> > >>> So are you saying that the DNS approach is invalid? > >> [KC>] No. The point is why DSMIP6 should say DNS is preferred way to do > >> HA bootstrapping? There are two distinct scenarios for mip6 > >> bootstrapping as per RFC 4640. DNS is preferred way for HA > >> bootstrapping > >> for only one of them i.e. split scenario. DHCP is preferred for the > >> integrated scenario. The DSMIP6 I-D should just point to the mip6 > >> bootstrapping solutions for split and integrated scenarios. At > >> this time > >> it only refers to the split I-D. That's the issue. > >> > >>> Or the fact that we have two different mechanisms for HA discovery? > >>> > >> [KC>] To be precise there are three ways... DHCP, Anycast, DNS. > >> > >>> We need to converge on a single approach. > >>> > >> [KC>] based on what? The DSMIP6 I-D clearly tries to ignore the > >> integrated bootstrapping solution. > >> > >>> -Raj > >>> > >>> > >>> On 2/28/07 10:35 AM, "ext Chowdhury, Kuntal" > >>> wrote: > >>> > >>>> Hi all, > >>>> > >>>> I see that in the DSMIP6 I-D > >> (draft-ietf-mip6-nemo-v4traversal-03.txt) > >>>> we have the following sentence in section 2.1 Home Agent Address > >>>> Discover > >>>> > >>>> " > >>>> The preferred solution for discovering the home agent's > >> IPv4 address > >> is > >>>> through the Domain Name System (DNS). > >>>> " > >>>> > >>>> The preferred solution for discovering Home Agent Address in the > >>>> integrated bootstrap scenario is DHCP not DNS. We need to address > >> this > >>>> issue. > >>>> > >>>> -Kuntal > >>>> > >>>> _______________________________________________ > >>>> Mip6 mailing list > >>>> Mip6@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/mip6 > >> > >> "This email message and any attachments are confidential > >> information of Starent Networks, Corp. The information > >> transmitted may not be used to create or change any > >> contractual obligations of Starent Networks, Corp. Any > >> review, retransmission, dissemination or other use of, or > >> taking of any action in reliance upon this e-mail and its > >> attachments by persons or entities other than the intended > >> recipient is prohibited. If you are not the intended > >> recipient, please notify the sender immediately -- by replying > >> to this message or by sending an email to > >> postmaster@starentnetworks.com -- and destroy all copies of > >> this message and any attachments without reading or disclosing > >> their contents. Thank you." > >> > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 17:06:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMWvs-0007pl-70; Wed, 28 Feb 2007 17:05:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMWvr-0007pe-86 for mip6@ietf.org; Wed, 28 Feb 2007 17:05:55 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMWvo-0006Ts-KS for mip6@ietf.org; Wed, 28 Feb 2007 17:05:55 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 28 Feb 2007 14:05:50 -0800 X-IronPort-AV: i="4.14,232,1170662400"; d="scan'208,217"; a="43859854:sNHT4404880980" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1SM5o7t022178; Wed, 28 Feb 2007 14:05:50 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1SM5ihq007488; Wed, 28 Feb 2007 14:05:49 -0800 (PST) Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 14:05:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Feb 2007 14:05:45 -0800 Message-ID: <28CEA477BE98ED48AF08A0B637A74BF40321CBDC@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised Milestones for MIP6 Working Group Thread-Index: Acdbgt6Wt9v630z6R+K5+perrE75TQ== From: "Gopal Dommety \(gdommety\)" To: X-OriginalArrivalTime: 28 Feb 2007 22:05:46.0477 (UTC) FILETIME=[990AA1D0:01C75B84] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7814; t=1172700350; x=1173564350; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gdommety@cisco.com; z=From:=20=22Gopal=20Dommety=20\(gdommety\)=22=20 |Subject:=20Revised=20=20Milestones=20for=20MIP6=20Working=20Group |Sender:=20; bh=57Skjmsmm8m2bIUvKzTT3hxFMS6hb16VNZcb8b5BKT4=; b=lyW8f5Jc7vQrqU9tSZSrP0KN5QazE2RBPe2BFinwP/ywRkYeuuMZ6w7ZP6kxoVDmJ1OjhNBt fZ8CnvBru5jVbsM1GvJyj0ws+8uMOT65QiMkSq52q/PyOAHKirt4veGs; Authentication-Results: sj-dkim-5; header.From=gdommety@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: Basavaraj Patil Subject: [Mip6] Revised Milestones for MIP6 Working Group X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1949098571==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1949098571== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75B84.98D85842" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75B84.98D85842 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 I am attaching the revised Milestones for the MIP6 Working Group. Please let me know if there are any changes required. =20 Regards, Gopal Dommety =20 =20 =20 Goals and Milestones: Done Submit I-D 'Issues with firewall Problem statement' to IESG =20 Done Submit I-D 'MIPv6 MIB' to IESG =20 Done Submit I-D 'Extensions to Socket Advanced API for MIPv6' to IESG Done Submit I-D 'Alternate Route Optimization (Pre-config Key) scheme' to IESG =20 Done Submit Bootstrapping problem statement to IESG =20 Done Submit I-D 'Authentication Option for MIPv6' to IESG =20 Done Submit I-D 'Identification Option for MIPv6' to IESG =20 Done Submit I-D 'MIPv6 operation with IKEV2 and the revised IPsec Architecture to IESG =20 Done Submit Problem statement and Solution to Mobile IPv6 transition between v4/v6 networks to IESG=20 Done Submit I-D 'Mobility management for Dual stack mobile nodes: A Problem Statement' to IESG for publication as Informational. =20 Done Submit I-D 'Address Location Privacy and Mobile IPv6 Problem Statement' to IESG for publication as Informational. =20 Done Submit I-D 'Bootstrapping solution for split Scenario' to IESG for publication as a Proposed Standard.=20 Done Submit I-D 'Using IPsec between Mobile and Correspondent IPv6 Nodes' to IESG for publication as Experimental. Apr 2007 Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational. =20 May 2007 Submit I-D 'Bootstrapping solution for Integrated Scenario' to IESG for publication as a Proposed Standard. =20 Jul 2007 Submit I-D 'DHCP Options for Home Information Discovery in MIPv6' for publication as a proposed standard. =20 Jul 2007 Submit I-D 'Mobility Header Home Agent Switch Message' to IESG for publication as a Proposed Standard.=20 Aug 2007 Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational. =20 Sep 2007 Submit I-D 'Home agent reliability' to IESG for publication as a Proposed Standard. =20 Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard. =20 Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard. =20 Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard. =20 Dec 2007 Submit I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a proposed standard. =20 Feb 2008 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational. =20 Feb 2008 Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard. =20 ------_=_NextPart_001_01C75B84.98D85842 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
    I=20 am attaching the revised  Milestones for the MIP6 Working Group. = Please let=20 me know if there are any changes required.
 
Regards,
Gopal=20 Dommety
 
 
 
Goals = and=20 Milestones:
Done    Submit I-D 'Issues with firewall = Problem=20 statement' to IESG 
Done    Submit I-D 'MIPv6 = MIB' to=20 IESG 
Done    Submit I-D 'Extensions to Socket = Advanced=20 API for MIPv6' to IESG 
Done    Submit I-D = 'Alternate=20 Route Optimization (Pre-config Key) scheme' to IESG =20
Done    Submit Bootstrapping problem statement to = IESG =20
Done    Submit I-D 'Authentication Option for MIPv6' = to=20 IESG 
Done    Submit I-D 'Identification Option = for=20 MIPv6' to IESG 
Done    Submit I-D 'MIPv6 = operation with=20 IKEV2 and the revised IPsec Architecture to IESG =20
Done    Submit Problem statement and Solution to = Mobile IPv6=20 transition between v4/v6 networks to IESG
Done    = Submit I-D=20 'Mobility management for Dual stack mobile nodes: A Problem Statement' = to IESG=20 for publication as Informational. 
Done    = Submit I-D=20 'Address Location Privacy and Mobile IPv6 Problem Statement' to IESG for = publication as Informational. 
Done    Submit = I-D=20 'Bootstrapping solution for split Scenario' to IESG for publication as a = Proposed Standard.
Done   Submit I-D 'Using IPsec between = Mobile and=20 Correspondent IPv6 Nodes' to IESG for publication as = Experimental.
Apr=20 2007    Submit I-D 'Motivation for Authentication I-D' to = IESG=20 for publication as Informational. 
May = 2007   Submit I-D=20 'Bootstrapping solution for Integrated Scenario' to IESG for publication = as a=20 Proposed Standard. 
Jul 2007     Submit I-D = 'DHCP=20 Options for Home Information Discovery in MIPv6' for publication as a = proposed=20 standard. 
Jul 2007     Submit I-D = 'Mobility Header=20 Home Agent Switch Message' to IESG for publication as a Proposed = Standard.=20
Aug 2007    Submit I-D 'Goals for AAA HA Interface' = to IESG=20 for publication as Informational. 
Sep 2007    = Submit=20 I-D 'Home agent reliability' to IESG for publication as a Proposed=20 Standard. 
Sep 2007    Submit I-D 'Mobile IPv6=20 Dual-Stack Operation' to IESG for publication as a Proposed = Standard. =20
Oct 2007    Submit I-D 'Mobile IPv6 Vendor Specific = Option'=20 to IESG for publication as a Proposed Standard. 
Dec=20 2007    Submit I-D 'Mobile IPv6 Experimental Allocations' = to IESG=20 for publication as a Proposed Standard. 
Dec = 2007   =20 Submit I-D 'RADIUS Mobile IPv6 Support' to IESG for publication as a = proposed=20 standard. 
Feb 2008    Submit I-D 'Mobile IPv6 = Operation=20 with Firewalls' to IESG for publication as Informational. 
Feb=20 2008    Submit I-D(s) related to specific updates and = corrections=20 of RFC 3775 to IESG for publication as Proposed Standard. =20
------_=_NextPart_001_01C75B84.98D85842-- --===============1949098571== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1949098571==-- From mip6-bounces@ietf.org Wed Feb 28 17:30:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMXJ5-00064E-Mr; Wed, 28 Feb 2007 17:29:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMXJ4-00061B-8b for mip6@ietf.org; Wed, 28 Feb 2007 17:29:54 -0500 Received: from tao.fdupont.fr ([82.236.136.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMXJ2-00017R-Rh for mip6@ietf.org; Wed, 28 Feb 2007 17:29:54 -0500 Received: from tao.fdupont.fr (localhost [127.0.0.1]) by tao.fdupont.fr (8.13.5/8.13.5) with ESMTP id l1SMSONE019127; Wed, 28 Feb 2007 23:28:25 +0100 (CET) Received: from tao.fdupont.fr (dupont@localhost) by tao.fdupont.fr (8.13.5/8.13.5/Submit) with ESMTP id l1SMSO4Y019124; Wed, 28 Feb 2007 23:28:24 +0100 (CET) Message-Id: <200702282228.l1SMSO4Y019124@tao.fdupont.fr> From: Francis Dupont To: "Gopal Dommety \(gdommety\)" Subject: Re: [Mip6] Revised Milestones for MIP6 Working Group In-reply-to: Your message of Wed, 28 Feb 2007 14:05:45 PST. <28CEA477BE98ED48AF08A0B637A74BF40321CBDC@xmb-sjc-224.amer.cisco.com> Date: Wed, 28 Feb 2007 23:28:23 +0100 X-Spam-Score: 1.7 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: I am attaching the revised Milestones for the MIP6 Working Group. Please let me know if there are any changes required. Done Submit I-D 'Using IPsec between Mobile and Correspondent IPv6 Nodes' to IESG for publication as Experimental. => s/Experimental/Proposed Standard/ BTW I submitted a revised version some hours ago. Thanks Francis.Dupont@fdupont.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 17:39:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMXRy-0008Vn-VA; Wed, 28 Feb 2007 17:39:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMXRx-0008U3-3G for mip6@ietf.org; Wed, 28 Feb 2007 17:39:05 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMXRv-0002cg-Od for mip6@ietf.org; Wed, 28 Feb 2007 17:39:05 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 28 Feb 2007 14:39:03 -0800 X-IronPort-AV: i="4.14,232,1170662400"; d="scan'208"; a="395049750:sNHT52944116" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1SMd33G010028; Wed, 28 Feb 2007 14:39:03 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1SMcuhq025641; Wed, 28 Feb 2007 14:38:56 -0800 (PST) Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 14:38:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Revised Milestones for MIP6 Working Group Date: Wed, 28 Feb 2007 14:38:40 -0800 Message-ID: <28CEA477BE98ED48AF08A0B637A74BF40321CC21@xmb-sjc-224.amer.cisco.com> In-Reply-To: <200702282228.l1SMSO4Y019124@tao.fdupont.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Revised Milestones for MIP6 Working Group Thread-Index: AcdbiHinKTrxTDVkSm2Ut4y8+Yq3QgAAFDKQ From: "Gopal Dommety \(gdommety\)" To: "Francis Dupont" X-OriginalArrivalTime: 28 Feb 2007 22:38:41.0768 (UTC) FILETIME=[32681E80:01C75B89] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1146; t=1172702343; x=1173566343; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gdommety@cisco.com; z=From:=20=22Gopal=20Dommety=20\(gdommety\)=22=20 |Subject:=20RE=3A=20[Mip6]=20Revised=20Milestones=20for=20MIP6=20Working= 20Group=20 |Sender:=20; bh=7eyXccebL/oTjZu/LUU3DNktztwfot4PwCyj05ghRHs=; b=gFUutLRpcSVkrOl/eEL/pYJbIVKHC7C3x6r0IdR+hGj7mPr1DnIQh8fWLWGPpxMw7PcFM2Jv VpZvIkz213hAScS68GqaAz6NhJcvUVHGcLlVTaSnNHV9VP5LpGssj/DE; Authentication-Results: sj-dkim-8; header.From=gdommety@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Francis, It shows up in the ID-Tracker as Experimental. Was there a change to this?It's intended status is Experimental. Isn't it?=20 -Gopal =20 Gopal Dommety, Ph.D ------------------------------------------------------- Judgment hinders imagination ---------------------------------------------- -----Original Message----- From: Francis Dupont [mailto:Francis.Dupont@fdupont.fr]=20 Sent: Wednesday, February 28, 2007 2:28 PM To: Gopal Dommety (gdommety) Cc: mip6@ietf.org; Basavaraj Patil Subject: Re: [Mip6] Revised Milestones for MIP6 Working Group=20 In your previous mail you wrote: I am attaching the revised Milestones for the MIP6 Working Group. Please let me know if there are any changes required. Done Submit I-D 'Using IPsec between Mobile and Correspondent IPv6 Nodes' to IESG for publication as Experimental. =3D> s/Experimental/Proposed Standard/ BTW I submitted a revised version some hours ago. Thanks Francis.Dupont@fdupont.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 19:17:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYyN-0002FL-GB; Wed, 28 Feb 2007 19:16:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYyL-0002EQ-Qr for mip6@ietf.org; Wed, 28 Feb 2007 19:16:37 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMYyC-0006ov-7u for mip6@ietf.org; Wed, 28 Feb 2007 19:16:37 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 16:16:21 -0800 Message-ID: <45E61B54.3040303@azairenet.com> Date: Wed, 28 Feb 2007 16:16:20 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Chowdhury, Kuntal" Subject: Re: [Mip6] DSMIP6 solution and integrated bootstrap scenario References: <7CCD07160348804497EF29E9EA5560D7FBD9D4$0001@exchtewks2.starentnetworks.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7FBD9D4$0001@exchtewks2.starentnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2007 00:16:21.0082 (UTC) FILETIME=[D6D47BA0:01C75B96] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Chowdhury, Kuntal wrote: >> Basavaraj.Patil@nokia.com wrote: >>> Okay.. I see your point now. >>> I agree that the DS-MIP6 I-D could either refer or mention the > methods >>> by which the MN can discover the HA. >> We can mention in the DS-MIPv6 spec, that if DS-MIPv6 >> is being used in the integrated scenario, DHCPv6 may >> also be used for HA bootstrapping. Thats not a big >> deal. >> > [KC>] IMHO, section 2.1 should just point to the two bootstrapping > solutions (i.e. split and integrated) so that deployments utilizing > either of the bootstrapping solution can use DSMIP6. No. We need to show at least one mechanism for MN to obtain the IPv4 address of the HA. Otherwise we are left only with manual configuration of HA's IPv4 address on the mobile node. We have three paragraphs in section 2.1 that describes how one can add the 'A' record for the HA in the DNS entry in addition to the 'AAAA' record and how the mobile node may obtain the HA's IPv4 address. Kuntal, I don't have a problem listing DHCP also as one of the solutions for DS-MIPv6 HA discovery, but we need to extend DHCPv4 (only DHCPv4 is available on an IPv4 access network) to return the IPv6 and IPv4 address of the DS-MIPv6 home agent. Please work on these extensions before demanding that we add references to other solutions. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 20:53:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMaTq-0001L9-Cq; Wed, 28 Feb 2007 20:53:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMaTp-0001L3-A9 for mip6@ietf.org; Wed, 28 Feb 2007 20:53:13 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMaTo-00035r-29 for mip6@ietf.org; Wed, 28 Feb 2007 20:53:13 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 17:53:11 -0800 Message-ID: <45E63205.2090708@azairenet.com> Date: Wed, 28 Feb 2007 17:53:09 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Gopal Dommety (gdommety)" Subject: Re: [Mip6] Revised Milestones for MIP6 Working Group References: <28CEA477BE98ED48AF08A0B637A74BF40321CBDC@xmb-sjc-224.amer.cisco.com> In-Reply-To: <28CEA477BE98ED48AF08A0B637A74BF40321CBDC@xmb-sjc-224.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2007 01:53:11.0535 (UTC) FILETIME=[5E213FF0:01C75BA4] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Gopal Dommety (gdommety) wrote: > Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for > publication as a Proposed Standard. We should try to send this to the IESG sooner than Sep 2007. > Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for > publication as a Proposed Standard. > Dec 2007 Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG > for publication as a Proposed Standard. These two documents are ready for WG last call. They can be done much earlier. No? Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 21:31: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 1HMb4S-000507-Es; Wed, 28 Feb 2007 21:31:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMb4R-0004zw-QK for mip6@ietf.org; Wed, 28 Feb 2007 21:31:03 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMb4Q-0005io-HU for mip6@ietf.org; Wed, 28 Feb 2007 21:31:03 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 18:31:02 -0800 Message-ID: <45E63AE1.4090708@azairenet.com> Date: Wed, 28 Feb 2007 18:30:57 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Mip6] AD review of draft-ietf-mip6-bootstrapping-split References: <459A5A6C.5070602@piuha.net> <45E00DD3.1010701@piuha.net> <45E32B26.7050702@azairenet.com> <45E4D408.8050709@azairenet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2007 02:31:02.0082 (UTC) FILETIME=[A77B3A20:01C75BA9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Mobile IPv6 Mailing List , James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Gerardo Giaretta wrote: >> > The AAA exchange may not be an additional one. Currently we are >> > discussing this issue in DIME WG (please, it would be great if you >> > take part on that discussion too); there are two options under >> > discussion, depending if the authorization for MIPv6 bootstrapping is >> > performed during the bootstrapping or after the first BU. The latter >> > option derives from the consideration that the MN is actually using >> > the MIP service only after the first BU. >> >> Why would a mobile node setup security associations with >> a home agent or send a BU to the home agent if not for >> mobility service? >> > > I agree for the BU. > > However, suppose the HA is acting also as VPN concentrator (or 3GPP > PDG or similar): there may be cases where the MN sets up a SA with > this box and then use it not for MIPv6. This is an issue in DIME > design: we are discussing when the authorization for MIPv6 should be > performed. That should be irrelevant. We are talking about DIME extensions to support MIPv6. If someone co-locates a PDG and a Mobile IPv6 HA, why do we care? It is for them to figure out how to make it work. :) Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 23:11: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 1HMcbx-0005NE-Fi; Wed, 28 Feb 2007 23:09:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMcbv-0005Mx-IS for mip6@ietf.org; Wed, 28 Feb 2007 23:09:43 -0500 Received: from omta01ps.mx.bigpond.com ([144.140.82.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMcbq-0004B9-0J for mip6@ietf.org; Wed, 28 Feb 2007 23:09:43 -0500 Received: from oaamta01ps.mx.bigpond.com ([124.191.178.123]) by omta01ps.mx.bigpond.com with ESMTP id <20070301040921.QOER3746.omta01ps.mx.bigpond.com@oaamta01ps.mx.bigpond.com>; Thu, 1 Mar 2007 04:09:21 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta01ps.mx.bigpond.com with ESMTP id <20070301040921.YUUO6229.oaamta01ps.mx.bigpond.com@PC20005>; Thu, 1 Mar 2007 04:09:21 +0000 From: "Hesham Soliman" To: "'Vijay Devarapalli'" , "'Gopal Dommety \(gdommety\)'" Subject: RE: [Mip6] Revised Milestones for MIP6 Working Group Date: Thu, 1 Mar 2007 15:09:14 +1100 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: <45E63205.2090708@azairenet.com> Thread-Index: AcdbpQ7W+jFwzapJQ6GRUN+r68ZwKQAEjlSg x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070301040921.YUUO6229.oaamta01ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: mip6@ietf.org, 'Basavaraj Patil' X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I don't think there are penalties for being early, so this date is fine with me. Hesham > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Thursday, March 01, 2007 12:53 PM > To: Gopal Dommety (gdommety) > Cc: mip6@ietf.org; Basavaraj Patil > Subject: Re: [Mip6] Revised Milestones for MIP6 Working Group > > Gopal Dommety (gdommety) wrote: > > > Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation' > to IESG for > > publication as a Proposed Standard. > > We should try to send this to the IESG sooner than Sep 2007. > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 23:24:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMcpj-0006Yd-MZ; Wed, 28 Feb 2007 23:23:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMcph-0006YS-Nj for mip6@ietf.org; Wed, 28 Feb 2007 23:23:57 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMcpg-0005AA-Eb for mip6@ietf.org; Wed, 28 Feb 2007 23:23:57 -0500 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 l214Nln01260; Wed, 28 Feb 2007 23:23:47 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Revised Milestones for MIP6 Working Group Date: Wed, 28 Feb 2007 22:23:43 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437112F75059@zrc2hxm2.corp.nortel.com> In-Reply-To: <45E63205.2090708@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Revised Milestones for MIP6 Working Group Thread-Index: AcdbpQ4HuWP+zC9XQfek81qpa2fM0wAEnUgQ References: <28CEA477BE98ED48AF08A0B637A74BF40321CBDC@xmb-sjc-224.amer.cisco.com> <45E63205.2090708@azairenet.com> From: "Ahmad Muhanna" To: "Vijay Devarapalli" , "Gopal Dommety \(gdommety\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Wednesday, February 28, 2007 7:53 PM > To: Gopal Dommety (gdommety) > Cc: mip6@ietf.org; Basavaraj Patil > Subject: Re: [Mip6] Revised Milestones for MIP6 Working Group >=20 > Gopal Dommety (gdommety) wrote: >=20 > > Sep 2007 Submit I-D 'Mobile IPv6 Dual-Stack Operation'=20 > to IESG for=20 > > publication as a Proposed Standard.=20 >=20 > We should try to send this to the IESG sooner than Sep 2007. >=20 > > Oct 2007 Submit I-D 'Mobile IPv6 Vendor Specific Option'=20 > to IESG for=20 [Ahmad] I agree with Vijay that this item is ready and can be done much earlier. > > publication as a Proposed Standard.=20 > > Dec 2007 Submit I-D 'Mobile IPv6 Experimental=20 > Allocations' to IESG=20 > > for publication as a Proposed Standard.=20 >=20 > These two documents are ready for WG last call. They can be=20 > done much earlier. No? >=20 > Vijay >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 23:44: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 1HMd8O-0005FO-V2; Wed, 28 Feb 2007 23:43:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMd8N-0005Ey-55 for mip6@ietf.org; Wed, 28 Feb 2007 23:43:15 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMd8J-0006Zs-QI for mip6@ietf.org; Wed, 28 Feb 2007 23:43:15 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 7F19390019 for ; Wed, 28 Feb 2007 23:43:08 -0500 (EST) 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 29106-03 for ; Wed, 28 Feb 2007 23:43:03 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 28 Feb 2007 23:43:03 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 23:43:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] DSMIP6 solution and integrated bootstrap scenario Date: Wed, 28 Feb 2007 23:43:03 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD9EB@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] DSMIP6 solution and integrated bootstrap scenario Thread-Index: Acdbltp0lYGXBpi4QU6U2KbWTEFALwAIsSMg From: "Chowdhury, Kuntal" To: "Vijay Devarapalli" X-OriginalArrivalTime: 01 Mar 2007 04:43:03.0599 (UTC) FILETIME=[1912CBF0:01C75BBC] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay, Let's not debate over specific cases like the IPv4 only access network case that you cite. There is no guarantee that the DNS method for Home Agent discovery will produce the information the MN is looking for all the time. What will the MN do in a situation when it fails to get the HA information from DNS? It will fallback on some other scheme, no? The MN needs to have fallback options regardless of which method is used i.e. DNS or DHCP or something else. There is no need in the DSMIP6 I-D to get into "preference" for mip6 bootstrap solution. Depending on the use case, access network capabilities (e.g. v4 or v6 or dual stack), deployment scenario, roaming agreement etc. either split or the integrated modes of mip6 bootstrapping will be used. The current draft is unduly biased towards DNS option and I am raising the point to fix that. I want the DSMIP6 I-D to be agnostic to the bootstrapping solution.=20 -Kuntal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Wednesday, February 28, 2007 6:16 PM > To: Chowdhury, Kuntal > Cc: Basavaraj.Patil@nokia.com; mip6@ietf.org > Subject: Re: [Mip6] DSMIP6 solution and integrated bootstrap scenario >=20 > Chowdhury, Kuntal wrote: >=20 > >> Basavaraj.Patil@nokia.com wrote: > >>> Okay.. I see your point now. > >>> I agree that the DS-MIP6 I-D could either refer or mention the > > methods > >>> by which the MN can discover the HA. > >> We can mention in the DS-MIPv6 spec, that if DS-MIPv6 > >> is being used in the integrated scenario, DHCPv6 may > >> also be used for HA bootstrapping. Thats not a big > >> deal. > >> > > [KC>] IMHO, section 2.1 should just point to the two bootstrapping > > solutions (i.e. split and integrated) so that deployments utilizing > > either of the bootstrapping solution can use DSMIP6. >=20 > No. We need to show at least one mechanism for MN to > obtain the IPv4 address of the HA. Otherwise we are > left only with manual configuration of HA's IPv4 > address on the mobile node. We have three paragraphs > in section 2.1 that describes how one can add the > 'A' record for the HA in the DNS entry in addition to > the 'AAAA' record and how the mobile node may obtain > the HA's IPv4 address. >=20 > Kuntal, I don't have a problem listing DHCP also as > one of the solutions for DS-MIPv6 HA discovery, but > we need to extend DHCPv4 (only DHCPv4 is available > on an IPv4 access network) to return the IPv6 and > IPv4 address of the DS-MIPv6 home agent. Please work > on these extensions before demanding that we add > references to other solutions. >=20 > Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 28 23:54:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMdIw-0004JJ-FK; Wed, 28 Feb 2007 23:54:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMdIu-00048n-Di for mip6@ietf.org; Wed, 28 Feb 2007 23:54:08 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMdIq-0007O6-0e for mip6@ietf.org; Wed, 28 Feb 2007 23:54:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id C7E419001A for ; Wed, 28 Feb 2007 23:54:00 -0500 (EST) 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 28526-12 for ; Wed, 28 Feb 2007 23:53:55 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 28 Feb 2007 23:53:55 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 23:53:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Revised Milestones for MIP6 Working Group Date: Wed, 28 Feb 2007 23:53:55 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD9EC@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Revised Milestones for MIP6 Working Group Thread-Index: Acdbgt6Wt9v630z6R+K5+perrE75TQAOdrhw From: "Chowdhury, Kuntal" To: "Gopal Dommety (gdommety)" , X-OriginalArrivalTime: 01 Mar 2007 04:53:55.0796 (UTC) FILETIME=[9DD02940:01C75BBD] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Gopal, " May 2007=A0=A0=A0Submit I-D 'Bootstrapping solution for Integrated = Scenario' to IESG for publication as a Proposed Standard Jul 2007 Submit I-D 'DHCP Options for Home Information Discovery in = MIPv6' for publication as a proposed standard " May and Jul 2007 milestones are way too conservative/late. I think 3GPP2 = has dependencies on these two I-Ds (past due): http://www.3gpp2.org/Public_html/IETF/IETF_Dependencies.cfm Can these dates be revised? We may need to have a chat with AC Mahendran = and Thomas Narten (3GPP2 and IETF liaisons) to update these dates. Regards, Kuntal ________________________________________ From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com]=20 Sent: Wednesday, February 28, 2007 4:06 PM To: mip6@ietf.org Cc: Basavaraj Patil Subject: [Mip6] Revised Milestones for MIP6 Working Group Hello, =A0 =A0=A0=A0 I am attaching the revised=A0 Milestones for the MIP6 Working = Group. Please let me know if there are any changes required. =A0 Regards, Gopal Dommety =A0 =A0 =A0 Goals and Milestones: Done=A0=A0=A0 Submit I-D 'Issues with firewall Problem statement' to = IESG=A0=20 Done=A0=A0=A0 Submit I-D 'MIPv6 MIB' to IESG=A0=20 Done=A0=A0=A0 Submit I-D 'Extensions to Socket Advanced API for MIPv6' = to IESG=A0=20 Done=A0=A0=A0 Submit I-D 'Alternate Route Optimization (Pre-config Key) = scheme' to IESG=A0=20 Done=A0=A0=A0 Submit Bootstrapping problem statement to IESG=A0=20 Done=A0=A0=A0 Submit I-D 'Authentication Option for MIPv6' to IESG=A0=20 Done=A0=A0=A0 Submit I-D 'Identification Option for MIPv6' to IESG=A0=20 Done=A0=A0=A0 Submit I-D 'MIPv6 operation with IKEV2 and the revised = IPsec Architecture to IESG=A0=20 Done=A0=A0=A0 Submit Problem statement and Solution to Mobile IPv6 = transition between v4/v6 networks to IESG=20 Done=A0=A0=A0 Submit I-D 'Mobility management for Dual stack mobile = nodes: A Problem Statement' to IESG for publication as Informational.=A0 = Done=A0=A0=A0 Submit I-D 'Address Location Privacy and Mobile IPv6 = Problem Statement' to IESG for publication as Informational.=A0=20 Done=A0=A0=A0 Submit I-D 'Bootstrapping solution for split Scenario' to = IESG for publication as a Proposed Standard.=20 Done =A0 Submit I-D 'Using IPsec between Mobile and Correspondent IPv6 = Nodes' to IESG for publication as Experimental. Apr 2007=A0=A0=A0 Submit I-D 'Motivation for Authentication I-D' to IESG = for publication as Informational.=A0=20 May 2007=A0=A0=A0Submit I-D 'Bootstrapping solution for Integrated = Scenario' to IESG for publication as a Proposed Standard.=A0=20 Jul 2007=A0=A0=A0=A0 Submit I-D 'DHCP Options for Home Information = Discovery in MIPv6' for publication as a proposed standard.=A0=20 Jul 2007=A0=A0=A0=A0 Submit I-D 'Mobility Header Home Agent Switch = Message' to IESG for publication as a Proposed Standard.=20 Aug 2007=A0=A0=A0 Submit I-D 'Goals for AAA HA Interface' to IESG for = publication as Informational.=A0=20 Sep 2007=A0=A0=A0 Submit I-D 'Home agent reliability' to IESG for = publication as a Proposed Standard.=A0=20 Sep 2007=A0=A0=A0 Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG = for publication as a Proposed Standard.=A0=20 Oct 2007=A0=A0=A0 Submit I-D 'Mobile IPv6 Vendor Specific Option' to = IESG for publication as a Proposed Standard.=A0=20 Dec 2007=A0=A0=A0 Submit I-D 'Mobile IPv6 Experimental Allocations' to = IESG for publication as a Proposed Standard.=A0=20 Dec 2007=A0=A0=A0 Submit I-D 'RADIUS Mobile IPv6 Support' to IESG for = publication as a proposed standard.=A0=20 Feb 2008=A0=A0=A0 Submit I-D 'Mobile IPv6 Operation with Firewalls' to = IESG for publication as Informational.=A0=20 Feb 2008=A0=A0=A0 Submit I-D(s) related to specific updates and = corrections of RFC 3775 to IESG for publication as Proposed Standard.=A0 = _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6