From mip4-bounces@ietf.org Thu Jul 06 02:14:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyN7u-00058M-1E; Thu, 06 Jul 2006 02:14:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyN7s-00052w-HX; Thu, 06 Jul 2006 02:14:12 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyN7q-0008Oc-Pu; Thu, 06 Jul 2006 02:14:12 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1E909898BC; Thu, 6 Jul 2006 09:14:10 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C1414898B9; Thu, 6 Jul 2006 09:14:09 +0300 (EEST) Message-ID: <44ACAA2D.5060504@piuha.net> Date: Thu, 06 Jul 2006 09:14:05 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org 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: c0bedb65cce30976f0bf60a0a39edea4 Cc: mip4@ietf.org Subject: [Mip4] summary of the ds-mip4 discussion for mip4 rechartering X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org I am summarizing the discussion so that we can conclude and move forward. Its been a long discussion and there were also some topics outside the MIP4 chartering question. For instance, at the end there was a subthread about the scalability of the current DS-MIPv6 solution. First, a number of question marks were raised about what actually is proposed. I believe clarifications were received on all questions. The essence of the proposal is to enable IPv6 usage in scenarios where MIPv4 is currently deployed. We need to make the charter text clearer since this was not immediately obvious to everyone. There were promises to update earlier problem statement drafts that people asked for. There was also a discussion of how this work should be divided to particular documents. In this case I believe a narrowly scoped, small document is better than attempting to combine everything to a single document. Given the clarification of the scope of the work above, most people seemed to agree that the MIPv4 and MIPv6 parts should be in separate documents. It is still unclear to me what the best approach is with regards to the problem statement part, though. From my point of view we need one, and either that is published as a common document in MIP6 or we need a separate one for MIP4. A number of concerns were also raised: - Is there a real-world demand and customers for this? (According to George there is). - That there is overlap for handling both IPv4 and IPv6 traffic. (Right, but its hard to get away from that if you intend to allow both IPv4 and IPv6 to be used regardless of what MIP infrastructure you are running on. Also part of the motivation for DS-MIPv6 is making it possible to use IPv4 Internet while still getting the benefits of Mobile IPv6 mobility; Personally, I believe we should definately keep IPv4 home address functionality in the DS-MIPv6 work.) - A number of arguments from the earlier MIP4 list discussion were pointed to. E.g., it would be better and more desirable to deploy MIPv6 at the time that you deploy IPv6, and the impact to market demand for MIPv6. - There is no danger of getting into a v6-only access network (true, but DS-MIPv4 is not addressing that; a clarification of the charter may be needed here) A fairly small number of people stated an opinion about the proposed work. The result is similar to the earlier discussion on the MIP4 list, i.e., there is no agreement but I think there is rough consensus for doing the work. Personally, I do think that this extension to MIP4 makes sense and I am going forward with the rechartering process. But a revised charter will first need to be written. Also, we should not overemphasize the significance of the extension. The main problem is not whether MIP4 deployments get to do IPv6 or not. The main question is what happens to all those current deployments that do not have either mobility or IPv6. With that in mind, I also do not think we should add a lot of functionality into DS-MIPv4. The scope of the work needs to be very constrained. --Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sat Jul 08 10:21:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzDg8-0001P0-8s; Sat, 08 Jul 2006 10:21:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyvAD-0008K2-S8 for mip4@ietf.org; Fri, 07 Jul 2006 14:34:53 -0400 Received: from barbarian.comsoc.org ([140.98.194.218]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FyvAC-0006QV-Ha for mip4@ietf.org; Fri, 07 Jul 2006 14:34:53 -0400 Received: from barbarian.comsoc.org (barbarian.comsoc.org [140.98.194.218]) by barbarian.comsoc.org (GMS Comm 11.01.3365/NY9491.00.1c9c152c) with ESMTP id za2899979 for wcnc2007cfp@comsoc.org; Fri, 7 Jul 2006 15:01:39 -0400 Received: from barbarian.comsoc.org (barbarian.comsoc.org [140.98.194.218]) by barbarian.comsoc.org (GMS Comm 11.01.3365/NY9491.00.1c9c152c) with ESMTP id za2899979 for wcnc2007cfp@comsoc.org; Fri, 7 Jul 2006 15:00:26 -0400 Received: from [140.98.210.253] by barbarian.comsoc.org (GMS 11.01.3365/NY9491.00.1c9c152c) with ESMTP id juadlcaa for wcnc2007cfp@comsoc.org; Fri, 7 Jul 2006 15:00:24 -0400 From: ComSocConferences@comsoc.org To: wcnc2007cfp@comsoc.org Date: Fri, 7 Jul 2006 14:25:07 -0400 MIME-Version: 1.0 Message-ID: X-Originating-IP: [140.98.210.253] X-ListVersion: 11 X-ListMember: mip4@ietf.org [wcnc2007cfp@comsoc.org] X-Spam-Score: 0.5 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 X-Mailman-Approved-At: Sat, 08 Jul 2006 10:21:03 -0400 Cc: Subject: [Mip4] =?windows-1252?q?IEEE_WCNC_2007_=96_Call_for_Papers?= X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1487004700==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1487004700== Content-Type: multipart/alternative; boundary="--=_NextPart_777D5154_24664436_01C9F258.D84EF1C0" This is a multi-part message in MIME format. ----=_NextPart_777D5154_24664436_01C9F258.D84EF1C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IEEE Wireless Communications and Networking Conference (WCNC 2007) 11 =96 15 March 2007 / Hong Kong / http://www.ieee-wcnc.org CALL FOR PAPERS: DEADLINE DATE OF 20 SEPTEMBER 2006 IEEE Wireless Communications and Networking Conference (WCNC) is one of the= world's foremost international technical conferences for engineers and= researchers at the forefront of development and deployment of wireless= technologies. In 2007, for the first time ever, WCNC will be held outside North America in= Asia's world city, Hong Kong. IMPORTANT DATES Full paper submissions: 20 September 2006 Notification of acceptance: 8 December 2006 Camera ready submission: 5 January 2007 CALL FOR PROPOSALS The WCNC 2007 organizing committee invites you to submit proposals for= tutorials, technical papers and Technology/Business Applications Panels. Deadline: 20 September 2006 ORGANIZATION General Chairs Technical Program= Chair Khaled B. Letaief, Chih-Lin I Ross D. Murch For more WCNC 2007 details & updates, visit: http://www.ieee-wcnc.org ----=_NextPart_777D5154_24664436_01C9F258.D84EF1C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
3D""
 

IEEE Wireless Communications and Networking Conference (WCNC 2007)
11 =96 15 March 2007 /Hong Kong / http://www.ieee-wcnc.org 

CALL FOR PAPERS:    DEADLINE DATE OF 20 SEPTEMBER 2006
 
IEEE Wireless Communications and Networking Conference (WCNC) is one of the world's foremost international technical conferences for engineers and researchers at the forefront of development and deployment of wireless technologies.  

In 2007, for the first time ever, WCNC will be held outside North America in Asia's world city, Hong Kong.

 

IMPORTANT DATES
Full paper submissions:           =     20 September 2006
Notification of= acceptance:             8 December 2006
Camera ready= submission:           =  5 January 2007

CALL FOR= PROPOSALS
The= WCNC 2007 organizing committee invites you to submit proposals for tutorials, technical papers and Technology/Business Applications Panels. 
Deadline:  20 September 2006

ORGANIZATION

General= Chairs                                             Technical Program Chair
Khaled B. Letaief, Chih-Lin I             = ;          Ross D.= Murch

For more= WCNC 2007 details & updates, visit:  http://www.ieee-wcnc.org<= /P>



----=_NextPart_777D5154_24664436_01C9F258.D84EF1C0-- --===============1487004700== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1487004700==-- From mip4-bounces@ietf.org Mon Jul 10 13:10:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzH1-0004bH-K7; Mon, 10 Jul 2006 13:10:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzzH0-0004an-EC for mip4@ietf.org; Mon, 10 Jul 2006 13:10:18 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzzGz-0004Zn-PZ for mip4@ietf.org; Mon, 10 Jul 2006 13:10:18 -0400 Received: from wee.isi.edu (wee.isi.edu [128.9.168.112]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k6AH96u21787 for ; Mon, 10 Jul 2006 10:09:06 -0700 (PDT) From: Wei Ye To: mip4@ietf.org Content-Type: text/plain; charset=UTF-8 Date: Mon, 10 Jul 2006 10:09:01 -0700 Message-Id: <1152551341.9960.17.camel@wee.isi.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: weiye@isi.edu Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by boreas.isi.edu id k6AH96u21787 X-Spam-Score: 0.0 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Subject: [Mip4] ACM SenSys 2006: Travel Grants, Posters, Demos and Workshops X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org ACM SenSys 2006: Travel Grants, Posters, Demos and Workshops Our Apologies if you have received multiple copies of this email. Wei Ye and Cormac J. Sreenan SenSys'06 Publicity Co-Chairs --------- The 4th ACM Conference on Embedded Networked Sensor Systems November 1-3, 2006 Boulder, Colorado, USA http://sensys.acm.org/2006/ Sponsored by ACM SIGCOMM, SIGMOBILE, SIGARCH, SIGOPS, SIGMETRICS and =20 SIGBED; with support from NSF. The 4th ACM Conference on Embedded Networked Sensor Systems (SenSys) =20 is a highly selective, single-track forum for the presentation of =20 research results on systems issues in the area of embedded, networked=20 sensors. Distributed systems based on networked sensors and actuators =20 with embedded computation capabilities allow for an instrumentation =20 of the physical world at an unprecedented scale and density, thus =20 enabling a new generation of monitoring and control applications. =20 This conference provides an ideal venue to address the research =20 challenges facing the design, deployment, use, and fundamental limits =20 of these systems. Sensor networks require contributions from many =20 fields, from wireless communication and networking, embedded systems =20 and hardware, distributed systems, data management, and applications, =20 so we welcome cross-disciplinary work. ACM SenSys 2006: Student Travel Grants -------------------------------------- We will assist around 17 US-based graduate students to attend this meeting. The amount of support provided to each student will be $881=20 on average, or the actual documented amount of expenses, whichever is less. It covers travel, lodging, registration, and meals. All travel support is made possible by a travel grant from the US National=20 Science Foundation (NSF). =20 Important Dates Travel applications due: September 1, 2006 Notification of awards: September 8, 2006 Acceptance by recipients: September 15, 2006 Application Procedure Applications for the travel award should be received electronically by Haiyun Luo (haiyun@cs.uiuc.edu) by Friday, September 1, 2006. Please make sure that you receive an email confirmation of your submission. An application will consist of the student's vita, a letter from the student, and a letter from the student's advisor. The letter from the student should include: 1. A brief summary of research interests and accomplishments to date 2. A description of areas reflected in the SenSys 2006 program that=20 would impact the students research 3. Importance of attend the conference to the students research activities =20 In addition, the student's advisor should send a letter of recommendation to the committee. It should include:=20 1. Confirmation that the student is a Ph.D. candidate in good=20 standing 2. The suitability SenSys 2006 program to the students research area 3. Ways in which attending the conference would benefit the particular student=20 4. The strengths and potential contributions of the student. The awards will be announced by Friday, September 8, 2006. Recipients will be required to accept the award by Friday, September 15, 2006, so that alternates can be notified in the event that a recipient declines. Award Selection Committee Nirupama Bulusu, Portland State U. Deepak Ganesan, UMass Haiyun Luo, UIUC Shivakant Mishra, U. of Colorado Sergio Servetto, Cornell=20 CALL FOR POSTERS ---------------- The poster session will provide a forum for researchers to showcase =20 their work and obtain feedback on ongoing research from knowledgeable =20 conference attendees. Areas of interest are the same as those listed =20 in the technical call for papers. While the poster need not describe =20 completed work, it should report on research for which at least =20 preliminary results are available. We especially encourage =20 submissions by students (that is, for which a student is the first =20 author on the poster). POSTER SUBMISSION INSTRUCTIONS Poster proposals must be submitted as a single PDF file with no more =20 than 3 pages. The first two pages should contain an abstract =20 describing the research content of the poster, along with title, =20 authors, institutional affiliations and contact information. The =20 third page should contain a thumbnail draft of the poster's contents. =20 Please submit your poster proposal as a PDF e-mail attachment to sensys06-poster-chairs@isi.edu with the subject line reading "Sensys Poster Submission" before the =20 deadline. Any questions for the Poster Co-chairs Henry Tirri (Nokia), =20 Robert Szewczyk (Moteiv) may also be directed to this address. IMPORTANT DATES Three-page poster proposal: 11:59pm (EST), July 24, 2006 Notification of acceptance: August 7, 2006 Camera-ready abstract: August 22, 2006 Conference dates: November 1-3, 2006 BASIC INFORMATION ABOUT POSTERS Two-page poster abstracts will appear in the conference proceedings. Authors of accepted poster proposals will have a chance to present the poster to interested attendees during a special poster session at SenSys. Well-crafted posters will tell the story well by themselves, but authors of posters are expected to be available to describe and discuss the work in the poster during the session. The poster dimensions are 30" by 40", with poster contents mounted on rectangular poster board that we will provide. You may choose a layout consisting of individual sheets of paper, or a monolithic large piece of poster paper (which can be printed at document companies). Henry Tirri, Nokia Robert Szewczyk, Moteiv SenSys 2006 Poster Chairs CALL FOR DEMOS -------------- Demonstrations showing innovative research and applications are =20 solicited. SenSys'06 is very interested in demonstrations of technology, platforms, and applications of wireless sensor networks. Two-page abstracts of accepted demos will be published in the SenSys conference proceedings. Submissions from both industries and universities are encouraged. Large-scale, outdoor demos can also be accommodated at the conference facility. For the first time, SenSys 2006 will present a best demo award. DEMO SUBMISSION INSTRUCTIONS Please send a two-page description of your demo to=20 sensys06-demo-chairs@isi.edu in PDF format by the dates listed below. An additional one page appendix can be included in the initial submission but will be removed in published proceedings. Be as specific as possible in describing what you will show. IMPORTANT DATES Two-page demo descriptions: 11:59pm (EST), July 24, 2006 Notification of acceptance: August 7, 2006 Camera-ready abstract: August 22, 2006 Conference dates: November 1-3, 2006 Chieh-Yih Wan, Intel Labs Jie Liu, Microsoft Research SenSys 2006 Demo Chairs Workshop on Distributed Smart Cameras (DSC-06) ---------------------------------------------- http://www.iti.tugraz.at/dsc06 Boulder, Colorado, USA October 31, 2006 Scope: Distributed smart cameras combine two concepts: physically =20 distributed cameras and distributed computing. Distributed smart =20 cameras are examples of high-performance multimedia sensor networks. =20 This area brings together researchers in image processing, sensor =20 networks, and embedded system architecture. Several groups are now working on distributed smart cameras, but =20 generally pursuing them in different research communities. This =20 meeting would be the first event to bring together all the research =20 groups working on this problem. We solicit papers addressing =20 theoretical and practical aspects of distributed smart cameras. We =20 particularly encourage submissions describing applications, case =20 studies or deployments. Topics of interest include, but are not limited to: - Distributed embedded systems for video - Smart camera architectures - Collaborative embedded vision - Networking for distributed smart cameras - Multi-sensor systems and sensor fusion - Middleware for distributed smart cameras - Applications of smart cameras in areas such as surveillance, =20 tracking and smart rooms Submission Instructions: We invite authors to submit papers no longer than 5 pages in PDF to =20 dsc06@iti.tugraz.at. Accepted papers will made available to workshop =20 participants. Demo presentations are welcome. If you plan to present =20 a demo of distributed smart cameras contact the workshop co-chairs. Important Dates: - Paper submission: July 31, 2006 - Notification of acceptance: Sep 15, 2006 - CR paper submission: Sep. 30, 2006 - Workshop: Oct. 31, 2006 Program co-chairs: B. Rinner, TU Graz W. Wolf, Princeton U. Program committee: F. Berry, Univ. Clermont-Ferrand S. Bhattacharyya, U. Maryland M. Bove, MIT Media Lab J. Ferryman, Reading Univ. C. Guestrin, CMU R. Kleihorst, Philips Research X. Koutsoukos, Vanderbilt U. C. Regazzoni, Univ. Genova M. Srivastava, UCLA W. Strasser, Univ. T=C3=BCbingen First Workshop on World-Sensor-Web (WSW'2006) --------------------------------------------- Mobile Device Centric Sensory Networks and Applications http://www.sensorplanet.org/wsw2006/ Boulder, Colorado, USA October 31, 200 SCOPE The global use of mobile phones on a scale never seen before enables =20 the development of new types of application scenarios. Furthermore, a =20 mobile device centric approach to large-scale sensory networks =20 provides a challenging platform for research purposes. Additionally, =20 connecting sensory networks to the Internet creates endless =20 opportunities for applications and services, new emerging models of =20 operation. The workshop aims to address these aspects, beside traditional =20 sensory network topics such as power management, communication =20 issues, topology management, distributed architectures, peer-to-peer =20 scenarios, etc. Demonstrations and initial ideas are welcome as well. Original, short or position papers (max 5 page), presenting results =20 on both theoretical and practical aspects of large-scale mobile =20 device centric sensor networks are expected. We are particularly =20 interested in prototype descriptions, reports from on-going trials =20 and demonstrations, real-life deployments. Live or videod demos are =20 encouraged. Topics of interest include but are not limited to: - device centric sensory networks - communication strategies and topology control - location and mobility management - power management, energy-efficient design - data gathering, transport, storage, retrieval, mining and =20 dissemination - data analysis and visualisation - modelling and simulation software tools - experimental systems and demonstrations - real-life deployments, middleware implementations - beyond location sensing - intelligent sensors, body sensors and their utilisation - phone as a gateway - end-user aspects, UI issues, use cases - sensory networks and the Web WORKSHOP CO-ORGANIZERS Henry Tirri, Nokia Research Center, Helsinki, Finland Barbara Heikkinen, Nokia Research Center, Helsinki, Finland Boda P=C3=A9ter, Nokia Research Center, Helsinki, Finland TECHNICAL PROGRAM COMMITTEE Joe Paradiso, MIT Media Laboratory, Cambridge, MA, USA Deborah Estrin, UCLA, Los Angeles, CA, USA Gaetano Borriello, University of Washington, Seattle, WA, USA Philippe Bonnet, University of Copenhagen, Copenhagen, Denmark Sam Madden, MIT CSAIL, Cambridge, USA Jukka Salminen, Nokia research Center, Helsinki, Finland IMPORTANT DATES Papers due: September 1, 2006 Notification of acceptance September 30, 2006 Camera-ready papers due October 10, 2006 SUBMISSION INSTRUCTIONS WSW'2006 invites submissions for position papers or short papers on =20 prototype descriptions, early research results, reports from on-going =20 demonstrations, etc. Demonstrations, live or videod, are mostly =20 encouraged. All papers should meet the following formatting rules: 1. Papers should be submitted in PDF format. 2. The maximum length is five pages. The paper size format is US=20 letter, including all text, figures, references, appendices, etc. 3. Two column formatting 4. One-inch margins on all sides 5. Minimum 10-point font size (smaller fonts are acceptable for =20 footnotes, references, and figure captions). Questions, inquiries Please mail to peter dot boda at nokia dot com with subject WSW2006.=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jul 18 02:26:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2j2Q-0005G2-Lm; Tue, 18 Jul 2006 02:26:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2j2P-0005Fx-K9 for mip4@ietf.org; Tue, 18 Jul 2006 02:26:33 -0400 Received: from airmail.airvananet.com ([12.6.244.34] helo=airmail.wirelessworld.airvananet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2j2O-0003vB-Aj for mip4@ietf.org; Tue, 18 Jul 2006 02:26:33 -0400 Received: from nilgiri.india.wirelessworld.airvananet.com ([192.168.51.3]) by airmail.wirelessworld.airvananet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 02:26:26 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Jul 2006 11:56:21 +0530 Message-ID: <653F3CF58193744C9DE59C217C072B5872C044@nilgiri.india.wirelessworld.airvananet.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: One clarification - rfc2002 'virtual network case' Thread-Index: AcaqMxX3hHRlAiloTTCEcsT/pcDnvg== From: "Subramonia Pillai" To: X-OriginalArrivalTime: 18 Jul 2006 06:26:26.0462 (UTC) FILETIME=[18E913E0:01C6AA33] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Subject: [Mip4] One clarification - rfc2002 'virtual network case' X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1690009470==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1690009470== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AA33.162702BA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AA33.162702BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 =20 "If the home network is a virtual network, the home network has no physical realization external to the home agent itself. In this case, there is no physical network link on which to send Agent Advertisement messages advertising the home agent. Mobile nodes for which this is the home network are always treated as being away from home." =20 =20 Can any one please explain above case?=20 =20 [My understanding is in virtual network (L3-VPN) the subnet belongs to=20 one site only - it can't be split between two sites, so when a node moves=20 to another site obviously it can access home network through visited network.=20 Why this is given in RFC as special case]. =20 Thanks Subu =20 ------_=_NextPart_001_01C6AA33.162702BA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi,
 
 
   “If the home network is a =
virtual network, the home network has =
no
   physical realization external to =
the home agent itself.  In =
this
   case, there is no physical =
network link on which to send =
Agent
   Advertisement messages =
advertising the home agent.  Mobile nodes =
for
   which this is the home network =
are always treated as being away =
from
   =
home.”
 
 
Can any =
one please explain above case? 
 
[My =
understanding is in virtual network (L3-VPN) the subnet belongs to =

one site =
only – it can’t be split between two sites, so when a node =
moves 
to =
another site obviously it can access home network through visited =
network. 
Why this =
is given in RFC as special =
case].
 
Thanks
Subu

 

------_=_NextPart_001_01C6AA33.162702BA-- --===============1690009470== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1690009470==-- From mip4-bounces@ietf.org Tue Jul 18 02:37:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2jDP-0006r4-E2; Tue, 18 Jul 2006 02:37:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2jDO-0006qz-Nq for mip4@ietf.org; Tue, 18 Jul 2006 02:37:54 -0400 Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2jDN-0004sb-8R for mip4@ietf.org; Tue, 18 Jul 2006 02:37:54 -0400 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by warlock.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6I6bnVI018454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Jul 2006 23:37:51 -0700 (PDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6I6blW4018241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 17 Jul 2006 23:37:47 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6I6bkgA018310; Mon, 17 Jul 2006 23:37:46 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 23:37:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] One clarification - rfc2002 'virtual network case' Date: Mon, 17 Jul 2006 23:37:53 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A0CBD4A@NAEX14.na.qualcomm.com> In-Reply-To: <653F3CF58193744C9DE59C217C072B5872C044@nilgiri.india.wirelessworld.airvananet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] One clarification - rfc2002 'virtual network case' Thread-Index: AcaqMxX3hHRlAiloTTCEcsT/pcDnvgAAKwdQ From: "Tsirtsis, George" To: "Subramonia Pillai" , X-OriginalArrivalTime: 18 Jul 2006 06:37:45.0655 (UTC) FILETIME=[ADBDB470:01C6AA34] X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1847413888==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1847413888== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AA34.AD6EC122" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AA34.AD6EC122 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Subramonia, =20 I do not think the RFC refers to L3-VPNs in the paragraph you quote below. The RFC simply indicates that in some cases there is no physical link (e.g., a physical LAN) to which the home subnet is located and so there is no way for a mobile node to ever "return home". In such cases, no matter where the mobile node connects in the Internet infrastructure it will always be "away from home". =20 You may also want to check out RFC3344 which replaces RFC2002, and it maintains the same quotation. =20 Regards George. =20 ________________________________ From: Subramonia Pillai [mailto:spillai@airvana.com]=20 Sent: Tuesday, July 18, 2006 2:26 AM To: mip4@ietf.org Subject: [Mip4] One clarification - rfc2002 'virtual network case' =20 Hi, =20 =20 "If the home network is a virtual network, the home network has no physical realization external to the home agent itself. In this case, there is no physical network link on which to send Agent Advertisement messages advertising the home agent. Mobile nodes for which this is the home network are always treated as being away from home." =20 =20 Can any one please explain above case?=20 =20 [My understanding is in virtual network (L3-VPN) the subnet belongs to=20 one site only - it can't be split between two sites, so when a node moves=20 to another site obviously it can access home network through visited network.=20 Why this is given in RFC as special case]. =20 Thanks Subu =20 ------_=_NextPart_001_01C6AA34.AD6EC122 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Subramonia,

 

I do not think the RFC refers to = L3-VPNs in the paragraph you quote below. The RFC simply indicates that in some = cases there is no physical link (e.g., a physical LAN) to which the home = subnet is located and so there is no way for a mobile node to ever “return = home”. In such cases, no matter where the mobile node connects in the Internet infrastructure it will always be “away from = home”.

 

You may also want to check out = RFC3344 which replaces RFC2002, and it maintains the same = quotation.

 

Regards

George.

 

From: = Subramonia Pillai [mailto:spillai@airvana.com]
Sent: Tuesday, July 18, = 2006 2:26 AM
To: mip4@ietf.org
Subject: [Mip4] One = clarification - rfc2002 'virtual network case'

 

Hi,
 
 
   “If the home network is a =
virtual network, the home network has no
   physical realization external to =
the home agent itself.  In this
   case, there is no physical =
network link on which to send Agent
   Advertisement messages =
advertising the home agent.  Mobile nodes =
for
   which this is the home network =
are always treated as being away from
   =
home.”
 
 
Can any =
one please explain above case? 
 
[My =
understanding is in virtual network (L3-VPN) the subnet belongs to =

one site =
only – it can’t be split between two sites, so when a node =
moves 
to =
another site obviously it can access home network through visited =
network. 
Why this =
is given in RFC as special case].
 
Thanks
Subu

 

------_=_NextPart_001_01C6AA34.AD6EC122-- --===============1847413888== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1847413888==-- From mip4-bounces@ietf.org Tue Jul 18 05:20:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2lkj-0005kE-2o; Tue, 18 Jul 2006 05:20:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2lkh-0005k7-QC for mip4@ietf.org; Tue, 18 Jul 2006 05:20:27 -0400 Received: from airmail.airvananet.com ([12.6.244.34] helo=airmail.wirelessworld.airvananet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2lkg-0001PQ-Dn for mip4@ietf.org; Tue, 18 Jul 2006 05:20:27 -0400 Received: from nilgiri.india.wirelessworld.airvananet.com ([192.168.51.3]) by airmail.wirelessworld.airvananet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 05:20:20 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Jul 2006 14:50:15 +0530 Message-ID: <653F3CF58193744C9DE59C217C072B5872C0C8@nilgiri.india.wirelessworld.airvananet.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call origination Thread-Index: AcaqS2DwMxTxcG3CQti7F/+Fq3FY+Q== From: "Arunkumar Sivaraman" To: X-OriginalArrivalTime: 18 Jul 2006 09:20:20.0622 (UTC) FILETIME=[64278AE0:01C6AA4B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Subject: [Mip4] Call origination X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0985545859==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0985545859== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AA4B.612F2DB8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AA4B.612F2DB8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a doubt on the following call origination scenario: =20 Network System: CDMA 2000 Scenario 1: MN in home network, powers on.=20 Doubts: 1. Does the MN get an ip address through normal IPCP procedures or through MIP RRQ with NAi extension to the HA. 2. What parameter sent by the MN makes the PDSN/HA send an agent advertisement with 'H' bit set. 3. Does (2) happen,at all, when MN is in home network? 4. Protocol call flow in this scenario. =20 Scenario 2: MN, having active call, hands off to a foreign network, for the first time. =20 Doubts: 1. Can the mobile in this scenario move into the foreign network with a ZERO HA address value? 2. If (1) ain't possible, other than static provisioning is there any other way for the mobile to acquire a HA address, while it is active in its home n/w? 3. Is the MN-FA authentication values provisioned in MN, or can they be constructed on the fly?=20 =20 regards, =20 Arunkumar Sivaraman, Airvana India Pvt. Ltd., Ph: +91-80-41348788. =20 "Work is something I do between weekends." =20 ------_=_NextPart_001_01C6AA4B.612F2DB8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

  I have a doubt on the following call = origination scenario:

 

Network System: CDMA 2000

Scenario 1: MN in home network, powers on. =

Doubts:

  1. Does the MN get an ip = address through normal IPCP procedures or through MIP RRQ with NAi = extension to the HA.
  2. What parameter sent by = the MN makes the PDSN/HA send an agent advertisement with ‘H’ bit = set.
  3. Does (2) happen,at = all, when MN is in home network?
  4. Protocol call flow in = this scenario.

 

Scenario 2: MN, having active call, hands off to a = foreign network, for the first time.

 

Doubts:

  1. Can the mobile in this = scenario move into the foreign network with a ZERO HA address = value?
  2. If (1) ain’t = possible, other than static provisioning is there any other way for the = mobile to acquire a HA address, while it is active in its home = n/w?
  3. Is the MN-FA = authentication values provisioned in MN, or can they be constructed on the fly? =

 

regards,

 

Arunkumar Sivaraman,

Airvana India Pvt. Ltd.,

Ph: +91-80-41348788.

 

"Work is something I do between = weekends."

 

------_=_NextPart_001_01C6AA4B.612F2DB8-- --===============0985545859== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0985545859==-- From mip4-bounces@ietf.org Tue Jul 18 10:44:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2qnp-000201-R6; Tue, 18 Jul 2006 10:44:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2qno-0001zv-Hp for mip4@ietf.org; Tue, 18 Jul 2006 10:44:00 -0400 Received: from dsl3.halflab.com ([64.81.61.172] helo=outpost.thehouse.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2qnm-0004He-72 for mip4@ietf.org; Tue, 18 Jul 2006 10:44:00 -0400 Received: from localhost ([127.0.0.1] ident=mccap) by outpost.thehouse.org with esmtp (Exim 4.50) id 1G2qnl-0003UY-0V; Tue, 18 Jul 2006 07:43:57 -0700 Message-ID: <44BCF3AC.4030004@petoni.org> Date: Tue, 18 Jul 2006 09:43:56 -0500 From: Pete McCann User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Arunkumar Sivaraman Subject: Re: [Mip4] Call origination References: <653F3CF58193744C9DE59C217C072B5872C0C8@nilgiri.india.wirelessworld.airvananet.com> In-Reply-To: <653F3CF58193744C9DE59C217C072B5872C0C8@nilgiri.india.wirelessworld.airvananet.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi, Arunkumar, Arunkumar Sivaraman wrote: > Hi, > > I have a doubt on the following call origination scenario: > > > > Network System: CDMA 2000 > > Scenario 1: MN in home network, powers on. > > Doubts: > > 1. Does the MN get an ip address through normal IPCP procedures or > through MIP RRQ with NAi extension to the HA. > 2. What parameter sent by the MN makes the PDSN/HA send an agent > advertisement with ‘H’ bit set. > 3. Does (2) happen,at all, when MN is in home network? > 4. Protocol call flow in this scenario. Call setup for cdma2000 links is described in 3GPP2 publication X.S0011, which is TIA-835. You can find a copy here: http://www.3gpp2.org/Public_html/specs/X.S0011-002-D_v1.0_060301.pdf To use Mobile IP, the MN does not negotiate an address with IPCP and instead leaves out the IP address configuration option entirely. The MN subsequently gets an agent advertisement and registers via the PDSN. The MN sets the home agent and home address fields to zero, and includes the NAI extension along with a Challenge-response extension. > Scenario 2: MN, having active call, hands off to a foreign network, for > the first time. > > > > Doubts: > > 1. Can the mobile in this scenario move into the foreign network with > a ZERO HA address value? > 2. If (1) ain’t possible, other than static provisioning is there any > other way for the mobile to acquire a HA address, while it is > active in its home n/w? > 3. Is the MN-FA authentication values provisioned in MN, or can they > be constructed on the fly? In a cdma2000 network the MN is never "at home" so the above scenario doesn't happen. -Pete > regards, > > > > Arunkumar Sivaraman, > > Airvana India Pvt. Ltd., > > Ph: +91-80-41348788. > > > > //"Work is something I do between weekends."// > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jul 18 11:14:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2rHX-0000Ze-5S; Tue, 18 Jul 2006 11:14:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2rHW-0000ZZ-Gu for mip4@ietf.org; Tue, 18 Jul 2006 11:14:42 -0400 Received: from dsl3.halflab.com ([64.81.61.172] helo=outpost.thehouse.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2rHW-0006V2-0M for mip4@ietf.org; Tue, 18 Jul 2006 11:14:42 -0400 Received: from localhost ([127.0.0.1] ident=mccap) by outpost.thehouse.org with esmtp (Exim 4.50) id 1G2rHU-0003zh-Kh; Tue, 18 Jul 2006 08:14:40 -0700 Message-ID: <44BCFAE0.6090209@petoni.org> Date: Tue, 18 Jul 2006 10:14:40 -0500 From: Pete McCann User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: mip4@ietf.org Content-Type: multipart/mixed; boundary="------------090106060304010105080906" X-Spam-Score: 0.1 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: Henrik Levkowetz Subject: [Mip4] Meeting minutes from Montreal X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --------------090106060304010105080906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please see attached, and send any updates/comments by the end of this week. -Pete --------------090106060304010105080906 Content-Type: text/plain; name="mip4-minutes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mip4-minutes.txt" MIP4 WG meeting, IETF 66 ------------------------ Document Status --------------- draft-ietf-mip4-rfc3344bis Waiting for Charlie to revise the document. Charlie: I had a revision ready a while a go but technical problems prevented me to publish it. I will summarize the changes and publish them soon and publish the revision soon draft-ietf-mip4-vpn-problem-solution Completed WG last call. Ready to be sent to the IESG. draft-ietf-mip4-fmipv4 Ready for WGLC draft-ietf-mip4-gen-ext Ready for WGLC draft-ietf-mip4-message-string-ext Under WG last call. some changes needed Henrik proposed some text. Kent requests to get approval for the text on the list draft-ietf-mip4-mobike-connectivity Some comments received during the first last call. second last call needed. draft-ietf-mip4-radius-requirements Ready for WGLC. Concerns about the need for 31 RADIUS attributes. Radext needs to do something before anything proceed. Aboba commented that the radius AVP space has to be extended Jari: AVP space is not exchausted but it will be considering what is in the pipeline. The AVP has to be extended somehow. Jari: Yes, radext needs to do something. Kent: this is a requirements document. Not the document that is defining the attributes draft-ietf-mip4-reg-tunnel With the AD, but has expired. Will be resubmitted next week draft-ietf-mip4-rfc2006bis New revision out draft-ietf-mip4-faerr draft-ietf-mip4-rfc3012bis draft-ietf-mobileip-lowlatency-handoffs-v4 Approved, in RFC Editor's queue New charter proposals --------------------- 1. Carrying IPv6 in MIPv4 Jari: It has been proposed to add IPv6 carrying capability to MIPv4, based on draft-tsirtsis-v4v6-mipv4 . This was approved by the IESG about 2 weeks ago, on June 29. George - Jari had a few questions on the mailing list about scoping the work Jari - It is related to the problem statement. On whether a problem statement is needed George - there is a dsmip problem statement common to both DS-MIPv4 and DS-MIPv6 in the MIP6 WG Vijay - dsmip problem statement only argues that running MIPv4 and MIPv6 at the same time is not a good idea. Does not really try to justify the extension to MIPv4 to add the capability to carry IPv6 traffic. Specifically it does not describe the scenarios in which it is useful to tunnel IPv6 over MIPv4 Hesham - ? Jari - Problem statement should be done. Could be in the MIP6 WG. 2. MIPv4 based Moving Network (NEMO) support George: Nemov4 basic was defined in the NEMO WG. NEMO WG is mainly IPv6. It was ok with one item, but does not want to take on NEMOv4 extensions. The problem is that base NEMOv4 spec does not support foreign agent or prefix allocation. These are minor extensions and can be done quickly in the MIPv4 WG Vidya - the base NEMOv4 spec will work with foreign agents but work unoptimized George - correct Viday - Very minor work. can be reviewed both by NEMO and MIP4 WGs. Henrik - Does not care whether this is done in NEMO or MIPv4. NEMOv4 base seems to be informational. Question is should NEMOv4 be informational or standards track Kent - Support moving base NEMOv4 here to MIP4 WG and do these small enhancements at the same time. Vidya - Support doing NEMOv4 as standards track in the MIP4 WG. Move the base draft here. George - Supports it. Jari - What kind of deployments plans or business interests exist for this? George - ?? Kent - Cisco has been shipping mobile routers for a while now. This work started because other companies wanted to standardize this. Alexandru Petresecu - We have customers for this. Regarding where to do this, the base NEMOv4 document is going for WG last call in the NEMO WG again. so we need to decide soon. Henrik - We are missing one thing. Carrying V4 NEMO traffic over NAT. Have you looked at this? George - Have looked at it. Nothing more is needed. Sri Gundavelli - Shouldn't be a problem. Alexandru - MIPv4 NAT traversal should be sufficient. Charlie - How is prefix ownership addressed in NEMOv6? Vijay - Problem still exists. Route Optimization for NEMOv6 is not addressed. George - Prefix assignment done exactly like home address allocation. Pete - Looks like there is consensus to take on these items. Will be added to the new charter proposal. George - What about base NEMOv4? Henrik - will talk to the NEMO WG chairs and the AD and decide. 3. Generic notification mechanism Sri Gundavelli presented the mechanism in the draft. Henrik - does not think this is useful for NEMO prefix delegation. Other cases like registration revocation make sense. Proposed to re-work the registration revocation mechanism to use this mechanism. Sri - Agrees Henrik - will be good to get reviews George - Thinks this is a good idea. Take it on as a MIP4 WG item. --------------090106060304010105080906 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --------------090106060304010105080906-- From mip4-bounces@ietf.org Tue Jul 18 14:50:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ueL-0003U4-4f; Tue, 18 Jul 2006 14:50:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2ueJ-0003Tz-0I for mip4@ietf.org; Tue, 18 Jul 2006 14:50:27 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2ueH-0006Hp-M2 for mip4@ietf.org; Tue, 18 Jul 2006 14:50:26 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k6IIoLA6025449 for ; Tue, 18 Jul 2006 11:50:25 -0700 (MST) Received: from ct11exm63.ds.mot.com (ct11exm63.am.mot.com [10.177.8.47]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k6IIoKVl003690 for ; Tue, 18 Jul 2006 13:50:20 -0500 (CDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] One clarification - rfc2002 'virtual network case' Date: Tue, 18 Jul 2006 14:50:19 -0400 Message-ID: <92D17ACC46FB33448977916D9EC398F0B4430C@ct11exm63.ds.mot.com> In-Reply-To: <653F3CF58193744C9DE59C217C072B5872C044@nilgiri.india.wirelessworld.airvananet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] One clarification - rfc2002 'virtual network case' Thread-Index: AcaqMxX3hHRlAiloTTCEcsT/pcDnvgAZ2GOw From: "Rao Satyanarayana-W60007" To: "Subramonia Pillai" , X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1278890692==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1278890692== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AA9B.04E420E1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AA9B.04E420E1 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I do not think the reference to virtual network mean L3-vpn. =20 - Satya Rao Mobile Devices Technology Office Motorola Tel: 512-996-6781 Email: sbrao@motorola.com =20 =20 ________________________________ From: Subramonia Pillai [mailto:spillai@airvana.com]=20 Sent: Tuesday, July 18, 2006 1:26 AM To: mip4@ietf.org Subject: [Mip4] One clarification - rfc2002 'virtual network case' =09 =09 Hi, =20 =20 "If the home network is a virtual network, the home network has no physical realization external to the home agent itself. In this case, there is no physical network link on which to send Agent Advertisement messages advertising the home agent. Mobile nodes for which this is the home network are always treated as being away from home." =20 =20 Can any one please explain above case?=20 =20 [My understanding is in virtual network (L3-VPN) the subnet belongs to=20 one site only - it can't be split between two sites, so when a node moves=20 to another site obviously it can access home network through visited network.=20 Why this is given in RFC as special case]. =20 Thanks Subu =20 ------_=_NextPart_001_01C6AA9B.04E420E1 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I do not think the reference to virtual network mean=20 L3-vpn.
 
- Satya = Rao
Mobile Devices Technology = Office
Motorola
Tel: 512-996-6781
Email: sbrao@motorola.com
 

From: Subramonia Pillai=20 [mailto:spillai@airvana.com]
Sent: Tuesday, July 18, 2006 = 1:26=20 AM
To: mip4@ietf.org
Subject: [Mip4] One = clarification -=20 rfc2002 'virtual network case'

Hi,
 
 
   “If the =
home network is a virtual network, the home network has =
no
   physical =
realization external to the home agent itself.  In =
this
   case, there is no =
physical network link on which to send =
Agent
   Advertisement =
messages advertising the home agent.  Mobile nodes =
for
   which this is the =
home network are always treated as being away =
from
   =
home.”
 
 
Can any one please explain =
above case? 
 
[My understanding is in =
virtual network (L3-VPN) the subnet belongs to =

one site only – it =
can’t be split between two sites, so when a node moves =

to another site obviously it =
can access home network through visited network. =

Why this is given in RFC as =
special case].
 
Thanks
Subu

 

------_=_NextPart_001_01C6AA9B.04E420E1-- --===============1278890692== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1278890692==-- From mip4-bounces@ietf.org Fri Jul 21 02:34:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3oaa-00009e-DM; Fri, 21 Jul 2006 02:34:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3oaY-00009Z-U5 for mip4@ietf.org; Fri, 21 Jul 2006 02:34:18 -0400 Received: from airmail.airvananet.com ([12.6.244.34] helo=airmail.wirelessworld.airvananet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3oaX-0007DJ-Ki for mip4@ietf.org; Fri, 21 Jul 2006 02:34:18 -0400 Received: from nilgiri.india.wirelessworld.airvananet.com ([192.168.51.3]) by airmail.wirelessworld.airvananet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 02:34:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Mip4] Call origination MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Jul 2006 12:04:04 +0530 Message-ID: <653F3CF58193744C9DE59C217C072B58762EE6@nilgiri.india.wirelessworld.airvananet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Call origination Thread-Index: AcaqeJl+5PnMT4TqTjmotzIZJ1sTRwBZ0FOAACvtNwA= From: "Arunkumar Sivaraman" To: X-OriginalArrivalTime: 21 Jul 2006 06:34:09.0835 (UTC) FILETIME=[AC576FB0:01C6AC8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Pete, Thanks for your response. My question below: > Network System: CDMA 2000 >=20 > Scenario 1: MN in home network, powers on. >=20 > Doubts: >=20 > 1. Does the MN get an ip address through normal IPCP procedures or > through MIP RRQ with NAi extension to the HA. > 2. What parameter sent by the MN makes the PDSN/HA send an agent > advertisement with 'H' bit set. > 3. Does (2) happen,at all, when MN is in home network? > 4. Protocol call flow in this scenario. Call setup for cdma2000 links is described in 3GPP2 publication X.S0011, which is TIA-835. You can find a copy here: http://www.3gpp2.org/Public_html/specs/X.S0011-002-D_v1.0_060301.pdf To use Mobile IP, the MN does not negotiate an address with IPCP and instead leaves out the IP address configuration option entirely. The MN subsequently gets an agent advertisement and registers via the PDSN. The MN sets the home agent and home address fields to zero, and includes the NAI extension along with a Challenge-response extension. [ARUN]: When you say the PDSN sends the agent advt, does it set the 'F' & 'R' bit. Going by your answer for the second question it looks like, the PDSN(acting as FA) will always force the mobile to register with it even when the MN is in its home network. 1. Is there a possible scenario in cdma 2000 networks, when the PDSN sends an agent advt with 'h' bit on (can the PDSN respond on behalf of the HA with the 'h' bit set agent advt. If yes, what parameter sent by the MN makes the PDSN take this decision).=20 2. Or is this possibility only when the HA is co-located with the PDSN functionality.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Scenario 2: MN, having active call, hands off to a foreign network, for=20 > the first time. >=20 > =20 >=20 > Doubts: >=20 > 1. Can the mobile in this scenario move into the foreign network with > a ZERO HA address value? > 2. If (1) ain't possible, other than static provisioning is there any > other way for the mobile to acquire a HA address, while it is > active in its home n/w? > 3. Is the MN-FA authentication values provisioned in MN, or can they > be constructed on the fly? In a cdma2000 network the MN is never "at home" so the above scenario doesn't happen. [ARUN]: This is like the condition of the MN "always being away from home" but why is this done in cdma 2000 n/w(s). regards, =20 Arunkumar Sivaraman, Airvana India Pvt. Ltd., Ph: +91-80-41348788. =20 "Work is something I do between weekends." -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jul 21 10:48:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3wIf-000658-2m; Fri, 21 Jul 2006 10:48:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3cSU-0004CO-ID; Thu, 20 Jul 2006 13:37:10 -0400 Received: from cowpens.ceas.rochester.edu ([128.151.162.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3cDg-0008Pe-VI; Thu, 20 Jul 2006 13:21:54 -0400 Received: from h307pc2 (h318fw1.ceas.rochester.edu [128.151.164.245]) by cowpens.ceas.rochester.edu (8.13.6/8.13.6) with SMTP id k6KHLqDM004724; Thu, 20 Jul 2006 13:21:52 -0400 (EDT) Message-ID: <010301c6ac20$ff3bd500$c000a8c0@h307pc2> From: "Wendi Heinzelman" To: , Date: Thu, 20 Jul 2006 13:21:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 06321bb70e4329e24fb56a67c5eca3a0 X-Mailman-Approved-At: Fri, 21 Jul 2006 10:48:20 -0400 Cc: Subject: [Mip4] IEEE SECON 2006 Call for Participation X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org (Apologies if you receive this information multiple times.) Dear Colleague, Please find below the Call for Participation for IEEE SECON 2006, The Third IEEE International Conference on Sensors, Mesh and Ad Hoc Communications and Networks. The detailed conference program, including advance technical program, panel, tutorial and workshops information, is presented below. More information is available at: http://www.ieee-secon.org/2006/. Discounted registration for the conference ends September 1, 2006. We look forward to your participation in the conference. If you have any questions, please do not hesitate to contact any of the conference organizers listed below. Best Regards, IEEE SECON 2006 Conference Organizing Committee *********************************************************************** CALL FOR PARTICIPATION IEEE SECON 2006 The Third IEEE International Conference on Sensors, Mesh and Ad Hoc Communications and Networks http://www.ieee-secon.org/2006/ Sponsored by IEEE Communications Society (www.comsoc.org) Technically Co-Sponsored by AFCEA (www.afcea.org) September 25-28, 2006 Hyatt Reston, Reston, Virginia, USA (Near Washington DC's Dulles airport) ************************************************************************ MONDAY, September 25, 2006 A. WORKSHOPS The IEEE SECON 2006 conference will host the following two workshops, that will be held on Monday, September 25, 2006: 1. Second IEEE Workshop on Wireless Mesh Networks: http://www.ieee-secon.org/2006/wimesh/index.htm Workshop Co-Chairs: Prof. Samir R. Das, Stony Brook University Dr. Thyaga Nandagopal, Bell Labs, Lucent Technologies 2. First IEEE Workshop on Networking Technologies for Software Defined Radio (SDR) Networks: http://www.ieee-secon.org/2006/wsdr/index.htm Workshop Chair: Dr. Thomas Hou, Virginia Tech. B. TUTORIAL: Title: 802.11s: Wireless Local Area Mesh Networking Standard Date: Monday, Sep 25, 2006; Time: 1:30 PM - 5:00 PM Speakers * Donald Eastlake, Motorola Laboratories * Susan Hares, NextHop Technologies * Meiyuan Zhao, Intel Research ========================================================================= TENTATIVE CONFERENCE ADVANCE PROGRAM TUESDAY, September 26, 2006 8:30 AM - 10:00 AM: Opening Remarks and Keynote Talk (TBA) 10.00 AM - 11:00 AM: Posters/Demos 11:00 AM - 12:30 PM: Panel 1: Mesh in Metro: reality and future Moderator: Prakash Iyer, Intel Panelists: Edward Naef, CSMG Vann Hasty, Motorola Malik Audeh, Tropos -------------------------------------------------------------------- 2:00 PM - 3:30 PM: (2 Parallel Tracks - Sessions 1 and 2) Session 1: Routing I Data-Centric Routing in Sensor Networks using Biased Walk Huilong Huang (University of Arizona); John Hartman (University of Arizona); Terril Hurst (University of Arizona) Search-Quality Tradeoffs for Routing in Non-Ideal Wireless Networks Chiranjeeb Buragohain (University of California, Santa Barbara); Divyakant Agrawal (University of California, Santa Barbara); Subhash Suri (University of California at Santa Barbara) GMR: Geographic Multicast Routing for Wireless Sensor Networks Juan Sanchez (University of Murcia); Pedro Ruiz (University of Murcia); Ivan Stojmenovic (University of Ottawa) Scalable Routing in Sensor Actuator Networks with Churn Thomas Fuhrmann (University of Karlsruhe) -------------------------------------------------------------------- Session 2: Security and Privacy Security Services in Wireless Sensor Networks Using Sparse Random Coding Farshid Delgosha (Georgia Institute of Technology); Erman ayday (Georgia Institute of Technology); Kevin Chan (Georgia Tech); Faramarz Fekri (Georgia Institute of Technology) Relationship-Based Detection of Spoofing-Related Anomalous Traffic in Ad Hoc Networks Qing Li (Rutgers University); Wade Trappe (Rutgers University) A Trust Based Framework for Secure Data Aggregation in Wireless Sensor Networks Wei Zhang (University of Texas at Arlington); Sajal Das (The University of Texas at Arlington); Yonghe Liu (UT Arlington) An Anonymous Routing Protocol with The Local-Repair Mechanism for Mobile Ad Hoc Networks Bo Zhu (George Mason University); Sushil Jajodia (George Mason University) -------------------------------------------------------------------- 4:00 PM - 5:30 PM: (2 Parallel Tracks - Sessions 3 and 4) Session 3: Forwarding Protocols Minimum Latency Broadcasting in Multi-Radio Multi-Channel Multi-Rate Wireless Meshes Junaid Qadir (University of New South Wales); Archan Misra (IBM T J Watson Research Center); Chun Tung Chou (University of New South Wales) Solicitation-Based Forwarding for Sensor Networks Seoung-Bum Lee (Columbia University); Kyung Joon Kwak (Columbia University); Andrew Campbell (Dartmouth College) Coverage Aware Buffer Management and Scheduling for Wireless Sensor Networks Eugene Chai (National University of Singapore); Mun Choon Chan (National University of Singapore); Akkihebbal L. Ananda (National University of Singapore) A Communication Architecture for Mobile Wireless Sensor and Actor Networks Tommaso Melodia (Georgia Institute of Technology); Dario Pompili (Georgia Institute of Technology); Ian Akyildiz (Georgia Institute of Technology) -------------------------------------------------------------------- Session 4: Spatial Reuse and Spectrum Allocation Belief-Assisted Pricing for Dynamic Spectrum Allocation in Wireless Networks with Selfish Users Zhu Ji (University of Maryland, College Park); K.J. Ray Liu (University of Maryland) Spatial Diversity Benefits by Means of Induced Fading Daniele Puccinelli (University of Notre Dame); Martin Haenggi (University of Notre Dame) Scheduling Optimization in Wireless MESH Networks with Power Control and Rate Adaptation Antonio Capone (Politecnico di Milano); Giuliana Carello (Politecnico di Milano) *************** END OF TUESDAY PROGRAM *********************************** WEDNESDAY, September 27, 2006 8:30 AM - 10.00 AM: Panel 2: Scaling to Large Sensor Networks - How Large is too Large? Moderator: Dr. James A. Freebersyser, BBN Panelists: Mr. Patrick Gonia, Honeywell Prof. William J. Kaiser, UCLA Prof. Prasun Sinha, Ohio State University Mr. Mike Horton, Crossbow 10.00 AM - 11:00 AM: Posters/Demos 11:00 AM - 12:30 PM: (3 Parallel Tracks - Sessions 5, 6 and 7) Session 5: Platforms and Development Environments Balancing Computation and Communication Costs: The Case for Hybrid Execution in Sensor Networks Ingwar Wirjawan (University of California, Davis); Joel Koshy (University of California, Davis); Raju Pandey (University of California, Davis); Yann Ramin (University of California, Davis) EmPro: An Environment/Energy Emulation and Profiling Platform for Wireless Sensor Networks Chulsung Park (University of California, Irvine); Pai Chou (University of California, Irvine) AmbiMax: Efficient, Autonomous Energy Harvesting System for Multiple-Supply Wireless Sensor Nodes Chulsung Park (University of California, Irvine); Pai Chou (University of California, Irivne) TinyXXL: Language and Runtime Support for Cross-Layer Interactions Andreas Lachenmann (University of Stuttgart); Pedro Jos Marrn (University of Stuttgart); Daniel Minder (University of Stuttgart); Matthias Gauger (University of Stuttgart); Olga Saukh (University of Stuttgart); Kurt Rothermel (University of Stuttgart) -------------------------------------------------------------------- Session 6: Cooperative Communication When Does Cooperation Have Better Performance in Sensor Networks? Ahmed Sadek (University of Maryland); Wei Yu (University of Maryland); K.J. Ray Liu (University of Maryland) Balancing Cooperation and Interference in Wireless Sensor Networks Sam Vakil (University of Toronto); Ben Liang (University of Toronto) Progressive Network Coding for Message-Forwarding in Ad-Hoc Wireless Networks Xingkai Bao (Lehigh University); Jing Li (Lehigh University) -------------------------------------------------------------------- Session 7: Disconnection Tolerance A Proactive Data Bundling System for Intermittent Mobile Connections Caitlin Holman (University of Califonia, Santa Barbara); Khaled Harras (University of Califonia, Santa Barbara); Kevin Almeroth (University of Califonia, Santa Barbara); Anderson Lam (University of Califonia, Santa Barbara) Island Hopping: Efficient Mobility-Assisted Forwarding in Partitioned Networks Natasa Sarafijanovic (EPFL); Michal Pirkowski (EPFL); Matthias Grossglauser (EPFL) Effective Dissemination of Presence Information in Highly Partitioned Mobile Ad Hoc Networks Christoph Lindemann (University of Leipzig); Oliver Waldhorst (University of Leipzig) -------------------------------------------------------------------- 2:00 PM - 3:30 PM: (3 Parallel Tracks - Sessions 8, 9, 10) Session 8: Routing II Improving Geographical Routing for Wireless Networks with an Efficient Path Pruning Algorithm Xiaoli Ma (Georgia Institute of Technology); Min-Te Sun (Auburn University); Gang Zhao (University of Louisville); Xiangqian Liu (University of Louisville) Supervised Learning in Sensor Networks: New Approaches with Routing, Reliability Optimizations Yong Wang (Princeton University); Margaret Martonosi (Princeton University); Li-Shiuan Peh (Princeton University) MERLIN: A synergetic integration of MAC and Routing Protocol for Distributed Sensor Networks Antonio Ruzzelli (University College Dublin); Michael O'Grady (University College Dublin); Gregory O'Hare (University College Dublin); Richard Tynan (University College Dublin) -------------------------------------------------------------------- Session 9: Network Modeling and Analysis A Spatio-Temporal Model for Physical Carrier Sensing Wireless Ad-Hoc Networks Eric Wong (University of California, San Diego); Rene Cruz (University of California, San Diego) A Realistic Power Consumption Model for Wireless Sensor Network Devices Qin Wang (Harvard University); Mark Hempstead (Harvard University); Woodward Yang (Harvard University) The Analysis of a Game Theoretic MAC Protocol for Wireless Networks Hazer Inaltekin (Cornell University); Stephen Wicker (Cornell University) Optimizing Delay in Sequential Change Detection on Ad Hoc Wireless Sensor Networks Venkata K. Prasanthi M. (Indian Institute of Science, Bangalore); Anurag Kumar (Indian Institute of Science, Bangalore) -------------------------------------------------------------------- Session 10: Sensor Coverage Deployment Strategies for Differentiated Detection in Wireless Sensor Networks Jingbin Zhang (University of Virginia); Ting Yan (University of Virginia); Sang Son (University of Virginia) Sacrificing a Little Coverage Can Substantially Increase Network Lifetime Limin Wang (Michigan State University); Sandeep Kulkarni (Michigan State University) Optimal Worst-Case Coverage of Directional Field-of-View Sensor Networks Jacob Adriaens (University of Wisconsin Madison); Seapahn Megerian (University of Wisconsin Madison); Miodrag Potkonjak (University of California at Los Angeles) Mutual Exclusion in Wireless Sensor and Actor Networks Ramanuja Vedantham (Georgia Institute of Technology); Zhenyun Zhuang (Georgia Institute of Technology); Raghupathy Sivakumar (Georgia Institute of Technology) -------------------------------------------------------------------- 4:00 PM - 5:30 PM (3 Parallel Tracks - Sessions 11, 12, 13) Session 11: Localization and Ranging I Localization in Sensor Networks using Consistency-based Statistical Error Models Jessica Feng (University of California, Los Angeles); Lewis Girod (University of California, Los Angeles); Miodrag Potkonjak (University of California at Los Angeles) A Practical Approach to Landmark Deployment for Indoor Localization Yingying Chen (Rutgers University); John-Austen Francisco (Rutgers University); Wade Trappe (Rutgers University); Richard Martin (Rutgers University) Angle of Arrival Localization for Wireless Sensor Networks Rong Peng (North Carolina State University); Mihail Sichitiu (North Carolina State University) Robot-Assisted Localization Techniques for Wireless Image Sensor Networks Huang Lee (Stanford University); Hattie Dong (Stanford University); Hamid Aghajan (Stanford University) -------------------------------------------------------------------- Session 12: Medium Access Multichannel MAC Protocols for Wireless Networks Ritesh Maheshwari (Stony Brook University); Himanshu Gupta (Stony Brook University); Samir Das (Stony Brook University) RT-Link: A Time-Synchronized Link Protocol for Energy Constrained Multi-Hop Wireless Networks Anthony Rowe (Carnegie Mellon University); Rahul Mangharam (Carnegie Mellon University); Ragunathan Rajkumar (Carnegie Mellon University) Understanding the Gap between the IEEE 802.11 Protocol Performance and the Theoretical Limits Mathilde Durvy (EPFL); Patrick Thiran (EPFL) Throughput-Oriented MAC for Mobile Ad Hoc Networks with Variable Packet Sizes Ossama Younis (University of Arizona); Fan Wang (University of Arizona); Marwan Krunz (University of Arizona) -------------------------------------------------------------------- Session 13: Theoretical Foundations Topology Control to Simultaneously Achieve Near-Optimal Node Degree and Low Path Stretch in Ad Hoc Networks Ece Gelal (University of California, Riverside); Gentian Jakllari (University of California, Riverside); Srikanth Krishnamurthy (University of California, Riverside); Neal E. Young (University of California, Riverside) Distributed Linear Parameter Estimation in Sensor Networks Based on Laplacian Dynamics Consensus Algorithm Arindam Kumar Das (University of Washington); Mehran Mesbahi (University of Washington) On the Information Lifetime and the Localization Cost in Sensor Networks with Random Topologies Cedric Westphal (Nokia Research Center) Cooperation Enforcement in Autonomous MANETs under Noise and Imperfect Observation Zhu Ji (University of Maryland, College Park); Wei Yu (University of Maryland, College Park); K.J. Ray Liu (University of Maryland, College Park) *********************************** END OF WEDNESDAY PROGRAM *********** THURSDAY, September 28, 2006 8:30 AM - 10:00 AM: Panel/Invited Session: TBA 10:00 AM - 11:00 AM: Posters/Demos 11:00 AM - 12:30 PM: (2 Parallel Tracks - Sessions 14, 15) Session 14: Topology Control Joint Range and Load Considerations for Topology Control in Wireless Ad Hoc Networks Sajjad Zarifzadeh (University of Tehran); Amir Nayyeri (University of Tehran) Distributed Fair Transmit Power Adjustment for Vehicular Ad Hoc Networks Marc Torrent-Moreno (University of Karlsruhe); Paolo Santi (CNR); Hannes Hartenstein (University of Karlsruhe) Low-Complexity Beamforming Techniques for Wireless Multihop Networks Robert Vilzmann (Technische Universit t Mnchen); Jrg Widmer (DoCoMo Euro-Labs); Imad Aad (DoCoMo Euro-Labs); Christian Hartmann (Technische Universit t Mnchen) Energy Efficient Transmission Scheme for Data-Gathering in Mobile Sensor Networks Chao Wang (University of Wisconsin, Madison); Parmesh Ramanathan (University of Wisconsin at Madison) Session 15: Energy Management LEARN: Localized Energy Aware Restricted Neighborhood Routing for Ad Hoc Networks Xiang-Yang Li (Illinois Institute of Technology); Yu Wang (Univeristy of North Carolina at Charlotte); Wen-Zhan Song (Washington State University, Vancouver); Weizhao Wang (Illinois Institute of Technology) A New Method for Distributing Power Usage Across a Sensor Network Patrick Vincent (Naval Postgraduate School); Murali Tummala (Naval Postgraduate School); John McEachen (Naval Postgraduate School) Energy Efficient Network Reconfiguration for Mostly-Off Sensor Networks Yuan Li (University of Southern California); Wei Ye (University of Southern California); John Heidemann (University of Southern California) 2:00 PM - 3:30 PM: (2 Parallel Tracks - Sessions 16, 17) Session 16: Localization and Ranging II Distance Matrix Reconstruction from Incomplete Distance Information for Sensor Network Localization Petros Drineas (RPI); Asif Javed (Rensselaer Polytechnic Institute); Malik Magdon-Ismail (RPI); Gopal Pandurangan (Purdue University); Reino Virrankoski (Helsinki University of Technology) ; Andreas Savvides (Yale University) MERIT: MEsh of RF sensors for Indoor Tracking Yui-Wah Lee (Bell Labs, Lucent Technologies); Erich Stuntebeck (Georgia Institute of Technology); Scott Miller (Bell Labs, Lucent Technologies) Reducing the Computational Cost of Bayesian Indoor Positioning Systems Konstantin Kleisouris (Rutgers University); Richard Martin (Rutgers University) Sensor-Enhanced Mobility Prediction for Energy-Efficient Localization Chuang-wen You (National Taiwan University); Yi-Chao Chen (National Taiwan University); Hao-hua Chu (National Taiwan University); Polly Huang (National Taiwan University); Ji-Rung Chiang (National Taiwan University); Seng-Yong Lau (National Taiwan University) Session 17: Fault Tolerance Memento: A Health Monitoring System for Wireless Sensor Networks Stanislav Rost (Massachusetts Institute of Technology); Hari Balakrishnan (Massachusetts Institute of Technology) Cross-Layer Analysis of Error Control in Wireless Sensor Networks Mehmet Vuran (Georgia Institute of Technology); Ian Akyildiz (Georgia Institute of Technology) RideSharing: Fault Tolerant Aggregation in Sensor Networks Using Corrective Actions Sameh Gobriel (University of Pittsburgh); Sherif Khattab (University of Pittsburgh); Daniel Mosse (University of Pittsburgh); Jose Brustoloni (University of Pittsburgh); Rami Melhem (University of Pittsburgh) ======================================================================== CONFERENCE ORGANIZING COMMITEE ------------------------------ GENERAL CHAIR: Krishna Sivalingam, University of Maryland Baltimore County, krishna@umbc.edu TECHNICAL PROGRAM CO-CHAIRS: Mark Yarvis, Intel Corporation, mark.d.yarvis@intel.com Michele Zorzi, Universita' degli Studi di Padova, zorzi@dei.unipd.it POSTERS/DEMOS CO-CHAIRS: Stefano Basagni, Northeastern University, basagni@ece.neu.edu Cedric Westphal, Nokia, Cedric.Westphal@nokia.com PANELS CO-CHAIRS: Ian Chakeres, Boeing, ian.chakeres@gmail.com Lily Yang, Intel, lily.l.yang@intel.com WORKSHOPS CHAIR: Tom Hou, Virginia Tech, thou@vt.edu STUDENT TRAVEL GRANTS CHAIR: Wenye Wang, NCSU, wwang@eos.ncsu.edu PUBLICITY CHAIR: Wendi Heinzelman, University of Rochester, wheinzel@ece.rochester.edu EXHIBITS/SPONSORSHIPS CHAIR: Vishal Anand, SUNY Brockport, vanand@brockport.edu LOCAL ARRANGEMENTS CHAIR: Mohamed Eltoweissy, Virgina Tech, toweissy@vt.edu STANDING COMMITTEE: Fred Bauer (fred@fredbauer.com) [CHAIR] Harvey Freeman Sung-Ju Lee, HP Labs Prasant Mohapatra, University of California, Davis TECHNICAL PROGRAM COMMITTEE --------------------------- Abouzeid, Alhussein Rensselaer Polytechnic Institute Almeroth, Kevin University of California at Santa Barbara Banerjee, Sujata Hewlett-Packard Laboratories Banerjee, Suman University of Wisconsin Basagni, Stefano Northeastern University Belding-Royer, Elizabeth University of California at Santa Barbara Bianchi, Giuseppe University of Rome, Tor Vergata Boutaba, Raouf University of Waterloo Cao, Guohong Pennsylvania State University Cayirci, Erdal GeNeTLab Chandra, Surendar University of Notre Dame Chevillat, Pierre IBM Zurich Research Laboratory Choi, Sunghyun Seoul National Unversity Chuah, Chen-Nee University of California, Davis Das, Sajal University of Texas at Arlington Das, Samir SUNY at Stony Brook Ekici, Eylem Ohio State University ElBatt, Tamer Hughes Research Laboratories, LLC Ephremides, Anthony University of Maryland at College Park Giordano, Silvia University of Applied Science SUPSI, Lugano Hares, Susan NextHop Havinga, Paul University of Twente Helmy, Ahmed University of Southern California Iyer, Sridhar Indian Institute of Technology Jetcheva, Jorjeta Firetide, Inc. Jha, Sanjay University of New South Wales Kangude, Shantanu Texas Instruments, Inc. Kasera, Sneha University of Utah Ko, Young-Bae Ajou University Koodli, Rajeev Nokia Research Center Krishnamachari, Bhaskar University of Southern California Krishnamurthy, Lakshman Intel Corporation Langendoen, Koen Delft University of Technology Lee, Sung-Ju Hewlett-Packard Laboratories Li, Li Bell Labs, Lucent Technologies Martin, Richard Rutgers University Mohapatra, Prasant University of California, Davis Morabito, Giacomo University of Catania Nandagopal, Thyaga Bell Labs, Lucent Technologies Ning, Peng North Carolina State University Pagani, Elena University of Milano Papagiannaki, Konstantina Intel Corporation Petrioli, Chiara University of Rome, la Sapienza Popovski, Petar Aalborg University Qiu, Lili University of Texas at Austin Ramasubramanian, Srini Unviersity of Arizona Ramasubramanian, Venugopalan Cornell University Reisslein, Martin Arizona State University Rhee, Sokwoo Millennial Net Roemer, Kay Swiss Federal Institute of Technology, Zurich Santi, Paolo CNR (National Research Council), Italy Schurgers, Curt University of California at San Diego Shorey, Rajeev General Motors Research, Bangalore Singh, Harkirat Samsung Electronics Singh, Suresh Portland State University Srinivasan, Vikram National University of Singapore Stankovic, John University of Virginia Trappe, Wade Rutgers University Tseng, Yu-Chee National Chiao-Tung University Wang, Xudong Kiyon, Inc. Westphal, Cedric Nokia Research Center Widmer, Joerg DoCoMo Eurolabs Zhang, Junshan Arizona State University Zhang, Qian Hong Kong University of Science and Technology Zheng, Haitao University of California at Santa Barbara Znati, Taieb University of Pittsburgh -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jul 24 15:50:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G56Ri-0002iJ-RA; Mon, 24 Jul 2006 15:50:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G56RH-0001kE-VP; Mon, 24 Jul 2006 15:50:03 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G56RG-0007uH-A7; Mon, 24 Jul 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6OJo1p0006973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jul 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G56RF-0005HL-RM; Mon, 24 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 24 Jul 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-reg-tunnel-02.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Regional Registration Author(s) : E. Gustafsson, et al. Filename : draft-ietf-mip4-reg-tunnel-02.txt Pages : 34 Date : 2006-7-24 Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. This document describes a new kind of "regional registrations", i.e. registrations local to the visited domain. The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This document is an optional extension to the Mobile IPv4 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-reg-tunnel-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-mip4-reg-tunnel-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-mip4-reg-tunnel-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-24131305.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-reg-tunnel-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-reg-tunnel-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-24131305.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Tue Jul 25 16:00:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5T4a-0000CK-Jp; Tue, 25 Jul 2006 16:00:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5T4X-0000Aq-52; Tue, 25 Jul 2006 16:00:05 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5T4W-0002Ds-Pc; Tue, 25 Jul 2006 16:00:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6PK01p0006019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 20:00:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G5T4T-0003pz-O9; Tue, 25 Jul 2006 16:00:01 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Tue, 25 Jul 2006 16:00:01 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: Peter McCann , mip4@ietf.org, Henrik Levkowetz Subject: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org The Mobility for IPv4 (mip4) working group in the Internet Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. +++ Mobility for IPv4 (mip4) ======================== Current Status: Active Working Group Chair(s): Peter McCann Henrik Levkowetz Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mip4@ietf.org To Subscribe: mip4-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/mip4/index.html Description of Working Group: IP mobility support for IPv4 nodes (hosts and routers) is specified in RFC3344. RFC 3344 mobility allows a node to continue using its "permanent" home address as it moves around the Internet. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings.Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns such as optimization, security, extensions, AAA support, and deployment issues. MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 networks). The scope of the deployment is on a fairly large scale and accordingly, the MIP4 WG will focus on deployment issues and on addressing known deficiencies and shortcomings in the protocol that have come up as a result of deployment experience. Specifically, the working group will complete the work items to facilitate interactions with AAA environments, interactions with enterprise environments when MIPv4 is used therein, and updating existing protocol specifications in accordance with deployment needs and advancing those protocols that are on the standards track. Work expected to be done by the MIP4 WG as proposed by this charter is as follows: 1. MIPv4 has been a proposed standard for several years. It has been adopted by other standard development organizations and has been deployed commercially. One of the next steps for the WG is to advance the protocol to draft standard status. As part of advancing base Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised to reflect implementation experience 2. Work items that are pending from the previous Mobile IP WG, which will be completed by the MIP4 WG, are: - completion of the MIB for the revised base Mobile IP specification (2006bis) - regional registration draft. 3. The MIP4 WG will also complete the work on MIPv4 interactions in VPN scenarios. This work will involve identifying the requirements and a solution development for MIPv4 operation in the presence of IPsec VPNs. 4. Additionally, a proposal has been made for how MOBIKE could work together with MIPv4. This proposal does not describe any new protocol, but formulates a best current practice for deploying MOBIKE together with MIPv4. The working group will adopt and complete this document. 5. Some issues have been raised with respect to RFC3519. These will be identified and addressed as appropriate, through errata, revision of RFC 3519, and/or supplemental documents as needed. 6. It has been proposed that the FMIP protocol, which has been standardised for MIPv6 in the MIPSHOP working group, should also be published as an experimental protocol for MIPv4. A draft for this exists. The working group will take up and carry this work forward to publication 7. An extension to carry generic strings in the Registration Reply message has been proposed. The purpose is to supply supplemental human-readable information intended to the MN user. The working group will complete the specification and applicability statement of such an extension. 8. RADIUS attributes for MIP4. A set of RADIUS attributes has been proposed for MIPv4. The working group will first produce a requirements specification, describing how the work differs from the requirements in RFC 2977 and the functionality provided by RFC 4004 (the MIPv4 Diameter App). The reason why this first step is required is that RFC 3127 shows that full RFC 2977 functionality can't be provided by even a considerably extended RADIUS, so we need to match the requirements to what can be done within RADIUS. Provided the requirements work finds approval with ADs and RADEXT WG, the workgroup will complete the specification of MIPv4 RADIUS attributes, solicit feedback from the RADEXT WG, adjust, and submit this for publication. Note that the work may require extensions to the RADIUS attribute space which will be handled outside the MIP4 WG. 9. MIPv4 Extension for Configuration Options. Several drafts have proposed extensions to help improve configuration of MIPv4 clients. The latest proposal is for a general configuration option extension which could carry information such as e.g., DNS address and DHCP server address. The working group will take on and complete one proposal for a configuration option extension. 10. Dual-stack Support There have been several proposals for how to enable an IPv6 connection over a network that supports Mobile IPv4. A protocol enhancement to MIPv4 would allow for IPv6 support in a region where Mobile IPv4 has already been implemented and deployed. This would allow a dual stack mobile node to maintain IPv6 connectivity when using MIPv4. The solution would therefore be applicable only to networks that are not deploying Mobile IPv6. The working group will take on and complete one proposal for IPv6 over Mobile IPv4. This work is restricted to a small protocol extension similar to current Mobile IPv4 functionality. Support for advanced Mobile IPv6 functionality is strictly outside the scope. A problem statement covering both Mobile IPv4 and IPv6 dual-stack issues is expected to come out of MIP6 WG, and will not be developed in MIP4 WG. Goals and Milestones: Done AAA Keys for MIPv4 to IESG Done MIPv4 VPN interaction problem statement to IESG Done Low latency handover to experimental Done Experimental MIPv4 message and extensions draft to IESG Done Dynamic Home Agent assignment protocol solution to IESG Done Revised MIPv4 Challenge/Response (3012bis) to IESG Done Regional registration document to IESG Aug 2006 MIPv4 Mobike interaction (BCP) to the IESG Aug 2006 MIPv4 VPN interaction (BCP) to the IESG Aug 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment Aug 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG Aug 2006 Revised MIPv4 specification to IESG for Draft Std. Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the IESG Sep 2006 FMIPv4 (Experimental) to the IESG Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG Nov 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jul 26 07:11:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5hIy-0002Vq-8a; Wed, 26 Jul 2006 07:11:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5hIw-0002R1-JG; Wed, 26 Jul 2006 07:11:54 -0400 Received: from us-gw.atrica.com ([63.160.45.2] helo=usmail.atrica.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5hIv-0005rM-UV; Wed, 26 Jul 2006 07:11:54 -0400 Received: from mail pickup service by usmail.atrica.com with Microsoft SMTPSVC; Wed, 26 Jul 2006 04:11:53 -0700 Received: from resolution.atrica.com ([63.160.45.67]) by usmail.atrica.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 13:02:24 -0700 Received: from usmailrelay0.atrica.com (unknown [63.160.45.96]) by resolution.atrica.com (Postfix) with ESMTP id 786E12C1AE for ; Tue, 25 Jul 2006 12:36:44 -0700 (PDT) Received: from megatron.ietf.org (stiedprmman1.ietf.org [156.154.16.145]) by usmailrelay0.atrica.com (Symantec Mail Security) with ESMTP id 0C37DFEB for ; Tue, 25 Jul 2006 13:02:23 -0700 (PDT) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5T4b-0000D5-RW; Tue, 25 Jul 2006 16:00:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5T4X-0000Aq-52; Tue, 25 Jul 2006 16:00:05 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5T4W-0002Ds-Pc; Tue, 25 Jul 2006 16:00:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6PK01p0006019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jul 2006 20:00:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G5T4T-0003pz-O9; Tue, 25 Jul 2006 16:00:01 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Tue, 25 Jul 2006 16:00:01 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Brightmail-Tracker: AAAAAA== X-OriginalArrivalTime: 25 Jul 2006 20:02:24.0670 (UTC) FILETIME=[3F2B03E0:01C6B025] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: Peter McCann , mip4@ietf.org, Henrik Levkowetz Subject: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) X-BeenThere: mip4@ietf.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org The Mobility for IPv4 (mip4) working group in the Internet Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. +++ Mobility for IPv4 (mip4) ======================== Current Status: Active Working Group Chair(s): Peter McCann Henrik Levkowetz Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mip4@ietf.org To Subscribe: mip4-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/mip4/index.html Description of Working Group: IP mobility support for IPv4 nodes (hosts and routers) is specified in RFC3344. RFC 3344 mobility allows a node to continue using its "permanent" home address as it moves around the Internet. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings.Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns such as optimization, security, extensions, AAA support, and deployment issues. MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 networks). The scope of the deployment is on a fairly large scale and accordingly, the MIP4 WG will focus on deployment issues and on addressing known deficiencies and shortcomings in the protocol that have come up as a result of deployment experience. Specifically, the working group will complete the work items to facilitate interactions with AAA environments, interactions with enterprise environments when MIPv4 is used therein, and updating existing protocol specifications in accordance with deployment needs and advancing those protocols that are on the standards track. Work expected to be done by the MIP4 WG as proposed by this charter is as follows: 1. MIPv4 has been a proposed standard for several years. It has been adopted by other standard development organizations and has been deployed commercially. One of the next steps for the WG is to advance the protocol to draft standard status. As part of advancing base Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised to reflect implementation experience 2. Work items that are pending from the previous Mobile IP WG, which will be completed by the MIP4 WG, are: - completion of the MIB for the revised base Mobile IP specification (2006bis) - regional registration draft. 3. The MIP4 WG will also complete the work on MIPv4 interactions in VPN scenarios. This work will involve identifying the requirements and a solution development for MIPv4 operation in the presence of IPsec VPNs. 4. Additionally, a proposal has been made for how MOBIKE could work together with MIPv4. This proposal does not describe any new protocol, but formulates a best current practice for deploying MOBIKE together with MIPv4. The working group will adopt and complete this document. 5. Some issues have been raised with respect to RFC3519. These will be identified and addressed as appropriate, through errata, revision of RFC 3519, and/or supplemental documents as needed. 6. It has been proposed that the FMIP protocol, which has been standardised for MIPv6 in the MIPSHOP working group, should also be published as an experimental protocol for MIPv4. A draft for this exists. The working group will take up and carry this work forward to publication 7. An extension to carry generic strings in the Registration Reply message has been proposed. The purpose is to supply supplemental human-readable information intended to the MN user. The working group will complete the specification and applicability statement of such an extension. 8. RADIUS attributes for MIP4. A set of RADIUS attributes has been proposed for MIPv4. The working group will first produce a requirements specification, describing how the work differs from the requirements in RFC 2977 and the functionality provided by RFC 4004 (the MIPv4 Diameter App). The reason why this first step is required is that RFC 3127 shows that full RFC 2977 functionality can't be provided by even a considerably extended RADIUS, so we need to match the requirements to what can be done within RADIUS. Provided the requirements work finds approval with ADs and RADEXT WG, the workgroup will complete the specification of MIPv4 RADIUS attributes, solicit feedback from the RADEXT WG, adjust, and submit this for publication. Note that the work may require extensions to the RADIUS attribute space which will be handled outside the MIP4 WG. 9. MIPv4 Extension for Configuration Options. Several drafts have proposed extensions to help improve configuration of MIPv4 clients. The latest proposal is for a general configuration option extension which could carry information such as e.g., DNS address and DHCP server address. The working group will take on and complete one proposal for a configuration option extension. 10. Dual-stack Support There have been several proposals for how to enable an IPv6 connection over a network that supports Mobile IPv4. A protocol enhancement to MIPv4 would allow for IPv6 support in a region where Mobile IPv4 has already been implemented and deployed. This would allow a dual stack mobile node to maintain IPv6 connectivity when using MIPv4. The solution would therefore be applicable only to networks that are not deploying Mobile IPv6. The working group will take on and complete one proposal for IPv6 over Mobile IPv4. This work is restricted to a small protocol extension similar to current Mobile IPv4 functionality. Support for advanced Mobile IPv6 functionality is strictly outside the scope. A problem statement covering both Mobile IPv4 and IPv6 dual-stack issues is expected to come out of MIP6 WG, and will not be developed in MIP4 WG. Goals and Milestones: Done AAA Keys for MIPv4 to IESG Done MIPv4 VPN interaction problem statement to IESG Done Low latency handover to experimental Done Experimental MIPv4 message and extensions draft to IESG Done Dynamic Home Agent assignment protocol solution to IESG Done Revised MIPv4 Challenge/Response (3012bis) to IESG Done Regional registration document to IESG Aug 2006 MIPv4 Mobike interaction (BCP) to the IESG Aug 2006 MIPv4 VPN interaction (BCP) to the IESG Aug 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment Aug 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG Aug 2006 Revised MIPv4 specification to IESG for Draft Std. Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the IESG Sep 2006 FMIPv4 (Experimental) to the IESG Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG Nov 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jul 26 09:24:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jN7-0001kq-QD; Wed, 26 Jul 2006 09:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5J01-0003Xg-M3; Tue, 25 Jul 2006 05:14:45 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Izz-0008R4-8Z; Tue, 25 Jul 2006 05:14:45 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Jul 2006 11:13:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Jul 2006 11:13:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tentative Agenda of BWAN (Broadband wireless for ubiquitous networking 2006) in Italy and the registration now open Thread-Index: AcaZOqizZtBmnYA2SI6JedWrRr3BmwAAAwaQAAAQFIAAAAtgsAAACGVQACBU9SA= From: "MATHOORASING Dean RD-DSPI-ISS" To: X-OriginalArrivalTime: 25 Jul 2006 09:13:29.0952 (UTC) FILETIME=[98448600:01C6AFCA] X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-Mailman-Approved-At: Wed, 26 Jul 2006 09:24:20 -0400 Cc: Subject: [Mip4] Tentative Agenda of BWAN (Broadband wireless for ubiquitous networking 2006) in Italy and the registration now open X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1080930332==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1080930332== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AFCA.9718F055" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AFCA.9718F055 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Dear All, >=20 The tentative agenda is available on BWAN website! The BWAN workshop is based on Broadband wireless access for ubiquitous networking will be scheduled on the 20th of september 2006 in Italy > The program include Invited speakers, a panel discussion with > industry/telcos leaders talking about 'trends and strategies of > Ubiquitous networking for 2010-2015' and the technical papers. The > registration is now open on the conference BWAN web site > www.bwan.org. Please forward this message to whom it may concern. >=20 > Regards=20 > BWAN Commitee > =20 > .=20 ------_=_NextPart_001_01C6AFCA.9718F055 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tentative Agenda of BWAN (Broadband wireless for ubiquitous = networking 2006) in Italy and the registration now open

Dear All,

The tentative agenda is available on BWAN website!
The BWAN workshop is = based on Broadband wireless access for ubiquitous networking will = be scheduled on the 20th of september 2006 in = Italy

The program include  Invited = speakers, a panel discussion with industry/telcos leaders  talking = about 'trends and strategies of Ubiquitous networking for = 2010-2015'  and the technical papers. The registration is now = open   on the conference BWAN web site www.bwan.org. Please forward this message to whom it may  = concern.

Regards
BWAN Commitee
 
.

------_=_NextPart_001_01C6AFCA.9718F055-- --===============1080930332== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1080930332==-- From mip4-bounces@ietf.org Wed Jul 26 11:44:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5lZB-00008j-Gi; Wed, 26 Jul 2006 11:44:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5lZA-00008Z-Du for mip4@ietf.org; Wed, 26 Jul 2006 11:44:56 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5lZ9-00055U-UM for mip4@ietf.org; Wed, 26 Jul 2006 11:44:56 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E32D889851; Wed, 26 Jul 2006 18:44:53 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 672F48984E; Wed, 26 Jul 2006 18:44:53 +0300 (EEST) Message-ID: <44C78DF3.30405@piuha.net> Date: Wed, 26 Jul 2006 18:44:51 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Eva_Fogelstr=F6m_=28KI/EAB=29=22?= 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: 944ecb6e61f753561f559a497458fb4f Cc: mip4@ietf.org Subject: [Mip4] AD review of draft-ietf-mip4-reg-tunnel-02.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Eva and others, I have performed my AD review on this draft. Overall, its ready for publication as Experimental. However, there are two technical issues and a few other nits that I would like to discuss before submission to the IESG. > A domain that supports regional registrations SHOULD also be > backwards compatible. > > If a FA only advertises an all-ones care-of address (i.e. for dynamic > GFA assignment), it will not be backwards compatible with [RFC3344], > since the MNs and HAs will also be required to support the regional > registration extensions defined in this document. This seems to suggest a model where those who employ this mechanism may end up preventing regular Mobile IP clients from getting service. I do not see why we would have to make this so. I wonder if it would be better to require both a regular address and gateway address (possibly all-ones) to be advertised? You could still require that mobile nodes compliant to reg-tunnel use dynamic assignment. > When a MN moves to a new domain (determined by comparing its NAI with > the FA-NAI included in received Agent Advertisements), it can opt to > use Regional Registrations. > If the MN receives an Agent Advertisement with the care-of address > field indicating the GFA set to all-ones, and if the MN determines > that it is within the same visited domain as when it did its last > home registration, it MAY send a Regional Registration Request to its > current GFA. Otherwise, it MUST send a Registration Request to its > HA as described in Section 7.1. > Upon receipt of an Agent Advertisement message with the 'I' flag set > and a FA-NAI extension, the MN compares the domain part of the FA NAI > with the domain part of its own NAI, to determine whether it is in > its home domain or in a visited domain. If the NAIs do not match, > the MN MUST assume it is in a foreign domain. Otherwise, if the MN > determines that it is in its home domain, it acts as defined in > [RFC3344]. This process produces two bits as output: 1) Did we move? 2) Are we in the home domain? I see a lot of value in determining 1. But is there a value in determining 2? Does this imply that you can not use regional registrations within the home domain? Do we want or need to prevent that? > Registration denied by the GFA: > > +---------------------+-------+---------------------+ > | Error Name | Value | Section of Document | > +---------------------+-------+---------------------+ > | REPLAY_PROT_UNAVAIL | TBD | Section 5.3 | > | ZERO_COA_NOT_SUPP | TBD | Section 7.3 | > +---------------------+-------+---------------------+ > > Registration denied by the HA (for dynamic GFA assignment): > > +---------------------+-------+---------------------+ > | Error Name | Value | Section of Document | > +---------------------+-------+---------------------+ > | ZERO_CAREOF_ADDRESS | TBD | Section 7.4 | > | ZERO_COA_NOT_SUPP | TBD | Section 7.4 | > +---------------------+-------+---------------------+ ZERO_COA_NOT_SUPP appears twice, but presumably this is the same value? If yes, please clarify so that neither IANA or readers will get confused. > If the > 'I' flag is set, and there are multiple care-of addresses, the first > care-of address is the local FA, and the last care-of address is the > GFA. Hmm... this seems to specify only the role of the first and the last address. What about the rest? Nits: > - The document seems to lack the recommended RFC 2119 boilerplate, even if > it appears to use RFC 2119 keywords -- however, there's a paragraph with a > matching beginning. Boilerplate error? > > Warning from idnits. > - Unused Reference: 'RFC2486' is defined on line 1345, but not referenced > Another idnits warning. Also, if you want to refer to RFC 2486, it has been obsoleted by RFC 4282. So use 4282 if you need it. The document talks about NAIs, so I would assume that a reference is needed. > to be protected by a MN-FA Authenticaion extension. Typo. --Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jul 26 13:59:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5nf9-0002P9-O4; Wed, 26 Jul 2006 13:59:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5nf7-0002P3-NG for mip4@ietf.org; Wed, 26 Jul 2006 13:59:13 -0400 Received: from dsl3.halflab.com ([64.81.61.172] helo=outpost.thehouse.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5nf7-00080Y-0Y for mip4@ietf.org; Wed, 26 Jul 2006 13:59:13 -0400 Received: from localhost ([127.0.0.1] ident=mccap) by outpost.thehouse.org with esmtp (Exim 4.50) id 1G5nf5-0000Pv-Ta; Wed, 26 Jul 2006 10:59:12 -0700 Message-ID: <44C7AD6F.10408@petoni.org> Date: Wed, 26 Jul 2006 12:59:11 -0500 From: Pete McCann User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: mip4@ietf.org Subject: Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org With the new charter item number 10, we are ready to start work on a dual-stack Mobile IPv4 solution. This note is to query the working group to see whether we have consensus on adopting http://www.ietf.org/internet-drafts/draft-tsirtsis-v4v6-mipv4-01.txt as that working group document. Please send responses to the list, stating whether you support the adoption of this document. -Pete IESG Secretary wrote: > The Mobility for IPv4 (mip4) working group in the Internet Area of the > IETF has been rechartered. For additional information, please contact > the Area Directors or the working group Chairs. > > +++ > > Mobility for IPv4 (mip4) > ======================== > > Current Status: Active Working Group > > Chair(s): > Peter McCann > Henrik Levkowetz > > Internet Area Director(s): > Jari Arkko > Mark Townsley > > Internet Area Advisor: > Jari Arkko > > Mailing Lists: > General Discussion: mip4@ietf.org > To Subscribe: mip4-request@ietf.org > In Body: subscribe > Archive: http://www.ietf.org/mail-archive/web/mip4/index.html > > Description of Working Group: > > IP mobility support for IPv4 nodes (hosts and routers) is specified in > RFC3344. RFC 3344 mobility allows a node to continue using its > "permanent" home address as it moves around the Internet. The Mobile > IP protocols support transparency above the IP layer, including > maintenance of active TCP connections and UDP port bindings.Besides > the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal > with concerns such as optimization, security, extensions, AAA support, > and deployment issues. > > MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 > networks). The scope of the deployment is on a fairly large scale and > accordingly, the MIP4 WG will focus on deployment issues and on > addressing known deficiencies and shortcomings in the protocol that > have come up as a result of deployment experience. Specifically, the > working group will complete the work items to facilitate interactions > with AAA environments, interactions with enterprise environments when > MIPv4 is used therein, and updating existing protocol specifications > in accordance with deployment needs and advancing those protocols that > are on the standards track. > > Work expected to be done by the MIP4 WG as proposed by this charter is > as follows: > > 1. MIPv4 has been a proposed standard for several years. It has been > adopted by other standard development organizations and has been > deployed commercially. One of the next steps for the WG is to advance > the protocol to draft standard status. As part of advancing base > Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised to > reflect implementation experience > > 2. Work items that are pending from the previous Mobile IP WG, which > will be completed by the MIP4 WG, are: > > - completion of the MIB for the revised base Mobile IP specification > (2006bis) > > - regional registration draft. > > 3. The MIP4 WG will also complete the work on MIPv4 interactions in > VPN scenarios. This work will involve identifying the requirements and > a solution development for MIPv4 operation in the presence of IPsec > VPNs. > > 4. Additionally, a proposal has been made for how MOBIKE could work > together with MIPv4. This proposal does not describe any new protocol, > but formulates a best current practice for deploying MOBIKE together > with MIPv4. The working group will adopt and complete this document. > > 5. Some issues have been raised with respect to RFC3519. These will be > identified and addressed as appropriate, through errata, revision of > RFC 3519, and/or supplemental documents as needed. > > 6. It has been proposed that the FMIP protocol, which has been > standardised for MIPv6 in the MIPSHOP working group, should also be > published as an experimental protocol for MIPv4. A draft for this > exists. The working group will take up and carry this work forward to > publication > > 7. An extension to carry generic strings in the Registration Reply > message has been proposed. The purpose is to supply supplemental > human-readable information intended to the MN user. The working group > will complete the specification and applicability statement of such an > extension. > > 8. RADIUS attributes for MIP4. A set of RADIUS attributes has been > proposed for MIPv4. > > The working group will first produce a requirements specification, > describing how the work differs from the requirements in RFC 2977 and > the functionality provided by RFC 4004 (the MIPv4 Diameter App). The > reason why this first step is required is that RFC 3127 shows that > full RFC 2977 functionality can't be provided by even a considerably > extended RADIUS, so we need to match the requirements to what can be > done within RADIUS. > > Provided the requirements work finds approval with ADs and RADEXT WG, > the workgroup will complete the specification of MIPv4 RADIUS > attributes, solicit feedback from the RADEXT WG, adjust, and submit > this for publication. Note that the work may require extensions to the > RADIUS attribute space which will be handled outside the MIP4 WG. > > 9. MIPv4 Extension for Configuration Options. > > Several drafts have proposed extensions to help improve configuration > of MIPv4 clients. The latest proposal is for a general configuration > option extension which could carry information such as e.g., DNS > address and DHCP server address. The working group will take on and > complete one proposal for a configuration option extension. > > 10. Dual-stack Support > > There have been several proposals for how to enable an IPv6 connection > over a network that supports Mobile IPv4. A protocol enhancement to > MIPv4 would allow for IPv6 support in a region where Mobile IPv4 has > already been implemented and deployed. This would allow a dual stack > mobile node to maintain IPv6 connectivity when using MIPv4. The > solution would therefore be applicable only to networks that are > not deploying Mobile IPv6. > > The working group will take on and complete one proposal for IPv6 over > Mobile IPv4. This work is restricted to a small protocol extension > similar to current Mobile IPv4 functionality. Support for advanced > Mobile IPv6 functionality is strictly outside the scope. > > A problem statement covering both Mobile IPv4 and IPv6 dual-stack > issues is expected to come out of MIP6 WG, and will not be developed > in MIP4 WG. > > Goals and Milestones: > > Done AAA Keys for MIPv4 to IESG > Done MIPv4 VPN interaction problem statement to IESG > Done Low latency handover to experimental > Done Experimental MIPv4 message and extensions draft to IESG > Done Dynamic Home Agent assignment protocol solution to IESG > Done Revised MIPv4 Challenge/Response (3012bis) to IESG > Done Regional registration document to IESG > Aug 2006 MIPv4 Mobike interaction (BCP) to the IESG > Aug 2006 MIPv4 VPN interaction (BCP) to the IESG > Aug 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment > Aug 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG > Aug 2006 Revised MIPv4 specification to IESG for Draft Std. > Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the IESG > Sep 2006 FMIPv4 (Experimental) to the IESG > Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG > Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG > Nov 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG > Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG > Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jul 26 23:22:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wSE-0005zD-Fk; Wed, 26 Jul 2006 23:22:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5wSC-0005z7-JH for mip4@ietf.org; Wed, 26 Jul 2006 23:22:28 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5wSB-0004ZH-8P for mip4@ietf.org; Wed, 26 Jul 2006 23:22:28 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 26 Jul 2006 20:22:28 -0700 X-IronPort-AV: i="4.07,186,1151910000"; d="scan'208"; a="308334400:sNHT26013716" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6R3MQbH012339; Wed, 26 Jul 2006 20:22:26 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6R3MOHS007006; Wed, 26 Jul 2006 20:22:26 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 20:22:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) Date: Wed, 26 Jul 2006 20:22:21 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52023B1EC6@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) Thread-Index: Acaw3UiQaaXqHFFPSR6tOTddTaJFXgATh60A From: "Kent Leung \(kleung\)" To: "Pete McCann" , X-OriginalArrivalTime: 27 Jul 2006 03:22:23.0788 (UTC) FILETIME=[E0AE7EC0:01C6B12B] DKIM-Signature: a=rsa-sha1; q=dns; l=868; t=1153970546; x=1154834546; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=20WG=20Action=3A=20RECHARTER=3A=20Mobility=20for=20IPv4=2 0(mip4); X=v=3Dcisco.com=3B=20h=3DCp0J6Hg4vWH12v3ea6skoxtNc5Q=3D; b=dQgRDnr07qesD0jucIpEImZkI1kiKAyerT60JoluoPEz/nWsN9GS0olkJ0h4Z3mujQOF4k5+ yQDJlEMZTXBDvjsmGR/x9GDI5V4Ns+5PwVB99P+Vu/lJKT2ZHbY1nxDY; Authentication-Results: sj-dkim-6.cisco.com; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Pete. I support this draft as WG document. May want to reference work on this topic in this older draft, draft-mccann-mobileip-ipv6mipv4-03.txt? Kent =20 > -----Original Message----- > From: Pete McCann [mailto:mccap@petoni.org]=20 > Sent: Wednesday, July 26, 2006 10:59 AM > To: mip4@ietf.org > Cc: Henrik Levkowetz > Subject: Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) >=20 > With the new charter item number 10, we are ready to start=20 > work on a dual-stack Mobile IPv4 solution. This note is to=20 > query the working group to see whether we have consensus on adopting >=20 > http://www.ietf.org/internet-drafts/draft-tsirtsis-v4v6-mipv4-01.txt >=20 > as that working group document. Please send responses to the=20 > list, stating whether you support the adoption of this document. >=20 > -Pete >=20 > =20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jul 27 09:10:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65dB-0005vF-Sz; Thu, 27 Jul 2006 09:10:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5luR-00060G-K8 for mip4@ietf.org; Wed, 26 Jul 2006 12:06:55 -0400 Received: from smtp107.biz.mail.mud.yahoo.com ([68.142.200.255]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5luP-0006zi-PT for mip4@ietf.org; Wed, 26 Jul 2006 12:06:55 -0400 Received: (qmail 73739 invoked from network); 26 Jul 2006 16:06:53 -0000 Received: from unknown (HELO YEOBS) (boonsain.yeo@sensimesh.com@218.186.174.131 with login) by smtp107.biz.mail.mud.yahoo.com with SMTP; 26 Jul 2006 16:06:52 -0000 Message-ID: <03cc01c6b0cd$7f94a4b0$6901a8c0@Wavex.com> From: "Boon Sain Yeo" To: , , , , , , , , , , , , , , , , , , , , , , , , , , , Date: Thu, 27 Jul 2006 00:06:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.5 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b X-Mailman-Approved-At: Thu, 27 Jul 2006 09:10:24 -0400 Cc: Subject: [Mip4] CFP - ISWPC 2007, San Juan, Pureto Rico X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org (Apologies if you receive multiple copies of this message) ---------------------------------------------------------------------- International Symposium on Wireless Pervasive Computing 2007 (ISWPC 2007) 5-7 February 2007, San Juan, Puerto Rico, USA http://www.iswpc.org/2007/ Technically Sponsored By: IEEE Communications Society and IEEE Vehicular Technology Society Hosted By: University of Puerto Rico at Mayaguez *** Submission Deadline -- August 20, 2006 **** ---------------------------------------------------------------------- SCOPE Wireless pervasive computing is a rapidly growing area that has attracted significant attention due to its potential impact on the quality of lifestyles of individuals. To enable wireless pervasive computing, it is necessary to integrate technologies from the fields of communications, signal processing, distributed computing, and numerous other fields. The aim of this symposium is to provide a platform for researchers in the area of wireless pervasive computing and related areas to showcase their results, launch new ideas, as well as to interact with colleagues from these areas. The scope of the symposium covers all enabling technologies of wireless pervasive computing. This includes a huge variety of topics ranging from wireless communications and networking to services and applications of pervasive computing. A series of panel and tutorials will also seek to inform and invoke interaction among researchers which are interested in this area. ---------------------------------------------------------------------- TOPICS OF INTEREST (INCLUDE BUT ARE NOT LIMITED TO THE FOLLOWING) - Ad hoc networks - Air interfaces (e.g. CDMA, OFDM, TDMA) - Bluetooth technologies - Coding and modulation techniques - Cognitive radio - Cooperative communications technologies - Cross-layer design - Detection and estimation - Diversity techniques & equalization - Dynamic spectrum management - Healthcare applications - Hybrid wireless networks - Interference avoidance - Interoperation of WLAN and other wireless systems - Localization and tracking techniques - Location management techniques Middleware - MIMO systems - Multimedia systems - Multirate and multicarrier communications - Multi-user Detection - PCS, GPRS, EDGE, 3GPP, UMTS, GSM and B3G systems - Power control Programmable radio - Propagation and channel characterization - QoS Support in wireless systems - Resource management and interference management - RF systems Security applications - Signal processing - Signal separation and interference rejection - Speech and video processing - Switching and routing techniques - UWB - Wearable devices - WiMAX - Wireless access techniques - Wireless multicasting - Wireless multimedia - Wireless network architecture - Wireless security - Wireless sensor networks - Wireless systems design - WLANs and WPANs ---------------------------------------------------------------------- PAPER SUBMISSION GUIDELINES Acceptance will be based on an extended abstract of about 1500 words (two pages in the standard IEEE conference format). The extended abstract should include diagrams, initial results, and details required for the reviewers to assess the contribution of your work. A short summary of approximately 150 words is also required at the time of submission of the extended abstract. Extended abstracts must be submitted electronically by August 20, 2006 , via EDAS (http://edas.info). Proceedings of the conference will be available on IEEE Xplore after the event. ---------------------------------------------------------------------- PANEL SESSIONS & TUTORIALS Proposals for Tutorial and Panel Sessions are also being solicited. Tutorials (half-day or full-day sessions) are intended to provide in-depth learning on a specific topic of interest to the participants. Panel sessions are 60 minutes long. They present leaders in a particular area discussing a topic of interest within the scope of the symposium. Proposals for Tutorials and Panel sessions should consist of 1000 words summary, a 150 word abstract, and a cover page listing the details of the author(s). For further details, please contact either the Tutorial Chair, Prof. Xiaoyan Hong (hxy@cs.ua.edu), or Panel Chair, Prof. Wilson Rivera (wrivera@ece.uprm.edu). ---------------------------------------------------------------------- IMPORTANT DATES Submission of Papers, proposals for tutorials and panel sessions: => August 20, 2006 Notification of Acceptance: => October 1, 2006 Submission of camera-ready versions of accepted papers: => November 18, 2006 ---------------------------------------------------------------------- http://www.iswpc.org/2007/ ---------------------------------------------------------------------- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jul 27 09:47:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66Cn-0006FS-92; Thu, 27 Jul 2006 09:47:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66Cm-00069z-DY for mip4@ietf.org; Thu, 27 Jul 2006 09:47:12 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G66Cl-0002sn-1H for mip4@ietf.org; Thu, 27 Jul 2006 09:47:12 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6RDl852012585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2006 06:47:09 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6RDl4mx026084; Thu, 27 Jul 2006 06:47:05 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 06:47:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) Date: Thu, 27 Jul 2006 06:47:03 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A0CC5A4@NAEX14.na.qualcomm.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC52023B1EC6@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) Thread-Index: Acaw3UiQaaXqHFFPSR6tOTddTaJFXgATh60AABXCEUA= From: "Tsirtsis, George" To: "Kent Leung \(kleung\)" , "Pete McCann" , X-OriginalArrivalTime: 27 Jul 2006 13:47:04.0602 (UTC) FILETIME=[24FCD7A0:01C6B183] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org I am aware of this draft but I have not read it for long time. I will go over it to see if there is anything that is not covered by the new draft. Some acknowledgments are indeed in order while I am also open to co-authoring if any of the authors of the mccann draft are still interested in working on this. George > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Wednesday, July 26, 2006 11:22 PM > To: Pete McCann; mip4@ietf.org > Cc: Henrik Levkowetz > Subject: RE: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) >=20 > Hi Pete. >=20 > I support this draft as WG document. >=20 > May want to reference work on this topic in this older draft, > draft-mccann-mobileip-ipv6mipv4-03.txt? >=20 > Kent >=20 >=20 >=20 > > -----Original Message----- > > From: Pete McCann [mailto:mccap@petoni.org] > > Sent: Wednesday, July 26, 2006 10:59 AM > > To: mip4@ietf.org > > Cc: Henrik Levkowetz > > Subject: Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) > > > > With the new charter item number 10, we are ready to start > > work on a dual-stack Mobile IPv4 solution. This note is to > > query the working group to see whether we have consensus on adopting > > > > http://www.ietf.org/internet-drafts/draft-tsirtsis-v4v6-mipv4-01.txt > > > > as that working group document. Please send responses to the > > list, stating whether you support the adoption of this document. > > > > -Pete > > > > >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jul 27 10:01:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66QJ-0006GA-RQ; Thu, 27 Jul 2006 10:01:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66QI-0006G0-ES for mip4@ietf.org; Thu, 27 Jul 2006 10:01:10 -0400 Received: from dsl3.halflab.com ([64.81.61.172] helo=outpost.thehouse.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G66QH-0005Qm-2d for mip4@ietf.org; Thu, 27 Jul 2006 10:01:10 -0400 Received: from localhost ([127.0.0.1] ident=mccap) by outpost.thehouse.org with esmtp (Exim 4.50) id 1G66QE-0001pr-O6; Thu, 27 Jul 2006 07:01:06 -0700 Message-ID: <44C8C71E.6000309@petoni.org> Date: Thu, 27 Jul 2006 09:01:02 -0500 From: Pete McCann User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A0CC5A4@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A0CC5A4@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org The old draft has expired so I think it would be inappropriate to reference it. However, a short acknowledgement would be nice. -Pete Tsirtsis, George wrote: > I am aware of this draft but I have not read it for long time. I will go > over it to see if there is anything that is not covered by the new > draft. Some acknowledgments are indeed in order while I am also open to > co-authoring if any of the authors of the mccann draft are still > interested in working on this. > > George > >> -----Original Message----- >> From: Kent Leung (kleung) [mailto:kleung@cisco.com] >> Sent: Wednesday, July 26, 2006 11:22 PM >> To: Pete McCann; mip4@ietf.org >> Cc: Henrik Levkowetz >> Subject: RE: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) >> >> Hi Pete. >> >> I support this draft as WG document. >> >> May want to reference work on this topic in this older draft, >> draft-mccann-mobileip-ipv6mipv4-03.txt? >> >> Kent >> >> >> >>> -----Original Message----- >>> From: Pete McCann [mailto:mccap@petoni.org] >>> Sent: Wednesday, July 26, 2006 10:59 AM >>> To: mip4@ietf.org >>> Cc: Henrik Levkowetz >>> Subject: Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) >>> >>> With the new charter item number 10, we are ready to start >>> work on a dual-stack Mobile IPv4 solution. This note is to >>> query the working group to see whether we have consensus on adopting >>> >>> http://www.ietf.org/internet-drafts/draft-tsirtsis-v4v6-mipv4-01.txt >>> >>> as that working group document. Please send responses to the >>> list, stating whether you support the adoption of this document. >>> >>> -Pete >>> >>> >> -- >> Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >> Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jul 27 10:04:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66T4-0001Dc-QP; Thu, 27 Jul 2006 10:04:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66T3-0001DX-6o for mip4@ietf.org; Thu, 27 Jul 2006 10:04:01 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G66T0-0006Cl-Pb for mip4@ietf.org; Thu, 27 Jul 2006 10:04:01 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6RE3vaI030551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2006 07:03:57 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6RE3tJ4000299; Thu, 27 Jul 2006 07:03:56 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 07:03:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) Date: Thu, 27 Jul 2006 07:03:54 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A0CC5A8@NAEX14.na.qualcomm.com> In-Reply-To: <44C8C71E.6000309@petoni.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) Thread-Index: AcaxhSV11jnELkgSRhOBoSjqMe+SvAAACwug From: "Tsirtsis, George" To: "Pete McCann" X-OriginalArrivalTime: 27 Jul 2006 14:03:55.0883 (UTC) FILETIME=[7FC213B0:01C6B185] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Indeed, I was not going to reference it as a draft but I would include the authors in the acks section. George > -----Original Message----- > From: Pete McCann [mailto:mccap@petoni.org] > Sent: Thursday, July 27, 2006 10:01 AM > To: Tsirtsis, George > Cc: Kent Leung (kleung); mip4@ietf.org; Henrik Levkowetz > Subject: Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) >=20 > The old draft has expired so I think it would be inappropriate to > reference it. However, a short acknowledgement would be nice. >=20 > -Pete >=20 > Tsirtsis, George wrote: > > I am aware of this draft but I have not read it for long time. I will go > > over it to see if there is anything that is not covered by the new > > draft. Some acknowledgments are indeed in order while I am also open to > > co-authoring if any of the authors of the mccann draft are still > > interested in working on this. > > > > George > > > >> -----Original Message----- > >> From: Kent Leung (kleung) [mailto:kleung@cisco.com] > >> Sent: Wednesday, July 26, 2006 11:22 PM > >> To: Pete McCann; mip4@ietf.org > >> Cc: Henrik Levkowetz > >> Subject: RE: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) > >> > >> Hi Pete. > >> > >> I support this draft as WG document. > >> > >> May want to reference work on this topic in this older draft, > >> draft-mccann-mobileip-ipv6mipv4-03.txt? > >> > >> Kent > >> > >> > >> > >>> -----Original Message----- > >>> From: Pete McCann [mailto:mccap@petoni.org] > >>> Sent: Wednesday, July 26, 2006 10:59 AM > >>> To: mip4@ietf.org > >>> Cc: Henrik Levkowetz > >>> Subject: Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) > >>> > >>> With the new charter item number 10, we are ready to start > >>> work on a dual-stack Mobile IPv4 solution. This note is to > >>> query the working group to see whether we have consensus on adopting > >>> > >>> http://www.ietf.org/internet-drafts/draft-tsirtsis-v4v6-mipv4-01.txt > >>> > >>> as that working group document. Please send responses to the > >>> list, stating whether you support the adoption of this document. > >>> > >>> -Pete > >>> > >>> > >> -- > >> Mip4 mailing list: Mip4@ietf.org > >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html > >> Supplemental site: http://www.mip4.org/ > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jul 27 10:37:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66z3-0007Nf-6J; Thu, 27 Jul 2006 10:37:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G66z1-0007IX-N0 for mip4@ietf.org; Thu, 27 Jul 2006 10:37:03 -0400 Received: from web60321.mail.yahoo.com ([209.73.178.129]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G66z0-0000zk-92 for mip4@ietf.org; Thu, 27 Jul 2006 10:37:03 -0400 Received: (qmail 56668 invoked by uid 60001); 27 Jul 2006 14:36:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=3CFeNgefp8fz7cciSxKyF7ek2We56jJ+GzJUTXxNOZ1cWQaVKFeZFat0oPRZOp/q0+YJ2tFhYOfhelfScmaOqgN3419ozMhXCSZl+gIkAxp5tC9HW7b+dyV0/pRIsxn0kXb58U6P8E9E2h2eTtU91UCloQYAp1VkY26JIfuJz+w= ; Message-ID: <20060727143657.56666.qmail@web60321.mail.yahoo.com> Received: from [12.129.211.52] by web60321.mail.yahoo.com via HTTP; Thu, 27 Jul 2006 07:36:57 PDT Date: Thu, 27 Jul 2006 07:36:57 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) To: "Tsirtsis, George" In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A0CC5A8@NAEX14.na.qualcomm.com> MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2037538499==" Errors-To: mip4-bounces@ietf.org --===============2037538499== Content-Type: multipart/alternative; boundary="0-1705317094-1154011017=:55477" --0-1705317094-1154011017=:55477 Content-Type: text/plain; charset=us-ascii There is a saying: no free lunch :) --behcet ----- Original Message ---- From: "Tsirtsis, George" To: Pete McCann Cc: Kent Leung (kleung) ; mip4@ietf.org; Henrik Levkowetz Sent: Thursday, July 27, 2006 9:03:54 AM Subject: RE: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) Indeed, I was not going to reference it as a draft but I would include the authors in the acks section. George > -----Original Message----- > From: Pete McCann [mailto:mccap@petoni.org] > Sent: Thursday, July 27, 2006 10:01 AM > To: Tsirtsis, George > Cc: Kent Leung (kleung); mip4@ietf.org; Henrik Levkowetz > Subject: Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) > > The old draft has expired so I think it would be inappropriate to > reference it. However, a short acknowledgement would be nice. > > -Pete > > Tsirtsis, George wrote: > > I am aware of this draft but I have not read it for long time. I will go > > over it to see if there is anything that is not covered by the new > > draft. Some acknowledgments are indeed in order while I am also open to > > co-authoring if any of the authors of the mccann draft are still > > interested in working on this. > > > > George > > > >> -----Original Message----- > >> From: Kent Leung (kleung) [mailto:kleung@cisco.com] > >> Sent: Wednesday, July 26, 2006 11:22 PM > >> To: Pete McCann; mip4@ietf.org > >> Cc: Henrik Levkowetz > >> Subject: RE: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) > >> > >> Hi Pete. > >> > >> I support this draft as WG document. > >> > >> May want to reference work on this topic in this older draft, > >> draft-mccann-mobileip-ipv6mipv4-03.txt? > >> > >> Kent > >> > >> > >> > >>> -----Original Message----- > >>> From: Pete McCann [mailto:mccap@petoni.org] > >>> Sent: Wednesday, July 26, 2006 10:59 AM > >>> To: mip4@ietf.org > >>> Cc: Henrik Levkowetz > >>> Subject: Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) > >>> > >>> With the new charter item number 10, we are ready to start > >>> work on a dual-stack Mobile IPv4 solution. This note is to > >>> query the working group to see whether we have consensus on adopting > >>> > >>> http://www.ietf.org/internet-drafts/draft-tsirtsis-v4v6-mipv4-01.txt > >>> > >>> as that working group document. Please send responses to the > >>> list, stating whether you support the adoption of this document. > >>> > >>> -Pete > >>> > >>> > >> -- > >> Mip4 mailing list: Mip4@ietf.org > >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html > >> Supplemental site: http://www.mip4.org/ > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --0-1705317094-1154011017=:55477 Content-Type: text/html; charset=us-ascii
There is a saying: no free lunch :)

--behcet

----- Original Message ----
From: "Tsirtsis, George" <tsirtsis@qualcomm.com>
To: Pete McCann <mccap@petoni.org>
Cc: Kent Leung (kleung) <kleung@cisco.com>; mip4@ietf.org; Henrik Levkowetz <henrik@levkowetz.com>
Sent: Thursday, July 27, 2006 9:03:54 AM
Subject: RE: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4)

Indeed, I was not going to reference it as a draft but I would include
the authors in the acks section.
George

> -----Original Message-----
> From: Pete McCann [mailto:mccap@petoni.org]
> Sent: Thursday, July 27, 2006 10:01 AM
> To: Tsirtsis, George
> Cc: Kent Leung (kleung); mip4@ietf.org; Henrik Levkowetz
> Subject: Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4)
>
> The old draft has expired so I think it would be inappropriate to
> reference it.  However, a short acknowledgement would be nice.
>
> -Pete
>
> Tsirtsis, George wrote:
> > I am aware of this draft but I have not read it for long time. I
will go
> > over it to see if there is anything that is not covered by the new
> > draft. Some acknowledgments are indeed in order while I am also open
to
> > co-authoring if any of the authors of the mccann draft are still
> > interested in working on this.
> >
> > George
> >
> >> -----Original Message-----
> >> From: Kent Leung (kleung) [mailto:kleung@cisco.com]
> >> Sent: Wednesday, July 26, 2006 11:22 PM
> >> To: Pete McCann; mip4@ietf.org
> >> Cc: Henrik Levkowetz
> >> Subject: RE: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4)
> >>
> >> Hi Pete.
> >>
> >> I support this draft as WG document.
> >>
> >> May want to reference work on this topic in this older draft,
> >> draft-mccann-mobileip-ipv6mipv4-03.txt?
> >>
> >> Kent
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Pete McCann [mailto:mccap@petoni.org]
> >>> Sent: Wednesday, July 26, 2006 10:59 AM
> >>> To: mip4@ietf.org
> >>> Cc: Henrik Levkowetz
> >>> Subject: Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4)
> >>>
> >>> With the new charter item number 10, we are ready to start
> >>> work on a dual-stack Mobile IPv4 solution.  This note is to
> >>> query the working group to see whether we have consensus on
adopting
> >>>
> >>>
http://www.ietf.org/internet-drafts/draft-tsirtsis-v4v6-mipv4-01.txt
> >>>
> >>> as that working group document.  Please send responses to the
> >>> list, stating whether you support the adoption of this document.
> >>>
> >>> -Pete
> >>>
> >>>
> >> --
> >> Mip4 mailing list: Mip4@ietf.org
> >>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
> >>      Charter page:
http://www.ietf.org/html.charters/mip4-charter.html
> >> Supplemental site: http://www.mip4.org/
> >

--
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

--0-1705317094-1154011017=:55477-- --===============2037538499== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============2037538499==-- From mip4-bounces@ietf.org Thu Jul 27 11:14:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67Zb-0004t9-0G; Thu, 27 Jul 2006 11:14:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67Za-0004sz-C9 for mip4@ietf.org; Thu, 27 Jul 2006 11:14:50 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G67ZY-0007pH-Qg for mip4@ietf.org; Thu, 27 Jul 2006 11:14:50 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id k6RFEgsV016831; Thu, 27 Jul 2006 08:14:42 -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 k6RFEdeT004761; Thu, 27 Jul 2006 10:14:40 -0500 (CDT) Message-ID: <44C8D85D.2070702@motorola.com> Date: Thu, 27 Jul 2006 17:14:37 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Behcet Sarikaya Subject: Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) References: <20060727143657.56666.qmail@web60321.mail.yahoo.com> In-Reply-To: <20060727143657.56666.qmail@web60321.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: "Tsirtsis, George" , mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Behcet Sarikaya wrote: > There is a saying: no free lunch :) I don't get that, what's the free lunch in this context? Alex > > --behcet > > ----- Original Message ---- > From: "Tsirtsis, George" > To: Pete McCann > Cc: Kent Leung (kleung) ; mip4@ietf.org; Henrik > Levkowetz > Sent: Thursday, July 27, 2006 9:03:54 AM > Subject: RE: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) > > Indeed, I was not going to reference it as a draft but I would include > the authors in the acks section. > George > > > -----Original Message----- > > From: Pete McCann [mailto:mccap@petoni.org] > > Sent: Thursday, July 27, 2006 10:01 AM > > To: Tsirtsis, George > > Cc: Kent Leung (kleung); mip4@ietf.org; Henrik Levkowetz > > Subject: Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) > > > > The old draft has expired so I think it would be inappropriate to > > reference it. However, a short acknowledgement would be nice. > > > > -Pete > > > > Tsirtsis, George wrote: > > > I am aware of this draft but I have not read it for long time. I > will go > > > over it to see if there is anything that is not covered by the new > > > draft. Some acknowledgments are indeed in order while I am also open > to > > > co-authoring if any of the authors of the mccann draft are still > > > interested in working on this. > > > > > > George > > > > > >> -----Original Message----- > > >> From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > >> Sent: Wednesday, July 26, 2006 11:22 PM > > >> To: Pete McCann; mip4@ietf.org > > >> Cc: Henrik Levkowetz > > >> Subject: RE: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) > > >> > > >> Hi Pete. > > >> > > >> I support this draft as WG document. > > >> > > >> May want to reference work on this topic in this older draft, > > >> draft-mccann-mobileip-ipv6mipv4-03.txt? > > >> > > >> Kent > > >> > > >> > > >> > > >>> -----Original Message----- > > >>> From: Pete McCann [mailto:mccap@petoni.org] > > >>> Sent: Wednesday, July 26, 2006 10:59 AM > > >>> To: mip4@ietf.org > > >>> Cc: Henrik Levkowetz > > >>> Subject: Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) > > >>> > > >>> With the new charter item number 10, we are ready to start > > >>> work on a dual-stack Mobile IPv4 solution. This note is to > > >>> query the working group to see whether we have consensus on > adopting > > >>> > > >>> > http://www.ietf.org/internet-drafts/draft-tsirtsis-v4v6-mipv4-01.txt > > >>> > > >>> as that working group document. Please send responses to the > > >>> list, stating whether you support the adoption of this document. > > >>> > > >>> -Pete > > >>> > > >>> > > >> -- > > >> Mip4 mailing list: Mip4@ietf.org > > >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > >> Charter page: > http://www.ietf.org/html.charters/mip4-charter.html > > >> Supplemental site: http://www.mip4.org/ > > > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jul 28 20:39:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6crk-0005cI-Mm; Fri, 28 Jul 2006 20:39:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6crj-0005RK-87 for mip4@ietf.org; Fri, 28 Jul 2006 20:39:39 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6cri-0000Ch-0B for mip4@ietf.org; Fri, 28 Jul 2006 20:39:39 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k6T0dQit009160; Fri, 28 Jul 2006 17:39:35 -0700 (MST) Received: from [10.169.4.67] (mvp-10-169-4-67.corp.mot.com [10.169.4.67]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k6T0dOXI025767; Fri, 28 Jul 2006 19:39:25 -0500 (CDT) Message-ID: <44CAAE3C.4070205@motorola.com> Date: Sat, 29 Jul 2006 02:39:24 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Pete McCann Subject: Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) References: <44C7AD6F.10408@petoni.org> In-Reply-To: <44C7AD6F.10408@petoni.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Pete McCann wrote: > With the new charter item number 10, we are ready to start work on a > dual-stack Mobile IPv4 solution. This note is to query the working > group to see whether we have consensus on adopting > > http://www.ietf.org/internet-drafts/draft-tsirtsis-v4v6-mipv4-01.txt > > as that working group document. Please send responses to the list, > stating whether you support the adoption of this document. I support this as a WG item. I have comments on it, sent separately. Alex -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jul 28 21:07:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6dIJ-0003br-8s; Fri, 28 Jul 2006 21:07:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6dII-0003bm-Af for mip4@ietf.org; Fri, 28 Jul 2006 21:07:06 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6dIH-0004CD-28 for mip4@ietf.org; Fri, 28 Jul 2006 21:07:06 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k6T174nY024278; Fri, 28 Jul 2006 18:07:04 -0700 (MST) Received: from [10.169.4.67] (mvp-10-169-4-67.corp.mot.com [10.169.4.67]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k6T172EN010237; Fri, 28 Jul 2006 20:07:03 -0500 (CDT) Message-ID: <44CAB4B5.80107@motorola.com> Date: Sat, 29 Jul 2006 03:07:01 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Pete McCann Subject: Re: comments on draft-tsirtsis-v4v6-mipv4 (was: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4)) References: <44C7AD6F.10408@petoni.org> In-Reply-To: <44C7AD6F.10408@petoni.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org draft-tsirtsis-v4v6-mipv4 describes three extensions to MIP4 header: IPv6 Prefix Extension, IPv6 Code Extension and IPv6 Tunnelling Mode extension. The first and last are sent by MN if it does CCoA or by FA otherwise. The second is sent by HA. > Extensions defined in this document allow a node that has IPv4 and > IPv6 [IPv6] addresses to maintain communications with either any of > its addresses while moving in IPv4 or dual stack networks. I think there is scoping question here. It seems to clash with what DS-MIPv6 does. I'd only care about DS-MIPv4 offering session continuity and reachability at a permanent IPv6 address (not IPv4, MIP4 cares for that) while connected to an IPv4-only network. For completeness, we may think too that DS-MIPv4 would be MIP4 encapsulated in IPv6. I.e. the access network is IPv6-only and the HA is IPv4-only. This draft demands HA to support both IPv4 _and_ IPv6 (because it does both proxy ARP and proxy ND). I think this is not a good idea, because, if we accept that there can be IPv6-only access network then we also accept that there can be IP4-only home networks. I don't think it's good to demand HA to be placed always at the junction. > 3.6. Dynamic IPv6 Prefix allocation This section describes how to put ::0 in RegReq and obtain an IPv6 prefix in RegRep. When MN is connected to an IPv4-only access network, it could open the MIP4 UDP tunnel and run DHCPv6-Prefix Delegation on it and thus HA delegates an IPv6 prefix to MN. Finally, I think it would be good to suggest that this spec (DS-MIPv4) extends the IPv4 Prefix Table of NEMOv4 (an informational draft in the NEMO WG) to contain pairs of IPv6 prefix-IPv6 Home Address. The NEMOv4 draft has this Prefix Table as IPv4-only. It is manually configured by admin and used to verify a certain IPv4 HoA can use a certain IPv4 MNP (mobile network prefix). Without extending the NEMOv4 Prefix Table with IPv6 addresses the DS-MIPv4 HA may be prone to some security risks. Alex -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sun Jul 30 13:28:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7F59-0005rV-Hf; Sun, 30 Jul 2006 13:28:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7F57-0005ps-NM for mip4@ietf.org; Sun, 30 Jul 2006 13:28:01 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7F55-0007QU-AD for mip4@ietf.org; Sun, 30 Jul 2006 13:28:01 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6UHRv5X028594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 30 Jul 2006 10:27:58 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6UHRr5t018235; Sun, 30 Jul 2006 10:27:57 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Jul 2006 10:27:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: comments on draft-tsirtsis-v4v6-mipv4 (was: [Mip4] WG Action:RECHARTER: Mobility for IPv4 (mip4)) Date: Sun, 30 Jul 2006 10:27:51 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A0CC749@NAEX14.na.qualcomm.com> In-Reply-To: <44CAB4B5.80107@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-tsirtsis-v4v6-mipv4 (was: [Mip4] WG Action:RECHARTER: Mobility for IPv4 (mip4)) Thread-Index: Acayq1t9Qz4b8Wn/SOynt8+1Eo/puwBTLs1g From: "Tsirtsis, George" To: "Alexandru Petrescu" , "Pete McCann" X-OriginalArrivalTime: 30 Jul 2006 17:27:53.0468 (UTC) FILETIME=[7D2A9BC0:01C6B3FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Alex, comment inline... > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Friday, July 28, 2006 9:07 PM > To: Pete McCann > Cc: mip4@ietf.org; Henrik Levkowetz > Subject: Re: comments on draft-tsirtsis-v4v6-mipv4 (was: [Mip4] WG > Action:RECHARTER: Mobility for IPv4 (mip4)) >=20 > draft-tsirtsis-v4v6-mipv4 describes three extensions to MIP4 header: > IPv6 Prefix Extension, IPv6 Code Extension and IPv6 Tunnelling Mode > extension. The first and last are sent by MN if it does CCoA or by FA > otherwise. The second is sent by HA. >=20 > > Extensions defined in this document allow a node that has IPv4 and > > IPv6 [IPv6] addresses to maintain communications with either any of > > its addresses while moving in IPv4 or dual stack networks. >=20 > I think there is scoping question here. It seems to clash with what > DS-MIPv6 does. >=20 > I'd only care about DS-MIPv4 offering session continuity and > reachability at a permanent IPv6 address (not IPv4, MIP4 cares for that) > while connected to an IPv4-only network. >=20 GT> Alex, on the face of it, what you are saying here does not seem to make sense. DS-MIPv4 is a simple extension to MIPv4. So, DS-MIPv4 is likely to be a super-set of MIPv4. It would actually be hard to remove feature that are present in MIPv4 as we extend the protocol to DS-MIPv4. > For completeness, we may think too that DS-MIPv4 would be MIP4 > encapsulated in IPv6. I.e. the access network is IPv6-only and the HA > is IPv4-only. This draft demands HA to support both IPv4 _and_ IPv6 > (because it does both proxy ARP and proxy ND). I think this is not a > good idea, because, if we accept that there can be IPv6-only access > network then we also accept that there can be IP4-only home networks. I > don't think it's good to demand HA to be placed always at the junction. >=20 GT> You bring up two points: (i) IPv6-only access network and (ii) IPv4-only home network. The draft proposal does not currently deal with IPv6-only access networks. WRT (i) we could indeed deal with this but, personally, I do not think this is an important case and we can always extend the protocol further when something like that is needed. (ii) has been discussed a number of times during the WG meeting and on the list and I think you are alone in thinking that there is an issue here. Since you seem convinced this is indeed an issue, you could write a draft, describing the problem and suggesting some solutions...so we can discuss it further.=20 > > 3.6. Dynamic IPv6 Prefix allocation >=20 > This section describes how to put ::0 in RegReq and obtain an IPv6 > prefix in RegRep. >=20 > When MN is connected to an IPv4-only access network, it could open the > MIP4 UDP tunnel and run DHCPv6-Prefix Delegation on it and thus HA > delegates an IPv6 prefix to MN. >=20 GT> This sounds like an option that is worth exploring. > Finally, I think it would be good to suggest that this spec (DS-MIPv4) > extends the IPv4 Prefix Table of NEMOv4 (an informational draft in the > NEMO WG) to contain pairs of IPv6 prefix-IPv6 Home Address. The NEMOv4 > draft has this Prefix Table as IPv4-only. It is manually configured by > admin and used to verify a certain IPv4 HoA can use a certain IPv4 MNP > (mobile network prefix). Without extending the NEMOv4 Prefix Table with > IPv6 addresses the DS-MIPv4 HA may be prone to some security risks. >=20 GT> Yes, I agree. Thanks George -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sun Jul 30 14:12:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7FmF-0005OB-5t; Sun, 30 Jul 2006 14:12:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7FmE-0005O6-S2 for mip4@ietf.org; Sun, 30 Jul 2006 14:12:34 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7FmD-0002PK-Ct for mip4@ietf.org; Sun, 30 Jul 2006 14:12:34 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id k6UICGUM012209; Sun, 30 Jul 2006 11:12:21 -0700 (MST) Received: from [10.169.4.30] (mvp-10-169-4-30.corp.mot.com [10.169.4.30]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k6UICDNm011603; Sun, 30 Jul 2006 13:12:14 -0500 (CDT) Message-ID: <44CCF679.9060300@motorola.com> Date: Sun, 30 Jul 2006 20:12:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: comments on draft-tsirtsis-v4v6-mipv4 (was: [Mip4] WG Action:RECHARTER: Mobility for IPv4 (mip4)) References: <7EB20EA0938B4D42A2D82689365C9B7A0CC749@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A0CC749@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Pete McCann , mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Tsirtsis, George wrote: >>> Extensions defined in this document allow a node that has IPv4 >>> and IPv6 [IPv6] addresses to maintain communications with either >>> any of its addresses while moving in IPv4 or dual stack networks. >>> >> I think there is scoping question here. It seems to clash with >> what DS-MIPv6 does. >> >> I'd only care about DS-MIPv4 offering session continuity and >> reachability at a permanent IPv6 address (not IPv4, MIP4 cares for >> that) while connected to an IPv4-only network. >> > > GT> Alex, on the face of it, what you are saying here does not seem > to make sense. DS-MIPv4 is a simple extension to MIPv4. So, DS-MIPv4 > is likely to be a super-set of MIPv4. It would actually be hard to > remove feature that are present in MIPv4 as we extend the protocol to > DS-MIPv4. Ok, it's everyone's interpretation. I wouldn't scope both DS-MIPv6 and DS-MIPv4 to offer session continuity and reachability at a permanent IPv4 Home Address with v4-only, especially when MIP4 does it too. >> For completeness, we may think too that DS-MIPv4 would be MIP4 >> encapsulated in IPv6. I.e. the access network is IPv6-only and the >> HA is IPv4-only. This draft demands HA to support both IPv4 _and_ >> IPv6 (because it does both proxy ARP and proxy ND). I think this >> is not a good idea, because, if we accept that there can be >> IPv6-only access network then we also accept that there can be >> IP4-only home networks. I don't think it's good to demand HA to be >> placed always at the junction. > > GT> You bring up two points: (i) IPv6-only access network and (ii) > IPv4-only home network. The draft proposal does not currently deal > with IPv6-only access networks. WRT (i) we could indeed deal with > this but, personally, I do not think this is an important case and we > can always extend the protocol further when something like that is > needed. (ii) has been discussed a number of times during the WG > meeting and on the list and I think you are alone in thinking that > there is an issue here. Ok, let's see what other comments you get. > Since you seem convinced this is indeed an issue, you could write a > draft, describing the problem and suggesting some solutions...so we > can discuss it further. Thanks for the invitation. >>> 3.6. Dynamic IPv6 Prefix allocation >> This section describes how to put ::0 in RegReq and obtain an IPv6 >> prefix in RegRep. >> >> When MN is connected to an IPv4-only access network, it could open >> the MIP4 UDP tunnel and run DHCPv6-Prefix Delegation on it and thus >> HA delegates an IPv6 prefix to MN. >> > > GT> This sounds like an option that is worth exploring. > >> Finally, I think it would be good to suggest that this spec >> (DS-MIPv4) extends the IPv4 Prefix Table of NEMOv4 (an >> informational draft in the NEMO WG) to contain pairs of IPv6 >> prefix-IPv6 Home Address. The NEMOv4 draft has this Prefix Table >> as IPv4-only. It is manually configured by admin and used to >> verify a certain IPv4 HoA can use a certain IPv4 MNP (mobile >> network prefix). Without extending the NEMOv4 Prefix Table with >> IPv6 addresses the DS-MIPv4 HA may be prone to some security risks. >> >> > > GT> Yes, I agree. Ok, thanks, Alex -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sun Jul 30 14:18:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7FrW-0000MB-Ss; Sun, 30 Jul 2006 14:18:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7FrW-0000IV-3Z for mip4@ietf.org; Sun, 30 Jul 2006 14:18:02 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7FrU-0002kn-Nm for mip4@ietf.org; Sun, 30 Jul 2006 14:18:02 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6UIHvG6001319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 30 Jul 2006 11:17:57 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6UIHu47016597; Sun, 30 Jul 2006 11:17:57 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Jul 2006 11:17:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: comments on draft-tsirtsis-v4v6-mipv4 (was: [Mip4] WG Action:RECHARTER: Mobility for IPv4 (mip4)) Date: Sun, 30 Jul 2006 11:17:58 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A0CC74C@NAEX14.na.qualcomm.com> In-Reply-To: <44CCF679.9060300@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-tsirtsis-v4v6-mipv4 (was: [Mip4] WG Action:RECHARTER: Mobility for IPv4 (mip4)) Thread-Index: Aca0A8lkzWbAzFreTfK0LziA/eNeqQAADghA From: "Tsirtsis, George" To: "Alexandru Petrescu" X-OriginalArrivalTime: 30 Jul 2006 18:17:56.0783 (UTC) FILETIME=[7B481BF0:01C6B404] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Pete McCann , mip4@ietf.org, Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Sunday, July 30, 2006 2:12 PM > To: Tsirtsis, George > Cc: Pete McCann; mip4@ietf.org; Henrik Levkowetz > Subject: Re: comments on draft-tsirtsis-v4v6-mipv4 (was: [Mip4] WG > Action:RECHARTER: Mobility for IPv4 (mip4)) >=20 > Tsirtsis, George wrote: > >>> Extensions defined in this document allow a node that has IPv4 > >>> and IPv6 [IPv6] addresses to maintain communications with either > >>> any of its addresses while moving in IPv4 or dual stack networks. > >>> > >> I think there is scoping question here. It seems to clash with > >> what DS-MIPv6 does. > >> > >> I'd only care about DS-MIPv4 offering session continuity and > >> reachability at a permanent IPv6 address (not IPv4, MIP4 cares for > >> that) while connected to an IPv4-only network. > >> > > > > GT> Alex, on the face of it, what you are saying here does not seem > > to make sense. DS-MIPv4 is a simple extension to MIPv4. So, DS-MIPv4 > > is likely to be a super-set of MIPv4. It would actually be hard to > > remove feature that are present in MIPv4 as we extend the protocol to > > DS-MIPv4. >=20 > Ok, it's everyone's interpretation. >=20 > I wouldn't scope both DS-MIPv6 and DS-MIPv4 to offer session continuity > and reachability at a permanent IPv4 Home Address with v4-only, > especially when MIP4 does it too. >=20 GT> Yes but what does that mean? Both DSMIPv4 and DSMIPv6 allow a binding between an IPv4HoA and a CoA. How would you NOT offer session continuity? > >> For completeness, we may think too that DS-MIPv4 would be MIP4 > >> encapsulated in IPv6. I.e. the access network is IPv6-only and the > >> HA is IPv4-only. This draft demands HA to support both IPv4 _and_ > >> IPv6 (because it does both proxy ARP and proxy ND). I think this > >> is not a good idea, because, if we accept that there can be > >> IPv6-only access network then we also accept that there can be > >> IP4-only home networks. I don't think it's good to demand HA to be > >> placed always at the junction. > > > > GT> You bring up two points: (i) IPv6-only access network and (ii) > > IPv4-only home network. The draft proposal does not currently deal > > with IPv6-only access networks. WRT (i) we could indeed deal with > > this but, personally, I do not think this is an important case and we > > can always extend the protocol further when something like that is > > needed. (ii) has been discussed a number of times during the WG > > meeting and on the list and I think you are alone in thinking that > > there is an issue here. >=20 > Ok, let's see what other comments you get. >=20 > > Since you seem convinced this is indeed an issue, you could write a > > draft, describing the problem and suggesting some solutions...so we > > can discuss it further. >=20 > Thanks for the invitation. >=20 GT> OK, the comment was kind of patronizing, sorry :-) Seriously though, writing a draft would be a good idea.=20 George -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jul 31 11:45:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ZxO-0002li-69; Mon, 31 Jul 2006 11:45:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7ZxN-0002la-8M for mip4@ietf.org; Mon, 31 Jul 2006 11:45:25 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7ZxL-0005l4-Ve for mip4@ietf.org; Mon, 31 Jul 2006 11:45:25 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k6VFjF6s026215; Mon, 31 Jul 2006 08:45:19 -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 k6VFjDet008137; Mon, 31 Jul 2006 10:45:14 -0500 (CDT) Message-ID: <44CE2588.8060002@motorola.com> Date: Mon, 31 Jul 2006 17:45:12 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: comments on draft-tsirtsis-v4v6-mipv4 (was: [Mip4] WG Action:RECHARTER: Mobility for IPv4 (mip4)) References: <7EB20EA0938B4D42A2D82689365C9B7A0CC74C@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A0CC74C@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Tsirtsis, George wrote: >> Tsirtsis, George wrote: >>>>> Extensions defined in this document allow a node that has >>>>> IPv4 and IPv6 [IPv6] addresses to maintain communications >>>>> with either any of its addresses while moving in IPv4 or dual >>>>> stack networks. >>>>> >>>> I think there is scoping question here. It seems to clash with >>>> what DS-MIPv6 does. >>>> >>>> I'd only care about DS-MIPv4 offering session continuity and >>>> reachability at a permanent IPv6 address (not IPv4, MIP4 cares >>>> for that) while connected to an IPv4-only network. >>>> >>> GT> Alex, on the face of it, what you are saying here does not >>> seem to make sense. DS-MIPv4 is a simple extension to MIPv4. So, >>> DS-MIPv4 is likely to be a super-set of MIPv4. It would actually >>> be hard to remove feature that are present in MIPv4 as we extend >>> the protocol to DS-MIPv4. >> Ok, it's everyone's interpretation. >> >> I wouldn't scope both DS-MIPv6 and DS-MIPv4 to offer session >> continuity and reachability at a permanent IPv4 Home Address with >> v4-only, especially when MIP4 does it too. >> > > GT> Yes but what does that mean? Both DSMIPv4 and DSMIPv6 allow a > binding between an IPv4HoA and a CoA. How would you NOT offer session > continuity? We aren't sync'ed, maybe because I missed to put the word "access" near "v4-only" above. DS-MIPv4 doesn't do anything special to bind an IPv4 HoA to an IPv4 CoA. If DS-MIPv4 MN accessed v6-only networks then it would have been necessary to bind an IPv6 CoA to an IPv4 HoA (something that DS-MIPv6 doesn't do, MIP6 doesn't do and MIP4 doesn't do)[*]. For the text in your draft, my (own) reading were happier if it only said: >>>>> MIP4 extensions defined in this document allow a node that >>>>> accesses an IPv4-only network to maintain communications at >>>>> its IPv6 Home Address(es) [see DS-MIPv6 for MIP6 extensions >>>>> to achieve same effect]. How people read and understand this or the original text is of course a matter of your evaluation. Alex [*]: we've discussed previously whether v6-only access networks are a necessary feature, or will ever be necessary. Of course, I can't say for the moment. If you guys have specific deployment scenarios where you know IPv6-only access networks don't happen then that's wonderful, deployments should drive protocol design. The discussions I have for v6-only access networks, v4-only home networks and v6-only home networks are just exercises in a lab. That for it. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/