From mip6-bounces@ietf.org Wed Jun 01 07:03:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdR09-0002dO-Jx; Wed, 01 Jun 2005 07:03:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdR07-0002dB-7u for mip6@megatron.ietf.org; Wed, 01 Jun 2005 07:03:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03779 for ; Wed, 1 Jun 2005 07:03:04 -0400 (EDT) Received: from casablanca.ucdavis.edu ([169.237.104.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdRJu-00043s-7K for mip6@ietf.org; Wed, 01 Jun 2005 07:23:35 -0400 Received: from lymeon.ucdavis.edu (lymeon.ucdavis.edu [169.237.104.171]) by casablanca.ucdavis.edu (8.13.3/8.13.1/it-defang-5.3.0) with ESMTP id j51B31TH018833 for ; Wed, 1 Jun 2005 04:03:01 -0700 (PDT) Received: from lymeon.ucdavis.edu (localhost [127.0.0.1]) by lymeon.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j51B31b4029530 for ; Wed, 1 Jun 2005 04:03:01 -0700 (PDT) Received: (from www@localhost) by lymeon.ucdavis.edu (8.12.10/8.12.9/Submit) id j51B31E1029529; Wed, 1 Jun 2005 04:03:01 -0700 (PDT) Date: Wed, 1 Jun 2005 04:03:01 -0700 (PDT) Message-Id: <200506011103.j51B31E1029529@lymeon.ucdavis.edu> To: mip6@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: [Mip6] Deadline extended: JSAC-MRNM X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY The deadline is extened until June 5th. http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications nad models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 5, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhône-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 01 10:55:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUcn-0000bR-Rq; Wed, 01 Jun 2005 10:55:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUcm-0000bM-D1 for mip6@megatron.ietf.org; Wed, 01 Jun 2005 10:55:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23451 for ; Wed, 1 Jun 2005 10:55:14 -0400 (EDT) Received: from smtp.um.es ([155.54.212.105] helo=xenon1.telemat.um.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdUwc-0007sb-E6 for mip6@ietf.org; Wed, 01 Jun 2005 11:15:47 -0400 Received: from localhost (localhost [127.0.0.1]) by xenon1.telemat.um.es (Postfix) with ESMTP id 756B71FA7F6 for ; Wed, 1 Jun 2005 16:55:06 +0200 (CEST) Received: from xenon1.telemat.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22964-01-35 for ; Wed, 1 Jun 2005 16:55:06 +0200 (CEST) Received: from [155.54.210.26] (dibulibu.um.es [155.54.1.250]) by xenon1.telemat.um.es (Postfix) with ESMTP id 188C91FA77A for ; Wed, 1 Jun 2005 16:55:06 +0200 (CEST) Message-ID: <429DCC4A.5010100@dif.um.es> Date: Wed, 01 Jun 2005 16:55:06 +0200 From: "Pedro M. Ruiz" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: multipart/mixed; boundary="------------050403000903030105050301" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Subject: [Mip6] Call for papers LOCAN 2005 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --------------050403000903030105050301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please find below, the following CFP for your consideration. Best wishes, Pedro M. Ruiz University of Murcia --------------050403000903030105050301 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="cfp.txt" Content-Disposition: inline; filename="cfp.txt" Content-Transfer-Encoding: 7bit We apologize if you receive multiple copies of this CFP ---------------------------------------------------------------------------- CALL FOR PAPERS - LOCAN 2005 1st International Workshop on Localized Communication and Topology Protocols for Ad hoc Networks in conjunction with MASS-2005 (www.mass05.wpi.edu) Washington, DC, USA, November 7-10, 2005 --------------------------------------------------------------------------- SUBJECT AND SCOPE ----------------- This workshop covers comprehensively the algorithmic issues in the hot area of ad hoc and sensor networking. The design of data communication techniques in multi-hop ad hoc networks has challenges at all layers of communication. This workshop concentrates on the network layer problems like data communication (routing, QoS-routing, geocasting, multicasting, broadcasting, etc.) and topology control (neighbor discovery, power adjustment, neighbor elimination, etc.). Additionally, sensor networks are currently recognized as one of the priority research areas by NSF. The area of sensor networking is gaining momentum within the researh community. This workshop will address ongoing research on this field, including problems such as: physical properties, sensor training, security through intelligent node cooperation, medium access, sensor area coverage with random and deterministic placement, object location, sensor position determination, energy efficient broadcasting and activity scheduling, routing, connectivity, data dissemination and gathering, sensor centric quality of routing, temporal message ordering, path exposure, tree reconfiguration, topology construction, and transport layer. The main paradigm shift is to apply localized (or greedy) schemes as opposed to existing protocols requiring global information. Localized algorithms are distributed algorithms where simple local node behaviour achieves a desired global objective. Localized protocols provide scalable solutions, that is, solutions for wireless networks with an arbitrary number of nodes, which is the main goal of this plan. Sensor and rooftop/mesh networks, for instance, have hundreds or thousands of nodes. The main objective of the workshop is to present state of the art research results on data communication and topology control in rapidly growing area of ad hoc and sensor networks, with emphasizes on localized techniques. Topics of interest include, but are not limited to: *Medium access control *Analytical, mobility and validation models for ad hoc networks *Hybrid networks and wireless Internet *Security in ad hoc networks *Data management issues, query processing, and data delivery *Routing, broadcasting and multicasting in ad hoc networks *Energy-efficient protocols for ad hoc networks *Quality of service in medium access control and routing *Topology construction and maintenance in ad hoc networks *Neighborhood discovery and mobility management IMPORTANT DATES --------------- Manuscript Submission: June 29, 2005 Acceptance Notification: July 29, 2005 Final Manuscript Due: August 26, 2005 PAPER SUBMISSION ---------------- Papers must not exceed 10 single-spaced and two-column pages using at least 10 point size type on 8.5 x 11 inches pages. See style files, author guidelines and instructions at the conference website. Accepted papers will be published by IEEE Computer Society Press, as proceedings of the MASS2005 workshops. Papers will be handled electronically through EDAS(http://edas.info). PROGRAM CO-CHAIRS ----------------- Dr. Pedro M. Ruiz Dept. Information and Comms. Engineering, University of Murcia, Spain pedrom@dif.um.es Dr. David Simplot-Ryl IRCICA/LIFL, Univ. Lille 1, INRIA Futurs, France David.Simplot@lifl.fr ADDITIONAL INFORMATION AND PC MEMBERS ------------------------------------- The list of PC members and additional information about the workshop will be continuously updated at the LOCAN 2005 website. http://ants.dif.um.es/locan2005/ --------------050403000903030105050301 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --------------050403000903030105050301-- From mip6-bounces@ietf.org Wed Jun 01 18:20:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddba4-0004o0-CB; Wed, 01 Jun 2005 18:20:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddba2-0004nl-Jg for mip6@megatron.ietf.org; Wed, 01 Jun 2005 18:20:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15199 for ; Wed, 1 Jun 2005 18:20:51 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddbtr-00024v-Un for mip6@ietf.org; Wed, 01 Jun 2005 18:41:28 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IHF0044ZET131@dns2.cselt.it> for mip6@ietf.org; Thu, 02 Jun 2005 00:07:49 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 02 Jun 2005 00:19:17 +0200 Date: Thu, 02 Jun 2005 00:20:28 +0200 From: Gerardo Giaretta To: Jari Arkko , Christian Vogt Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.132 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: Review of draft-irtf-mobopts-ro-enhancements-00 Thread-Index: AcVm+CF/0I7iDLcqTkmF5sxnQOaXEw== Content-class: urn:content-classes:message X-OriginalArrivalTime: 01 Jun 2005 22:19:17.0500 (UTC) FILETIME=[F3502BC0:01C566F7] X-Spam-Score: 2.4 (++) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, mobopts@irtf.org Subject: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi Christian and Jari, Raj requested me to review draft-irtf-mobopts-ro-enhancements-00. Here are some comments and question. General comment: I think the draft is very well-written and provide a complete analysis of the topic. The unique general issue I found is that it is very long. I agree with James' comment that the draft could be shortened removing some sections that are not completely in the scope of the draft (e.g. section 5.13 and 5.14, more about these sections below). More detailed comments: - section 1, paragraph 4 "In the opposite direction, the mobile node may tunnel packets to the home agent". I think this sentence is not completely correct, or at least a bit misleading. If route optimization is not used, the MN MUST tunnel packets to the HA. Is "MAY" used in this sentence to highlight that the MN can choose to use bidirectional tunneling or route optimization?=20 - section 1, paragraph 10 "This can lead to handover delay unacceptable for many real-time or interactive applications like Voice over IP (VoIP) and audio or video streaming". I'd suggest to remove audio/video streaming here. Streaming applications are not real-time nor interactive: they usually buffer few seconds of the movie/sound and thus are usually not affected by MIPv6 handover latency. At least this is what we have experimented in our labs. - section 3.1, paragraph 7 "The mobile node must compute a message-authentication code keyed with the Home and Care-of Keygen Token". Actually the MAC is keyed with the Kbm, that is a 20 octets SHA-1 hash of the concatenation of Home and Care-of Keygen Token - section 4.1, paragraph 1: I would mention explicitly that the handoff latency for a route-optimized communication is longer than for a bi-directional tunneled communication. - section 4.1, paragraph 2: since the CN is not always required to send the BA, I wonder why the MN should by default wait for the BA. Or are you suggesting the MN asks the CN an ack? If so, I think the sentence should be rephrased. - section 4.1, paragraph 3 "But more generally, mobile nodes wait for the home registration to be completed and acknowledged before initiating the correspondent registration". Are you referring to some specific implementations? I'm asking this because the open source implementation we use in our labs does not wait the BA. - section 4.4, paragraph 2: I would add references to draft-koodli-mip6-location-privacy-00 and to draft-koodli-mip6-location-privacy-solutions-00 - section 5.2, paragraph 1: What do you mean by "close to the mobile node"? Shouldn't it be "on the path between MN and HA"? - section 5.3, paragraph 2: the sentence is not clear to me. The last BA is referred to BA from CN, I suppose. If so, I think it should be mentioned explicitly. - section 5.13: as mentioned before I think this section is not really in the scope of the draft. If you think it is, I'd suggest to include some more text explaining how HMIPv6 influences RO operations (e.g. reduction of signaling overhead). The same applies to section 5.14. I think that FMIPv6 has even less impact on RO than HMIPv6. So I suggest you include some more text to explain how these protocols are tied to RO. - section 5.16, last sentence: are there simulations that prove that RR can be too expensive? A reference could be helpful.=20 - section 6.2.1, last paragraph: HMIPv6 causes always a tunneling overhead that is not present in plain MIPv6. Therefore, some localized mobility protocols always cause overhead and not only "in some situations". - section 6.2.2, paragraph 1 "On the other hand, nodes that do share a common secret should be allowed to omit the home-address test". Isn't required that the common secret is tied to the Home Address used in order to remove the home address test? Editorial comments: - section 4.1, last paragraph: Section 6.3.1 should be in brackets or similar - section 5.1, paragraph 2: s/IP-ddress/IP-address - section 5.7, paragraph 5: s/its is the data/it is the data - section 5.8, paragraph 2: s/it in general/it is in general Hope this helps. Regards, --Gerardo Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 01 23:23:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdgIh-0003Hg-Mt; Wed, 01 Jun 2005 23:23:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdgIf-0003HO-D8; Wed, 01 Jun 2005 23:23:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05194; Wed, 1 Jun 2005 23:23:12 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdgcX-0008OE-2x; Wed, 01 Jun 2005 23:43:52 -0400 Received: from jurassic.eng.sun.com ([129.146.58.37]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j523N9Kg013472; Wed, 1 Jun 2005 20:23:09 -0700 (PDT) Received: from shubho (shubho.SFBay.Sun.COM [129.146.74.85]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j523N9bI548231; Wed, 1 Jun 2005 20:23:09 -0700 (PDT) Message-Id: <200506020323.j523N9bI548231@jurassic.eng.sun.com> Date: Wed, 1 Jun 2005 20:22:57 -0700 (PDT) From: Samita Chakrabarti To: jari.arkko@piuha.net, chvogt@tm.uka.de MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 52WeRDTMpz+fAovmy8baIg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc X-Spam-Score: 2.4 (++) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: mip6@ietf.org, mobopts@irtf.org Subject: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hello: As per Basavaraj's request, I am posting my comments on this draft. Thanks, -Samita --------------------------------------------------------------------------- Overall: This document has a lot of information of which significant part can go to the appendix for details. Please shorten this draft. Currently, it is too long; at the end the reader can easily forget the purpose. This draft needs an editorial change for clear objectives/goals, list of deployable proposals and analysis of the suggested ones. Again, some more data to show when and how RO might be useful in certain applications would be useful. section 1: " Mobile IPv6 [29], its IPv4 counterpart [28], and the Host Identity Protocol [9] are three dominant mobility-management protocols that the IETF has developed to facilitate the continued use of existing transport protocols and applications in an Internet with mobility support." Reference [9] refers to the 00 version of hip draft. At the present, both MIP6 and MIP4 are in more mature state than HIP. This sentence could be reworded to say something like "additionally IETF is developing Host Identity Protocol [9] for mobility management". Typo : Page 5 : s/has send/has sent/ Page 6: s/lightway/lightweight/ section 2: Like to see the description in this section be a bit short and concise. Refering to draft-ietf-mip6-ro-sec makes sense to shorten this section. Section 3.1: Like the diagram. 3.2: s/could built/could build/ Please shorten this section 3.3: "tree types" - three types? Here is a good place to refer to ro-sec document and point to certain sections of that document. Section 4. This paragraph is not clear. Please list the three items (latency, signalling and security improvement) as goals for clear readability. 4.1 Last line could be: The delays introduced by the rest of the stack can be significant(see Section 6.3.1). 4.2 s/section Section 3/Section 3/ "For example, of the 716 Mbps signaling overhead generated by 100 million route-optimized mobile nodes, 220 Mbps goes through a home agent." Is this a deployment scenario? 100 milllion MNs per one HA? Section 5.1 and 5.2 Not clear about the enhancement of using "IP-address test" and "Protected Tunnel". Does it suggest a separate IP-address test other than HoTI COTI ? Is the "protected tunnel" between MN and CN - not sure what message these two sections are carrying. Section 5.3: After successful BU to HA, the MN-HA tunnel is created if it is not a refresh. So, how does the MN send optimistic RO to CN using Hoti msg while the tunnel is not configured yet ? Section 5.5 : Please use a diagram to describe concurrency. It is too much text to follow. Section 5.12 - 5.17: There are too many options to confuse the reader. Why do we need to list so many of them ? I think, mobopts draft should pick the strong improvement alternatives and list them in the main section. The rest should go to the appendix in a concise form. It has got too much information to process. Section 6; What are the criteria to evaluate recent proposals? If section 5 lists all the proposals in much abbreviated form, then it'd be nice if this section analyzes the primary proposals in a concise manner. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 02 01:16:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddi3r-0002in-89; Thu, 02 Jun 2005 01:16:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddi3p-0002fD-Cs for mip6@megatron.ietf.org; Thu, 02 Jun 2005 01:16:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11741 for ; Thu, 2 Jun 2005 01:16:04 -0400 (EDT) Received: from [218.249.29.198] (helo=center.njtu.edu.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdiNk-0005Cm-Il for mip6@ietf.org; Thu, 02 Jun 2005 01:36:43 -0400 Received: from zhanghk (remotehost [127.0.0.1]) by mail.student.njtu.edu.cn (ecMail) with ESMTP id 5D7B918C077 for ; Thu, 2 Jun 2005 13:29:30 +0800 (CST) Date: Thu, 2 Jun 2005 13:16:48 +0800 From: "HKzhang@center.njtu.edu.cn" To: "mip6" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====001_Dragon262426740658_=====" Message-Id: <20050602052930.5D7B918C077@mail.student.njtu.edu.cn> X-Spam-Score: 1.1 (+) X-Scan-Signature: d2bb8c7db26f2d12109e0cd8e454db52 Subject: [Mip6] Re:draft-zhang-mipv6-multicast-dma-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --=====001_Dragon262426740658_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 bWlwNkhpLCBldmVyeW9uZToNCiAgSSBhbSBIb25nLUtlIFpoYW5nIGFuZCBnbGFkIHRvIGNvbnRy aWJ1dGUgb3VyIGRyYWZ0IGFzIGEgaW5kaXZpZHVhbCBkcmFmdCB0byB0aGlzIGdyb3VwIGFuZCBo b3BlIHRvIGdldCB5b3VyIGNvbW1lbnRzLiBGaXJzdCwgSSBnaXZlIGFuIGludHJvZHVjdGlvbiBh cyBmb2xsb3dzOg0KICBJUHY2IHdpbGwgcmVwbGFjZSBJUHY0IGdyYWR1YWxseSBpbiBuZXh0IGdl bmVyYXRpb24gbmV0d29yay4gQWxvbmcgd2l0aCB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhlIHdpcmVs ZXNzIElQIHRlY2hub2xvZ2llcywgbW9yZSBhbmQgbW9yZSBwZW9wbGUgaGF2ZSB0aGUgY2hhbmNl IHRvIHVzZSB3aXJlbGVzcyBlcXVpcG1lbnQgYWNjZXNzaW5nIG5ldHdvcmsuIFRoZXkgd2lsbCBs aWtlaW5nIHRoaXMgbWV0aG9kIGdyYWR1YWxseSBhbmQgYmVpbmcgaW4gdGhlIGhhYml0IG9mIGFj Y2Vzc2luZyB3aXJlbGVzcyBuZXR3b3JrLiBOb3cgdGhlcmUgYXJlIG1vcmUgdGhhbiAyMDAgbWls bGlvbnMgb2YgbW9iaWxlIHRlcm1pbmFsIHVzZXJzIHN1Y2ggYXMgbW9iaWxlIHBob25lIHVzZXJz IGluIENoaW5hLiBNdWx0aWNhc3QgaXMgYWxzbyBhIGhvdCBwb2ludCBhbmQgbWFueSByZXNlYXJj aCBoYXZlIGJlZW4gc3R1ZHllZCBpbiBpdC4gVGhlcmUgaGF2ZSBiZWVuIG1hbnkgbXVsdGljYXN0 IHJvdXRlIHByb3RvY29scywgc3VjaCBhcyBEVk1SUCwgTU9TUEYsIE1TRFAsIEJHTVAgYW5kIFBJ TS1TU00gYW5kIHNvIG9uLiBVbmZvcnR1bmF0ZWx5IHRoZXkgYXJlIG5vdCBzdWl0IHRvIG1vYmls aXR5IHdpcmVsZWxlc3MgbmV0d29yay4gU3VwcG9ydGluZyB0aGUgbW9iaWxpdHkgYW5kIG11bHRp Y2FzdCB3aWxsIGJlY29tZXMgdGhlIGluZXZpdGFibGUgZnVuY3Rpb24gaW4gbmV4dCBnZW5lcmF0 aW9uIG5ldHdvcmsuIFNvIGhvdyB0byBzdXBwb3J0IG11bHRpY2FzdCBpbiBtb2JpbGUgSVB2NiBu ZXR3b3JrIGlzIGEgaW5ldml0YWJsZSBxdWVzdGlvbi4gVGhlIHJlc2VhcmNoIGluIG1vYmlsZSBt dWx0aWNhc3QgaXMgaW1wb3J0YW50IGFuZCBuZWNlc3NhcnkuIA0KICBIb3dldmVyIHdlIGZhY2Ug dGhlIGNoYWxsZW5nZSB0byBjb21iaW5lIG1vYmlsZSBJUCB3aXRoIG11bHRpY2FzdCBub3cuIFRo ZXJlIGFyZSBtYW55IGRpZmZpY3VsdGllcyBkdXJpbmcgdGhlIHJlc2VhcmNoZXMuIEZpcnN0IHRo ZSBleGlzdGluZyBJUCBtdWx0aWNhc3QgcHJvdG9jb2xzIGNhbqGvdCBzYXRpc2Z5IHRoZSBuZWVk cyBvZiBub2RlIGZvciBtb2JpbGl0eS4gU2Vjb25kIHRoZSBoYW5kb2ZmIHRpbWUgb2YgbW9iaWxl IG5vZGUgYW5kIHRoZSBkZWxheSB1c2VkIGluIHJlam9pbmluZyBpbiBtdWx0aWNhc3QgZ3JvdXAg aXMgdG9vIGxvbmcgLCBzbyBpdCBjYW6hr3QgbWVldCB0aGUgcmVxdWlyZW1lbnQgb2YgUW9TIHll dC4gVGhpcmQgdGhlIHJlY29uc3RydWN0aW9uIG9mIG11bHRpY2FzdCB0cmVlIGNhdXNlZCBieSB0 aGUgTU4gaGFuZG9mZiBpbiB0aGUgc3VibmV0IGZyZXF1ZW50bHkgYnVyZGVuIHRoZSBuZXR3b3Jr IGxvYWQuIEZvdXJ0aCB0aGUgZXhpc3RpbmcgbW9iaWxlIElQIG11bHRpY2FzdCBwcm90b2NvbHMg aGF2ZSB0aGUgcHJvYmxlbXMgb2YgdHJpYW5nbGUgcm91dGUgYW5kIHR1bm5lbCBjb25ncmVnYXRp b24uIEFib3ZlIGFsbCB0aGUgb3B0aW1pemF0aW9uIGRlc2lnbiBmb3IgbW9iaWxlIG11bHRpY2Fz dCByb3V0ZSBpcyB2ZXJ5IGltcG9ydGFudC4NCiAgRm9yIGNvbnF1ZXJ2aW5nIHRoZSBhYm92ZSBw cm9ibGVtcywgd2UgcHJvcG9zZSBhIERNQSAoRHluYW1pYyBNdWx0aWNhc3QgQWdlbnQpIGFwcHJv YWNoIGluIG91ciBkcmFmdC4gVGhlIERNQSBhcHByb2FjaCBpcyBiYXNlZCBvbiB0aGUgcG9ycG9z ZWQgTUlQLUJUIChNb2JpbGUgSVAgqEMgQmlkaXJlY3Rpb25hbCB0dW5uZWwpIGFuZCBNSVAtUlMg KE1vYmlsZSBJUCCoQyBSZW1vdGUgU3Vic2NyaXB0aW9uKS4gVGhlIE1JUC1CVCB1c2UgYSBiaS1k aXJlY3Rpb25hbCB0dW5uZWwgYmV0d2VlbiBhIE1OIHdpdGggaXRzIEhBIHRvIHN1cHBvcnQgbXVs Y2FzdCBpbiBtb2JpbGUgbmV0d29yay4gVGhlIE1JUC1SUyB1c2luZyBhIG11bHRpY2FzdCByb3V0 ZXIgaW4gYSBmb3JlaWduIHN1Ym5ldCBiZWluZyB2aXNpdGVkIHRvIHN1cHBvcnQgbXVsdGljYXN0 IGluIG1vYmlsZSBuZXR3b3JrLiBUaGVzZSB0d28gbWV0aG9kcyBjYW4gcmVtYWluIHRoZSBtdWx0 aWNhc3QgY29tbXVuaWNhdGlvbnMgd2hlbiBNTnMgbW92ZSwgYnV0IHRoZXJlIGFyZSBzb21lIGRp c2FkdmFudGFnZXMgYWJvdXQgdGhlbS4gVG8gTUlQLUJULCB0aGUgdHJpYW5nbGUgcm91dGUgcHJv YmxlbSB3aWxsIGFkZCB0aGUgbmV0d29yayBjb3N0IGFuZCB0aGUgdHVubmVsIGNvbmdyZWF0aW9u IHByb2JsZW0gY2FuIG5vdCBiZSBzb2x2ZWQgeWV0LiBUbyBNSVAtUlMsIHdoZW4gdGhlIGhhbmRv ZmYgb2NjdXJlcyBmcmVxdWVudGx5LCB0aGUgcmVqb2luIG9mIGEgTU4gYW5kIHRoZSByZWNvbnN0 cnVjdGlvbiBvZiBtdWx0aWNhc3QgdHJlZSB3aWxsIGNhdXNlIHRvbyBsb25nIGRlbGF5IGFuZCB0 b28gbXVjaCBjb3N0Lg0KVGhlIERNQSBjb25xdWVycyB0aGUgcHJvYmxlbXMgaW4gTUlQLUJUIGFu ZCBNSVAtUlMuIFRoZSBETUEgYXBwcm9hY2ggaW5jbHVkZXMgdGhyZWUgY29uY2VwdHMgb2YgTVNB IChNdWx0aWNhc3Qgc3VibmV0IEFnZW50KSwgRE1BIGFuZCBUdW5uZWwgU3RhdGUuIFRoZSBhcHBy b2FjaCBpcyBhIGNvbWJpbmF0aW9uIG9mIE1JUC1CVCBhbmQgTUlQLVJTLCBhbmQgaXQgaXMgYWxz byBhIGh5YnJpZCBzb2x1dGlvbiBvZiBtb3ZlbWVudCBiYXNlZCBtZXRob2QgYW5kIGRpc3RhbmNl IGJhc2VkIG1ldGhvZC4gU3VjaCBhIGNvbmZpZ3VyYXRpb24gYWxsb3dzIE1OcyB0byBvcHRpbWl6 ZSBtdWx0aWNhc3Qgcm91dGVzLCBhbmQgbWVhbndoaWxlIHJlZHVjZSB0aGUgbnVtYmVyIG9mIGhh bmRvZmZzIGJ5IHNlbGVjdGluZyBuZXcgbXVsdGljYXN0IGFnZW50cyBkeW5hbWljYWxseS4gSW4g YWRkaXRpb24gdG8gd2Vha2VuaW5nIHRoZSB0cmlhbmdsZSByb3V0ZSBwcm9ibGVtIGFuZCBkaW1p bmlzaGluZyB0aGUgaW5mbHVlbmNlIG9mIGhhbmRvZmYgdG8gbXVsdGljYXN0DQpBIHRocm91Z2hu ZXNzIGZsb3cgY2hhcnQgb2YgRE1BIGFwcHJvYWNoLCB0aGUgb3BlcmF0aW9uIG9mIE1TQSBhbmQg ZHluYW1pYyBtdWx0aWNhc3QgYWdlbnQgc2VsZWN0aW9uIGFsbCBoYXZlIGJlZW4gZ2l2ZW4uIFRo ZSBtYXRobWF0aWNzIGFuYWx5c2lzIGFuZCBzaW11bGF0aW9uIGluIE5TIGFyZSBhbHNvIGNvbXBs ZXRlZC4gVGhlIHJlc3VsdHMgaW4gc2ltdWxhdGlvbiBkZW5vdGUgdGhhdCBETUEgYXBwcm9hY2gg Y2FuIGVmZmVjdGl2ZWx5IHJlZHVjZXMgdGhlIHJlY29uc3RydWN0aW5nIG9mIG11bHRpY2FzdCB0 cmVlIGFuZCB0aGUgbXVsdGljYXN0IHBhY2thZ2VzIGNhbiBiZSBmb3J3YXJkZWQgdGhyb3VnaCBv cHRpbWFsIHBhdGguICAgDQogIFRoZSBETUEgYXBwcm9hY2ggY2FuIGltcHJvdmluZyB0aGUgbmV0 d29yayBwZXJmb3JtYW5jZSBlZmZlY3RpdmVseSBhbmQgYWRhcHQgdG8gdGhlIG1vYmlsZSBJUHY2 IG11bHRpY2FzdC4NCkF0IGxhc3QsIEkgaG9wZSB0byBnZXQgeW91ciBoZWxwIHRvIG1ha2UgdGhp cyBkcmFmdCB3b25kZXJmdWwgYW5kIHRvIHByZXNlbnQgaXQgYXQgdW5jb21pbmcgSUVURiBpbiBQ YXJpcy4NCkJlc3QgcmVnYXJkcyB3aXRoIG1hbnkgdGhhbmtzIA0KSG9uZy1LZSBaaGFuZyANCg0K IAkJCQkNCg0KoaGhoaGhoaGhoaGhoaGhoUhLemhhbmcNCqGhoaGhoaGhoaGhoaGhoaFIS3poYW5n QGNlbnRlci5uanR1LmVkdS5jbg0KoaGhoaGhoaGhoaGhoaGhoaGhoaEyMDA1LTA2LTAyDQo= --=====001_Dragon262426740658_===== Content-Type: application/octet-stream; name="draft-zhang-mipv6-multicast-dma-00.txt" Content-Disposition: attachment; filename="draft-zhang-mipv6-multicast-dma-00.txt" Content-Transfer-Encoding: base64 DQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEhvbmctS2UgWmhhbmcNCkRvY3VtZW50OiBkcmFmdC16aGFuZy1taXB2Ni1tdWx0aWNhc3Qt ZG1hLTAwLnR4dCAgICAgICAgICAgICAgICBCbyBTaGVuDQpFeHBpcmVzOiBOb3ZlbWJlciAyMDA1 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJpbmctWWkgWmhhbmcNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQmVpamluZyBKaWFvdG9uZyBVbml2ZXJz aXR5IElQIExhYg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIE1heSAyMDA1DQoNCg0KICAgICAgICAgIE1vYmlsZSBJUHY2IE11 bHRpY2FzdCB3aXRoIER5bmFtaWMgTXVsdGljYXN0IEFnZW50DQogICAgICAgICAgIDxkcmFmdC16 aGFuZy1taXB2Ni1tdWx0aWNhc3QtZG1hLTAwLnR4dD4NCg0KDQpTdGF0dXMgb2YgdGhpcyBNZW1v IA0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBpbiBmdWxs IGNvbmZvcm1hbmNlIA0KICAgd2l0aCBhbGwgcHJvdmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mIFJG QzIwMjYuIA0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRo ZSBJbnRlcm5ldCBFbmdpbmVlcmluZyANCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMs IGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgICAgDQogICBvdGhlciBncm91cHMg bWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERy YWZ0cy4gDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IA0KICAgbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFj ZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMNCiAgIGF0IGFueSB0aW1lLiAgSXQg aXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIA0KICAgcmVmZXJlbmNl IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz LiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vz c2VkIGF0IA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50 eHQgDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2Fu IGJlIGFjY2Vzc2VkIGF0IA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s LiANCg0KQWJzdHJhY3QgDQoNCiAgIFRoaXMgZG9jdW1lbnQgYWRkcmVzc2VzIHRoZSBpc3N1ZSBv ZiBkZWxpdmVyaW5nIElQdjYgbXVsdGljYXN0IA0KICAgdHJhZmZpYyB0byBNTiAobW9iaWxlIG5v ZGVzKS4gQW4gYXBwcm9hY2gsbmFtZWQgRE1BIChEeW5hbWljIA0KICAgTXVsdGljYXN0IEFnZW50 KSxpcyBwcm9wb3NlZC4gVGhlIGFwcHJvYWNoIGlzIGEgY29tYmluYXRpb24gb2YgTUlQLQ0KICAg QlQgYW5kIE1JUC1SUyBbMV0sIGFuZCBpcyBhbHNvIGEgaHlicmlkIHNvbHV0aW9uIG9mIE1vdmVt ZW50IA0KICAgQmFzZWQgTWV0aG9kIFsyXSBhbmQgRGlzdGFuY2UgQmFzZWQgTWV0aG9kIFszXS4g U3VjaCBhIGNvbmZpZ3VyYXRpb24gDQogICBhbGxvd3MgTU5zIHRvIG9wdGltaXplIG11bHRpY2Fz dCByb3V0ZXMsIGFuZCByZWR1Y2UgdGhlIG51bWJlciBvZiANCiAgIGhhbmRvZmZzIGJ5IHNlbGVj dGluZyBuZXcgbXVsdGljYXN0IGFnZW50cyBkeW5hbWljYWxseS4gDQogICBJbiBhZGRpdGlvbiB0 byB3ZWFrZW5pbmcgdGhlIHRyaWFuZ2xlIHJvdXRlIHByb2JsZW0gYW5kIGRpbWluaXNoaW5nIA0K ICAgdGhlIGluZmx1ZW5jZSBvZiBoYW5kb2ZmIHRvIG11bHRpY2FzdCwgdGhpcyBhcHByb2FjaCBw cm92aWRlcyBnbG9iYWwgDQogICBtb2JpbGl0eSBpbiB0aGUgSW50ZXJuZXQgd2l0aCBubyByZXN0 cmljdGlvbiBvZiBuZXR3b3JrIA0KICAgdG9wb2xvZ2llcy4NCg0KDQpIb25nLUtlIFpoYW5nIGV0 IGFsLiAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDA1ICAgICAgIFtQYWdlIGldDQoN Cg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgTW9iaWxlIElQdjYgTXVsdGljYXN0IHdpdGggRE1B ICAgICAgICAgTWF5IDIwMDUNClRhYmxlIG9mIENvbnRlbnRzIA0KDQogICBTdGF0dXMgb2YgdGhp cyBNZW1vLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uaQ0K ICAgQWJzdHJhY3QuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLmkNCiAgIDEuIEludHJvZHVjdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xDQogICAxLjEgTW90aXZhdGlvbi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMQ0KICAgMS4yIENv bnZlbnRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjINCiAgIDIuIER5bmFtaWMgTXVsdGljYXN0IEFnZW50IGZvciBNb2JpbGUgSVB2NiBNdWx0 aWNhc3QuLi4uLi4uLi4uLi4uLi4yDQogICAyLjEgVGhlIEJhc2ljIElkZWEuLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMg0KICAgMi4yIE9wZXJhdGlvbiBv ZiBNU0EuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMNCiAg IDIuMyBEeW5hbWljIE11bHRpY2FzdCBBZ2VudCBTZWxlY3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi41DQogICAzLiBDb25jbHVzaW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNw0KICAgQWNrbm93bGVkZ2VtZW50cy4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcNCiAgIENvcHlyaWdo dCBOb3RpY2UuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li44DQoNCjEuIEludHJvZHVjdGlvbg0KDQogICAxLjEgTW90aXZhdGlvbg0KICAgTXVsdGljYXN0 IGlzIGFuIGVmZmljaWVudCB3YXkgZm9yIGZvcndhcmRpbmcgZGF0YSBmcm9tIG9uZSBub2RlIG9y IA0KICAgbXVsdGktbm9kZXMgdG8gbXVsdGktbm9kZXMuIFN1cHBvcnRpbmcgbW9iaWxpdHkgYmVj b21lcyBhbiANCiAgIGluZXZpdGFibGUgZnVuY3Rpb24gb2YgbXVsdGljYXN0IHRlY2hub2xvZ2ll cy4NCiAgDQogICBUaGUgbW9iaWxpdHkgc3VwcG9ydCBmb3IgSVB2NiBwcm90b2NvbCBbMV0gc3Bl Y2lmaWVzIHR3byBiYXNpYyANCiAgIG1ldGhvZHMgZm9yIG1vYmlsZSBtdWx0aWNhc3Q6ICgxKSBh IGJpLWRpcmVjdGlvbmFsIHR1bm5lbCBmcm9tIGEgTU4gDQogICB0byBpdHMgSEEgKEhvbWUgQWdl bnQpLCBjYWxsZWQgTUlQLUJUIChNb2JpbGUgSVAtQmktZGlyZWN0aW9uYWwgDQogICB0dW5uZWwp OyAoMikgYSAobG9jYWwpIG11bHRpY2FzdCByb3V0ZXIgb24gdGhlIGZvcmVpZ24gbGluayBiZWlu ZyANCiAgIHZpc2l0ZWQsIGNhbGxlZCBNSVAtUlMgKE1vYmlsZSBJUC1SZW1vdGUgU3Vic2NyaXB0 aW9uKS4gSW4gTUlQLUJULCANCiAgIHRoZSBNTiB0dW5uZWxzIGl0cyBtdWx0aWNhc3QgZ3JvdXAg bWVtYmVyc2hpcCBjb250cm9sIHBhY2tldHMgdG8gaXRzIA0KICAgSEEsIGFuZCBhbHNvIHRoZSBI QSBmb3J3YXJkcyBtdWx0aWNhc3QgcGFja2V0cyBkb3duIHRoZSB0dW5uZWwgdG8gdGhlIA0KICAg TU4gWzFdLiBJbiBNSVAtUlMsIHRoZSBNTiBNVVNUIHVzZXMgaXRzIGNhcmUtb2YgYWRkcmVzcyBh bmQgTVVTVCBOT1QgDQogICB1c2UgdGhlIEhvbWUgQWRkcmVzcyBkZXN0aW5hdGlvbiBvcHRpb24g d2hlbiBzZW5kaW5nIE1MRCAoTXVsdGljYXN0IA0KICAgTGlzdGVuZXIgRGlzY292ZXJ5KSBwYWNr ZXRzWzEsNF0uDQoNCiAgIFRoZSB0d28gYmFzaWMgbWV0aG9kcyBjYW4gcmV0YWluIG11bHRpY2Fz dCBjb21tdW5pY2F0aW9ucyB3aGVuIA0KICAgTU5zIG1vdmUuIEhvd2V2ZXIgc29tZSBpc3N1ZXMg c3RpbGwgZXhpc3QuDQoNCiAgICAgbyBGaXJzdCwgTUlQLUJUIHN1ZmZlcnMgdGhlIHRyaWFuZ2xl IHJvdXRlLHdoaWNoIGlzIGNvbXBvc2VkIG9mIE1ODQogICAgICAgLUhBIHR1bm5lbCBhbmQgSEEt UyBtdWx0aWNhc3QgdHJlZSBwYXRoLiBXaGVuIHRoZSBNTiBpcyBmYXIgZnJvbSANCiAgICAgICBp dHMgSEEsIHRoZSBkYXRhIGZvcndhcmRpbmcgcGF0aCBvZiBtdWx0aWNhc3QgYmVjb21lcyANCiAg ICAgICBkZXRlcmlvcmF0aXZlLg0KDQogICANCg0KDQpIb25nLUtlIFpoYW5nIGV0IGFsLiAgICAg ICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDA1ICAgICAgICBbUGFnZSAxXQ0KDQoNCklOVEVS TkVULURSQUZUICAgICAgICAgIE1vYmlsZSBJUHY2IE11bHRpY2FzdCB3aXRoIERNQSAgICAgICAg IE1heSAyMDA1DQogDQogICAgIG8gU2Vjb25kLCBtdWx0aXBsZSB0dW5uZWxzIGZyb20gYSBzdWJu ZXQgdG8gYSBIQSBhcmUgZXN0YWJsaXNoZWQgDQogICAgICAgaW4gTUlQLUJUIHdoZW4gc29tZSBN TnMsIHdoaWNoIGNvbWUgZnJvbSB0aGUgc2FtZSBob21lIGxpbmssDQogICAgICAgYXR0YWNoIGF0 IG9uZSBBUiAoQWNjZXNzIFJvdXRlcikgaW4gdGhlIHN1Ym5ldCxhbmQgdGhlc2UgTU5zIA0KICAg ICAgIGpvaW4gdGhlIHNhbWUgbXVsdGljYXN0IGdyb3VwIHNpbXVsdGFuZW91c2x5LiBUaGlzIGNh c2UgaXMgDQogICAgICAgY2FsbGVkIHR1bm5lbHMgY29uZ3JlZ2F0aW9uLCB3aGljaCBsZWFkcyB0 byBtb3JlIG5ldHdvcmsgDQogICAgICAgcmVzb3VyY2VzIGJlaW5nIGNvbnN1bWVkLg0KDQogICAg IG8gVGhpcmQsIGFsdGhvdWdoIHRoZSBtdWx0aWNhc3QgcGF0aCBpbiBNSVAtUlMgaXMgb3B0aW1h bCwgdGhlIA0KICAgICAgIGZyZXF1ZW50IGhhbmRvZmZzIG9mIGEgTU4sIHdoaWNoIGFyZSBkdWUg dG8gdGhlIG1vdmVtZW50IG9mIHRoZSANCiAgICAgICBNTiBhbW9uZyBzdWJuZXRzLCBwcm9kdWNl IG11Y2ggbGF0ZW5jeS4gVGhpcyBpcyBiZWNhdXNlIHRoZSANCiAgICAgICBoYW5kb2ZmIGFjdGlv biBtYWtlcyB0aGUgTU4gdG8gbGVhdmUgYW5kIHJlLWpvaW4gdGhlIG11bHRpY2FzdCANCiAgICAg ICBncm91cC4NCg0KICAgVGhpcyBkb2N1bWVudCBhZGRyZXNzZXMgdGhlc2UgcHJvYmxlbXMuIEFu IGFwcHJvYWNoIG5hbWVkIERNQSANCiAgIChEeW5hbWljIE11bHRpY2FzdCBBZ2VudCkgaXMgcHJv cG9zZWQsIHdoaWNoIGFjY2VwdHMgdGhlIG1lcml0cyBvZiANCiAgIE1JUC1CVCBhbmQgTUlQLVJT LiBETUEgdXNlcyBNb3ZlbWVudCBCYXNlZCBNZXRob2QgYW5kIERpc3RhbmNlIEJhc2VkIA0KICAg TWV0aG9kIHRvIHNlbGVjdCBhIG5ldyBtdWx0aWNhc3QgYWdlbnQgZHluYW1pY2FsbHksIGFuZCB0 aGUgbmV3IA0KICAgc2VsZWN0ZWQgYWdlbnQgaXMgcmVzcG9uc2libGUgZm9yIGZvcndhcmRpbmcg bXVsdGljYXN0IGRhdGEgDQogICB0byB0aGUgTU4uIFN1Y2ggYSBjb25maWd1cmF0aW9uIGFsbG93 cyBNTnMgb3B0aW1pemUgbXVsdGljYXN0IHJvdXRlcyANCiAgIGFuZCBtZWFud2hpbGUgcmVkdWNl IHRoZSBudW1iZXIgb2YgaGFuZG9mZnMuIEluIGFkZGl0aW9uIHRvIA0KICAgd2Vha2VuaW5nIHRo ZSB0cmlhbmdsZSByb3V0ZSBwcm9ibGVtIGFuZCBkaW1pbmlzaGluZyB0aGUgaW5mbHVlbmNlIA0K ICAgb2YgaGFuZG9mZiB0byBtdWx0aWNhc3QsIHRoaXMgYXBwcm9hY2ggcHJvdmlkZXMgZ2xvYmFs IG1vYmlsaXR5IGluIA0KICAgdGhlIEludGVybmV0IHdpdGggbm8gcmVzdHJpY3Rpb24gb2YgbmV0 d29yayB0b3BvbG9naWVzLg0KDQogICBJbiB0aGUgbmV4dCBzZWN0aW9ucywgd2Ugd2lsbCBmaXJz dCBpbnRyb2R1Y2UgdGhlIGJhc2ljIGlkZWEgb2YgDQogICB0aGUgRE1BLiBUaGVuLCB3ZSB3aWxs IGRlc2NyaWJlIHRoZSBkZXRhaWwgb2Ygb3BlcmF0aW9ucyBvZiBhIE1TQSANCiAgIChNdWx0aWNh c3QgU3VibmV0IEFnZW50KSBhbmQgRE1BIHNlbGVjdGlvbiBwcm9jZXNzLg0KDQogICAxLjIgQ29u dmVudGlvbnMNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJF RCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJF Q09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluDQogICB0aGlzIGRvY3VtZW50IGFy ZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDLTIxMTkgWzVdLg0KDQogICBU aGlzIGRvY3VtZW50IGlzIGEgcHJvZHVjdCBvZiAuLi4gLi4uIC4uLiAuLi4NCg0KMi4gRHluYW1p YyBNdWx0aWNhc3QgQWdlbnQgZm9yIE1vYmlsZSBJUHY2IE11bHRpY2FzdA0KDQogICAyLjEgVGhl IGJhc2ljIGlkZWENCg0KICAgSW4gdGhpcyBkb2N1bWVudCwgdGhyZWUgY29uY2VwdHMgYXJlIGRl ZmluZWQ6IE1TQSAobXVsdGljYXN0IHN1Ym5ldCANCiAgIEFnZW50KSwgRE1BIGFuZCBUdW5uZWwg U3RhdGUuDQoNCg0KSG9uZy1LZSBaaGFuZyBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTm92 ZW1iZXIgMjAwNSAgICAgICAgW1BhZ2UgMl0NCg0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICBN b2JpbGUgSVB2NiBNdWx0aWNhc3Qgd2l0aCBETUEgICAgICAgICBNYXkgMjAwNQ0KDQogICBNU0Eg aXMgdGhlIG9ubHkgbXVsdGljYXN0IGFjY2VzcyBwb2ludCBpbiBvbmUgc3VibmV0LiBJdCBpcyAN CiAgIHJlc3BvbnNpYmxlIGZvciBmb3J3YXJkaW5nIG11bHRpY2FzdCBkYXRhZ3JhbXMgdG8gZXZl cnkgTU4gdGhhdCANCiAgIHZpc2l0cyBpdHMgc3VibmV0LCBhbmQgdGhlIEFjY2VzcyBSb3V0ZXIg cnVubmluZyBtdWx0aWNhc3QgcHJvdG9jb2wgDQogICBpbiBhIHN1Ym5ldCBjYW4gYWN0IGFzIGEg TVNBLiBNU0EgaXMgaW4gY2hhcmdlIG9mIGxvY2FsIGR5bmFtaWMgDQogICBncm91cCBtZW1iZXJz aGlwIG1hbmFnZW1lbnQgaW5mb3JtYXRpb24gdmlhIE1MRCBwcm90b2NvbCwgYW5kIA0KICAgcGVy aW9kaWNhbGx5IHNlbmRzIHF1ZXJ5IG1lc3NhZ2VzIHRvIHNvbGljaXQgcmVwb3J0cyBvZiBhbGwg DQogICBtdWx0aWNhc3QgYWRkcmVzc2VzIHRoYXQgYXJlIGJlaW5nIGxpc3RlbmVkIHRvIGJ5IGxv Y2FsIGhvc3RzLg0KDQogICBUdW5uZWwgU3RhdGUgaXMgYSBmbGFnIGluIGV2ZXJ5IGVudHJ5IG9m IG11bHRpY2FzdCByb3V0ZSB0YWJsZSB0aGF0IA0KICAgaXMgbWFpbnRhaW5lZCBieSBNU0EuIEl0 IHJlcHJlc2VudHMgdGhlIHN0YXRlIG9mIGVhY2ggZ3JvdXAgRyAocmVjb3JkDQogICAtcyB3aGV0 aGVyIHRoZSBtdWx0aWNhc3QgcGFja2V0cyBhcmUgcmVjZWl2ZWQgdGhyb3VnaCB0dW5uZWwpLg0K DQogICBXaGVuIGEgTU4gZmlyc3Qgam9pbnMgYSBtdWx0aWNhc3QgZ3JvdXAgdGhyb3VnaCBhIE1T QSwgdGhlIE1TQSANCiAgIGJlY29tZXMgdGhlIGN1cnJlbnQgRE1BIG9mIHRoZSBNTi4gQmVmb3Jl IGEgbmV3IERNQSBpcyBzZWxlY3RlZCwgdGhlIA0KICAgY3VycmVudCBETUEgcmVjZWl2ZXMgbXVs dGljYXN0IGRhdGEgZnJvbSB0aGUgdHJlZS4gV2hlbiB0aGUgTU4gDQogICBsZWF2ZXMgdGhlIHN1 Ym5ldCB3aGljaCBpdHMgRE1BIGlzIGluIGFuZCBhdHRhY2hlcyBhdCBhIG5ldyBzdWJuZXQsIA0K ICAgdGhlIE1TQSBpbiB0aGUgbmV3IHN1Ym5ldCBnZXRzIG11bHRpY2FzdCBkYXRhIHRocm91Z2gg dGhlIHR1bm5lbCANCiAgIGZyb20gdGhlIE1TQSB0byB0aGUgTU4ncyBETUEsIGFuZCB0aGVuIGZv cndhcmRzIHRoZSBkYXRhIHRvIHRoZSBNTi4gDQogICBUaGUgY3VycmVudCBNU0EgZXhjaGFuZ2Vz IE1MRCBpbmZvcm1hdGlvbiB3aXRoIHRoZSBNTidzIERNQSB0aHJvdWdoIA0KICAgdGhlIHR1bm5l bCBhbHNvLg0KDQogICBFYWNoIE1OIGNvcnJlc3BvbmRzIHdpdGggYSBETUEgd2hpY2ggaXMgc2Vs ZWN0ZWQgZHluYW1pY2FsbHkgDQogICBhY2NvcmRpbmcgdG8gcGFzc2VkIHBhdGggb2YgTU4uIFRo ZSBETUEgc2VsZWN0aW5nIG1ldGhvZCBhbmQgDQogICBjb25kaXRpb25zIGFyZSBkZXNjcmliZWQg aW4gdGhlIG5leHQgc3ViLXNlY3Rpb24uIEEgTVNBIHdpbGwgam9pbiANCiAgIG11bHRpY2FzdCB0 cmVlIGRpcmVjdGx5IGlmIGl0IGlzIHNlbGVjdGVkIGFzIGEgRE1BLiANCg0KICAgRHluYW1pYyBz ZWxlY3Rpb24gb2YgRE1BIGNhbiBvcHRpbWl6ZSBtdWx0aWNhc3QgdHJhbnNtaXQgcGF0aHMgZHVl IA0KICAgdG8gdGhlIHNob3J0ZXN0IHBhdGggZnJvbSBETUEgdG8gbXVsdGljYXN0IHNvdXJjZS4g RXhjZXNzaXZlbHkgbG9uZyANCiAgIHR1bm5lbHMgY2FuIGJlIGF2b2lkZWQgYmVjYXVzZSBvZiB0 aGUgc2hvcnQgZGlzdGFuY2UgYmV0d2VlbiBETUEgYW5kIA0KICAgc3VibmV0LiBUaGUgRE1BIGNh biBtYWtlIGdvb2QgdXNlIG9mIG5ldHdvcmsgcmVzb3VyY2VzIGFuZCBhdm9pZCANCiAgIGNob2tl IHBvaW50cyBvZiB0aGUgbmV0d29yaywgY29tcGFyZWQgd2l0aCBzdGF0aWMgc3VibmV0IGFnZW50 LiANCiAgIFR1bm5lbCBTdGF0ZSBtYWtlcyBzdXJlIHRoYXQgdGhlcmUgaXMgb25seSBvbmUgbXVs dGljYXN0IGFnZW50DQogICBwcm92aWRpbmcgc2VydmljZSwgd2hpY2ggY29ycmVzcG9uZHMgd2l0 aCBNTnMgb2YgYSBuZXctam9pbiBtdWx0aWNhc3QNCiAgIGdyb3VwIGluIGEgc3VibmV0LiBJdCBj YW4gYWxzbyBhdm9pZCB0aGUgdHVubmVsIGNvbmdyZWdhdGlvbiBwcm9ibGVtLg0KICAgV2hlbiBh IE1OIG1vdmVzIGZyb20gYSBzdWJuZXQgdG8gYW5vdGhlciBzdWJuZXQsIGl0IGRvZXMgbm90IG5l ZWQgdG8gDQogICByZWpvaW4gbXVsdGljYXN0IHRyZWVzIGR1ZSB0byBETUEuIFNvIHRoZSBpbXBh Y3Qgb24gdGhlIG11bHRpY2FzdA0KICAgdHJlZSBpcyByZWR1Y2VkLg0KDQogICAyLjIgT3BlcmF0 aW9uIG9mIE1TQQ0KDQogICBFYWNoIE1TQSBtYWludGFpbnMgYSBWaXNpdG9yIFRhYmxlLiBUaGVy ZSBhcmUgdHdvIGVsZW1lbnRzIGtlcHQgaW4gDQogICBldmVyeSBlbnRyeSBvZiB0aGUgVmlzaXRv ciBUYWJsZTogTU4gaXRlbSBhbmQgRE1BIGl0ZW0uIFRoZSBtZWFuaW5ncyANCiAgIGFyZToNCg0K SG9uZy1LZSBaaGFuZyBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAwNSAg ICAgICAgW1BhZ2UgM10NCg0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICBNb2JpbGUgSVB2NiBN dWx0aWNhc3Qgd2l0aCBETUEgICAgICAgICBNYXkgMjAwNQ0KDQogICAgIG8gTU4gaXRlbSByZWNv cmRzIHRoZSBtb2JpbGUgbm9kZXMgdGhhdCB2aXNpdCB0aGUgc3VibmV0IHRoZSBNU0EgDQogICAg ICAgYmVsb25ncyB0byBhbmQgbmVlZCB0byBiZSBzZXJ2ZWQ7DQoNCiAgICAgbyBETUEgaXRlbSBy ZWNvcmRzIHdoaWNoIE1TQSBpcyBzZWxlY3RlZCBhcyB0aGUgTU4ncyBETUEuDQoNCiAgICAgICAg ICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgICAgICAgICAgICB8ICBNTiAg IHwgICAgRE1BICAgfA0KICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLXwNCiAg ICAgICAgICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAt LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogICBPbiBhcnJpdmluZyBhdCBhIG5ldyBmb3JlaWduIG5l dHdvcmssIGEgTU4gb2J0YWlucyBhIG5ldyBDb0EgKGNhcmUtDQogICBvZiBhZGRyZXNzKS4gVGhl IE1OIHJlZ2lzdGVycyBpdHMgY3VycmVudCBDb0Egd2l0aCBpdHMgSEEsIGFuZCB0aGVuIA0KICAg dGhlIE1OIGltbWVkaWF0ZWx5IHNlbmRzIG1lc3NhZ2UgdG8gaXRzIGN1cnJlbnQgc3VibmV0J3Mg TVNBLiBUaGUgDQogICBtZXNzYWdlIG1haW5seSBjb250YWlucyB0aGUgTUxEIGdyb3VwIG1lbWJl cnNoaXAgcmVwb3J0IG1lc3NhZ2UgYW5kIA0KICAgdGhlIElQIGFkZHJlc3Mgb2YgcE1TQSAocHJl dmlvdXMgc3VibmV0J3MgTVNBKS4gV2hlbiByZWNlaXZpbmcgdGhlIA0KICAgTUxEIGdyb3VwIG1l bWJlcnNoaXAgcmVwb3J0IG1lc3NhZ2UgdGhhdCBpcyBzZW50IGJ5IGEgbmV3IHZpc2l0b3IgZm9y IA0KICAgZ3JvdXAgRywgdGhlIGRldGFpbCBvcGVyYXRpb25zIG9mIHRoZSBNU0EgYXJlIGFzIGZv bGxvd3M6DQoNCiAgICAgbyBJZiB0aGUgTVNBIGFscmVhZHkgaGFzIGFuIGVudHJ5IGZvciBncm91 cCBHIGluIGl0cyBtdWx0aWNhc3QgDQogICAgICAgcm91dGUgdGFibGUsIGFkZCBNTiB0byB0aGUg ZW50cnkncyBvdXRnb2luZyBpbnRlcmZhY2UgbGlzdCwgYW5kIA0KICAgICAgIHRoZW4gZXhhbWlu ZSB0aGUgVHVubmVsIFN0YXRlLiBJZiB0aGUgVHVubmVsIFN0YXRlIGlzICdZRVMnLCBpdCANCiAg ICAgICBpbmRpY2F0ZXMgdGhhdCB0aGUgTVNBIGhhcyBhbHJlYWR5IGNyZWF0ZWQgdGhlIHR1bm5l bCBmb3IgdGhlIA0KICAgICAgIGdyb3VwIGFuZCBpcyByZWNlaXZpbmcgbXVsdGljYXN0IGRhdGFn cmFtcyB2aWEgdGhlIHR1bm5lbC4gSW4NCiAgICAgICB0aGlzIGNhc2UsIGl0IG9ubHkgcmVxdWly ZXMgZm9yd2FyZGluZyB0aGUgTUxEIGdyb3VwIG1lbWJlcnNoaXAgDQogICAgICAgcmVwb3J0IG1l c3NhZ2UgdG8gdGhlIG90aGVyIGVuZCBvZiB0aGUgdHVubmVsLiBJZiB0aGUgZW50cnkgDQogICAg ICAgcmVsYXRlZCB0byB0aGUgTU4gZXhpc3RzIGluIHRoZSBNU0EncyBWaXNpdG9yIFRhYmxlLCB0 aGVuIHRoZSANCiAgICAgICBNU0EgaXMgaG9sZGluZyBpdC4gT3RoZXJ3aXNlIGlmIHRoZXJlIGlz IG5vIGVudHJ5IHJlbGF0ZWQgdG8gdGhlDQogICAgICAgTU4gaW4gaXRzIFZpc2l0b3IgVGFibGUs IGl0IGNyZWF0ZXMgYSBuZXcgZW50cnkgZm9yIHRoZSBNTi4gSW4gDQogICAgICAgb3JkZXIgdG8g b3B0aW1pemUgdGhlIGRlbGl2ZXJ5IHBhdGgsIHRoZSBNU0Egb2YgdGhlIGN1cnJlbnQNCiAgICAg ICBzdWJuZXQgaXMgc2VsZWN0ZWQgYXMgdGhlIERNQSBvZiBhIE1OIGFjY29yZGluZyB0byBjZXJ0 YWluIHJ1bGVzLg0KICAgICAgIEluIHRoaXMgY2FzZSwgY3VycmVudCBzdWJuZXQncyBNU0EgYWRk cyBhbiBlbnRyeSBpbiBpdHMgTVNBIGxpc3QgDQogICAgICAgKGRldGFpbGVkIGluIG5leHQgc3Vi LXNlY3Rpb24pIHRvIHJlY29yZCB0aGUgbW92ZW1lbnQgcGF0aCBvZiANCiAgICAgICB0aGUgTU4u IEFuZCB0aGVuIHRoZSBjdXJyZW50IHN1Ym5ldCdzIE1TQSBjb21tdW5pY2F0ZXMgd2l0aCB0aGUg DQogICAgICAgTVNBIG9mIHRoZSBwcmV2aW91cyBzdWJuZXQgdGhhdCBNTiB2aXNpdGVkIHRvIG9i dGFpbiB0aGUgSVAgDQogICAgICAgYWRkcmVzcyBvZiB0aGUgcHJldmlvdXMgRE1BLCBhbmQgaW5m b3JtcyB0aGUgcHJldmlvdXMgRE1BIHRvIA0KICAgICAgIGRlbGV0ZSBhbGwgZGF0YSBzdHJ1Y3R1 cmVzIHRoYXQgYXJlIHJlbGF0ZWQgdG8gdGhlIE1OLg0KICAgDQogICAgIG8gSWYgdGhlIE1TQSBo YXMgbm8gZW50cnkgZm9yIGdyb3VwIEcgaW4gaXRzIG11bHRpY2FzdCByb3V0ZSANCiAgICAgICB0 YWJsZSwgaXQgaW5kaWNhdGVzIHRoYXQgdGhlIE1OIGlzIHRoZSBmaXJzdCBncm91cCBtZW1iZXIg b2YgDQogICAgICAgZ3JvdXAgRyBpbiB0aGUgc3VibmV0LCB0aGVuIE1TQSBjcmVhdGVzIGEgbmV3 IGVudHJ5IGZvciBncm91cCBHIA0KICAgICAgIGluIGl0cyBtdWx0aWNhc3Qgcm91dGUgdGFibGUg YW5kIGFkZHMgdGhlIE1OIHRvIHRoZSBlbnRyeSdzIA0KICAgICAgIG91dGdvaW5nIGludGVyZmFj ZSBsaXN0Lg0KDQogIEhvbmctS2UgWmhhbmcgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE5v dmVtYmVyIDIwMDUgICAgICBbUGFnZSA0XQ0KDQoNCklOVEVSTkVULURSQUZUICAgICAgICAgIE1v YmlsZSBJUHY2IE11bHRpY2FzdCB3aXRoIERNQSAgICAgICAgIE1heSAyMDA1DQoNCiAgICAgbyBJ ZiB0aGVyZSBhbHJlYWR5IGV4aXN0cyBhbiBlbnRyeSByZWxhdGVkIHRvIHRoZSBNTiBpbiB0aGUg TVNBJ3MgDQogICAgICAgVmlzaXRvciBUYWJsZSwgb25seSB3aGVuIHRoZSBNU0Egb2YgY3VycmVu dCBzdWJuZXQgYWN0cyBhcyB0aGUgDQogICAgICAgRE1BIG9mIHRoZSBNTiBpbiB0aGlzIGVudHJ5 LCB0aGUgTVNBIHNpbXBseSBzZW5kcyBqb2luIG1lc3NhZ2VzIA0KICAgICAgIHRvIHRoZSBtdWx0 aWNhc3QgdHJlZS4gT3RoZXJ3aXNlIGlmIHRoZSBETUEgaXMgbm90IHRoZSBNU0Egb2YgDQogICAg ICAgY3VycmVudCBzdWJuZXQsIHRoZW4gc2V0IHRoZSBUdW5uZWwgU3RhdGUgdG8gJ1lFUycsIGNy ZWF0ZSB0dW5uZWwgDQogICAgICAgd2l0aCB0aGUgRE1BIG9mIE1OLCBhbmQgZm9yd2FyZCB0aGUg TUxEIGdyb3VwIG1lbWJlcnNoaXAgcmVwb3J0IA0KICAgICAgIG1lc3NhZ2UgdG8gdGhlIG90aGVy IGVuZCBvZiB0aGUgdHVubmVsLiANCg0KICAgICBvIElmIHRoZXJlIGlzIG5vIGVudHJ5IHJlbGF0 ZWQgdG8gdGhlIE1OIGluIGl0cyBWaXNpdG9yIFRhYmxlLCB0aGUgDQogICAgICAgTVNBIGNyZWF0 ZXMgb25lIGVudHJ5IGZvciB0aGUgTU4sIGNvbW11bmljYXRlcyB3aXRoIHRoZSBwTVNBIHRvIA0K ICAgICAgIG9idGFpbiB0aGUgSVAgYWRkcmVzcyBvZiB0aGUgcHJldmlvdXMgRE1BLCBhbmQgdGhl biBjb21tdW5pY2F0ZXMgDQogICAgICAgd2l0aCB0aGUgcERNQS4gSWYgdGhlIHBETUEgZG9lc24n dCByZS1zZWxlY3QgYSBuZXcgRE1BLCB0aGUgTVNBIA0KICAgICAgIGFkZHMgdGhlIHBETUEgdG8g dGhlIGVudHJ5IGFzIHRoZSBNTidzIGN1cnJlbnQgRE1BLCBzZXRzIHRoZSANCiAgICAgICBUdW5u ZWwgU3RhdGUgdG8gJ1lFUycsIGNyZWF0ZXMgdHVubmVsIHdpdGggdGhlIGN1cnJlbnQgRE1BIG9m IE1OLCANCiAgICAgICBhbmQgdGhlbiBmb3J3YXJkcyB0aGUgTUxEIGdyb3VwIG1lbWJlcnNoaXAg cmVwb3J0IG1lc3NhZ2UgdG8gDQogICAgICAgdGhlIG90aGVyIGVuZCBvZiB0aGUgdHVubmVsLiBJ ZiB0aGUgcERNQSByZS1zZWxlY3RzIGEgbmV3IERNQSwgDQogICAgICAgdGhlIE1TQSBvZiBjdXJy ZW50IHN1Ym5ldCB3b3JrcyBhcyB0aGUgbmV3IERNQSwgdGhlIE1TQSBzaW1wbHkgDQogICAgICAg c2VuZHMgam9pbiBtZXNzYWdlcyB0byB0aGUgbXVsdGljYXN0IHRyZWUsIGFuZCBhdCB0aGUgc2Ft ZSB0aW1lLCANCiAgICAgICB0aGUgY3VycmVudCBzdWJuZXQncyBNU0EgY3JlYXRlcyBhbmQgbWFp bnRhaW5zIGFuIGVudHJ5IGZvciB0aGUgDQogICAgICAgTU4gaW4gaXRzIE1TQSBsaXN0Lg0KICAg DQogICBBIE1OIGdyb3VwIG1lbWJlciBkb2Vzbid0IHNlbmQgYSBsZWF2aW5nIG1lc3NhZ2Ugd2hl biBpdCBkZXBhcnRzIGZyb20gDQogICB0aGUgY3VycmVudCBzdWJuZXQgdG8gdmlzaXQgYW5vdGhl cjsgdGhlIE1TQSBkZXRlY3RzIGl0cyBkZXBhcnR1cmUgYnkgDQogICB0aGUgdGltZW91dCBvZiB0 aW1lci4gV2hlbiB0aGUgTVNBIGRldGVjdHMgdGhhdCBhIE1OIGlzIGRlcGFydGluZyANCiAgIGZy b20gdGhlIGN1cnJlbnQgc3VibmV0LCBpdCBkZWxldGVzIHRoZSBlbnRyeSBtYWludGFpbmVkIGZv ciB0aGUgTU4gDQogICBpbiBpdHMgVmlzaXRvciBUYWJsZS4gRm9yIGVhY2ggbXVsdGljYXN0IGdy b3VwIEcgd2hpY2ggdGhlIA0KICAgbGVhdmluZyBNTiBoYXMgam9pbmVkLCB0aGUgTVNBIGRlbGV0 ZXMgdGhlIE1OIGZyb20gdGhlIGdyb3VwIEcgDQogICBlbnRyeSdzIG91dGdvaW5nIGludGVyZmFj ZSBsaXN0Lg0KDQogICAyLjMgRHluYW1pYyBNdWx0aWNhc3QgQWdlbnQgU2VsZWN0aW9uDQogICAN CiAgIEluIERNQSwgdGhlIGtleSBwb2ludCBpcyB0aGUgd2F5IG9mIERNQSByZS1zZWxlY3Rpbmcu IFRoZSBmb2xsb3dpbmcgDQogICBzZWxlY3Rpb24gcHJpbmNpcGxlcyBhcmUgYmFzZWQgb24gYm90 aCBNb3ZlbWVudCBhbmQgRGlzdGFuY2UsIGFuZCANCiAgIHRoZSBzZWxlY3Rpb24gb2YgRE1BIGNh biBiZSBwZXJmb3JtZWQgYnkgYSBNTidzIGN1cnJlbnQgRE1BIG9yIHRoZSANCiAgIE1OIGl0c2Vs Zi4gVGhlIGZvbGxvd2luZyBkZXNjcmlwdGlvbiBpbGx1c3RyYXRlcyB0aGUgZHluYW1pYyANCiAg IG11bHRpY2FzdCBhZ2VudCBzZWxlY3Rpb24gcHJvY2VzcyBieSBETUEuDQogICANCiAgIEVhY2gg TU4gY29ycmVzcG9uZHMgdG8gb25seSBvbmUgRE1BIGF0IG9uZSB0aW1lLiBETUEgaXMgYSANCiAg IG11bHRpY2FzdCByb3V0ZXIgd2hpY2ggcGFydGljaXBhdGVzIGluIEludGVybmV0IHJvdXRpbmcs IHByb3ZpZGVzIA0KICAgbXVsdGljYXN0IHNlcnZpY2UgZm9yIE1OLCBhbmQgYWN0cyBhcyBhbiBh Y2Nlc3MgcG9pbnQgZm9yIHRoZSBNTiB0byANCiAgIHRoZSBNYm9uZS4gRWFjaCBtdWx0aWNhc3Qg cm91dGVyIHdoaWNoIHdvcmtzIGFzIGEgRE1BIGZvciBhbiBNTiANCiAgIG1haW50YWlucyBhIHRh YmxlIGFuZCBjb21wdXRlcyBETUEgcmUtc2VsZWN0aW9uIGZvciBhbiBNTiB3aGljaCANCiAgIHNl bGVjdHMgaXQgYXMgaXRzIERNQSBhY2NvcmRpbmcgdG8gYSBzcGVjaWZpYyBydWxlLiBUaGUgdGFi bGUgDQoNCkhvbmctS2UgWmhhbmcgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE5vdmVtYmVy IDIwMDUgICAgICAgIFtQYWdlIDVdDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgTW9iaWxl IElQdjYgTXVsdGljYXN0IHdpdGggRE1BICAgICAgICAgTWF5IDIwMDUNCiAgDQogY2hhbmdlcyBk eW5hbWljYWxseSB3aXRoIHRoZSByb3V0ZSB3aGljaCB0aGUgTU4gcGFzc2VzIHRocm91Z2guIA0K ICAgVGhlIGNvcnJlc3BvbmRpbmcgRE1BLCB0aGVyZWZvcmUsaXMgc2VsZWN0ZWQgZHluYW1pY2Fs bHkgd2l0aCANCiAgIHRoZSBwb3NpdGlvbiBvZiB0aGUgTU4uIFRoYXQgaXMgd2h5IGl0IGlzIGNh bGxlZCBkeW5hbWljIG11bHRpY2FzdCANCiAgIGFnZW50IChETUEpLg0KDQogICBUaGUgTVNBIGxp c3Qgd2hpY2ggdGhlIGNvcnJlc3BvbmRpbmcgRE1BIG1haW50YWlucyB0aGUgZm9sbG93aW5nIA0K ICAgcmVjb3JkczoNCg0KICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAg ICAgICAgICAgICAgICAgIHwgIE1OICAgfCAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAt LS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgICAgICAgICAgfCAgTVNBICB8IEluY3JlbWVu dHwNCiAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS18DQogICAgICAgICAgICAg ICAgICB8IERNQSAgIHwgICAgMSAgICAgfA0KICAgICAgICAgICAgICAgICAgfCBNU0EgMSB8ICAg IDIgICAgIHwNCiAgICAgICAgICAgICAgICAgIHwgTVNBIDIgfCAgICAxICAgICB8DQogICAgICAg ICAgICAgICAgICB8IC4uLiAgIHwgICAuLi4gICAgfA0KICAgICAgICAgICAgICAgICAgfCBNU0Eg biB8ICAgIDMgICAgIHwNCiAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN CiAgIFRoZSBtZWFuaW5nIG9mIHRoZSBlbGVtZW50IGluIHRoZSBNU0EgbGlzdCBpcyBhcyBmb2xs b3dzOg0KICAgDQogICAgIG8gTU4gaXRlbSByZWNvcmRzIHRoZSBtb2JpbGUgbm9kZSB3aGljaCBz ZWxlY3RlZCB0aGUgTVNBIGFzIERNQTsNCiAgIA0KICAgICBvIE1TQSBpdGVtIHJlY29yZHMgTVNB IG9mIGVhY2ggc3VibmV0IHdoaWNoIE1OIHBhc3NlcyB0aHJvdWdoOw0KICAgICANCiAgICAgbyBJ bmNyZW1lbnQgaXRlbSByZWNvcmRzIG1haW50YWluIHRoZSBwYXRoIGluY3JlbWVudCBvZiB0aGUg TVNBLg0KICAgDQogICBUaGUgZWxlbWVudHMgb2YgZm9ybWluZyBNU0EgbGlzdCBjYW4gYmUgZGl2 aWRlZCBpbnRvIHRocmVlIA0KICAgY2F0ZWdvcmllczoNCiAgIA0KICAgICBvIElmIHRoZSBzdWJu ZXQgaXMgdGhlIGZpcnN0IHN1Ym5ldCB3aGljaCB0aGUgTU4gcGFzc2VzIHRocm91Z2gsIA0KICAg ICAgIHRoZSBNU0Egb2YgdGhpcyBzdWJuZXQgd29ya3MgYXMgRE1BLCBhbmQgaXMgdGhlIGluaXRp YWwgRE1BIG9mIA0KICAgICAgIHRoZSBNTi4gSW4gdGhpcyBjYXNlLCBpdCBjcmVhdGVzIGFuZCBt YWludGFpbnMgYW4gZW50cnkgZm9yIHRoaXMgDQogICAgICAgTU4gaW4gdGhlIE1TQSBsaXN0IG9m IHRoaXMgTVNBLg0KICAgDQogICAgIG8gV2hlbiBhIE1OIGVudGVycyBhIG5ldyBmb3JlaWduIHN1 Ym5ldCwgdGhlIE1TQSBvZiB0aGlzIHN1Ym5ldCANCiAgICAgICByZWNlaXZlcyBNTEQgZ3JvdXAg bWVtYmVyIHJlcG9ydCBtZXNzYWdlcyBvZiB0aGUgTU4uIElmIHRoZSBNU0EgDQogICAgICAgaGFz IGEgZ3JvdXAgbWVtYmVyIG9mIHRoaXMgbXVsdGljYXN0IGdyb3VwLCBpdCByZWNlaXZlcyANCiAg ICAgICBtdWx0aWNhc3QgcGFja2V0cyBhbmQgZm9yd2FyZHMgdGhlbSB0byB0aGUgTU4uIElmIHRo ZXJlIGlzIG5vIA0KICAgICAgIGVudHJ5IGFib3V0IHRoaXMgTU4gaW4gdGhlIE1TQSBWaXNpdG9y IFRhYmxlLCBpdCBzZWxlY3RzIHRoZSBNU0EgDQogICAgICAgb2YgY3VycmVudCBzdWJuZXQgYXMg RE1BIG9mIE1OIHRvIG9wdGltaXplIHRoZSB0cmFmZmljIHJvdXRlLiBJbiANCiAgICAgICB0aGlz IGNhc2UsIGl0IGNyZWF0ZXMgYW5kIG1haW50YWlucyB0YWJ1bGF0aW9uIGZvciB0aGlzIE1OIGlu DQoNCkhvbmctS2UgWmhhbmcgZXQgYWwuICAgICAgICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIw MDUgICAgICAgIFtQYWdlIDZdDQoNCg0KSU5URVJORVQtRFJBRlQgICAgICAgICAgTW9iaWxlIElQ djYgTXVsdGljYXN0IHdpdGggRE1BICAgICAgICAgTWF5IDIwMDUNCg0KICAgICAgIHRoZSBNU0Eg bGlzdCBvZiB0aGlzIE1TQSwgYW5kIGFubm91bmNlcyB0aGUgcHJldmlvdXMgRE1BIHRvIA0KICAg ICAgIGRlbGV0ZSBhbGwgZGF0YSBzdHJ1Y3R1cmVzIG9mIHJlbGF0ZWQgTU5zLg0KICAgDQogICAg IG8gV2hlbiBhIE1OIGpvaW5zIGEgbmV3IGZvcmVpZ24gc3VibmV0LCBNU0EgcmVjZWl2ZXMgTUxE IGdyb3VwIA0KICAgICAgIG1lbWJlciByZXBvcnQgbWVzc2FnZSBvZiB0aGUgTU4uIElmIHRoZSBN TiBpcyB0aGUgZmlyc3QgZ3JvdXAgDQogICAgICAgbWVtYmVyIGluIHRoZSBzdWJuZXQgYW5kIHRo ZXJlIGlzIG5vIGVsZW1lbnQgb2YgdGhpcyBNTiBpbiB0aGUgDQogICAgICAgTVNBIFZpc2l0b3Ig VGFibGUsIHRoZSBNU0EgY29tbXVuaWNhdGVzIHdpdGggdGhlIHByZXZpb3VzIERNQSBvZiANCiAg ICAgICBNTi4gSWYgdGhlIHByZXZpb3VzIERNQSBzZWxlY3RzIGEgbmV3IERNQSwgdGhlIE1TQSBv ZiBjdXJyZW50IA0KICAgICAgIHN1Ym5ldCB3b3JrcyBhcyBuZXcgRE1BLCBhbmQgaXQgY3JlYXRl cyBhbmQgbWFpbnRhaW5zIGFuIGVudHJ5IA0KICAgICAgIGZvciB0aGlzIE1OIGluIHRoZSBNU0Eg bGlzdCBvZiB0aGlzIE1TQS4NCg0KICAgV2hlbiB0aGUgZW50cnkgaXMgY3JlYXRlZCBpbiBNU0Eg bGlzdCBmb3IgYSBNTiwgdGhlIE1OIGFuZCBpdHMgDQogICBjdXJyZW50IHN1Ym5ldCBNU0EgYXJl IHdyaXR0ZW4gdG8gdGhlIGxvY2F0aW9uIG9mIERNQS4gV2hlbmV2ZXIgdGhlIA0KICAgTU4gZW50 ZXJzIGEgbmV3IGZvcmVpZ24gc3VibmV0LCB0aGUgbmV3IHN1Ym5ldCBNU0Egd2lsbCBjb21tdW5p Y2F0ZSANCiAgIHdpdGggdGhlIERNQSBvZiB0aGUgTU4uIElmIHRoZSBETUEgcmVjZWl2ZXMgbmV3 IG1lc3NhZ2VzIGZyb20gdGhlIA0KICAgbmV3IGZvcmVpZ24gc3VibmV0IHRvIGluZm9ybSB0aGF0 IGEgbmV3IERNQSBzZWxlY3Rpb24gaGFzIGJlZW4gdGFrZW4gDQogICBwbGFjZSwgdGhlIERNQSBk ZWxldGVzIHRoZSBlbnRyeSBtYWludGFpbmVkIGZvciB0aGUgTU47IG90aGVyd2lzZSB0aGUgDQog ICBETUEgd2lsbCBsb29rIHVwIHRoZSBlbnRyeSBsaXN0IGFuZCBkZXRlcm1pbmUgaWYgdGhlcmUg aXMgYSANCiAgIHJlY29yZCBmb3IgaXQuIElmIGl0IGlzIG51bGwsIHRoZSBETUEgYWRkcyB0aGUg bmV3IGZvcmVpZ24gTVNBIHRvIA0KICAgdGhlIE1TQSBsaXN0LiBXaGVuIHRoZSBzdW1tYXRpb24g b2YgdGhlIHBhdGggaW5jcmVtZW50IG9mIE1TQXMgaW4gDQogICBNU0EgbGlzdCByZWFjaGVzIHRo ZSBhc3NpZ25lZCB0aHJlc2hvbGQsIERNQSByZS1zZWxlY3Rpb24gDQogICBvY2N1cnMuIEF0IHRo aXMgcG9pbnQsIHRoZSBvbGQgRE1BIHNlbmRzIGEgbWVzc2FnZSB0byB0aGUgTU4sIGFuZCANCiAg IHRoZW4gdGhlIE1OIGdpdmVzIG5vdGljZSB0byB0aGUgTVNBIG9mIHRoZSBzdWJuZXQgaXQgYmVs b25ncyB0by4gDQogICBPbmNlIHRoZSBjdXJyZW50IE1TQSByZWNlaXZlcyB0aGUgbWVzc2FnZSwg aXQgd2lsbCBjaG9vc2UgaXRzZWxmIGFzIA0KICAgdGhlIG5ldyBETUEgb2YgdGhlIG1vYmlsZSBu b2RlLCBhbmQgYWRkIGFuIGVudHJ5IGZvciB0aGUgTU4gaW4gaXRzIA0KICAgTVNBIGxpc3QuDQog ICANCiAgIFRoZSBwYXRoIGluY3JlbWVudCBvZiBhIE1TQSBpcyBkZWZpbmVkIGFzIFtMZW5ndGgo TU4tRE1BKS9MZW5ndGgoRE1BDQogICAtUyldLCB3aGVyZSBbeF0gaXMgdGhlIG1pbmltdW0gaW50 ZWdlciBncmVhdGVyIHRoYW4gb3IgZXF1YWwgdG8geCwgDQogICBhbmQgTGVuZ3RoKHkpIGlzIHRo ZSBkaXN0YW5jZSBvZiB0aGUgcGF0aCB5Lg0KDQogICBJZiB0aGUgTVNBIG5lZWRzIHRvIHJlY2Vp dmUgbXVsdGljYXN0IHBhY2tldHMgdmlhIHRoZSBETUEsIGl0IA0KICAgY3JlYXRlcyBhIHR1bm5l bCBiZXR3ZWVuIHRoZSBNU0EgYW5kIHRoZSBETUEgdG8gZXN0YWJsaXNoIHRoZSANCiAgIGV4aXN0 ZW5jZSBvZiB0aGUgbWVtYmVyc2hpcC4gSWYgdGhlIERNQSBoYXMgYmVlbiB0aGUgbWVtYmVyIG9m IHRoZSANCiAgIGdyb3VwLCB0aGUgRE1BIHdpbGwgYWRkIGEgbGluayB0byB0aGUgTVNBIGluIHRo ZSBvdXRwdXQgaW50ZXJmYWNlIA0KICAgbGlzdC4gSWYgbm90LGl0IG5lZWQgdG8gcmVxdWVzdCB0 byBhZGQgdGhlIGdyb3VwLiBXaGVuIHRoZSBETUEgDQogICByZWNlaXZlcyB0aGUgbXVsdGljYXN0 IHBhY2tldHMsIGl0IHdpbGwgZm9yd2FyZCB0aGVtIHRvIGFsbCB0aGUgDQogICBtZW1iZXJzIG9m IHRoZSBncm91cCB0aHJvdWdoIGxvY2FsIGxpbmssIGFuZCBmb3J3YXJkIHRoZW0gdG8gb3RoZXIg DQogICBNU0FzIHRocm91Z2ggYSB0dW5uZWwuDQoNCjMuIENvbmNsdXNpb24NCg0KICAgVGhpcyBk b2N1bWVudCBoYXMgZGlzY3Vzc2VkIHRoZSBzdXBwb3J0IG9mIElQdjYgbXVsdGljYXN0IGZvciBt b2JpbGUNCg0KSG9uZy1LZSBaaGFuZyBhbC4gICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIg MjAwNSAgICAgICAgICAgW1BhZ2UgN10NCg0KDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICBNb2Jp bGUgSVB2NiBNdWx0aWNhc3Qgd2l0aCBETUEgICAgICAgICBNYXkgMjAwNQ0KIA0KICAgbm9kZXMu IFRoZSBhcHByb2FjaCBwcmVzZW50ZWQgaXMgYmFzZWQgb24gSUVURiBCaS1kaXJlY3Rpb25hbCB0 dW5uZWwgDQogICBhbmQgcmVtb3RlIHN1YnNjcmlwdGlvbi4gSXQgYWxzbyBpbnRlZ3JhdGVzIHRo ZSBtZXJpdHMgb2YgTW92ZW1lbnQgDQogICBiYXNlZCBhbmQgRGlzdGFuY2UgYmFzZWQgbG9jYXRp b24gbWFuYWdlbWVudCBtZXRob2RzLiBUaGUgcHVycG9zZSBpcyANCiAgIHRvIG9wdGltaXplIG1v YmlsZSBub2RlcyBtdWx0aWNhc3QgcGF0aCwgYW5kIG1lYW53aGlsZSByZWR1Y2UgdGhlIA0KICAg bGF0ZW5jeSBhbmQgdGhlIGltcGFjdCBvbiBtdWx0aWNhc3QgdHJlZXMgd2hpY2ggcmVzdWx0IGZy b20gdGhlIA0KICAgbW92ZW1lbnQgYW5kIGhhbmRvZmYgb2YgbW9iaWxlIG5vZGVzLg0KDQpBY2tu b3dsZWRnZW1lbnRzDQoNCiBSZWZlcmVuY2VzDQogSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KICAg WzFdIEpvaG5zb24sIEQuLCBQZXJraW5zIEMuLCBhbmQgQXJra28sIEouLCAiTW9iaWxpdHkgU3Vw cG9ydCBpbiANCiAgICAgICBJUHY2IiwgUkZDIDM3NzUsIEp1bmUgMjAwNC4NCg0KICAgWzJdIFpo YW5nLCBKLiBZLiAiTG9jYXRpb24gTWFuYWdlbWVudCBpbiBDZWxsdWxhciBOZXR3b3JrcyIuIDIw MDEuDQoNCiAgIFszXSBCYXItTm95LCBBLiBLZXNzbGVyLCBJLiBhbmQgU2lkaSwgTS4gIk1vYmls ZSBVc2VyczogVG8gdXBkYXRlIG9yIA0KICAgICAgIG5vdCB0byBVcGRhdGU/IiwgV2lyZWxlc3Mg TmV0d29ya3MgSm91cm5hbCwgMTk5NSwxKDIpOjE3NS04Ni4NCg0KICAgWzRdIERlZXJpbmcsIFMu LCBGZW5uZXIsIFcuIGFuZCBCLiBIYWJlcm1hbiwgIk11bHRpY2FzdCBMaXN0ZW5lcg0KICAgICAg IERpc2NvdmVyeSAoTUxEKSBmb3IgSVB2NiIsIFJGQyAyNzEwLCBPY3RvYmVyIDE5OTkuDQogIE5v cm1hdGl2ZSBSZWZlcmVuY2VzDQogICBbNV0gQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVz ZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50DQogICAgICAgTGV2ZWxzIiwgQkNQIDE0 LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KQXV0aG9ycycgQWRkcmVzc2VzDQogICAgDQogIEhv bmctS2UgWmhhbmcsIEJvIFNoZW4sIEJpbmctWWkgWmhhbmcNCiAgTkpUVSBJUCBMYWJzDQogIEJl aWppbmcgSmlhb3RvbmcgVW5pdmVyc2l0eQ0KICBCZWlqaW5nIDEwMDA0NA0KICBDaGluYQ0KICBQ aG9uZTogICs4NiAxMCA1MTY4NTY3Nw0KICBIb25nLUtlIFpoYW5nOmhremhhbmdAY2VudGVyLm5q dHUuZWR1LmNuDQogIEJpbmctWWkgWmhhbmc6YmluZ3lpemhhbmdAaG90bWFpbC5jb20NCg0KQ29w eXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNSkuICBBbGwgUmlnaHRzIFJlc2Vy dmVkLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNv cGllZCBhbmQgZnVybmlzaGVkIHRvDQogICBvdGhlcnMsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRo YXQgY29tbWVudCBvbiBvciBvdGhlcndpc2UgZXhwbGFpbiBpdA0KICAgb3IgYXNzaXN0IGluIGl0 cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGllZCwgcHVibGlzaGVkIA0KICAg YW5kIGRpc3RyaWJ1dGVkLCBpbiB3aG9sZSBvciBpbiBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9u IG9mIGFueSANCiAgIGtpbmQsIHByb3ZpZGVkIHRoYXQgdGhlIGFib3ZlIGNvcHlyaWdodCBub3Rp Y2UgYW5kIHRoaXMgcGFyYWdyYXBoIA0KICAgDQpIb25nLUtlIFpoYW5nIGV0IGFsLiAgICAgICAg ICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDA1ICAgICAgICBbUGFnZSA4XQ0KDQoNCklOVEVSTkVU LURSQUZUICAgICAgICAgIE1vYmlsZSBJUHY2IE11bHRpY2FzdCB3aXRoIERNQSAgICAgICAgIE1h eSAyMDA1DQoNCiAgIGFyZSBpbmNsdWRlZCBvbiBhbGwgc3VjaCBjb3BpZXMgYW5kIGRlcml2YXRp dmUgd29ya3MuICBIb3dldmVyLCB0aGlzIA0KICAgZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUg bW9kaWZpZWQgaW4gYW55IHdheSwgc3VjaCBhcyBieSByZW1vdmluZyANCiAgIHRoZSBjb3B5cmln aHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXIg DQogICBJbnRlcm5ldCBvcmdhbml6YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVy cG9zZSBvZiANCiAgIGRldmVsb3BpbmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2Ug dGhlIHByb2NlZHVyZXMgZm9yIA0KICAgY29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJbnRlcm5l dCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlIA0KICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVk IHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFuIA0KICAgRW5nbGlzaC4N Cg0KICAgVGhlIGxpbWl0ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBhYm92ZSBhcmUgcGVycGV0dWFs IGFuZCB3aWxsIG5vdCBiZSANCiAgIHJldm9rZWQgYnkgdGhlIEludGVybmV0IFNvY2lldHkgb3Ig aXRzIHN1Y2Nlc3NvcnMgb3IgYXNzaWducy4NCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgcHJvdmlkZWQgb24gYW4gDQogICAiQVMgSVMi IGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVS SU5HIA0KICAgVEFTSyBGT1JDRSBESVNDTEFJTVMgQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1Ig SU1QTElFRCwgSU5DTFVESU5HIA0KICAgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBU SEFUIFRIRSBVU0UgT0YgVEhFIElORk9STUFUSU9OIA0KICAgSEVSRUlOIFdJTEwgTk9UIElORlJJ TkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRiANCiAgIE1FUkNIQU5U QUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KICAgRnVuZGlu ZyBmb3IgdGhlIFJGQyBlZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRo ZSANCiAgIEludGVybmV0IFNvY2lldHkuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KSG9uZy1LZSBaaGFuZyBldCBhbC4gICAgICAgICAgICAgIEV4cGlyZXMg Tm92ZW1iZXIgMjAwNSAgICAgICAgW1BhZ2UgOV0NCg== --=====001_Dragon262426740658_===== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --=====001_Dragon262426740658_=====-- From mip6-bounces@ietf.org Thu Jun 02 03:39:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdkIY-0002gD-Ud; Thu, 02 Jun 2005 03:39:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdkIV-0002WE-4r; Thu, 02 Jun 2005 03:39:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14695; Thu, 2 Jun 2005 03:39:21 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1+YmN1rJxbPWYYCoZcUS/gz98Z7Eb+P42o=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdkcT-0004Jl-4z; Thu, 02 Jun 2005 04:00:02 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1DdkIA-00083e-Fm; Thu, 02 Jun 2005 09:39:05 +0200 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtpsa id 1DdkI9-0004J7-Hu; Thu, 02 Jun 2005 09:39:01 +0200 Message-ID: <429EB794.7020900@tm.uka.de> Date: Thu, 02 Jun 2005 09:39:00 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Samita Chakrabarti , Gerardo Giaretta References: <200506020323.j523N9bI548231@jurassic.eng.sun.com> In-Reply-To: <200506020323.j523N9bI548231@jurassic.eng.sun.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -19.7 (-------------------) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, jari.arkko@piuha.net, mobopts@irtf.org Subject: [Mip6] Re: Review of draft-irtf-mobopts-ro-enhancements-00 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi Samita and Gerardo, thank both of you very much vor your detailed comments on draft-irtf-mobopts-ro-enhancements-00. We'll wait a little longer in case there are additional reviews. You'll hear from us then. Regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 03 06:14:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1De9Bj-0005DL-F0; Fri, 03 Jun 2005 06:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdsvQ-00072g-WB; Thu, 02 Jun 2005 12:52:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06497; Thu, 2 Jun 2005 12:52:06 -0400 (EDT) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdtFU-0000Mk-Tz; Thu, 02 Jun 2005 13:12:53 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j52GoCOs005085; Thu, 2 Jun 2005 11:50:14 -0500 (CDT) Received: from [135.180.160.116] (thyaga-pcho.dnrc.bell-labs.com [135.180.160.116]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j52Gnhb10917; Thu, 2 Jun 2005 12:49:43 -0400 (EDT) Message-ID: <429F38A8.2010707@lucent.com> Date: Thu, 02 Jun 2005 12:49:44 -0400 From: Thyaga Nandagopal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rajeev Shorey Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by hoemail2.lucent.com id j52GoCOs005085 X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 03 Jun 2005 06:14:02 -0400 Cc: Subject: [Mip6] Deadline Extended: COMSWARE 2006 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Please note: extended submission deadline: June 24, 2005 (Our apologies if you receive multiple copies of this document) CALL FOR PAPERS *************** The First International Conference on Communication Systems Software and Middleware http://www.comsware.org ----------------------- January 8 - 12, 2006 Taj Palace Hotel, New Delhi, India Technical Co-Sponsor : IEEE Communications Society In Co-operation with : ACM SIGMOBILE Sponsored by: CreateNet (Italy), ICST (USA) Co-Sponsors: IBM, Microsoft Research, NOKIA, Lucent Technologies, Sasken University Co-Sponsor: Indian Institute of Technology, Delhi Paper Submission: June 24, 2005 (extended) (Instructions at http://www.comsware.org) (Proceedings to be published by IEEE and to appear in IEEE=20 Explore) The convergence of the communications, information technologies and the=20 Internet has ushered in a revolution in the way people communicate with=20 each other. The key enabler for this convergence has been the=20 advancement of software technology in various communication sectors, as=20 evident by the high levels of activity in the industry, academia, and=20 standards bodies, coupled with the increasing dependence of this=20 convergence to sustain and improve growth rates in many countries around=20 the world. This new international conference will provide a forum to exchange=20 ideas, techniques, and applications, discuss best practices and=20 challenging issues, raise awareness and share experiences among=20 researchers, practitioners, standard developers and policy makers in the=20 field of software techniques in communications. The conference will bring leading researchers and practitioners in areas ranging from=20 communications software and software engineering aspects of=20 communications software, to middleware and networking protocols. The=20 objective of the conference is to provide a high degree of=20 collaboration, participation and discussions of the various topics among multi-national participants from the industrial, governmental and=20 academic sectors. COMSWARE will include a regular paper track and an industry track. The=20 paper track will include a highly selective technical program. The=20 conference solicits original, previously unpublished research work,=20 experimental efforts, and practical experiences for the technical=20 program. COMSWARE will also feature panel discussions from experts in academia and industry, workshops and tutorials featuring the=20 state-of-the-art in various communications software and related areas.=20 There will be demos and exhibits that will expose the delegates to=20 exciting products and software solutions from industry and academia.=20 Accepted papers will be published by IEEE Computer Society. The top=20 papers accepted to the conference will be published in a reputed journal. Areas of interest include, but are not limited to: =B7 Communications Software =B7 Reconfigurable Software Stacks =B7 Software Engineering Aspects of Communications Software =B7 Context-Based and Implicit Computing =B7 Telecommunications Services and QoS =B7 Software for Billing and Pricing =B7 User Interfaces and Interaction Models =B7 Multi-Agent Systems =B7 Client-Server Applications =B7 Mobile and Intermittently Connected Applications =B7 Mobile Data Management =B7 Middleware Services and Agent Technologies =B7 Middleware for Wireless Sensor Networks =B7 Middleware for P2P Systems =B7 Middleware for Future Communication Networks =B7 Information Infrastructure and Security =B7 Security and Privacy Issues of Pervasive Computing Systems =B7 Network Operations and Management =B7 Policy and Workflow-based Network Operations =B7 Reliability Support Software =B7 Resource Management in Pervasive Computing Platforms =B7 Management Software for Optical Networks =B7 Network Monitoring Software =B7 Internet and IP based Services =B7 Dynamic Service Composition and Deployment =B7 Service Discovery Mechanisms =B7 Wireless/Mobile Service Management and Delivery =B7 Mobile / Wireless Computing Systems and Services =B7 Performance Evaluation Techniques =B7 Location Determination =B7 Positioning and Tracking Technologies =B7 Smart Devices and Smart Spaces =B7 Enterprise Networking =B7 Personal Area Networks =B7 Integration of Wired and Wireless Networks =B7 Next Generation Networks and Services Deadlines ********* Paper Submission: June 24, 2005 (Instructions at http://www.comsware.org= ) Notification of Acceptance: August 15, 2005 Camera-ready due: September 26, 2005 Conference Organizing Committee ******************************* General Chairs: Victor Bahl, Microsoft Research, USA Bijendra Nath Jain, IIT, Delhi, India Henning Schulzrinne, Columbia University, USA Alfred Spector, IBM Research, USA Steering Committee: Imrich Chlamtac, University of Trento, Italy=20 (Chair) Rajeev Shorey, IBM Research, India (Co-Chair) Prasant Mohapatra, University of California,=20 Davis, USA (Co-Chair) Program Chairs: Sanjoy Paul, Whenu, USA G. Venkatesh, SASKEN Technologies, India Jim Woodcock, University of York, UK Tutorial Chair: Archan Misra, IBM Research, USA Workshop Chairs: Ashwin Gumaste, Fujitsu Research, USA Gaurav Sharma, University of Rochester, USA Demos/Exhibit Chair: Huzur Saran, IIT, Delhi, India Demos/Exhibit Co-Chair: Jaijit Bhattacharya, Oracle, India Publicity Chair: Thyaga Nandagopal, Lucent Technologies, USA Publicity Co-Chairs: Sunghyun Choi, Seoul National University, Korea Marco Conti, IIT, Pisa, Italy Ben Lancini, LinLan, Brisbane, Australia Prashant Pradhan, IBM Research, USA Hemant Chaskar, Airtight Networks, India Local Arrangement Co-Chairs: Sudipta Maitra, IBM, Delhi Laurent Mignet, IBM Research, Delhi _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 03 12:19:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeEt2-0000S5-IX; Fri, 03 Jun 2005 12:19:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeEt0-0000Os-1t; Fri, 03 Jun 2005 12:19:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11847; Fri, 3 Jun 2005 12:19:03 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeFDF-00081q-AF; Fri, 03 Jun 2005 12:40:02 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j53GIwma016001; Fri, 3 Jun 2005 19:19:02 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jun 2005 19:18:43 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Jun 2005 11:18:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Jun 2005 11:18:39 -0500 Message-ID: <456943D540CFC14A8D7138E64843F85301042164@daebe101.NOE.Nokia.com> Thread-Topic: Design team formed for addressing v4 traversal Thread-Index: AcVoV+cHzxslcntLTH+GlD2uf4edtg== To: , X-OriginalArrivalTime: 03 Jun 2005 16:18:40.0472 (UTC) FILETIME=[E7773580:01C56857] X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: Subject: [Mip6] Design team formed for addressing v4 traversal X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hello, The MIP6 and NEMO WGs have formed a design team to work on developing a comprehensive solution for dealing with the problem of MIP6 MNs/Routers that roam into and attach to a v4 only access network.=20 The design team consists of : James Kempf, Ryuji Wakikawa, Pascal Thubert, Hesham Soliman and, Vijay Devarapalli =20 The MIP6/NEMO chairs will advise the design team as needed. The charter of the design team is to: 1. Write up the problem statement, scenarios to be addressed and requirements=20 2. Develop a protocol solution to address the scenarios The design team will present at least the scenarios and problem statement being worked on at the next IETF meeting (IETF63). A mailing list for the DT discussions has been setup (thanks to Ryuji). The archives will be made available to the MIP6/NEMO WGs when the design team has concluded.=20 If you have any questions about this work, please contact the chairs. -MIP6/NEMO chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 03 17:13:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeJU0-0004Js-7Z; Fri, 03 Jun 2005 17:13:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeJTy-0004Jl-FE for mip6@megatron.ietf.org; Fri, 03 Jun 2005 17:13:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15120 for ; Fri, 3 Jun 2005 17:13:32 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeJoG-0001i7-Bt for mip6@ietf.org; Fri, 03 Jun 2005 17:34:33 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j53KfXo27711 for ; Fri, 3 Jun 2005 13:41:33 -0700 X-mProtect: <200506032041> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRr6Qct; Fri, 03 Jun 2005 13:41:07 PDT Message-ID: <42A0C7CE.9D079883@iprg.nokia.com> Date: Fri, 03 Jun 2005 14:12:46 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IPv6 Mailing List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Mip6] draft-ietf-mip6-precfgKbm-03.txt` X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hello folks, I have submitted a new revision of the aformentioned Internet Draft. It has been given a new title (but still using the same filename): Securing Mobile IPv6 Route Optimization Using a Static Shared Key I have also copied it to the following URL: http://people.nokia.net/~charliep/txt/mobilev6/precfg.txt Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 06 04:06:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfCd9-0007vq-Fa; Mon, 06 Jun 2005 04:06:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfCd8-0007vi-9A; Mon, 06 Jun 2005 04:06:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08345; Mon, 6 Jun 2005 04:06:40 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfCxu-0002vq-Gt; Mon, 06 Jun 2005 04:28:12 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IHN00EMVL9FM3@szxga01-in.huawei.com>; Mon, 06 Jun 2005 16:08:04 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IHN00E59L9FLQ@szxga01-in.huawei.com>; Mon, 06 Jun 2005 16:08:03 +0800 (CST) Received: from c03731 ([10.110.90.91]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IHN00HYZLB7TY@szxml02-in.huawei.com>; Mon, 06 Jun 2005 16:09:08 +0800 (CST) Date: Mon, 06 Jun 2005 16:04:27 +0800 From: chenhongfei Subject: =?gb2312?B?tPC4tDogW01pcDZdIERlc2lnbiB0ZWFtIGZvcm1lZCBmb3IgYWRkcg==?= =?gb2312?B?ZXNzaW5nIHY0IHRyYXZlcnNhbA==?= In-reply-to: <456943D540CFC14A8D7138E64843F85301042164@daebe101.NOE.Nokia.com> To: Basavaraj.Patil@nokia.com Message-id: <000501c56a6e$5c4834f0$5b5a6e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hello, CNGI(China Next Generation Internet) which is ipv4/ipv6 network has been builded last year. But the network of the collage is IPv4 only now. and the gateway router of the collage isn't connect CNGI directly. It connect CNGI across the metro network which is ipv4 only. So the ISATAP isn't a good solution. I read about the charter of design term. Could this protocol solve this issue? Could HA assign a fixed IPv6 address for MN? Hongfei Chen -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] = =B4=FA=B1=ED Basavaraj.Patil@nokia.com =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA6=D4=C24=C8=D5 0:19 =CA=D5=BC=FE=C8=CB: mip6@ietf.org; nemo@ietf.org =D6=F7=CC=E2: [Mip6] Design team formed for addressing v4 traversal Hello, The MIP6 and NEMO WGs have formed a design team to work on developing a comprehensive solution for dealing with the problem of MIP6 MNs/Routers that roam into and attach to a v4 only access network.=20 The design team consists of : James Kempf, Ryuji Wakikawa, Pascal Thubert, Hesham Soliman and, Vijay Devarapalli =20 The MIP6/NEMO chairs will advise the design team as needed. The charter of the design team is to: 1. Write up the problem statement, scenarios to be addressed and requirements=20 2. Develop a protocol solution to address the scenarios The design team will present at least the scenarios and problem statement being worked on at the next IETF meeting (IETF63). A mailing list for the DT discussions has been setup (thanks to Ryuji). The archives will be made available to the MIP6/NEMO WGs when the design team has concluded.=20 If you have any questions about this work, please contact the chairs. -MIP6/NEMO chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 06 05:11:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfDeA-0004kd-Sz; Mon, 06 Jun 2005 05:11:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Df9P5-0004J3-6e; Mon, 06 Jun 2005 00:39:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28350; Mon, 6 Jun 2005 00:39:56 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Df9jr-0006na-5F; Mon, 06 Jun 2005 01:01:27 -0400 Received: from ececs.uc.edu ([129.137.4.130] helo=mail.ececs.uc.edu) by mx2.foretec.com with esmtp (Exim 4.24) id 1Df9P4-0008Qx-Na; Mon, 06 Jun 2005 00:39:58 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.ececs.uc.edu (Postfix) with ESMTP id 3178ED15; Sun, 5 Jun 2005 16:24:17 -0400 (EDT) Received: from mail.ececs.uc.edu ([127.0.0.1]) by localhost (mail.ececs.uc.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20157-02; Sun, 5 Jun 2005 16:23:56 -0400 (EDT) Received: from ececsqzeng (ececs-qzeng.rhod.uc.edu [10.63.10.63]) by mail.ececs.uc.edu (Postfix) with SMTP id B6EA6D23; Sun, 5 Jun 2005 16:22:00 -0400 (EDT) Message-ID: <039201c56a0c$7f9b4080$3f0a3f0a@ececsqzeng> From: "Qing-An Zeng" To: "Qing-An Zeng" Date: Sun, 5 Jun 2005 16:22:00 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: amavisd-new at ececs.uc.edu X-Spam-Score: 0.1 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 X-Mailman-Approved-At: Mon, 06 Jun 2005 05:11:49 -0400 Cc: Subject: [Mip6] Call for Papers: IEEE MHWMN'05 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0692851399==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0692851399== Content-Type: multipart/alternative; boundary="----=_NextPart_000_038B_01C569EA.B3656E80" This is a multi-part message in MIME format. ------=_NextPart_000_038B_01C569EA.B3656E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please accept our apologies if you receive this announcements from = multiple sources. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 First Call for Papers: IEEE International Workshop on Heterogeneous Multi-Hop Wireless and = Mobile Networks 2005 (IEEE MHWMN'05) =20 http://www.ececs.uc.edu/~qzeng/MHWMN2005/CFP.html=20 =20 to be held in conjunction with IEEE MASS 2005. Washington DC, USA, November 7-11, 2005. =20 AIM and SCOPE:=20 -------------------------- The traditional centralized wireless and mobile networks are based on = single-hop architecture and rely on the existing fixed infrastructure = such as base stations or access points. The proliferation and deployment = of radio access networks such as Wireless WANs, Wireless LANs, and = Wireless PANs with distinguishing characteristics of data rate, coverage = range, power, mobility, and prices will clearly lead to a need for = seamless and ubiquitous access across these various networks. Such an = integrated heterogeneous environment enables a user to access a = particular network depending upon the application needs and the types of = radio access networks (RANs) available (e.g., cellular network, ad hoc, = WLAN, WPAN etc). The heterogeneous multi-hop wireless and mobile = networks, on the other hand, provide unlimited mobility and greater = flexibility but introduce a number of challenges due to dynamic network = topology. The design of efficient and scalable protocols for existing = multi-hop wireless and mobile networks such as wireless and mobile ad = hoc networks continue to pose challenges at all the layers of networking = stack. Therefore, it is necessary to investigate a global heterogeneous = architecture and services that together provide seamless integration of = single-hop networks (e.g., cellular, WLAN, WWAN) and multi-hop mobile ad = hoc networks.=20 =20 The aim of this workshop is to bring together practitioners and = researchers from both academia and industry in order to have a forum for = discussion and technical presentations on the latest research and future = research directions in heterogeneous multi-hop wireless and mobile = networks. We are seeking original and previously unpublished research = papers addressing theoretical and application issues in heterogeneous = multi-hop wireless mobile networks.=20 =20 TOPICS:=20 ------------- Topics of interest include, but are not limited to, the following areas: - Multi-hop architectures and protocols for resource management=20 - Quality of services (QoS) delivery in MHWMN=20 - Robust and scalable routing protocols for MHWMN=20 - MAC protocols for MHWMN=20 - Self-configuration and synchronization for MHWMN=20 - Security issues in MHWMN=20 - Topology control and management for MHWMN=20 - Mobility models and location management in MHWMN=20 - Cross-layer design and interactions for MHWMN=20 - Modeling and performance evaluation for MHWMN=20 - Algorithms for localization and signal processing in MHWMN=20 - Implementation testbeds for MHWMN=20 - Operating systems and middleware for MHWMN=20 =20 SUBMISSIONS:=20 ------------------------ Submissions will be judged on correctness, originality, technical = strength, significance and quality of presentation. The manuscript must = follow IEEE two-column format with single-spaced, ten-point font in the = text. The maximum manuscript length is eight (8) pages. Authors are = requested to submit their papers (PDF format), contact addresses, = telephone number, fax number, and e-mail addresses (text format) to the = co-chairs Qing-An Zeng (qzeng@ececs.uc.edu) and Mieso Denko = (denko@cis.uoguelph.ca) by July 1, 2005.=20 =20 Note: Some selected high quality papers from the workshop will be = published at JPCC (Journal of Pervasive Computing and Communications) = Special Issue on "Key Technologies and Applications of Wireless Sensor = and Body-area Networks". Selected authors will be invited to submit = extended versions of their papers for publication in the special issue =20 IMPORTANT DATES: -------------------------------- Paper submission: July 1, 2005 Notification of acceptance: August 5, 2005=20 Camera-ready papers: August 26, 2005 =20 WORKSHOP GENERAL CHAIR: ------------------------------------------------ Anup Kumar Computer Engineering and Computer Science Department University of Louisville, KY 40292, USA Email: ak@louisville.edu =20 =20 WORKSHOP CO-CHAIRS:=20 --------------------------------------- Qing-An Zeng Department of Electrical & Computer Engineering=20 and Computer Science University of Cincinnati Cincinnati, OH 45221-0030, USA Email: qzeng@ececs.uc.edu =20 =20 Mieso Denko Department of Computing and Information Science University of Guelph N1G 2W1, Ontario, Canada Email: denko@cis.uoguelph.ca =20 PUBLICITY CHAIR: ---------------------------- Kui Wu Department of Computer Science University of Victoria V8W 3P6, British Columbia, Canada=20 Email: wkui@cs.uvic.ca =20 =20 PROGRAM COMMITTEE: -------------------------------------- Boukerche, Azzedine, University of Ottawa, Canada Caffery, James, University of Cincinnati, USA Cheng, Maggie, University of Missouri-Rolla, USA Cheng, Xiuzhen, George Washington University, USA Conrad, James, University of North Carolina at Charlotte, USA Dahlberg, Teresa, University of North Carolina, USA Datta, Suprakash, York University, Canada Ghosh, Ratan, Indian Institute of Technology, India Huang, Qingfeng, Palo Alto Research Center (PARC) Inc., USA Leung, Victor C. M., The University of British Columbia, Canada Li, Bo, Hong Kong University of Science and Technology, Hong Kong Li, Wei (Wayne), University Toledo, USA Lin, Chuang, Tsinghua University, China Nakano, Koji, Hiroshima University, Japan Nasser, Nidal, University of Guelph, Canada Olariu, Stephan, Old Dominion University, USA Park, Sang-Eon, Cal Poly Pomona, USA Pierre, Samuel, Ecole Polytechnique de Montreal, Canada Srimani, Pradip K., Clemson University, USA Tseng, Yu-Chee, National Chiao Tung University, Taiwan Vlajic, Natalija, York University, Canada Wang, Li-Chun, National Chiao-Tung University, Taiwan Watanabe, Takashi, University of Shizuoka, Japan Wu, Hong-Yi, University of Louisiana, USA Xue, Guoliang (Larry), Arizona State University, USA=20 Yang, Jiasi, Chengdu University of Information Technology, China Yang, Yuanyuan, SUNY at Stony Brook, USA Yeh, Chi-Hsiang, Queen's University, Canada Youn, Jon (Jong-Hoon), University of Nebraska at Omaha, USA Zhang, Jingyuan, University of Alabama, USA Zhou, Hong, University of Southern Queensland, Australia ------=_NextPart_000_038B_01C569EA.B3656E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Please accept our apologies if you = receive this=20 announcements from multiple sources.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D <= /FONT>
 
First Call for = Papers:

IEEE=20 International Workshop on Heterogeneous Multi-Hop Wireless and Mobile = Networks=20 2005 (IEEE MHWMN'05)
 
http://www.ececs.uc.edu/~qzeng/MHWMN2005/CFP.html 
 
to be held in conjunction with = IEEE MASS=20 2005.
Washington DC, USA, November 7-11, = 2005.
 
AIM and=20 SCOPE:
--------------------------
The traditional centralized wireless = and mobile=20 networks are based on single-hop architecture and rely on the existing = fixed=20 infrastructure such as base stations or access points. The proliferation = and=20 deployment of radio access networks such as Wireless WANs, Wireless = LANs, and=20 Wireless PANs with distinguishing characteristics of data rate, coverage = range,=20 power, mobility, and prices will clearly lead to a need for seamless and = ubiquitous access across these various networks. Such an integrated=20 heterogeneous environment enables a user to access a particular network=20 depending upon the application needs and the types of radio access = networks=20 (RANs) available (e.g., cellular network, ad hoc, WLAN, WPAN etc). The=20 heterogeneous multi-hop wireless and mobile networks, on the other hand, = provide=20 unlimited mobility and greater flexibility but introduce a number of = challenges=20 due to dynamic network topology. The design of efficient and scalable = protocols=20 for existing multi-hop wireless and mobile networks such as wireless and = mobile=20 ad hoc networks continue to pose challenges at all the layers of = networking=20 stack. Therefore, it is necessary to investigate a global heterogeneous=20 architecture and services that together provide seamless integration of=20 single-hop networks (e.g., cellular, WLAN, WWAN) and multi-hop mobile ad = hoc=20 networks.
 
The aim of this workshop is to bring together=20 practitioners and researchers from both academia and industry in order = to have a=20 forum for discussion and technical presentations on the latest research = and=20 future research directions in heterogeneous multi-hop wireless and = mobile=20 networks. We are seeking original and previously unpublished research = papers=20 addressing theoretical and application issues in heterogeneous multi-hop = wireless mobile networks.
 
TOPICS: =
-------------
Topics of interest include, but are not = limited to,=20 the following areas:
- Multi-hop architectures and protocols for = resource=20 management
- Quality of services (QoS) delivery in MHWMN
- = Robust and=20 scalable routing protocols for MHWMN
- MAC protocols for MHWMN
- = Self-configuration and synchronization for MHWMN
- Security issues = in MHWMN=20
- Topology control and management for MHWMN
- Mobility models = and=20 location management in MHWMN
- Cross-layer design and interactions = for MHWMN=20
- Modeling and performance evaluation for MHWMN
- Algorithms = for =20 localization and signal processing in MHWMN
- Implementation = testbeds for=20 MHWMN
- Operating systems and middleware for MHWMN=20
 
SUBMISSIONS:
------------------------
Submissions will be judged on = correctness,=20 originality, technical strength, significance and quality of = presentation. The=20 manuscript must follow IEEE two-column format with single-spaced, = ten-point font=20 in the text. The maximum manuscript length is eight (8) pages. Authors = are=20 requested to submit their papers (PDF format), contact addresses, = telephone=20 number, fax number, and e-mail addresses (text format) to the co-chairs = Qing-An=20 Zeng (qzeng@ececs.uc.edu) and = Mieso=20 Denko (denko@cis.uoguelph.ca) by July = 1, 2005.
 
Note:  Some selected high quality papers from the workshop will be = published at=20 JPCC (Journal of Pervasive Computing and Communications) Special Issue = on =93Key=20 Technologies and Applications of Wireless Sensor and Body-area = Networks=94.=20 Selected authors will be invited to submit extended versions of their = papers for=20 publication in the special issue
 
IMPORTANT=20 DATES:
--------------------------------
Paper=20 submission:          &n= bsp;           &nb= sp;      July=20 1, 2005
Notification of=20 acceptance:          &n= bsp;      =20 August 5, 2005
Camera-ready=20 papers:           =             &= nbsp;August=20 26, 2005

 
WORKSHOP GENERAL=20 CHAIR:
------------------------------------------------
Anup=20 Kumar
Computer Engineering and Computer Science = Department
University of=20 Louisville, KY 40292, USA
Email: ak@louisville.edu   =

 
WORKSHOP CO-CHAIRS:=20
---------------------------------------
Qing-An=20 Zeng
Department of Electrical & Computer Engineering=20
    and Computer Science
University of=20 Cincinnati
Cincinnati, OH 45221-0030, USA
Email: qzeng@ececs.uc.edu  =20
 
Mieso Denko
Department of Computing and Information=20 Science
University of Guelph
N1G 2W1, Ontario, Canada
Email: denko@cis.uoguelph.ca=20  

PUBLICITY CHAIR:
----------------------------
Kui=20 Wu
Department of Computer Science
University of Victoria
V8W = 3P6,=20 British Columbia, Canada
Email: wkui@cs.uvic.ca  =20
 
PROGRAM COMMITTEE:
--------------------------------------
Boukerche, Azzedine, = University=20 of Ottawa, Canada
Caffery, James, University of Cincinnati, = USA
Cheng,=20 Maggie, University of Missouri-Rolla, USA
Cheng, Xiuzhen, George = Washington=20 University, USA
Conrad, James, University of North Carolina at = Charlotte,=20 USA
Dahlberg, Teresa, University of North Carolina, USA
Datta, = Suprakash,=20 York University, Canada
Ghosh, Ratan, Indian Institute of Technology, = India
Huang, Qingfeng, Palo Alto Research Center (PARC) Inc., = USA
Leung,=20 Victor C. M., The University of British Columbia, Canada
Li, Bo, Hong = Kong=20 University of Science and Technology, Hong Kong
Li, Wei (Wayne), = University=20 Toledo, USA
Lin, Chuang, Tsinghua University, China
Nakano, Koji,=20 Hiroshima University, Japan
Nasser, Nidal, University of Guelph,=20 Canada
Olariu, Stephan, Old Dominion University, USA
Park, = Sang-Eon, Cal=20 Poly Pomona, USA
Pierre, Samuel, Ecole Polytechnique de Montreal,=20 Canada
Srimani, Pradip K., Clemson University, USA
Tseng, Yu-Chee, = National Chiao Tung University, Taiwan
Vlajic, Natalija, York = University,=20 Canada
Wang, Li-Chun, National Chiao-Tung University, = Taiwan
Watanabe,=20 Takashi, University of Shizuoka, Japan
Wu, Hong-Yi, University of = Louisiana,=20 USA
Xue, Guoliang (Larry), Arizona State University, USA
Yang, = Jiasi,=20 Chengdu University of Information Technology, China
Yang, Yuanyuan, = SUNY at=20 Stony Brook, USA
Yeh, Chi-Hsiang, Queen's University, Canada
Youn, = Jon=20 (Jong-Hoon), University of Nebraska at Omaha, USA
Zhang, Jingyuan, = University=20 of Alabama, USA
Zhou, Hong, University of Southern Queensland,=20 Australia
------=_NextPart_000_038B_01C569EA.B3656E80-- --===============0692851399== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0692851399==-- From mip6-bounces@ietf.org Mon Jun 06 18:55:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfQVM-0005b8-A0; Mon, 06 Jun 2005 18:55:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfQVK-0005b0-Hi; Mon, 06 Jun 2005 18:55:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27497; Mon, 6 Jun 2005 18:55:31 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfQqF-0000Vs-DK; Mon, 06 Jun 2005 19:17:12 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j56MMsV07488; Mon, 6 Jun 2005 15:22:54 -0700 X-mProtect: <200506062222> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdJ5mKhl; Mon, 06 Jun 2005 15:22:53 PDT Message-ID: <42A4D42F.4050708@iprg.nokia.com> Date: Mon, 06 Jun 2005 15:54:39 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: chenhongfei Subject: Re: =?GB2312?B?tPC4tDogW01pcDZdIERlc2lnbiB0ZWFtIGZvcm1lZCBmb3IgYQ==?= =?GB2312?B?ZGRyZXNzaW5nIHY0IHRyYXZlcnNhbA==?= References: <000501c56a6e$5c4834f0$5b5a6e0a@china.huawei.com> In-Reply-To: <000501c56a6e$5c4834f0$5b5a6e0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 8bit Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org I am not sure I understood your questions completely, but I will try to answer some of the questions. chenhongfei wrote: > Hello, > > CNGI(China Next Generation Internet) which is ipv4/ipv6 network has been > builded last year. But the network of the collage is IPv4 only now. and > the gateway router of the collage isn't connect CNGI directly. It > connect CNGI across the metro network which is ipv4 only. So the ISATAP > isn't a good solution. I read about the charter of design term. Could > this protocol solve this issue? yes. the college network and the metro network will both be treated as pure IPv4 routable Internet and the MN would be able to reach the IPv6 Home Agent. > Could HA assign a fixed IPv6 address for > MN? yes. the MN can have a fixed IPv6 HoA. Vijay > > Hongfei Chen > > -----SJ<~T-<~----- > 7"<~HK: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] 4z1m > Basavaraj.Patil@nokia.com > 7"KMJ1 JU<~HK: mip6@ietf.org; nemo@ietf.org > VwLb: [Mip6] Design team formed for addressing v4 traversal > > > Hello, > > The MIP6 and NEMO WGs have formed a design team to work on developing > a comprehensive solution for dealing with the problem of MIP6 > MNs/Routers that roam into and attach to a v4 only access network. > > The design team consists of : > James Kempf, Ryuji Wakikawa, Pascal Thubert, Hesham Soliman and, > Vijay Devarapalli > > The MIP6/NEMO chairs will advise the design team as needed. > > The charter of the design team is to: > > 1. Write up the problem statement, scenarios to be addressed and > requirements > 2. Develop a protocol solution to address the scenarios > > The design team will present at least the scenarios and problem > statement being worked on at the next IETF meeting (IETF63). > A mailing list for the DT discussions has been setup (thanks to > Ryuji). The archives will be made available to the MIP6/NEMO WGs when > the design team has concluded. > > If you have any questions about this work, please contact the chairs. > > -MIP6/NEMO chairs > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 07 03:31:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfYZ3-0003Nc-LY; Tue, 07 Jun 2005 03:31:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfYZ1-0003N6-Rq; Tue, 07 Jun 2005 03:31:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23815; Tue, 7 Jun 2005 03:31:53 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfYtz-0003T2-Pd; Tue, 07 Jun 2005 03:53:38 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IHP00CQNEGUQG@szxga02-in.huawei.com>; Tue, 07 Jun 2005 15:36:31 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IHP00DMKEGUTB@szxga02-in.huawei.com>; Tue, 07 Jun 2005 15:36:30 +0800 (CST) Received: from c03731 ([10.110.90.91]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IHP008WKEGNHG@szxml02-in.huawei.com>; Tue, 07 Jun 2005 15:36:24 +0800 (CST) Date: Tue, 07 Jun 2005 15:31:41 +0800 From: chenhongfei Subject: RE: RE: [Mip6] Design team formed for addressing v4 traversal In-reply-to: <42A4D42F.4050708@iprg.nokia.com> To: "'Vijay Devarapalli'" Message-id: <000001c56b32$f3767250$5b5a6e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.3 (/) X-Scan-Signature: b148ead9c6581b10314b24a9438d3a5f Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0150757662==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0150757662== Content-type: multipart/related; boundary="Boundary_(ID_R0/5BqIVchcsgNI5gXyMyg)" This is a multi-part message in MIME format. --Boundary_(ID_R0/5BqIVchcsgNI5gXyMyg) Content-type: multipart/alternative; boundary="Boundary_(ID_r59r0AblhMIBmKPlqDqhkA)" --Boundary_(ID_r59r0AblhMIBmKPlqDqhkA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi It's difficult to describe my question clearly by word. look the figure please. Router A is the gateway of the Enterprise network. Router B is a router location in the v6 internet. HOST-A and HOST-B are v4/v6 pc. Enterprise network and the v6 internet and the Metro network are operated by different department. Router A should access the v6 internet without changed the Metro network. After I read the charter of the design team. I think that result of the design team is a good solution. Router B is HA and HOST-A is MN. Is that right? -----Original Message----- From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] Sent: Tuesday, June 07, 2005 6:55 AM To: chenhongfei Cc: Basavaraj.Patil@nokia.com; nemo@ietf.org; mip6@ietf.org Subject: Re: Re: [Mip6] Design team formed for addressing v4 traversal I am not sure I understood your questions completely, but I will try to answer some of the questions. chenhongfei wrote: > Hello, > > CNGI(China Next Generation Internet) which is ipv4/ipv6 network has been > builded last year. But the network of the collage is IPv4 only now. and > the gateway router of the collage isn't connect CNGI directly. It > connect CNGI across the metro network which is ipv4 only. So the ISATAP > isn't a good solution. I read about the charter of design term. Could > this protocol solve this issue? yes. the college network and the metro network will both be treated as pure IPv4 routable Internet and the MN would be able to reach the IPv6 Home Agent. > Could HA assign a fixed IPv6 address for > MN? yes. the MN can have a fixed IPv6 HoA. Vijay > > Hongfei Chen > > -----SJ<~T-<~----- > 7"<~HK: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] 4z1m > Basavaraj.Patil@nokia.com > 7"KMJ1 JU<~HK: mip6@ietf.org; nemo@ietf.org > VwLb: [Mip6] Design team formed for addressing v4 traversal > > > Hello, > > The MIP6 and NEMO WGs have formed a design team to work on developing > a comprehensive solution for dealing with the problem of MIP6 > MNs/Routers that roam into and attach to a v4 only access network. > > The design team consists of : > James Kempf, Ryuji Wakikawa, Pascal Thubert, Hesham Soliman and, > Vijay Devarapalli > > The MIP6/NEMO chairs will advise the design team as needed. > > The charter of the design team is to: > > 1. Write up the problem statement, scenarios to be addressed and > requirements > 2. Develop a protocol solution to address the scenarios > > The design team will present at least the scenarios and problem > statement being worked on at the next IETF meeting (IETF63). > A mailing list for the DT discussions has been setup (thanks to > Ryuji). The archives will be made available to the MIP6/NEMO WGs when > the design team has concluded. > > If you have any questions about this work, please contact the chairs. > > -MIP6/NEMO chairs > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 --Boundary_(ID_r59r0AblhMIBmKPlqDqhkA) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi

It’s difficult to describe my question clearly by word. look the figure please.

Router A is the gateway of the Enterprise network. Router B is a router location in the v6 internet. HOST-A and HOST-B are v4/v6 pc. Enterprise network and the v6 internet and the Metro network are operated  by different department. Router A should access the v6 internet without changed the Metro network. After I read the charter of the design team. I think that result of the design team is a good solution. Router B is HA and HOST-A is MN. Is that right?

 

 

-----Original Message-----
From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com]
Sent: Tuesday, June 07, 2005 6:55 AM
To: chenhongfei
Cc: Basavaraj.Patil@nokia.com; nemo@ietf.org; mip6@ietf.org
Subject: Re: Re: [Mip6] Design team formed for addressing v4 traversal

 

I am not sure I understood your questions completely, but I will

try to answer some of the questions.

 

chenhongfei wrote:

> Hello,

>

> CNGI(China Next Generation Internet) which is ipv4/ipv6 network has been

> builded last year. But the network of the collage is IPv4 only now. and

> the gateway router of the collage isn't connect CNGI directly. It

> connect CNGI across the metro network which is ipv4 only. So the ISATAP

> isn't a good solution. I read about the charter of design term. Could

> this protocol solve this issue?

 

yes. the college network and the metro network will both be treated

as pure IPv4 routable Internet and the MN would be able to reach

the IPv6 Home Agent.

 

> Could HA assign a fixed IPv6 address for

> MN?

 

yes. the MN can have a fixed IPv6 HoA.

 

Vijay

 

>

> Hongfei Chen

>

> -----SJ<~T-<~-----

> 7"<~HK: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] 4z1m

> Basavaraj.Patil@nokia.com

> 7"KMJ1<d: 2005Dj6TB4HU 0:19

> JU<~HK: mip6@ietf.org; nemo@ietf.org

> VwLb: [Mip6] Design team formed for addressing v4 traversal

>

>

> Hello,

>

> The MIP6 and NEMO WGs have formed a design team to work on developing

> a comprehensive solution for dealing with the problem of MIP6

> MNs/Routers that roam into and attach to a v4 only access network.

>

> The design team consists of :

> James Kempf, Ryuji Wakikawa, Pascal Thubert, Hesham Soliman and,

> Vijay Devarapalli 

>

> The MIP6/NEMO chairs will advise the design team as needed.

>

> The charter of the design team is to:

>

> 1. Write up the problem statement, scenarios to be addressed and

>    requirements

> 2. Develop a protocol solution to address the scenarios

>

> The design team will present at least the scenarios and problem

> statement being worked on at the next IETF meeting (IETF63).

> A mailing list for the DT discussions has been setup (thanks to

> Ryuji). The archives will be made available to the MIP6/NEMO WGs when

> the design team has concluded.

>

> If you have any questions about this work, please contact the chairs.

>

> -MIP6/NEMO chairs

>

>

>

> _______________________________________________

> Mip6 mailing list

> Mip6@ietf.org

> https://www1.ietf.org/mailman/listinfo/mip6

>

>

> _______________________________________________

> Mip6 mailing list

> Mip6@ietf.org

> https://www1.ietf.org/mailman/listinfo/mip6

--Boundary_(ID_r59r0AblhMIBmKPlqDqhkA)-- --Boundary_(ID_R0/5BqIVchcsgNI5gXyMyg) Content-id: Content-type: image/gif; name=image001.gif Content-transfer-encoding: base64 Content-disposition: attachment; filename=image001.gif Content-Transfer-Encoding: base64 R0lGODlhxwEMAXcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAADG AQwBhQAAAAAAAAwMDAcHBxUVFRAQEBMTExgYGA8PDxQUFBcXFw4ODg0NDQkJCREREQoKChISEhkZ GQQEBCMjIysrKzw8PDMzMzs7OyoqKiAgIFxcXFhYWEVFRVZWVl9fX2JiYn9/f3t7e3Z2dmxsbHp6 emtra5OTk4ODg4eHh5eXl52dnZWVlbe3t6+vr6enp9vb29fX19/f38/Pz8fHx+/v7+fn5/f39/// /wECAwECAwECAwECAwECAwECAwECAwECAwb/QEBASBwai8ijMslcOpvQpzRKnVqr2Ku2ORR2A98w wDsGl8XktFmNXrvb8LOcPX/X43Tydp/t8/9+WWtjhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2e kV2foqOkpaanqKmqq6yag62wsbKztLW2t6ahuLu8vb6/wMGPr8LFxsfIycrDy83Oz9DRrcTS1dbX 2Nm62dzd3t+91ODj5OXmm9vn6uvs7YTi7vHy89Hp9Pf4+cDw+v3+/6nsARxIsGAmfgYTKlxoSCDD h7TASJxoZglEVggvaiQFyApFixsrOQxJEl1GdERKSjqpsiUjkKtGuiwkc6bNMl5qBtSpkuXN/41G KvqSmPInz58Lgx69RdToUqT6lAqFBpPkU6j0mo7TCvQqVndepXF9GParOp/fxiZEa3ZdWW9qB75t 2y0uPrtR59KtdkSh3q1757G9+xdu4cDJ8Dr6yG+Q4mJ9+x1GfKzwl3eHqAkMOxmUv8GUnx2+jLMh os0iZXUWG7rcZNI5YxMLqqcibaK2z6yGBDrt7ta4Oodxo7t06al9adc+buu3MufAm3uCjTOyLtKX JxYdTly6YOjRZwk3jnk7TeZIyqecHVxw+LrTKZou/k5+7o+ytadpDj5Y7/f7IIabWwBi0x9ASpnz X4HhAJjggdMwyJeEmEEYk4UUfoLhRRue0v9hhp18yNCC4YgIIiYmjkhieycukyJZL7oSY4sr0Xja iuLZmJiOicxICY48ouIjh0DGFCRkRypS5E5J/jJkSU++1KSTUyqJzJJVopTlaZVtyaKXmRmDJZg/ ksklkmaqlmaYwoy5JjNvnudfnBjRKec+UR6Zp1EB2imkn/MNtSePg/LZIKClFGooL24iqp6j5H0J 6XST3hmcoidiilSUmoLY6U2cfiqhqDM9ZmSlnJDqFH+optrqjS+q6uCrVoona3i3QmVirtHxuumH jQLqq67B1krrJcNipV8uyQbWrFlVhXgsitNaYuokxdr5bGjjVSvmsiiC29Zr29K1YSg61YT/roCu elvmqUUtou6j5prk7rs7OabdG01NlVO5Ox50748WWlefcd29si63BwE87qmwdfcvdea1NpfD9QaE nhoHW1oxw8hi/LCHdvRrMm76XqsrtXruIrKeL0+oBX7RujIwsixnqLKUu8U8skg+XxmbhmMG/VVZ Rvs3IMmW3ZyatUnXooS/Ru7co9NP46usfC4vGPWi2H4dYadW0xsiY8ZOLC5NYnuntU3ZcjSYcxHf eF7dDbUtKSh6Mzvszr/hfXd5gpu9F9Klxh1hjtvZ5i929T3Yt9RAQxmvNrxpqBt2eHN3nMTOejW5 va6lS+nlU/e7cXUfO1s5UAQ28lqkqCNM/3vhrmMbkt7p4oifx5yLi67ichGs0eRHRYa1x3BymGjK UivPMykvVG/99djTKProOD/fcaBZZz607J5cb8L56Kev/vU6v50Uyd8zX+P8kUu5SfUmBHCD+vzn /5EJ1WMQZ7hnrVwwgQ0oU5hyHHeb4SyHPdKj3STwZ4IbWNCCAehf+vR3wf0B8AUFEt3xPASF9dAn XkLJjgnrlsKXbGMuL+BfBy14Pv2hj4M0rKAHP4ir15GFhE5QXXpQWJ0B3cZ2aFiM4SARQw3qsIPn m6ETAdirAjrPgCucj8EIR0QTIpF1i1nYBKc4wx3qcIroAyFwBgiR/hjRcZtLUP3giBy2Sf9FOUos SxPRyMcpqhFk7ltLG//zgT1qEIceLKMT/wjIsLXxeF4p5AY3CMUoKlKDjKQM4h7pvKt8oJB7LKMZ ZXjBDKbxBR+oog/fN8KnfPKT+CujKcnYweq9UpWBLAgBrXg5Rrzylebr4ylt+UtcOpKVsJNgIn7J TFBi75nXa+Yt18hLv1hliYiQpja3yc1PKqlsI4JaOFVxR7zwRBzgEWMjusnOdtrxd2CjnyDJyUUJ ogU1HLEUYySigXb6U5t/3OfWVkkQDF3HdqZJXtpO9yiBovKfEAXmO/cVT89Yk571zA/V8qOH2lCM oQiD50Mj6s9Mqg2eLWHjPDVGOCGCbl3/LfRiL0FaBJQCYKQk5WYA87bPpfUkl5+pU0ZZxzXzqHCI M2VoT9NBzJw2c6c94pdNR2g8g5xLTul44Z2S0zj5EW2pirCeU2FpUrvdjXgKAqpkhKo28KGOjkLE ZqrQtp9FRLOd7GuYS7ZnVVgUzKtns89GGwFNaF5ol82zaKbgJ9fAdixZU11rVQsaT3U2o6cICl/x zLW252A2KgT9B2LlWSOfumhiklVrPkbLGyAV9bJoFVpog+qXyAItghNixyZ1WdvXztVhnYVLyJiC hViwFlbBdRXA0CYT3KKpmn41Yk2XCk64+TafyxXoIQQwgAlsAAQcIEABnhOusSU1c9VN/6xoYwtG bdiUAB2gwQxhQAEDyBa6fsvnKI7rVo3FrKgGYIEoLRiCA4hJr6J4kJAGm7MQntdAhDDACQZ8wQpg 6i+zuy45k0tat+TJud6YAIUvWAMEtElGDauZcZGqWuGm13vqQMGIK3xigUFNVFazrWYFpeGIRI0A Ap7xDURQKMtw5rIsNtZJzokn+/DYHAOQr5Bb0CebHbMeSpyDvPJYIh0zhb2yKAAMhHyDFIz3UKST HYOdoRiKCrY49xkcozjMqPF5wwVkTiWatSQvMGPEIVvkGBjx2F6XnbaxVBkBmScwlPhsOa1nwgNM TYtaywFWGgSowYxZQIA6a26h5LAH5P8WWCHgITrBy+3vNSowYhoooGv7Za1WTDY0/TAQei8mmJ8T xSZvxFeU9PV0gh+tW/UqrceiUTU2FNCCGFxQBidIgLBRfTV5mO7YXk72pauRAAY0wAIBcIB9Dc3r M31HzXuiK3y2bSZ47FLFpz7srtka75WVu9d5ieCHz5HVHsJY2Xd56+Lcg+9GDtvclGW3cuc9bQf/ u95ZAThK1A0WhBv801YBcYq1a+1qiwaOJzyZrelsZbkVvCCFNeyNs30Wi7NZPTBFj+CgEzdRGySY fczrShhe45MfWqZa7q9laUptidMDfzZEI2N4aHT+LhGytk6oy0nePSwq3B0UnOEsDyn/RR4im7cu /znFPtpvZZZ3wVdvhyEtWcmk56+SOfzg1zcb9oABvXXreVx8/pr2daxdfZfsOiapLlpQkxeh6dFq oMj1576f4+/pu6Qlc35Nj8NWjrWejQJz7XMSQjyBJ8y8b/MEeWEKs6w/rHupjPtR8m0Mcl5U/C4k OUVEsv2Ci7S0WTelpqBnmcXOtXmUaF9DSuL+9sfvH+pTr/rdxar1LqR064XPC7KiT5S0xGD6bJlS K2kcmYwTYaHxPtPvt+KXsdQ6H2fY1J+iu/LRe7CSa0cvOc79T0N4qvVMf767TnN3O+d0rucd4idT sGc2Q7dg+KFTKQdN26R7HSYXPJcZ/70BeuMzFlxhgQooUGP1TxC4c33VIBCSbhwHAB3oTx94Zfnm JHHzAAtwASBgAQ2wAHUCaAx2gniVZCtVdQE3J85BABegaR0EAxjgN4SXCDiFg9KkRtQVU1kxGoQB GcWiAhRGApRCXZeQhEooUVzSEa4hfzsWOwf2Gx4wYxewdzSTCVqohFCVZteAefvVDpz3Z7sRATYw YzUgbcxgg5SmCU2Fgzs1h/VDFbKBUfwGWwlWAmTGAc2lYwciVmPVhoNYcp7FcEkzgTcmCngmZCiA XCU4C/7XTTpneGHog27jYsm2GgzgbELGaRT4ibjQgKP4ewh2bHv2hlC3Gg4gA2RGZf+vqIOhplxV RiXWYH4HBoaSUAApQGZERncodovEYiDGKAkfQGYVAHbtsjdzwmaYeDqrAQGsSGEzMG7OaBLPpyq3 IjKg4woWMGI2kAEhiGoHkjra9i0vMzyeoAC/VkY1cI07KI9XSFGs0SZBs46bIAAK4AJjZkEysAIE IICdpzlYKAVuhow/J4JfCHGRkAAFIAHg5gB6eFHtcylfozCe0iKxYpGYYyMQSVys1zfsQSEtyR8F 042MY3SaFCTXUk5NKIh8UXYC1CQKdgVbdlz4FJTL84SWFz1HOIBMkpRX9E0uWX5+pTtWCZXxsGQq GYeAVpUR6JRYWWzGRocH82a35lH/+6FAy/EvD1QyhAaWYXkWTJYj1/EENcUcdjBUuZFFB5R3wLiU cdly4rNiWjRdW2QwUoVVUXdEC5NEgxmYcvmYAzdqXcSXsRdpineAlCmZkAlpY5kvoLcvXBOaGYhr I2eAUvWWxNaZ/LYUueIrMzktrsmNvBKbx8IWtolxrOmZn6ksu+lhipU7v5mRnPkzw7kVs5mTxxmM wXk4yxlqOHZSXRlGzWeIzylcVwkvuON7q+l4cXidhlGK3/l6YaJQgDlw4LmS4qmbEcNAb9VAdxlX vZee7sWD95Z3CUMdk5Z4iEeY9Kme+HVwq5MEyxJz/HlQtvKf9Rku05idZAc+Bmod/wg6nwpajIFV NJGDgW5FmuuYkhWKixK5JHxndtb5oVhmhBfDWCTKUib6k/6VhkRJILl5mxhJceDgky16KYlhkwvX oDl6X4dXD035oy7ymh/no0T6clSBYzyapGh3ogEyo6z5LIoipbvZpPZJbk4qlsX4JFi6pRfCDSlp pcepjrEFh2Calf/Vl7oTREiapjcqlz0JVm8Kp60ZVHVqpx2npxX6pXyaJWT6pwgSqIKaWoV6nX56 qC2jqIhKqIwacY+6nIkaqdpDqWXqqJYqh5n6m5O6qTLpqVOKqaDKm6OKlZ1aqu8hqqiKnKtqqq1q qqr6qmIqq0l5qrTKLrfqNLaaqzAZw6v3squ+ejTB+quxOqz1aKw06oXK2pdi1Kww96yI56zRCq0f I63VSq3WmoDGGgQAOw== --Boundary_(ID_R0/5BqIVchcsgNI5gXyMyg)-- --===============0150757662== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0150757662==-- From mip6-bounces@ietf.org Tue Jun 07 05:49:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfaiW-0007BK-53; Tue, 07 Jun 2005 05:49:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfaiU-0007BC-AJ; Tue, 07 Jun 2005 05:49:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05303; Tue, 7 Jun 2005 05:49:47 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfb3V-0006Tf-2b; Tue, 07 Jun 2005 06:11:34 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j579nVW32223; Tue, 7 Jun 2005 11:49:31 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j579nVOS020882; Tue, 7 Jun 2005 11:49:31 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200506070949.j579nVOS020882@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Christian Vogt Subject: Re: [Mip6] Francis' Review of draft-irtf-mobopts-ro-enhancements (was Re: FW: Please review draft-irtf-mobopts-ro-enhancements-00.txt) In-reply-to: Your message of Fri, 27 May 2005 16:13:42 +0200. <42972B16.9000801@tm.uka.de> Date: Tue, 07 Jun 2005 11:49:31 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 2.4 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: MIP6 , tm-ro2@tm.uka.de, Wassim Haddad , Jari Arkko , Basavaraj Patil , MOBOPTS X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: > => IMHO, you also get lower latency with OMIPv6 alone, in addition to > getting higher security, since you > don't need to do the HoTI/HoT exchange. you are right. The path through the HA is longer than the direct one in many, probably most, scenarios. => this is what I call "the Internet is a metric space" assumption which IMHO should be explicitly cited at the beginning of any latency text. BTW this is a reasonable assumption when the symmetrical stuff is removed (*). Regards Francis.Dupont@enst-bretagne.fr PS: a metric space is a space with a distance (d:ExE -> R+) with these 3 properties for all points A, B and C: (i) d(A,A) = 0 (ii) d(A,B) = d(B,A) (iii) d(A,B) + d(B,C) >= d(A,C) of course the last one is the one which matters. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 07 06:39:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfbUP-00069e-KC; Tue, 07 Jun 2005 06:39:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfbUK-00069V-5L; Tue, 07 Jun 2005 06:39:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08884; Tue, 7 Jun 2005 06:39:13 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfbpM-0007Vp-2a; Tue, 07 Jun 2005 07:01:00 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j57Ad0W03768; Tue, 7 Jun 2005 12:39:00 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j57Ad0Xt021018; Tue, 7 Jun 2005 12:39:01 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200506071039.j57Ad0Xt021018@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" Subject: Re: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00.txt In-reply-to: Your message of Thu, 26 May 2005 16:02:22 PDT. <0abd01c56246$fe2927f0$016115ac@dcml.docomolabsusa.com> Date: Tue, 07 Jun 2005 12:39:00 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 2.4 (++) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: => I agree with your main comment, for instance the security of RR was already well analyzed and should not be reproduced in the document. Section 2.0: I believe Pekka Nikander has a MIP6 WG draft (draft-ietf-mip6-ro-sec-02.txt) that discusses many of the issues that are discussed in this and subsequent sections. This draft should be referenced somewhere here. => the example itself (:-). Section 2.3, 2nd last para: I was looking here for the standard "ingress filtering will handle redirection-based DoS attacks" here, and the refutation of why that isn't practical. It might be useful to put in a forward reference, since it is dealt with later in the paper. => note that my argument about the ingress filtering is not this one. Section 3.2, end of 1st para: The impact on the core Internet of bidirectional tunneling is actually quite minimal given the amount of dark fiber left over from the Boom. It has been estimated that less that 10% of the cross-continent fiber in North America is lit, and the number is probably similar for intercontinental and other long distance links in other countries. => soem kind of "the Internet is ultra-metric" argument? (d(A,B) + d(B,C) = d(A,C)) Section 3.2, 6th para: This paragraph misses the issue of CRL checks. These could be a significant issue when using certificates for route optimization security. => note the CRL check issue is a property of some PKIs, including X.509 as it should be used... Section 3.2, 9th para: In my mind, the primary argument against depending on ingress filtering is that there is no incentive - financial, regulatory, or legal - for ISPs to deploy it. => as you said after this is true for any global Internet security device. A diligent ISP will of course do so, but a corrupt ISP might even have a financial incentive to not deploy it, if redirection-based DoS attacks using route optimization ever become possible and are exploited for financial gain. This has been an issue with spam, for example. I think something to that effect needs to be said. While some people might be offended by this, the need for security in the Internet results from the fact that, lacking any incentives to the contrary, some people will do bad things if they can get away with it and it can result in financial gain. Most discussions of security ignore this basic fact of human nature, and treat the problem like solar physics or something. => I fully agree but your argument works only against the "ingress filtering will save MIPv6" thesis, not against my "without ingress filtering we have no defense against flooding attacks with or without MIPv6". The current situation unfortunately supports mine with the everyday DDoS attacks using "botnets", and if today the issue is for IPv4, IPv6 is a worse case because the lack of support for ingress filtering BCPs (with a plural because BCP84/RFC3704 is more critical for the IPv6 way to support multi-homing). The argument you advance later in the paper that the attacker can still mount an attack on the subnet is irrelevent. An attacker can do that without using route optimization, by creating a zombie and programming it to iterate through non-existant addresses in the victim subnet. => note this is in fact an instance of my argument in favor of the ingress filtering! Section 6.3.2: final, all-encompassing method -> widespread method Actually, I disagree with this conclusion. I think the current crop of limited applicability RO security protocols are likely to die from lack of implementation and interest and a next gen protocol, possibly including CGA and CBA, that is widely applicable and a big improvement on RR is likely to have more success. => I don't know: when I ask friends about their interest into RO deployment (I control the implementation point :-), the two common concerns are the lack of security of RR and the complexity of CN code. There are some limited applicability ROs which answer to both but they have limited applicability... I believe CGA or something equivalent (but without CBA which gives nothing real in exchange of its extra complexity) is the last chance of RO, but do we need RO? Section 6.3.2: One issue that I've never really seen dealt with is whether or not RO is really needed. => this is the question we should not ask because we are afraid of its possible answer (:-). Nobody has measured this. Skype seems to get by with lots of indirect routes For example, our experiments show that when we make a Skype call from one node in our San Jose lab to another, it goes through a supernode in Europe, yet the quality of the call is fine. Everybody seems to be assuming this is a problem, but nobody seems to have set up a network and actually measured whether it is *really* a problem, with MOS scores, etc. => bi-tunneling has still good security properties: it can be made very secure (encrypt everything) and provide location privacy. Perhaps we should put our effort on the basic MIPv6/NEMO support. I believed there was no good business cases for MIPv6, mainly because computers are not designed to be mobile, and smaller devices worked better without IP. But today I believe MIPv6 is better than depending in WLAN & co security: + unified framework + easy vertical handoff support + good performance on handoffs (.5 RTT vs re-auth nightmare) - no DoS protection but 802.11i for instance has none too... has 3GPP2 already what I am thinking to? Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 07 06:47:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfbbv-0007a1-7s; Tue, 07 Jun 2005 06:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfbbu-0007Zt-4X; Tue, 07 Jun 2005 06:47:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09372; Tue, 7 Jun 2005 06:47:03 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dfbwv-0007eW-85; Tue, 07 Jun 2005 07:08:50 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j57AknW04184; Tue, 7 Jun 2005 12:46:49 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j57AkmmC021055; Tue, 7 Jun 2005 12:46:48 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200506071046.j57AkmmC021055@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Gerardo Giaretta Subject: Re: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00 In-reply-to: Your message of Thu, 02 Jun 2005 00:20:28 +0200. Date: Tue, 07 Jun 2005 12:46:48 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 2.4 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Christian Vogt , mip6@ietf.org, Jari Arkko , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: - section 4.1, paragraph 2: since the CN is not always required to send the BA, I wonder why the MN should by default wait for the BA. Or are you suggesting the MN asks the CN an ack? If so, I think the sentence should be rephrased. => a general problem in MIPv6 specs is there is no explanation about when a BA should be asked (always with the HA, and with a CN only when the previous CoA no more works). - section 4.1, paragraph 3 "But more generally, mobile nodes wait for the home registration to be completed and acknowledged before initiating the correspondent registration". Are you referring to some specific implementations? I'm asking this because the open source implementation we use in our labs does not wait the BA. => as an implementor I agree: there is no reason to wait! And this should be more true with alternate RO protections. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 07 12:35:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfh2l-0007jj-5C; Tue, 07 Jun 2005 12:35:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dfh2i-0007jL-UM for mip6@megatron.ietf.org; Tue, 07 Jun 2005 12:35:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09368 for ; Tue, 7 Jun 2005 12:35:05 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfhNl-0007NW-Hc for mip6@ietf.org; Tue, 07 Jun 2005 12:56:56 -0400 Message-ID: <05ae01c56b7f$01163b60$5e6015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Francis Dupont" References: <200506071039.j57Ad0Xt021018@givry.rennes.enst-bretagne.fr> Subject: Re: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00.txt Date: Tue, 7 Jun 2005 09:35:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org > Section 3.2, end of 1st para: The impact on the core Internet of > bidirectional tunneling is actually quite minimal given the amount of dark > fiber left over from the Boom. It has been estimated that less that 10% of > the cross-continent fiber in North America is lit, and the number is > probably similar for intercontinental and other long distance links in other > countries. > > => soem kind of "the Internet is ultra-metric" argument? > (d(A,B) + d(B,C) = d(A,C)) > I'm not sure this is always the case. If d() is inversely proportional to network bandwidth, then suppose: bandwidth(A,B) = 1 Gbit bandwidth(B,C) = 1 Gbit bandwidth(A,C) = 64 kbit > A diligent ISP will of course do so, but a > corrupt ISP might even have a financial incentive to not deploy it, if > redirection-based DoS attacks using route optimization ever become possible > and are exploited for financial gain. This has been an issue with spam, for > example. I think something to that effect needs to be said. While some > people might be offended by this, the need for security in the Internet > results from the fact that, lacking any incentives to the contrary, some > people will do bad things if they can get away with it and it can result in > financial gain. Most discussions of security ignore this basic fact of human > nature, and treat the problem like solar physics or something. > > => I fully agree but your argument works only against the "ingress > filtering will save MIPv6" thesis, not against my "without ingress > filtering we have no defense against flooding attacks with or without > MIPv6". The current situation unfortunately supports mine with the > everyday DDoS attacks using "botnets", and if today the issue is for > IPv4, IPv6 is a worse case because the lack of support for ingress > filtering BCPs (with a plural because BCP84/RFC3704 is more critical > for the IPv6 way to support multi-homing). > I don't think my argument has anything to do with MIP. My argument is: Because the Internet is for all intents and purposes completely unregulated, *any* protocol security design (MIP6, Mobike, or whatever) that depends on ISPs or anybody else for that matter behaving in a way that is public-spirited and beneficial to the community but which may be perverted by financial incentives is bound to fail. Being a good IETFer, I dislike cops and government as much as anybody else, but the fact is that one of the chief reasons spam continues to be a problem is that the spammers pay off their ISPs to continue to allow them to function (it's called a "pink letter", try googling it) while the ISPs turn a blind eye. Would new laws and regulations coupled with some high profile raids and convictions of ISPs help? Dunno. Maybe it would just raise the price of the bribe, since the risk level goes up, or move the ISPs who let themselves be bribed to North Korea. Anyway, enough said. This is probably not the right list to discuss this topic on. > The argument you advance > later in the paper that the attacker can still mount an attack on the subnet > is irrelevent. An attacker can do that without using route optimization, by > creating a zombie and programming it to iterate through non-existant > addresses in the victim subnet. > > => note this is in fact an instance of my argument in favor of > the ingress filtering! > Sure, I agree. And if all ISPs were public spirited and willing to forgoe the extra $100,000 a month being offered by the spammers, we wouldn't have nearly the problem with spam that we do. > Section 6.3.2: final, all-encompassing method -> widespread method > Actually, I disagree with this conclusion. I think the current crop of > limited applicability RO security protocols are likely to die from lack of > implementation and interest and a next gen protocol, possibly including CGA > and CBA, that is widely applicable and a big improvement on RR is likely to > have more success. > > => I don't know: when I ask friends about their interest into RO deployment > (I control the implementation point :-), the two common concerns are the > lack of security of RR and the complexity of CN code. There are some > limited applicability ROs which answer to both but they have limited > applicability... I believe CGA or something equivalent (but without CBA > which gives nothing real in exchange of its extra complexity) is the > last chance of RO, but do we need RO? > I agree about CGA, perhaps coupled with CBA. Actually, I'm pretty optimistic here. I think that *if* route optimization turns out to be worthwhile, some of the new work will result in a security protocol that is considerably better than RR. > Section 6.3.2: One issue that I've never really seen dealt with is whether > or not RO is really needed. > > => this is the question we should not ask because we are afraid of its > possible answer (:-). > Yes, interesting, isn't it? :-) > Nobody has measured this. Skype seems to get by > with lots of indirect routes For example, our experiments show that when we > make a Skype call from one node in our San Jose lab to another, it goes > through a supernode in Europe, yet the quality of the call is fine. > Everybody seems to be assuming this is a problem, but nobody seems to have > set up a network and actually measured whether it is *really* a problem, > with MOS scores, etc. > > => bi-tunneling has still good security properties: it can be made very > secure (encrypt everything) and provide location privacy. Perhaps we > should put our effort on the basic MIPv6/NEMO support. I believed there > was no good business cases for MIPv6, mainly because computers are not > designed to be mobile, and smaller devices worked better without IP. Actually, I think the case is still undecided. If it turns out that route optimization results in a 10-20% return if you are far from the POP, but otherwise on the order of 1-2%, maybe it's not worth the extra code and effort to implement and deploy it, but we really don't know that. I'm really like to get some kind of measurement project together that could measure how much of an improvement route optimization really makes in various places around the world. > But today I believe MIPv6 is better than depending in WLAN & co security: > + unified framework > + easy vertical handoff support > + good performance on handoffs (.5 RTT vs re-auth nightmare) > - no DoS protection but 802.11i for instance has none too... > has 3GPP2 already what I am thinking to? > Agree. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 07 16:04:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfkIv-0001Pr-4w; Tue, 07 Jun 2005 16:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfkIr-0001P4-Gm; Tue, 07 Jun 2005 16:04:01 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28452; Tue, 7 Jun 2005 16:03:59 -0400 (EDT) Message-Id: <200506072003.QAA28452@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 07 Jun 2005 16:03:59 -0400 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-mipext-advapi-04.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Extension to Sockets API for Mobile IPv6 Author(s) : S. Chakrabarti, E. Nordmark Filename : draft-ietf-mip6-mipext-advapi-04.txt Pages : 22 Date : 2005-6-7 This document describes data structures and API support for Mobile IPv6 as an extension to Advanced Socket API for IPv6. Mobility Support in IPv6 introduces mobility protocol header for IPv6. It is expected that future Mobile IPv6 applications and implementations may need to access Mobility binding messages and Return Routability messages for diagnostic, packet accounting and local policy setting purposes. In order to provide portability for Mobile IP applications that use sockets under IPv6, standardization is needed for the Mobile IPv6 specific APIs. This document provides mechanism for API access to retrieve and set information for Mobility Header messages, Home Address destination options and type 2 Routing header extension headers. It discusses the common data structures and definitions that might be used by advanced Mobile IPv6 socket applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-mipext-advapi-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-mipext-advapi-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-mipext-advapi-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-7163249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-mipext-advapi-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-mipext-advapi-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-7163249.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Tue Jun 07 17:24:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DflYG-0003jn-PY; Tue, 07 Jun 2005 17:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DflYC-0003hv-M7; Tue, 07 Jun 2005 17:23:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14914; Tue, 7 Jun 2005 17:23:54 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfltI-000169-EJ; Tue, 07 Jun 2005 17:45:46 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j57LNVE24078; Tue, 7 Jun 2005 23:23:31 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j57LNV8s023649; Tue, 7 Jun 2005 23:23:31 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200506072123.j57LNV8s023649@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" Subject: Re: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00.txt In-reply-to: Your message of Tue, 07 Jun 2005 09:35:58 PDT. <05ae01c56b7f$01163b60$5e6015ac@dcml.docomolabsusa.com> Date: Tue, 07 Jun 2005 23:23:31 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 2.4 (++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: > => soem kind of "the Internet is ultra-metric" argument? => in fact it is not ultra-metric but simply dimension one > (d(A,B) + d(B,C) = d(A,C)) => to summary to go through the HA does add a delay. > A diligent ISP will of course do so, but a > corrupt ISP might even have a financial incentive to not deploy it, if > redirection-based DoS attacks using route optimization ever become possible > and are exploited for financial gain. This has been an issue with spam, for > example. I think something to that effect needs to be said. While some > people might be offended by this, the need for security in the Internet > results from the fact that, lacking any incentives to the contrary, some > people will do bad things if they can get away with it and it can result in > financial gain. Most discussions of security ignore this basic fact of human > nature, and treat the problem like solar physics or something. > > => I fully agree but your argument works only against the "ingress > filtering will save MIPv6" thesis, not against my "without ingress > filtering we have no defense against flooding attacks with or without > MIPv6". The current situation unfortunately supports mine with the > everyday DDoS attacks using "botnets", and if today the issue is for > IPv4, IPv6 is a worse case because the lack of support for ingress > filtering BCPs (with a plural because BCP84/RFC3704 is more critical > for the IPv6 way to support multi-homing). > I don't think my argument has anything to do with MIP. => I agree: my understanding of your argument is ISPs won't help to the security of any protocol because there is no real incentive. My argument is: Because the Internet is for all intents and purposes completely unregulated, *any* protocol security design (MIP6, Mobike, or whatever) that depends on ISPs or anybody else for that matter behaving in a way that is public-spirited and beneficial to the community but which may be perverted by financial incentives is bound to fail. => so the protection against DDoS is bound to fail. I apply your argument to MIPv6 because the security target of MIPv6 is not to be perfect but to simply be not worse than IPv6. For flooding/DDoS and ingress filtering is a case of shared success (or shared fate). Being a good IETFer, I dislike cops and government as much as anybody else, but the fact is that one of the chief reasons spam continues to be a problem is that the spammers pay off their ISPs to continue to allow them to function (it's called a "pink letter", try googling it) while the ISPs turn a blind eye. Would new laws and regulations coupled with some high profile raids and convictions of ISPs help? Dunno. Maybe it would just raise the price of the bribe, since the risk level goes up, or move the ISPs who let themselves be bribed to North Korea. => I believe the situation is better for ingress filtering than for spam because ingress filtering is something really controlled by ISPs. IMHO we only need good ingress filtering support in routers (I'd like to add this in the IPv6 ready logo program with things like RFC 3871, i.e., not only test conformance but test usability in the real world) and a strong incentive, for instance tier-1 accepting only clients with deployed ingress filtering... Anyway, enough said. This is probably not the right list to discuss this topic on. => I disagree: to get a more secure Internet is a legitime topic even we know the IETF can't enforce anything... Actually, I think the case is still undecided. If it turns out that route optimization results in a 10-20% return if you are far from the POP, but otherwise on the order of 1-2%, maybe it's not worth the extra code and effort to implement and deploy it, but we really don't know that. => there are at least two cases where RO will never be interesting: access to big servers (because the overhead of the CN support is too high) and access to the company (i.e., the road warrior case, because the HA is on the mandatory path). VoIP and co is not clear because the ratio between the core and access networks is so high... Perhaps there is only the mobile to mobile (i.e., the two Japanese in America in the same street)? I'm really like to get some kind of measurement project together that could measure how much of an improvement route optimization really makes in various places around the world. => I know people fond of GPS antenna to get One Way Delays... So I believe the measures are already available: we need realitisc scenarios? Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 08 01:35:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DftE2-0004Tl-IV; Wed, 08 Jun 2005 01:35:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DftE0-0004Te-Gz for mip6@megatron.ietf.org; Wed, 08 Jun 2005 01:35:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21583 for ; Wed, 8 Jun 2005 01:35:35 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DftZB-0002gO-2P for mip6@ietf.org; Wed, 08 Jun 2005 01:57:31 -0400 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 8E9AA4C13B for ; Wed, 8 Jun 2005 14:34:44 +0900 (JST) Date: Wed, 8 Jun 2005 14:35:18 +0900 From: Thierry Ernst To: mip6@ietf.org Message-Id: <20050608143518.4d5b218e.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Subject: [Mip6] Monami6 mailing list: MObile Nodes And Multiple Interfaces in IPv6 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Dear all, This is a announcement and motivations to join the Monami6 mailiing list: http://www.nautilus6.org/ietf/ In several occasions, the issue of supporting and using multiple interfaces **simulateneously** on mobile nodes operating MIP6 (or NEMO BS) were discussed on this ML and other places. There are several solutions, each addressing a different part of the entire problem. There were some attempts to include a milestone in the MIP6 charter to work on that topic, but this was rejected, for several reasons including: - no time to deal with this topic [agree a given WG has limited time] - some claiming it's not necessary [huh ?] - topic is too broad to be covered by MIP6 WG [agree] - should be done at IRTF [huh ?] - and other. Basically, MIP (and NEMO Basic Support) would be affected by small straight forward changes (multiple CoA registration for instance), whereas additional non-MIP-specific mechanisms would be needed to benefit from the multihomed configurations of MNs. It is doubful, given the past resistance in this MIP6 WG that MIP6 would be the right working group, all the more since some of the idenfified issues are not MIP6 issues per se (however, it is a common understanding of the people working on these issues that MIP6 and NEMO deployment would most benefit of such extensions, this driving us to focus on IP-layer mobility protocols). We are therefore envisioning the creation of a new working group and we are engaged into the set up of a BOF at next IETF meeting in Paris. The potential-&-to-be-approved BOF would be called Monami6 (MObile Nodes And Multiple Interfaces in IPv6). If you are interested, please do join our IETF mailing list from the web page http://www.nautilus6.org/ietf/ where our objectives are explained and relevant documents are listed. If you lack background: Problem statement drafts: 1. Goals and Benefits of Multihoming draft-ernst-generic-goals-and-benefits-01.txt 2. Analysis of Multihoming in Network Mobility Support draft-ietf-nemo-multihoming-issues-02.txt 3. Analysis of Multihoming in Mobile IPv6 draft-montavont-mobileip-multihoming-pb-statement-04.txt There were some discussions about this topic on the MIP6 ML quite frequently, including in the following threads (see MIP6 archives): - Sep.03: Are multihoming mechanisms part of the charter - Oct.03: Draft Agenda for WG meeting at IETF58 - Nov.03: multi-interfaced vs multi-addressed [Re: [Mip6] Draft Agenda for WG meeting at IETF58] - Dec.04: FW: MIP6 agenda (Final) And discussions during IETF meetings: - Nov.03: MIP6 WG, 58th IETF meeting - Nov.03: Multi-link flow Bar BOF (somewhat related) - Dec.04: MIP6 WG, 61th IETF meeting Regards, Thierry. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 08 11:23:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg2P4-0003Bo-MC; Wed, 08 Jun 2005 11:23:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg2P3-0003Bj-5D for mip6@megatron.ietf.org; Wed, 08 Jun 2005 11:23:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09070 for ; Wed, 8 Jun 2005 11:23:30 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg2kE-00070o-SD for mip6@ietf.org; Wed, 08 Jun 2005 11:45:32 -0400 Message-ID: <06b201c56c3e$28df6b70$5e6015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Thierry Ernst" , References: <20050608143518.4d5b218e.ernst@sfc.wide.ad.jp> Subject: Re: [Mip6] Monami6 mailing list: MObile Nodes And Multiple Interfacesin IPv6 Date: Wed, 8 Jun 2005 08:24:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Thierry, I'm certainly interested in this and, in the past, I've organized a bar BOF on multiple host registrations, though the primary interest at that point seemed to be for Mobile IPv4. Nothing came out of it, though, since nobody seemed to want to really work on the problem (as opposed to talking about it). I'm glad to see that's changed. But I did not sense any hostility to working on this problem (more lack of committment even though there was interest) in the MIP6 WG, and I believe that would, in fact, be a good venue to do the work. I think MIP6 is approaching completion of existing charter items and might possibly consider a charter update. Or perhaps your concern is that the work spans multihomed mobile network and multihomed hosts, and therefore spans the charters of the two WGs? I might point out that the MIP IPv4/IPv6 transition team is currently being hosted by the MIP6 WG but is also working to accommodate mobile networks? Perhaps the load could be split and the topic of multihomed hosts and networks could be hosted by NEMO? I don't want to discourage the initiative to have a BOF in Paris, but just bring up a couple of additional possibilities for consideration. Good working group chairs are a scarce resource in IETF, and the fewer WGs the IESG has to keep track of the higher the probability that they will be able to achieve better management. jak ----- Original Message ----- From: "Thierry Ernst" To: Sent: Tuesday, June 07, 2005 10:35 PM Subject: [Mip6] Monami6 mailing list: MObile Nodes And Multiple Interfacesin IPv6 > > Dear all, > > This is a announcement and motivations to join the Monami6 mailiing > list: http://www.nautilus6.org/ietf/ > > In several occasions, the issue of supporting and using multiple > interfaces **simulateneously** on mobile nodes operating MIP6 (or NEMO > BS) were discussed on this ML and other places. There are several > solutions, each addressing a different part of the entire problem. There > were some attempts to include a milestone in the MIP6 charter to work on > that topic, but this was rejected, for several reasons including: > > - no time to deal with this topic [agree a given WG has limited time] > - some claiming it's not necessary [huh ?] > - topic is too broad to be covered by MIP6 WG [agree] > - should be done at IRTF [huh ?] > - and other. > > Basically, MIP (and NEMO Basic Support) would be affected by small > straight forward changes (multiple CoA registration for instance), > whereas additional non-MIP-specific mechanisms would be needed to > benefit from the multihomed configurations of MNs. > > It is doubful, given the past resistance in this MIP6 WG that MIP6 would > be the right working group, all the more since some of the idenfified > issues are not MIP6 issues per se (however, it is a common understanding > of the people working on these issues that MIP6 and NEMO deployment > would most benefit of such extensions, this driving us to focus on > IP-layer mobility protocols). > > We are therefore envisioning the creation of a new working group and we > are engaged into the set up of a BOF at next IETF meeting in Paris. The > potential-&-to-be-approved BOF would be called Monami6 (MObile Nodes And > Multiple Interfaces in IPv6). If you are interested, please do join our > IETF mailing list from the web page http://www.nautilus6.org/ietf/ > where our objectives are explained and relevant documents are listed. > > If you lack background: > > Problem statement drafts: > 1. Goals and Benefits of Multihoming > draft-ernst-generic-goals-and-benefits-01.txt > 2. Analysis of Multihoming in Network Mobility Support > draft-ietf-nemo-multihoming-issues-02.txt > 3. Analysis of Multihoming in Mobile IPv6 > draft-montavont-mobileip-multihoming-pb-statement-04.txt > > There were some discussions about this topic on > the MIP6 ML quite frequently, including in the following threads (see > MIP6 archives): > - Sep.03: Are multihoming mechanisms part of the charter > - Oct.03: Draft Agenda for WG meeting at IETF58 > - Nov.03: multi-interfaced vs multi-addressed [Re: [Mip6] Draft Agenda > for WG meeting at IETF58] > - Dec.04: FW: MIP6 agenda (Final) > > And discussions during IETF meetings: > - Nov.03: MIP6 WG, 58th IETF meeting > - Nov.03: Multi-link flow Bar BOF (somewhat related) > - Dec.04: MIP6 WG, 61th IETF meeting > > Regards, > Thierry. > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 08 12:12:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg3Ak-0004O6-LW; Wed, 08 Jun 2005 12:12:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg3Ai-0004Mc-OU for mip6@megatron.ietf.org; Wed, 08 Jun 2005 12:12:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13051 for ; Wed, 8 Jun 2005 12:12:50 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg3Vz-0008HF-EQ for mip6@ietf.org; Wed, 08 Jun 2005 12:34:53 -0400 Message-ID: <072a01c56c45$164a04a0$5e6015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Nicolas Montavont" References: <20050608143518.4d5b218e.ernst@sfc.wide.ad.jp> <06b201c56c3e$28df6b70$5e6015ac@dcml.docomolabsusa.com> <42A711F3.8050302@nist.gov> Subject: Re: [Mip6] Monami6 mailing list: MObile Nodes And Multiple Interfacesin IPv6 Date: Wed, 8 Jun 2005 09:13:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Thierry Ernst X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Nicolas, > About introducing this work in MIP6 WG, we tried to present our drafts > and introduce this subject one year ago, without real success (we have > been allocated one slot to discuss draft-montavont, that's hit). Maybe > things have changed since then. > Did you try in NEMO as well? The MIP6 WG has this in its charter: The primary goal of the MIP6 working group will be to enhance base IPv6 mobility by continuing work on developments that are required for wide-scale deployments. I think one could argue that the ability to handle multihomed hosts, given the emergence of multiinterface mobile devices within the last two years since the charter was written, falls into this category. In addition, there's this item: - Support for a Mobile Node changing its home address, either because of renumbering in its home network or because it periodically changes addresses (perhaps via RFC3041) One could argue that the ability to have more than one RFC 3041 privacy home address at a time, and not merely the ability to change the home address periodically, could also be useful even in a single interface device. > Again, I think having a BOF could give us the opportunity to identify > the need of a new WG, or how to introduce this standardization into any > existing WG. > Sure, I think it is worthwhile having a BOF to discuss the technical issues, even if the work ends up in either NEMO or MIP6. Ultimately, its up to the IESG to decide how to manage getting the work done. The primary questions are whether there are people who are willing to do the work, what the problem is, and what the technical issues are in solving it. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 08 15:58:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg6gb-0006YC-VG; Wed, 08 Jun 2005 15:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg6gX-0006XG-B9; Wed, 08 Jun 2005 15:57:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02058; Wed, 8 Jun 2005 15:57:55 -0400 (EDT) Message-Id: <200506081957.PAA02058@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 08 Jun 2005 15:57:55 -0400 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-precfgkbm-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Securing Mobile IPv6 Route Optimization Using a Static Shared Key Author(s) : C. Perkins Filename : draft-ietf-mip6-precfgkbm-02.txt Pages : 6 Date : 2005-6-8 A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-precfgkbm-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-precfgkbm-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-precfgkbm-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: <2005-6-8162341.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-precfgkbm-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-precfgkbm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-8162341.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Thu Jun 09 00:05:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgEIl-0007HV-SQ; Thu, 09 Jun 2005 00:05:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgEIj-0007HH-R4 for mip6@megatron.ietf.org; Thu, 09 Jun 2005 00:05:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26161 for ; Thu, 9 Jun 2005 00:05:50 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgEdd-0005Zs-0C for mip6@ietf.org; Thu, 09 Jun 2005 00:27:30 -0400 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id D10DC4C82A for ; Thu, 9 Jun 2005 13:04:12 +0900 (JST) Date: Thu, 9 Jun 2005 13:04:48 +0900 From: Thierry Ernst To: mip6@ietf.org Subject: Re: [Mip6] Monami6 mailing list: MObile Nodes And Multiple Interfaces in IPv6 Message-Id: <20050609130448.21e6f808.ernst@sfc.wide.ad.jp> In-Reply-To: <42A72C7D.2030903@nist.gov> References: <20050608143518.4d5b218e.ernst@sfc.wide.ad.jp> <06b201c56c3e$28df6b70$5e6015ac@dcml.docomolabsusa.com> <42A711F3.8050302@nist.gov> <072a01c56c45$164a04a0$5e6015ac@dcml.docomolabsusa.com> <42A72C7D.2030903@nist.gov> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi James, everyone, About having a BOF vs speak about this in the MIP6 WG, I think it's pretty obvious for everyone that we need enough time slot to deal with the issue of multihomed mobile nodes and routers. I doubt any of MIP6 or NEMO WG would allocate enough time, and since the topics spans both WGs, a BOF is full of sense. I think James doesn't argue having a BOF, but only argue about creating a WG. So we want to request a BOF (which may end up either in a new WG - I think it would be better, and necessary; or in a new item in MIP6 or NEMO). I think we should discuss the purpose of the BOF and the intended output on the Monami6 ML from now on: please visit http://www.nautilis6.org/ietf for registering. > >>About introducing this work in MIP6 WG, we tried to present our > >drafts>and introduce this subject one year ago, without real success > >(we have>been allocated one slot to discuss draft-montavont, that's > >hit). Maybe>things have changed since then. > >> > >> > >> > > > >Did you try in NEMO as well? Well, we have some activity there, but this issue is not specific to NEMO, so let's not mix things. I think it's better to let the NEMO WG advance it's own work. > Actually, it seems hard at this point of time to ask NEMO WG to focus > on multihoming of both single MNs and MRs / mobile networks. I think > NEMO WG is now beginning to investigate route optimization and > security issues. Maybe I should let Thierry answers this question. Well, we have to complete the prefix delegation work and the RO analysis (plus polish the other documents, including the analysis of multihoming in NEMO). Then, the WG should better close down, or work on a RO solution is the RO analysis concludes we should. In anycase, NEMO should focus on NEMO-specific work. Any work that spans both MH or MR should be in an independent WG. My vision is rather to close down MIP6 and NEMO as soon as possible, and create new WGs that should at once consider solutions for both MHs and MRs. About the IPv4/IPv6 transition team, this work is hosted by both the NEMO and MIP6 WGs. But this is a very specific point. Working on multihomed mobile hosts and routers is broader than the transition activity, and IMHO deserves a dedicated WG to the contrary of the transition work. > >The MIP6 WG has this in its charter: > > > > The primary goal of the MIP6 working group will be to enhance > > base IPv6 mobility by continuing work on developments that are > > required for wide-scale deployments. > > > >I think one could argue that the ability to handle multihomed hosts, > >given the emergence of multiinterface mobile devices within the last > >two years since the charter was written, falls into this category. In > >addition, there's this item: > > > > > Definitly. I think one deployment issue of MIP6 in large scale will be > the multihoming support, and how well MIP6 is able to handle > multihoming features. > > > - Support for a Mobile Node changing its home address, either > > because of renumbering in its home network or because it > > periodically changes addresses (perhaps via RFC3041) > > > >One could argue that the ability to have more than one RFC 3041 > >privacy home address at a time, and not merely the ability to change > >the home address periodically, could also be useful even in a single > >interface device. > > > > > > > >>Again, I think having a BOF could give us the opportunity to > >identify>the need of a new WG, or how to introduce this > >standardization into any>existing WG. > >> > >> > >> > > > >Sure, I think it is worthwhile having a BOF to discuss the technical > >issues, even if the work ends up in either NEMO or MIP6. Ultimately, > >its up to the IESG to decide how to manage getting the work done. The > >primary questions are whether there are people who are willing to do > >the work, what the problem is, and what the technical issues are in > >solving it. > > > > > I am happy we agree on this point. > If we schedule a BOF in Paris, I hope chairs of both MIP6 and NEMO can > join in order to discuss the better place to do this work Thierry. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 09 07:36:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgLL7-0003ld-Ri; Thu, 09 Jun 2005 07:36:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgLL2-0003l7-66; Thu, 09 Jun 2005 07:36:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15608; Thu, 9 Jun 2005 07:36:43 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX18FyBijIjKvrhuqQTTLPYbnZnEjZQRixII=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgLgT-0005EI-P2; Thu, 09 Jun 2005 07:58:54 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1DgLKn-00040X-Nw; Thu, 09 Jun 2005 13:36:36 +0200 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtpsa id 1DgLKm-0002k4-3i; Thu, 09 Jun 2005 13:36:28 +0200 Message-ID: <42A829BB.1060207@tm.uka.de> Date: Thu, 09 Jun 2005 13:36:27 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Samita Chakrabarti References: <200506020323.j523N9bI548231@jurassic.eng.sun.com> In-Reply-To: <200506020323.j523N9bI548231@jurassic.eng.sun.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -44.4 (--------------------------------------------) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, jari.arkko@piuha.net, mobopts@irtf.org Subject: [Mip6] Samitas Review of draft-irtf-mobopts-ro-enhancements-00 (was Re: Review of draft-irtf-mobopts-ro-enhancements-00) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi Samita, I incorporated your comments into the document. Responses are inline. Again, thanks a lot for the review. - Christian ++++ > Overall: This document has a lot of information of which significant > part can go to the appendix for details. Please shorten this draft. > Currently, it is too long; at the end the reader can easily forget > the purpose. This draft needs an editorial change for clear > objectives/goals, list of deployable proposals and analysis of the > suggested ones. Again, some more data to show when and how RO might > be useful in certain applications would be useful. James also listed a few sections that he thinks should be shortened. You added sections 2, 3.2, and 5.12 through 5.17. At the moment, I am collecting these pointers. Will cut the sections at the next stage. > section 1: " Mobile IPv6 [29], its IPv4 counterpart [28], and the > Host Identity Protocol [9] are three dominant mobility-management > protocols that the IETF has developed to facilitate the continued use > of existing transport protocols and applications in an Internet with > mobility support." > > Reference [9] refers to the 00 version of hip draft. At the present, > both MIP6 and MIP4 are in more mature state than HIP. This sentence > could be reworded to say something like "additionally IETF is > developing Host Identity Protocol [9] for mobility management". Ok, it's reworded. > Typo : Page 5 : s/has send/has sent/ Page 6: s/lightway/lightweight/ > Fixed. > section 2: > > Like to see the description in this section be a bit short and > concise. Refering to draft-ietf-mip6-ro-sec makes sense to shorten > this section. Ok. The due reference to draft-ietf-mip6-ro-sec is now in the text. As far as shortening goes, see my first comment. > Section 3.1: Like the diagram. Thanks. :) > 3.2: s/could built/could build/ Please shorten this section See my introductory text. > 3.3: "tree types" - three types? Here is a good place to refer to > ro-sec document and point to certain sections of that document. You are right; I put the reference in. > Section 4. This paragraph is not clear. Please list the three items > (latency, signalling and security improvement) as goals for clear > readability. Rewrote that part. > 4.1 Last line could be: The delays introduced by the rest of the > stack can be significant(see Section 6.3.1). Ok. > 4.2 s/section Section 3/Section 3/ > > "For example, of the 716 Mbps signaling overhead generated by 100 > million route-optimized mobile nodes, 220 Mbps goes through a home > agent." > > Is this a deployment scenario? 100 milllion MNs per one HA? I pass this question on to the folks working at operators or services providers... > Section 5.1 and 5.2 > > Not clear about the enhancement of using "IP-address test" and > "Protected Tunnel". Does it suggest a separate IP-address test other > than HoTI COTI ? Is the "protected tunnel" between MN and CN - not > sure what message these two sections are carrying. These two sections describe technique used in RFC 3775. Their purpose is mainly for completeness. Anyway, I changed the first paragraphs of both section 5.1 and 5.2 to make this clearer. Also, the introductory text of section 5 mentions that the section starts with techniques already used by RFC 3775. > Section 5.3: > > After successful BU to HA, the MN-HA tunnel is created if it is not a > refresh. So, how does the MN send optimistic RO to CN using Hoti msg > while the tunnel is not configured yet ? The SA at the HA may point to an old CoA at the time the HoTI is received because IPsec processing of the HoTI does not depend on the CoA. RFC 2401 defines that source addresses of the outer IPv6 headers are not checked. So the HoTI can pass even when sent from a new CoA. However, the SA must be up-to-date when processing the HoT. After all, that message must be encapsulated somehow and eventually reach the MN at its new attachment point. See also RFC 3776, section 3.2 (Return Routability Signaling), section 5.2.2 (Return Routability Signaling; yes, the name is the same), and section 6.6 (HoTI from the MN). > Section 5.5 : > > Please use a diagram to describe concurrency. It is too much text to > follow. Good idea. Added a diagram. > Section 5.12 - 5.17: > > There are too many options to confuse the reader. Why do we need to > list so many of them ? I think, mobopts draft should pick the strong > improvement alternatives and list them in the main section. The rest > should go to the appendix in a concise form. It has got too much > information to process. Yes, James also mentioned cutting these sections. I see your point. > Section 6; What are the criteria to evaluate recent proposals? If > section 5 lists all the proposals in much abbreviated form, then it'd > be nice if this section analyzes the primary proposals in a concise > manner. In fact, much of the details that were discussed in this section actually belonged to the Enhancement Toolbox section, so I moved it over. Also, I clarified the objective of this section, and rewrote parts of it to make it more concise. Allright. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Samita Chakrabarti wrote: > Hello: > > As per Basavaraj's request, I am posting my comments on this draft. > > Thanks, -Samita > --------------------------------------------------------------------------- > > Overall: This document has a lot of information of which significant part can > go to the appendix for details. Please shorten this draft. Currently, > it is too long; at the end the reader can easily forget the purpose. > This draft needs an editorial change for clear objectives/goals, list > of deployable proposals and analysis of the suggested ones. Again, > some more data to show when and how RO might be useful in certain > applications would be useful. > > section 1: " Mobile IPv6 [29], its IPv4 counterpart [28], and the > Host Identity Protocol [9] are three dominant mobility-management > protocols that the IETF has developed to facilitate the continued use > of existing transport protocols and applications in an Internet with > mobility support." > > Reference [9] refers to the 00 version of hip draft. At the present, > both MIP6 and MIP4 are in more mature state than HIP. This sentence > could be reworded to say something like "additionally IETF is developing > Host Identity Protocol [9] for mobility management". > > > Typo : Page 5 : s/has send/has sent/ Page 6: s/lightway/lightweight/ > > > > section 2: > > Like to see the description in this section be a bit short and concise. > Refering to draft-ietf-mip6-ro-sec makes sense to shorten this > section. > > > Section 3.1: Like the diagram. 3.2: s/could built/could build/ Please > shorten this section > > 3.3: "tree types" - three types? Here is a good place to refer to > ro-sec document and point to certain > sections of that document. > > Section 4. This paragraph is not clear. Please list the three items (latency, > signalling and security improvement) as goals for clear readability. > > 4.1 Last line could be: The delays introduced by the rest of the > stack can be significant(see > Section 6.3.1). 4.2 s/section Section 3/Section 3/ > > "For example, of the 716 Mbps signaling overhead generated by 100 > million route-optimized mobile nodes, 220 Mbps goes through a home > agent." > > Is this a deployment scenario? 100 milllion MNs per one HA? > > Section 5.1 and 5.2 > > Not clear about the enhancement of using "IP-address test" and "Protected > Tunnel". Does it suggest a separate IP-address test other than HoTI > COTI ? Is the "protected tunnel" between MN and CN - not sure what > message these two > sections are carrying. > > Section 5.3: > > After successful BU to HA, the MN-HA tunnel is created if it is not a refresh. > So, how does the MN send optimistic RO to CN using Hoti msg while the tunnel > is not configured yet ? > > Section 5.5 : > > Please use a diagram to describe concurrency. It is too much text to follow. > > Section 5.12 - 5.17: > > There are too many options to confuse the reader. Why do we need to list so > many of them ? I think, mobopts draft should pick the strong improvement > alternatives and list them in the main section. The rest should go to the > appendix in a concise form. It has got too much information to > process. > > Section 6; What are the criteria to evaluate recent proposals? If > section 5 lists all the proposals in much abbreviated form, then it'd > be nice if this section analyzes the primary proposals in a concise manner. > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 09 07:38:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgLMq-0003wX-Dv; Thu, 09 Jun 2005 07:38:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgLMo-0003wL-Oo for mip6@megatron.ietf.org; Thu, 09 Jun 2005 07:38:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15745 for ; Thu, 9 Jun 2005 07:38:33 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgLiF-0005Gj-AY for mip6@ietf.org; Thu, 09 Jun 2005 08:00:45 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id CE7FF4CCBF for ; Thu, 9 Jun 2005 20:37:26 +0900 (JST) Date: Thu, 9 Jun 2005 20:38:01 +0900 From: Thierry Ernst To: ml-mip6 Message-Id: <20050609203801.6305ae0e.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Thu__9_Jun_2005_20_38_01_+0900_0ZSXQ0IG3qnDyRCb" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Subject: [Mip6] Fw: I-D ACTION:draft-montavont-mobileip-multihoming-pb-statement-04.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --Multipart=_Thu__9_Jun_2005_20_38_01_+0900_0ZSXQ0IG3qnDyRCb Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear all, As you can see, we have submitted an improved version of our Problem Statement draft for multihomed mobile nodes operating MIP6. We would appreciate to get comments on the monami6 ML (join from http://www.nautilus6.org/ietf/index.html) rather than on mip6 unless you don't want to join this IETF ML for some good reasons. Thierry --Multipart=_Thu__9_Jun_2005_20_38_01_+0900_0ZSXQ0IG3qnDyRCb Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Original-To: ernst@sfc.wide.ad.jp Received: from ironport1.sfc.wide.ad.jp (ironport1.sfc.wide.ad.jp [203.178.142.150]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 093F04C0E5; Thu, 9 Jun 2005 05:15:29 +0900 (JST) Received: from megatron.ietf.org (132.151.6.71) by ironport1.sfc.wide.ad.jp with ESMTP; 09 Jun 2005 05:15:48 +0900 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= X-IronPort-AV: i="3.93,184,1114959600"; d="txt'208?scan'208,208"; a="1935063:sNHT94478468" Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg6wD-0006C8-GN; Wed, 08 Jun 2005 16:14:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg6ah-0005Km-Rv for i-d-announce@megatron.ietf.org; Wed, 08 Jun 2005 15:51:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00830 for ; Wed, 8 Jun 2005 15:51:53 -0400 (EDT) Message-Id: <200506081951.PAA00830@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 08 Jun 2005 15:51:53 -0400 Subject: I-D ACTION:draft-montavont-mobileip-multihoming-pb-statement-04.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Multihoming in Mobile IPv6 Author(s) : N. Montavont, et al. Filename : draft-montavont-mobileip-multihoming-pb-statement-04.txt Pages : 33 Date : 2005-6-8 The use of multiple interfaces is foreseen to provide ubiquitous, permanent and fault-tolerant access to the Internet, particularly on mobile nodes which are more prone to failure or sudden lack of connectivity. However, Mobile IPv6 currently lacks support for such multihomed nodes. Individual solutions have been proposed to extend Mobile IPv6 but all issues have not been addressed in a single document. The purpose of the present document is thus to fill up this gap and to raise the discussion in order to make sure that forthcoming solutions will address all the issues. In this document, we propose a taxonomy to classify the situations where a mobile node could be multihomed. This taxonomy is then used to highlight the issues preventing mobile nodes operating Mobile IPv6 to be multihomed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-montavont-mobileip-multihoming-pb-statement-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-montavont-mobileip-multihoming-pb-statement-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-montavont-mobileip-multihoming-pb-statement-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-8162236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montavont-mobileip-multihoming-pb-statement-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-montavont-mobileip-multihoming-pb-statement-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-8162236.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --Multipart=_Thu__9_Jun_2005_20_38_01_+0900_0ZSXQ0IG3qnDyRCb Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --Multipart=_Thu__9_Jun_2005_20_38_01_+0900_0ZSXQ0IG3qnDyRCb-- From mip6-bounces@ietf.org Thu Jun 09 08:09:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgLqc-00060b-Hx; Thu, 09 Jun 2005 08:09:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg2il-0007kY-9y for mip6@megatron.ietf.org; Wed, 08 Jun 2005 11:44:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10924 for ; Wed, 8 Jun 2005 11:43:56 -0400 (EDT) Received: from rimp1.nist.gov ([129.6.16.226] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg340-0007ZN-SA for mip6@ietf.org; Wed, 08 Jun 2005 12:05:58 -0400 Received: from [129.6.50.178] (p613571.campus.nist.gov [129.6.50.178] (may be forged)) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j58FhTk0007164; Wed, 8 Jun 2005 11:43:33 -0400 Message-ID: <42A711F3.8050302@nist.gov> Date: Wed, 08 Jun 2005 11:42:43 -0400 From: Nicolas Montavont User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Monami6 mailing list: MObile Nodes And Multiple Interfacesin IPv6 References: <20050608143518.4d5b218e.ernst@sfc.wide.ad.jp> <06b201c56c3e$28df6b70$5e6015ac@dcml.docomolabsusa.com> In-Reply-To: <06b201c56c3e$28df6b70$5e6015ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: nicolas.montavont@nist.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 09 Jun 2005 08:09:21 -0400 Cc: mip6@ietf.org, Thierry Ernst X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi James, Thank you for expressing your valuable thoughts on the Monami6 BOF. I think one of the purpose of the BOF is to gather interested people to discuss the value to have a dedicated WG to treat Multihoming on nodes operating MIP6 and NEMO. It would be good to have a slot time long enough to focus on that goal, and to determine how to do this work. And I think this work should not be sparse into several WGs. About introducing this work in MIP6 WG, we tried to present our drafts and introduce this subject one year ago, without real success (we have been allocated one slot to discuss draft-montavont, that's hit). Maybe things have changed since then. Again, I think having a BOF could give us the opportunity to identify the need of a new WG, or how to introduce this standardization into any existing WG. Nicolas James Kempf wrote: >Thierry, > >I'm certainly interested in this and, in the past, I've organized a bar BOF >on multiple host registrations, though the primary interest at that point >seemed to be for Mobile IPv4. Nothing came out of it, though, since nobody >seemed to want to really work on the problem (as opposed to talking about >it). I'm glad to see that's changed. > >But I did not sense any hostility to working on this problem (more lack of >committment even though there was interest) in the MIP6 WG, and I believe >that would, in fact, be a good venue to do the work. I think MIP6 is >approaching completion of existing charter items and might possibly consider >a charter update. Or perhaps your concern is that the work spans multihomed >mobile network and multihomed hosts, and therefore spans the charters of the >two WGs? I might point out that the MIP IPv4/IPv6 transition team is >currently being hosted by the MIP6 WG but is also working to accommodate >mobile networks? Perhaps the load could be split and the topic of multihomed >hosts and networks could be hosted by NEMO? > >I don't want to discourage the initiative to have a BOF in Paris, but just >bring up a couple of additional possibilities for consideration. Good >working group chairs are a scarce resource in IETF, and the fewer WGs the >IESG has to keep track of the higher the probability that they will be able >to achieve better management. > > jak > > > >----- Original Message ----- >From: "Thierry Ernst" >To: >Sent: Tuesday, June 07, 2005 10:35 PM >Subject: [Mip6] Monami6 mailing list: MObile Nodes And Multiple Interfacesin >IPv6 > > > > >>Dear all, >> >>This is a announcement and motivations to join the Monami6 mailiing >>list: http://www.nautilus6.org/ietf/ >> >>In several occasions, the issue of supporting and using multiple >>interfaces **simulateneously** on mobile nodes operating MIP6 (or NEMO >>BS) were discussed on this ML and other places. There are several >>solutions, each addressing a different part of the entire problem. There >>were some attempts to include a milestone in the MIP6 charter to work on >>that topic, but this was rejected, for several reasons including: >> >>- no time to deal with this topic [agree a given WG has limited time] >>- some claiming it's not necessary [huh ?] >>- topic is too broad to be covered by MIP6 WG [agree] >>- should be done at IRTF [huh ?] >>- and other. >> >>Basically, MIP (and NEMO Basic Support) would be affected by small >>straight forward changes (multiple CoA registration for instance), >>whereas additional non-MIP-specific mechanisms would be needed to >>benefit from the multihomed configurations of MNs. >> >>It is doubful, given the past resistance in this MIP6 WG that MIP6 would >>be the right working group, all the more since some of the idenfified >>issues are not MIP6 issues per se (however, it is a common understanding >>of the people working on these issues that MIP6 and NEMO deployment >>would most benefit of such extensions, this driving us to focus on >>IP-layer mobility protocols). >> >>We are therefore envisioning the creation of a new working group and we >>are engaged into the set up of a BOF at next IETF meeting in Paris. The >>potential-&-to-be-approved BOF would be called Monami6 (MObile Nodes And >>Multiple Interfaces in IPv6). If you are interested, please do join our >>IETF mailing list from the web page http://www.nautilus6.org/ietf/ >>where our objectives are explained and relevant documents are listed. >> >>If you lack background: >> >>Problem statement drafts: >>1. Goals and Benefits of Multihoming >> draft-ernst-generic-goals-and-benefits-01.txt >>2. Analysis of Multihoming in Network Mobility Support >> draft-ietf-nemo-multihoming-issues-02.txt >>3. Analysis of Multihoming in Mobile IPv6 >> draft-montavont-mobileip-multihoming-pb-statement-04.txt >> >>There were some discussions about this topic on >>the MIP6 ML quite frequently, including in the following threads (see >>MIP6 archives): >>- Sep.03: Are multihoming mechanisms part of the charter >>- Oct.03: Draft Agenda for WG meeting at IETF58 >>- Nov.03: multi-interfaced vs multi-addressed [Re: [Mip6] Draft Agenda >> for WG meeting at IETF58] >>- Dec.04: FW: MIP6 agenda (Final) >> >>And discussions during IETF meetings: >>- Nov.03: MIP6 WG, 58th IETF meeting >>- Nov.03: Multi-link flow Bar BOF (somewhat related) >>- Dec.04: MIP6 WG, 61th IETF meeting >> >>Regards, >>Thierry. >> >>_______________________________________________ >>Mip6 mailing list >>Mip6@ietf.org >>https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> > > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 09 08:09:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgLqc-000610-VZ; Thu, 09 Jun 2005 08:09:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg4U7-0005NM-2g for mip6@megatron.ietf.org; Wed, 08 Jun 2005 13:37:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19915 for ; Wed, 8 Jun 2005 13:36:57 -0400 (EDT) Received: from rimp1.nist.gov ([129.6.16.226] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dg4pP-0001pe-3m for mip6@ietf.org; Wed, 08 Jun 2005 13:58:59 -0400 Received: from [129.6.50.178] (p613571.campus.nist.gov [129.6.50.178] (may be forged)) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j58HahL2026824; Wed, 8 Jun 2005 13:36:47 -0400 Message-ID: <42A72C7D.2030903@nist.gov> Date: Wed, 08 Jun 2005 13:35:57 -0400 From: Nicolas Montavont User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Monami6 mailing list: MObile Nodes And Multiple Interfaces in IPv6 References: <20050608143518.4d5b218e.ernst@sfc.wide.ad.jp> <06b201c56c3e$28df6b70$5e6015ac@dcml.docomolabsusa.com> <42A711F3.8050302@nist.gov> <072a01c56c45$164a04a0$5e6015ac@dcml.docomolabsusa.com> In-Reply-To: <072a01c56c45$164a04a0$5e6015ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: nicolas.montavont@nist.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 09 Jun 2005 08:09:21 -0400 Cc: mip6@ietf.org, Thierry Ernst X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org James Kempf wrote: >Nicolas, > > > >>About introducing this work in MIP6 WG, we tried to present our drafts >>and introduce this subject one year ago, without real success (we have >>been allocated one slot to discuss draft-montavont, that's hit). Maybe >>things have changed since then. >> >> >> > >Did you try in NEMO as well? > > Actually, it seems hard at this point of time to ask NEMO WG to focus on multihoming of both single MNs and MRs / mobile networks. I think NEMO WG is now beginning to investigate route optimization and security issues. Maybe I should let Thierry answers this question. >The MIP6 WG has this in its charter: > > The primary goal of the MIP6 working group will be to enhance base > IPv6 mobility by continuing work on developments that are required for > wide-scale deployments. > >I think one could argue that the ability to handle multihomed hosts, given >the emergence of multiinterface mobile devices within the last two years >since the charter was written, falls into this category. In addition, >there's this item: > > Definitly. I think one deployment issue of MIP6 in large scale will be the multihoming support, and how well MIP6 is able to handle multihoming features. > - Support for a Mobile Node changing its home address, either > because of renumbering in its home network or because it > periodically changes addresses (perhaps via RFC3041) > >One could argue that the ability to have more than one RFC 3041 privacy home >address at a time, and not merely the ability to change the home address >periodically, could also be useful even in a single interface device. > > > >>Again, I think having a BOF could give us the opportunity to identify >>the need of a new WG, or how to introduce this standardization into any >>existing WG. >> >> >> > >Sure, I think it is worthwhile having a BOF to discuss the technical issues, >even if the work ends up in either NEMO or MIP6. Ultimately, its up to the >IESG to decide how to manage getting the work done. The primary questions >are whether there are people who are willing to do the work, what the >problem is, and what the technical issues are in solving it. > > I am happy we agree on this point. If we schedule a BOF in Paris, I hope chairs of both MIP6 and NEMO can join in order to discuss the better place to do this work Nicolas > jak > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 09 09:27:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgN4g-0005vz-O5; Thu, 09 Jun 2005 09:27:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgN4f-0005vW-JQ; Thu, 09 Jun 2005 09:27:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28970; Thu, 9 Jun 2005 09:27:55 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX19qLD1FnC6rHFGHYmAvtXTaPUwUvViqz2w=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgNQ8-00034u-7W; Thu, 09 Jun 2005 09:50:09 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1DgN4Y-0007lH-54; Thu, 09 Jun 2005 15:27:54 +0200 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtpsa id 1DgN4W-0003C3-5i; Thu, 09 Jun 2005 15:27:48 +0200 Message-ID: <42A843D2.50804@tm.uka.de> Date: Thu, 09 Jun 2005 15:27:46 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Narayanan Vidya-CVN065 Subject: Vidyas Review of draft-irtf-mobopts-ro-enhancements-00 (was Re: [Mip6] Review Comments and Questions on draft-irtf-mobopts-ro-enhancements-00.txt) References: <1B631E11D496D711BB2800065BFCB6A11B7A7084@il02exm13> In-Reply-To: <1B631E11D496D711BB2800065BFCB6A11B7A7084@il02exm13> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -40.6 (----------------------------------------) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hy Vidya, based on your review, I revised the RO Enhancements document. You can check the new version at http://doc.tm.uka.de/2005/draft-irtf-mobopts-ro-enhancements-01-pre.txt Thanks again for your comments, - Christian ++++ > 1. The draft provides a good, comprehensive overview of the security > aspects of RO and the solution space in general. However, given that > there is already a draft on RO security, perhaps the security > aspects should be integrated with that draft and this draft should > attempt to cover the solution space alone? The security aspects discussed in the document certainly cannot replace the RO Security Background. Nevertheless, Jari and I thought we should put them in to give the reader just enough of background she or he needs to understand the document. Definitely, if the Research Group decides to remove the security section from this RO Enhancements draft, or move it to the RO Security Background, we'll do that. Please don't mind that I leave the security section in the document until we decide what to do. > 2. Need for "fast" RO - The draft mentions in a few places (including > section 4) that one of the objectives for RO is latency > optimization. I belong to the group that is yet to be convinced that > there is a real need for "fast" RO. In my mind, there is a need for > fast handoffs, but not necessarily fast RO. I don't think that RO is > going to satisfy the latency requirements of real-time applications. > Link layer mechanisms are defining methods to reduce the handoff > latency to less than 100ms or so. Such enhancements are useful during > inter-subnet handoffs only if the network layer latency can be > reduced to adding very marginal latency on top of that. Do we really > think RO is going to buy us that? Given that any design for RO cannot > control the relative positions of the CN and the MN, it doesn't seem > like any RO solution can claim that. The need for such applications > really drives us towards FMIP-like approaches. What you identify is an exemplar for the trade-off between good performance and high investment costs. ;) But there have also been comments (by James and Samita) to remove the parts on FMIP and HMIP from the RO Enhancement draft. The reason being that both may be combined, but are not directly related to RO. Still, you are making a good point. I added this to the Conclusions. > I still think RO can be useful - when long periods of traffic > exchange happens between an MN and CN, it may be better to get away > from triangular routing. I noticed that James brought up the point of > almost ubiquitous wireline bandwidth perhaps eliminating the need for > RO. While that is a very valid argument against the real need for RO, > I think it will still be good to design the support for RO, before > widespread deployment of CNs that don't support it. Yes, I agree. You may also want to avoid that all data goes through a single of of failure, i.e., the home agent (unless you do HA relocation, of course). In fact, this contradicts the original Internet design guideline to make communications robust to outages of some network entities. > I am only questioning the need for latency reduction as a design > objective for an RO solution. I think it's attractive, even for not-so-delay-sensitive applications, to reduce global signaling delays from two RTT to one RTT. > 3. One of the situations in which RO can be useful is when the RO > solution allows the MN and CN to continue communication during a > period of HA unavailability (failure, for e.g.). The current RR > solution does not achieve this, due to the necessity for short > lifetimes and hence the need for home address tests via the HA every > so often. It may be worthwhile adding this to the design goals for > the solution. That's an excellent comment. This affects both data packets and signaling packets. (See my comment from above.) I added a sub-section on this to section 4. > 4. Section 3.3 (last paragraph) mentions the fact that the current RR > solution trades off protection against attacks on CN's processing > capacity for protection against CN's memory. Perhaps an RO solution > can be flexible enough to allow the CN to determine what trade off > makes sense in a particular case? That's right. Added this to section 3.3. > 5. Section 6.2.1 talks about HMIP and FMIP-like proposals. I am not > sure I understand how such proposals can replace RO. For e.g., the > use of FMIP will remove stringent latency requirements on RO, but not > provide a solution for RO itself, right? You are right: One should emphasize that there are two aspects of RO: Routing data packets the direct way, and making end-to-end signaling efficient. This document talks about the latter. I added this clarification to section 5.15. Ok, best regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Narayanan Vidya-CVN065 wrote: > Here are some comments and questions I have from reviewing the draft. > > > Thanks, Vidya > > 1. The draft provides a good, comprehensive overview of the security > aspects of RO and the solution space in general. However, given that > there is already a draft on RO security, perhaps the security aspects > should be integrated with that draft and this draft should attempt > to cover the solution space alone? > > 2. Need for "fast" RO - The draft mentions in a few places (including > section 4) that one of the objectives for RO is latency > optimization. I belong to the group that is yet to be convinced that > there is a real need for "fast" RO. In my mind, there is a need for > fast handoffs, but not necessarily fast RO. I don't think that RO is > going to satisfy the latency requirements of real-time applications. > Link layer mechanisms are defining methods to reduce the handoff > latency to less than 100ms or so. Such enhancements are useful during > inter-subnet handoffs only if the network layer latency can be > reduced to adding very marginal latency on top of that. Do we really > think RO is going to buy us that? Given that any design for RO cannot > control the relative positions of the CN and the MN, it doesn't seem > like any RO solution can claim that. The need for such applications > really drives us towards FMIP-like approaches. > > I still think RO can be useful - when long periods of traffic > exchange happens between an MN and CN, it may be better to get away > from triangular routing. I noticed that James brought up the point of > almost ubiquitous wireline bandwidth perhaps eliminating the need for > RO. While that is a very valid argument against the real need for RO, > I think it will still be good to design the support for RO, before > widespread deployment of CNs that don't support it. > > I am only questioning the need for latency reduction as a design > objective for an RO solution. > > 3. One of the situations in which RO can be useful is when the RO > solution allows the MN and CN to continue communication during a > period of HA unavailability (failure, for e.g.). The current RR > solution does not achieve this, due to the necessity for short > lifetimes and hence the need for home address tests via the HA every > so often. It may be worthwhile adding this to the design goals for > the solution. > > 4. Section 3.3 (last paragraph) mentions the fact that the current RR > solution trades off protection against attacks on CN's processing > capacity for protection against CN's memory. Perhaps an RO solution > can be flexible enough to allow the CN to determine what trade off > makes sense in a particular case? > > 5. Section 6.2.1 talks about HMIP and FMIP-like proposals. I am not > sure I understand how such proposals can replace RO. For e.g., the > use of FMIP will remove stringent latency requirements on RO, but not > provide a solution for RO itself, right? _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 09 09:39:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgNFk-0000NI-U1; Thu, 09 Jun 2005 09:39:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgNFi-0000N0-Gf; Thu, 09 Jun 2005 09:39:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00237; Thu, 9 Jun 2005 09:39:20 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX18yODkO9Rl97ITYpJugbdOkxhey7M3bNBY=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgNbB-0003cp-PQ; Thu, 09 Jun 2005 10:01:34 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1DgNFd-00085T-3z; Thu, 09 Jun 2005 15:39:20 +0200 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtpsa id 1DgNFb-0004r2-IX; Thu, 09 Jun 2005 15:39:15 +0200 Message-ID: <42A84682.6060707@tm.uka.de> Date: Thu, 09 Jun 2005 15:39:14 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Narayanan Vidya-CVN065 , "'Wassim Haddad'" Subject: Re: [Mobopts] RE: [Mip6] Review Comments and Questions on draft-irtf-mobopts-ro-enhancements-00.txt References: <1B631E11D496D711BB2800065BFCB6A11B7A7086@il02exm13> In-Reply-To: <1B631E11D496D711BB2800065BFCB6A11B7A7086@il02exm13> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -40.5 (----------------------------------------) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi Vidya, hi Wassim, I added the aspect of independecy from the HA to section 5.9 of draft-irtf-mobopts-ro-enhancements-00. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Narayanan Vidya-CVN065 wrote: > Hi Wassim, Yes, this seems to be the case. I did not see this point > brought out in draft-irtf-mobopts-ro-enhancements. It might be good > to add some text about this in the draft. > > Regards, Vidya > > >> -----Original Message----- From: Wassim Haddad >> [mailto:Wassim.Haddad@ericsson.com] Sent: Friday, May 27, 2005 8:57 >> AM To: Narayanan Vidya-CVN065 Cc: mip6@ietf.org; mobopts@irtf.org >> Subject: Re: [Mip6] Review Comments and Questions on >> draft-irtf-mobopts-ro-enhancemen ts-00.txt >> >> >> Hello Vidya, >> >> On 26-May-05, at 11:25 PM, Narayanan Vidya-CVN065 wrote: >> >> >>> 3. One of the situations in which RO can be useful is when the RO >>> solution allows the MN and CN to continue communication during a >>> period of HA unavailability (failure, for e.g.). The current RR >>> solution does not achieve this, due to the necessity for short >>> lifetimes and hence the need for home address tests via the HA >>> every so often. It may be worthwhile adding this to the design >>> goals for the solution. >> >> => In OMIPv6, you need to do only *one* HoA test at the beginning. >> The shared secret, i.e., SKbm, lifetime is set to 24 hours so that >> you don't need to exchange HoTI/HoT messages during this period. >> >> >> Regards, >> >> Wassim H. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 09 10:46:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgOID-0000gv-VI; Thu, 09 Jun 2005 10:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgOIC-0000gj-1v; Thu, 09 Jun 2005 10:46:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08058; Thu, 9 Jun 2005 10:45:57 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX19YbFmiORKhAgwLseUg5irx3QhJDlYBb7o=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgOdf-00071x-Dc; Thu, 09 Jun 2005 11:08:12 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1DgOI0-0001sE-G5; Thu, 09 Jun 2005 16:45:56 +0200 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtpsa id 1DgOHy-0006tG-Ne; Thu, 09 Jun 2005 16:45:46 +0200 Message-ID: <42A85619.8030703@tm.uka.de> Date: Thu, 09 Jun 2005 16:45:45 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Gerardo Giaretta References: In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -28.7 (----------------------------) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Jari Arkko , mobopts@irtf.org Subject: [Mip6] Re: Review of draft-irtf-mobopts-ro-enhancements-00 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi Gerardo, thanks again for reviewing the doc. Some responses below. You can check the new version at http://doc.tm.uka.de/2005/draft-irtf-mobopts-ro-enhancements-01-pre.txt - Christian ++++ > General comment: I think the draft is very well-written and provide a > complete analysis of the topic. The unique general issue I found is > that it is very long. I agree with James' comment that the draft > could be shortened removing some sections that are not completely in > the scope of the draft (e.g. section 5.13 and 5.14, more about these > sections below). Ok, will do that. > More detailed comments: > > - section 1, paragraph 4 "In the opposite direction, the mobile node > may tunnel packets to the home agent". I think this sentence is not > completely correct, or at least a bit misleading. If route > optimization is not used, the MN MUST tunnel packets to the HA. Is > "MAY" used in this sentence to highlight that the MN can choose to > use bidirectional tunneling or route optimization? You are right, the text is misleading. The idea was that RO is the alternative, and the MN may choose (provided the CN supports RO). But, again, this is confusing, so I changed it. > - section 1, paragraph 10 "This can lead to handover delay > unacceptable for many real-time or interactive applications like > Voice over IP (VoIP) and audio or video streaming". I'd suggest to > remove audio/video streaming here. Streaming applications are not > real-time nor interactive: they usually buffer few seconds of the > movie/sound and thus are usually not affected by MIPv6 handover > latency. At least this is what we have experimented in our labs. Would you say that rapid handovers and small buffers in less-provisioned devices can be an issue with streaming? Anyway, I changed the text. > - section 3.1, paragraph 7 "The mobile node must compute a > message-authentication code keyed with the Home and Care-of Keygen > Token". Actually the MAC is keyed with the Kbm, that is a 20 octets > SHA-1 hash of the concatenation of Home and Care-of Keygen Token Right, this was imprecise. Corrected it. > - section 4.1, paragraph 1: I would mention explicitly that the > handoff latency for a route-optimized communication is longer than > for a bi-directional tunneled communication. Yes, it's added. > - section 4.1, paragraph 2: since the CN is not always required to > send the BA, I wonder why the MN should by default wait for the BA. > Or are you suggesting the MN asks the CN an ack? If so, I think the > sentence should be rephrased. Right. > - section 4.1, paragraph 3 "But more generally, mobile nodes wait for > the home registration to be completed and acknowledged before > initiating the correspondent registration". Are you referring to some > specific implementations? I'm asking this because the open source > implementation we use in our labs does not wait the BA. Kame-Shisa does it. We added the optimization not to wait for the BA from the HA. Actually, not waiting for the BA is not standard-conform. RFC 3775 says that the lifetime of correspondent registrations must not exceed that of the home registration. And the latter becomes known to the MN only with the BA. I don't think this requirement is critical, though. After all, it's up to the MN to request the CN lifetime anyway. It could just ignore the home-registration lifetime. > - section 4.4, paragraph 2: I would add references to > draft-koodli-mip6-location-privacy-00 and to > draft-koodli-mip6-location-privacy-solutions-00 Definitely a good idea. > - section 5.2, paragraph 1: What do you mean by "close to the mobile > node"? Shouldn't it be "on the path between MN and HA"? The critical link on the patch between the MN and the HA is a wireless first hop. Anyway, the text is unclear. Rewrote that sentence. > - section 5.3, paragraph 2: the sentence is not clear to me. The last > BA is referred to BA from CN, I suppose. If so, I think it should be > mentioned explicitly. Done. > - section 5.13: as mentioned before I think this section is not > really in the scope of the draft. If you think it is, I'd suggest to > include some more text explaining how HMIPv6 influences RO operations > (e.g. reduction of signaling overhead). The same applies to section > 5.14. I think that FMIPv6 has even less impact on RO than HMIPv6. So > I suggest you include some more text to explain how these protocols > are tied to RO. It seems there is pretty much agreement in that FMIPv6 and HMIPv6 should be removed from this particular document. > - section 5.16, last sentence: are there simulations that prove that > RR can be too expensive? A reference could be helpful. I don't have such a reference. Is your suggestion to remove the section in this case? > - section 6.2.1, last paragraph: HMIPv6 causes always a tunneling > overhead that is not present in plain MIPv6. Therefore, some > localized mobility protocols always cause overhead and not only "in > some situations". That's right. But I have already removed that sub-section. > - section 6.2.2, paragraph 1 "On the other hand, nodes that do share > a common secret should be allowed to omit the home-address test". > Isn't required that the common secret is tied to the Home Address > used in order to remove the home address test? You are right. Added that. > Editorial comments: > > - section 4.1, last paragraph: Section 6.3.1 should be in brackets or > similar Oops, it's done. > - section 5.1, paragraph 2: s/IP-ddress/IP-address Ok. > - section 5.7, paragraph 5: s/its is the data/it is the data Ok. > - section 5.8, paragraph 2: s/it in general/it is in general Ok. > Hope this helps. It did. ;) Thanks, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Gerardo Giaretta wrote: > Hi Christian and Jari, > > Raj requested me to review draft-irtf-mobopts-ro-enhancements-00. > Here are some comments and question. > > General comment: I think the draft is very well-written and provide a > complete analysis of the topic. The unique general issue I found is > that it is very long. I agree with James' comment that the draft > could be shortened removing some sections that are not completely in > the scope of the draft (e.g. section 5.13 and 5.14, more about these > sections below). > > More detailed comments: > > - section 1, paragraph 4 "In the opposite direction, the mobile node > may tunnel packets to the home agent". I think this sentence is not > completely correct, or at least a bit misleading. If route > optimization is not used, the MN MUST tunnel packets to the HA. Is > "MAY" used in this sentence to highlight that the MN can choose to > use bidirectional tunneling or route optimization? > > - section 1, paragraph 10 "This can lead to handover delay > unacceptable for many real-time or interactive applications like > Voice over IP (VoIP) and audio or video streaming". I'd suggest to > remove audio/video streaming here. Streaming applications are not > real-time nor interactive: they usually buffer few seconds of the > movie/sound and thus are usually not affected by MIPv6 handover > latency. At least this is what we have experimented in our labs. > > - section 3.1, paragraph 7 "The mobile node must compute a > message-authentication code keyed with the Home and Care-of Keygen > Token". Actually the MAC is keyed with the Kbm, that is a 20 octets > SHA-1 hash of the concatenation of Home and Care-of Keygen Token > > - section 4.1, paragraph 1: I would mention explicitly that the > handoff latency for a route-optimized communication is longer than > for a bi-directional tunneled communication. > > - section 4.1, paragraph 2: since the CN is not always required to > send the BA, I wonder why the MN should by default wait for the BA. > Or are you suggesting the MN asks the CN an ack? If so, I think the > sentence should be rephrased. > > - section 4.1, paragraph 3 "But more generally, mobile nodes wait for > the home registration to be completed and acknowledged before > initiating the correspondent registration". Are you referring to some > specific implementations? I'm asking this because the open source > implementation we use in our labs does not wait the BA. > > - section 4.4, paragraph 2: I would add references to > draft-koodli-mip6-location-privacy-00 and to > draft-koodli-mip6-location-privacy-solutions-00 > > - section 5.2, paragraph 1: What do you mean by "close to the mobile > node"? Shouldn't it be "on the path between MN and HA"? > > - section 5.3, paragraph 2: the sentence is not clear to me. The last > BA is referred to BA from CN, I suppose. If so, I think it should be > mentioned explicitly. > > - section 5.13: as mentioned before I think this section is not > really in the scope of the draft. If you think it is, I'd suggest to > include some more text explaining how HMIPv6 influences RO operations > (e.g. reduction of signaling overhead). The same applies to section > 5.14. I think that FMIPv6 has even less impact on RO than HMIPv6. So > I suggest you include some more text to explain how these protocols > are tied to RO. > > - section 5.16, last sentence: are there simulations that prove that > RR can be too expensive? A reference could be helpful. > > - section 6.2.1, last paragraph: HMIPv6 causes always a tunneling > overhead that is not present in plain MIPv6. Therefore, some > localized mobility protocols always cause overhead and not only "in > some situations". > > - section 6.2.2, paragraph 1 "On the other hand, nodes that do share > a common secret should be allowed to omit the home-address test". > Isn't required that the common secret is tied to the Home Address > used in order to remove the home address test? > > > Editorial comments: > > - section 4.1, last paragraph: Section 6.3.1 should be in brackets or > similar > > - section 5.1, paragraph 2: s/IP-ddress/IP-address > > - section 5.7, paragraph 5: s/its is the data/it is the data > > - section 5.8, paragraph 2: s/it in general/it is in general > > > Hope this helps. > > Regards, --Gerardo > > > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia > S.p.A. > > ==================================================================== > CONFIDENTIALITY NOTICE This message and its attachments are addressed > solely to the persons above and may contain confidential information. > If you have received the message in error, be informed that any use > of the content hereof is prohibited. Please return it immediately to > the sender and delete the message. Should you have any questions, > please send an e_mail to MailAdmin@tilab.com. Thank you > ==================================================================== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 09 12:28:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgPtW-0008Im-Ti; Thu, 09 Jun 2005 12:28:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgPtV-0008IX-Jz; Thu, 09 Jun 2005 12:28:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18787; Thu, 9 Jun 2005 12:28:34 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1/VgNAXJ7pHHNmE/2nrYpwwWZ/JLedvhjs=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgQEy-0004nO-7b; Thu, 09 Jun 2005 12:50:50 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1DgPtH-0005CK-Lp; Thu, 09 Jun 2005 18:28:27 +0200 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtpsa id 1DgPtG-0006Gk-2C; Thu, 09 Jun 2005 18:28:22 +0200 Message-ID: <42A86E25.1080704@tm.uka.de> Date: Thu, 09 Jun 2005 18:28:21 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Francis Dupont Subject: Re: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00 References: <200506071046.j57AkmmC021055@givry.rennes.enst-bretagne.fr> In-Reply-To: <200506071046.j57AkmmC021055@givry.rennes.enst-bretagne.fr> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -28.0 (----------------------------) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , mip6@ietf.org, Jari Arkko , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org > => a general problem in MIPv6 specs is there is no explanation about > when a BA should be asked (always with the HA, and with a CN only when > the previous CoA no more works). Hi Francis, you are saying that the MN should request a BA from the CN when the previous CoA doesn't work any more. Is this specified in RFC 3775 as such? Whether or not it's in RFC 3775, what you say makes sense IMO. I don't think RFC 3775 mention this, however. There is just the last paragraph on page 133... Regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Francis Dupont wrote: > In your previous mail you wrote: > > - section 4.1, paragraph 2: since the CN is not always required to send > the BA, I wonder why the MN should by default wait for the BA. Or are > you suggesting the MN asks the CN an ack? If so, I think the sentence > should be rephrased. > > => a general problem in MIPv6 specs is there is no explanation about > when a BA should be asked (always with the HA, and with a CN only when > the previous CoA no more works). > > - section 4.1, paragraph 3 "But more generally, mobile nodes wait for > the home registration to be completed and acknowledged before initiating > the correspondent registration". Are you referring to some specific > implementations? I'm asking this because the open source implementation > we use in our labs does not wait the BA. > > => as an implementor I agree: there is no reason to wait! And this should > be more true with alternate RO protections. > > Regards > > Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 09 14:53:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgS9q-0003da-Ls; Thu, 09 Jun 2005 14:53:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgS9p-0003dS-L1; Thu, 09 Jun 2005 14:53:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03675; Thu, 9 Jun 2005 14:53:36 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgSVK-0002rK-H1; Thu, 09 Jun 2005 15:15:52 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j59IL1k11805; Thu, 9 Jun 2005 11:21:01 -0700 X-mProtect: <200506091821> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141133.americas.nokia.com (172.18.141.133, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpd8NMjaV; Thu, 09 Jun 2005 11:20:59 PDT Message-ID: <42A89003.4000300@iprg.nokia.com> Date: Thu, 09 Jun 2005 11:52:51 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: chenhongfei Subject: Re: [Mip6] Design team formed for addressing v4 traversal References: <000001c56b32$f3767250$5b5a6e0a@china.huawei.com> In-Reply-To: <000001c56b32$f3767250$5b5a6e0a@china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: 8bit Cc: nemo@ietf.org, mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org chenhongfei wrote: > Hi > > Its difficult to describe my question clearly by word. look the figure > please. > > Router A is the gateway of the Enterprise network. Router B is a router > location in the v6 internet. HOST-A and HOST-B are v4/v6 pc. Enterprise > network and the v6 internet and the Metro network are operated by > different department. Router A should access the v6 internet without > changed the Metro network. After I read the charter of the design team. > I think that result of the design team is a good solution. Router B is > HA and HOST-A is MN. Is that right? yes. this scenario will be addressed. regards Vijay > > > > > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Tuesday, June 07, 2005 6:55 AM > To: chenhongfei > Cc: Basavaraj.Patil@nokia.com; nemo@ietf.org; mip6@ietf.org > Subject: Re: Re: [Mip6] Design team formed for addressing v4 traversal > > > > I am not sure I understood your questions completely, but I will > > try to answer some of the questions. > > > > chenhongfei wrote: > >> Hello, > >> > >> CNGI(China Next Generation Internet) which is ipv4/ipv6 network has been > >> builded last year. But the network of the collage is IPv4 only now. and > >> the gateway router of the collage isn't connect CNGI directly. It > >> connect CNGI across the metro network which is ipv4 only. So the ISATAP > >> isn't a good solution. I read about the charter of design term. Could > >> this protocol solve this issue? > > > > yes. the college network and the metro network will both be treated > > as pure IPv4 routable Internet and the MN would be able to reach > > the IPv6 Home Agent. > > > >> Could HA assign a fixed IPv6 address for > >> MN? > > > > yes. the MN can have a fixed IPv6 HoA. > > > > Vijay > > > >> > >> Hongfei Chen > >> > >> -----SJ<~T-<~----- > >> 7"<~HK: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] 4z1m > >> Basavaraj.Patil@nokia.com > >> 7"KMJ1 >> JU<~HK: mip6@ietf.org; nemo@ietf.org > >> VwLb: [Mip6] Design team formed for addressing v4 traversal > >> > >> > >> Hello, > >> > >> The MIP6 and NEMO WGs have formed a design team to work on developing > >> a comprehensive solution for dealing with the problem of MIP6 > >> MNs/Routers that roam into and attach to a v4 only access network. > >> > >> The design team consists of : > >> James Kempf, Ryuji Wakikawa, Pascal Thubert, Hesham Soliman and, > >> Vijay Devarapalli > >> > >> The MIP6/NEMO chairs will advise the design team as needed. > >> > >> The charter of the design team is to: > >> > >> 1. Write up the problem statement, scenarios to be addressed and > >> requirements > >> 2. Develop a protocol solution to address the scenarios > >> > >> The design team will present at least the scenarios and problem > >> statement being worked on at the next IETF meeting (IETF63). > >> A mailing list for the DT discussions has been setup (thanks to > >> Ryuji). The archives will be made available to the MIP6/NEMO WGs when > >> the design team has concluded. > >> > >> If you have any questions about this work, please contact the chairs. > >> > >> -MIP6/NEMO chairs > >> > >> > >> > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >> > >> > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 09 15:05:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgSKy-0005gW-GS; Thu, 09 Jun 2005 15:05:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgSKx-0005fm-Qj for mip6@megatron.ietf.org; Thu, 09 Jun 2005 15:05:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04844 for ; Thu, 9 Jun 2005 15:05:06 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgSgT-0003DH-KR for mip6@ietf.org; Thu, 09 Jun 2005 15:27:22 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j59IWqY31410; Thu, 9 Jun 2005 11:32:52 -0700 X-mProtect: <200506091832> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141133.americas.nokia.com (172.18.141.133, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdRULQbU; Thu, 09 Jun 2005 11:32:50 PDT Message-ID: <42A892CA.6090305@iprg.nokia.com> Date: Thu, 09 Jun 2005 12:04:42 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [Mip6] Monami6 mailing list: MObile Nodes And Multiple Interfaces in IPv6 References: <20050608143518.4d5b218e.ernst@sfc.wide.ad.jp> In-Reply-To: <20050608143518.4d5b218e.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org hi Thierry, thanks for your efforts on this. I definitely support this work and see it as something that definitely enhances MIPv6 and NEMO protocols. I also think that this work should be done ASAP. doing the work in a separate WG is fine with me. but I prefer just doing this in the MIP6 WG. a new WG approval takes much longer. I would support modifying the MIP6 charter to include this work. I think the current problem statement draft you have is clear enough to start work on the solution right away. Vijay Thierry Ernst wrote: > Dear all, > > This is a announcement and motivations to join the Monami6 mailiing > list: http://www.nautilus6.org/ietf/ > > In several occasions, the issue of supporting and using multiple > interfaces **simulateneously** on mobile nodes operating MIP6 (or NEMO > BS) were discussed on this ML and other places. There are several > solutions, each addressing a different part of the entire problem. There > were some attempts to include a milestone in the MIP6 charter to work on > that topic, but this was rejected, for several reasons including: > > - no time to deal with this topic [agree a given WG has limited time] > - some claiming it's not necessary [huh ?] > - topic is too broad to be covered by MIP6 WG [agree] > - should be done at IRTF [huh ?] > - and other. > > Basically, MIP (and NEMO Basic Support) would be affected by small > straight forward changes (multiple CoA registration for instance), > whereas additional non-MIP-specific mechanisms would be needed to > benefit from the multihomed configurations of MNs. > > It is doubful, given the past resistance in this MIP6 WG that MIP6 would > be the right working group, all the more since some of the idenfified > issues are not MIP6 issues per se (however, it is a common understanding > of the people working on these issues that MIP6 and NEMO deployment > would most benefit of such extensions, this driving us to focus on > IP-layer mobility protocols). > > We are therefore envisioning the creation of a new working group and we > are engaged into the set up of a BOF at next IETF meeting in Paris. The > potential-&-to-be-approved BOF would be called Monami6 (MObile Nodes And > Multiple Interfaces in IPv6). If you are interested, please do join our > IETF mailing list from the web page http://www.nautilus6.org/ietf/ > where our objectives are explained and relevant documents are listed. > > If you lack background: > > Problem statement drafts: > 1. Goals and Benefits of Multihoming > draft-ernst-generic-goals-and-benefits-01.txt > 2. Analysis of Multihoming in Network Mobility Support > draft-ietf-nemo-multihoming-issues-02.txt > 3. Analysis of Multihoming in Mobile IPv6 > draft-montavont-mobileip-multihoming-pb-statement-04.txt > > There were some discussions about this topic on > the MIP6 ML quite frequently, including in the following threads (see > MIP6 archives): > - Sep.03: Are multihoming mechanisms part of the charter > - Oct.03: Draft Agenda for WG meeting at IETF58 > - Nov.03: multi-interfaced vs multi-addressed [Re: [Mip6] Draft Agenda > for WG meeting at IETF58] > - Dec.04: FW: MIP6 agenda (Final) > > And discussions during IETF meetings: > - Nov.03: MIP6 WG, 58th IETF meeting > - Nov.03: Multi-link flow Bar BOF (somewhat related) > - Dec.04: MIP6 WG, 61th IETF meeting > > Regards, > Thierry. > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 09 19:14:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgWEk-00013N-5g; Thu, 09 Jun 2005 19:14:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgWEh-00012K-Se; Thu, 09 Jun 2005 19:14:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29027; Thu, 9 Jun 2005 19:14:52 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgWaE-0006nh-3B; Thu, 09 Jun 2005 19:37:12 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j59NELf23331; Fri, 10 Jun 2005 01:14:21 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j59NELNP034795; Fri, 10 Jun 2005 01:14:21 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200506092314.j59NELNP034795@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Christian Vogt Subject: Re: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00 In-reply-to: Your message of Thu, 09 Jun 2005 18:28:21 +0200. <42A86E25.1080704@tm.uka.de> Date: Fri, 10 Jun 2005 01:14:21 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 2.4 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Gerardo Giaretta , mip6@ietf.org, Jari Arkko , mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: > => a general problem in MIPv6 specs is there is no explanation about > when a BA should be asked (always with the HA, and with a CN only when > the previous CoA no more works). you are saying that the MN should request a BA from the CN when the previous CoA doesn't work any more. Is this specified in RFC 3775 as such? => no but it should be even it is common sense. Whether or not it's in RFC 3775, what you say makes sense IMO. => good implementations (argh, I'll loose some friends :-) should not blindy put and not put the BA ask flag... I don't think RFC 3775 mention this, however. There is just the last paragraph on page 133... => it explains what is the effect for the flag, not really when it should be set to one. Regards Francis.Dupont@enst-bretagne.fr PS: I mentioned this because IMHO it is one of the killing details which is (was now :-) nowhere. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 09 21:25:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgYGf-0003Ot-VV; Thu, 09 Jun 2005 21:25:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgYGe-0003Og-L5 for mip6@megatron.ietf.org; Thu, 09 Jun 2005 21:25:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07849 for ; Thu, 9 Jun 2005 21:25:02 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgYcD-0002TB-3M for mip6@ietf.org; Thu, 09 Jun 2005 21:47:22 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 03AFF4CF66; Fri, 10 Jun 2005 10:23:55 +0900 (JST) Date: Fri, 10 Jun 2005 10:24:31 +0900 From: Thierry Ernst To: Vijay Devarapalli , "Basavaraj.Patil@nokia.com" , Gopal Dommety Subject: Re: [Mip6] Monami6 mailing list: MObile Nodes And Multiple Interfaces in IPv6 Message-Id: <20050610102431.18407493.ernst@sfc.wide.ad.jp> In-Reply-To: <42A892CA.6090305@iprg.nokia.com> References: <20050608143518.4d5b218e.ernst@sfc.wide.ad.jp> <42A892CA.6090305@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi Vijay, Thanks for supporting the need for such features. In any case we will ask a BOF because we need time, and I still believe a new independant group is the best as working on this issue is not just about standardizing e.g. multiple CoA but multiple CoA and other mechanisms. Also, since it spans MIP6 and NEMO BS, and should be applied to HMIPv6 and FMIPv6, I think the working on it in the MIP6 WG is missleading. About time to create a new WG, if approved, it could be done by 64th IETF; in the meantime people on the monami6 list can make good progress. But let's don't argue this point at this time, and let's concentrate on having a good BOF where all that have to be said will be said thoroughly. Official position of the MIP6 chairs on this matter would also be appreciated. Thierry On Thu, 09 Jun 2005 12:04:42-0700 Vijay Devarapalli wrote: > hi Thierry, > > thanks for your efforts on this. I definitely support this work > and see it as something that definitely enhances MIPv6 and NEMO > protocols. I also think that this work should be done ASAP. > > doing the work in a separate WG is fine with me. > > but I prefer just doing this in the MIP6 WG. a new WG approval > takes much longer. I would support modifying the MIP6 charter > to include this work. I think the current problem statement draft > you have is clear enough to start work on the solution right > away. > > Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 10 02:46:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgdHH-0005DQ-CF; Fri, 10 Jun 2005 02:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgdHF-0005D6-6B for mip6@megatron.ietf.org; Fri, 10 Jun 2005 02:46:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18849 for ; Fri, 10 Jun 2005 02:45:58 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgdcp-0002A6-WF for mip6@ietf.org; Fri, 10 Jun 2005 03:08:20 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j5A6DZ218988; Thu, 9 Jun 2005 23:13:35 -0700 X-mProtect: <200506100613> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp166220.americas.nokia.com (10.241.166.220, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdddBMrV; Thu, 09 Jun 2005 23:13:33 PDT Message-ID: <42A93705.9090702@iprg.nokia.com> Date: Thu, 09 Jun 2005 23:45:25 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [Mip6] Monami6 mailing list: MObile Nodes And Multiple Interfaces in IPv6 References: <20050608143518.4d5b218e.ernst@sfc.wide.ad.jp> <42A892CA.6090305@iprg.nokia.com> <20050610102431.18407493.ernst@sfc.wide.ad.jp> In-Reply-To: <20050610102431.18407493.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Gopal Dommety , mip6@ietf.org, "Basavaraj.Patil@nokia.com" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org okay. we can discuss this more at the BOF. Vijay Thierry Ernst wrote: > Hi Vijay, > > Thanks for supporting the need for such features. > > In any case we will ask a BOF because we need time, and I still believe > a new independant group is the best as working on this issue is not just > about standardizing e.g. multiple CoA but multiple CoA and other > mechanisms. Also, since it spans MIP6 and NEMO BS, and should be applied > to HMIPv6 and FMIPv6, I think the working on it in the MIP6 WG is > missleading. > > About time to create a new WG, if approved, it could be done by 64th > IETF; in the meantime people on the monami6 list can make good progress. > But let's don't argue this point at this time, and let's concentrate on > having a good BOF where all that have to be said will be said > thoroughly. > > Official position of the MIP6 chairs on this matter would also be > appreciated. > > Thierry > > On Thu, 09 Jun 2005 12:04:42-0700 Vijay > Devarapalli wrote: > > >>hi Thierry, >> >>thanks for your efforts on this. I definitely support this work >>and see it as something that definitely enhances MIPv6 and NEMO >>protocols. I also think that this work should be done ASAP. >> >>doing the work in a separate WG is fine with me. >> >>but I prefer just doing this in the MIP6 WG. a new WG approval >>takes much longer. I would support modifying the MIP6 charter >>to include this work. I think the current problem statement draft >>you have is clear enough to start work on the solution right >>away. >> >>Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 10 14:38:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgoOY-0006V6-7O; Fri, 10 Jun 2005 14:38:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgmSt-0003YO-55; Fri, 10 Jun 2005 12:34:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06236; Fri, 10 Jun 2005 12:34:35 -0400 (EDT) Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgmoY-0000tm-Ay; Fri, 10 Jun 2005 12:57:04 -0400 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.11/8.12.9) with ESMTP id j5AGYE9u031533; Fri, 10 Jun 2005 18:34:14 +0200 Received: from sophia.inria.fr (penguin.inria.fr [138.96.240.36]) by sophia.inria.fr (8.12.11/8.12.9) with ESMTP id j5AGUGrR030562; Fri, 10 Jun 2005 18:30:16 +0200 Message-ID: <42A9C018.DFF146AD@sophia.inria.fr> Date: Fri, 10 Jun 2005 18:30:16 +0200 From: Sara Alouf X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.23 i686) X-Accept-Language: en, fr, pt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: undisclosed-recipients:; X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (sophia.inria.fr [138.96.64.20]); Fri, 10 Jun 2005 18:33:46 +0200 (MEST) X-Virus-Scanned: by amavisd-new at sophia.inria.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 10 Jun 2005 14:38:16 -0400 Subject: [Mip6] Performance 2005: Call for Posters X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org PERFORMANCE 2005 IFIP WG 7.3 International Symposium on Computer Performance, Modeling, Measurements and Evaluation Oct. 3-7, Juan-les-Pins, France http://www-sop.inria.fr/maestro/performance2005/ CALL FOR POSTERS The PERFORMANCE 2005 conference solicits posters on recent or ongoing research in the areas of: * Performance-oriented design and evaluation of: communication networks, mobile and wireless systems, Internet servers and E-commerce systems, Web services, Web architectures, peer-to-peer systems, grid computing, computer architectures, database systems, operating systems, software systems, distributed systems, multimedia systems, file and I/O systems, memory systems, real-time systems, and fault-tolerant systems. * Techniques and algorithms: analytic modeling, performance optimization, queueing analysis, stochastic scheduling, model verification and validation, power analysis, hybrid models, experimental design, system or network measurement and monitoring, workload characterization, simulation, and statistical analysis. The poster session is intended to present and discuss innovative research work in an informal setting. The submission by students is especially encouraged. SUBMISSION GUIDELINES A poster submission consists of an extended abstract of up to 2 pages (double column, 9-point or larger fonts) including the names and affiliations of the authors. Poster submissions must be sent by email to posters.perf2005(at)sophia.inria.fr as Postscript or Adobe PDF files. Posters will be selected by the Poster Committee. The extended abstracts of accepted posters will be published in a special issue of the Performance Evaluation Review. Any question must be directed to the Poster Committee Chair at posters.perf2005(at)sophia.inria.fr IMPORTANT DATES Submission due: July 7, 2005 Notification to authors: July 22, 2005 Camera ready extended abstract due: August 19, 2005 POSTER COMMITTEE Thomas Bonald, France Telecom (chair) Sem Borst, Bell Labs and CWI Alain Jean-Marie, U. Montpellier and INRIA (other members to be announced) -- Sara Alouf Publicity Chair of Performance 2005 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Jun 11 01:19:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgyPN-0003lm-C6; Sat, 11 Jun 2005 01:19:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgyPL-0003lW-D1; Sat, 11 Jun 2005 01:19:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14439; Sat, 11 Jun 2005 01:19:46 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgyl0-0000mN-VF; Sat, 11 Jun 2005 01:42:19 -0400 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IHW008G1MSB6H@mailout2.samsung.com>; Sat, 11 Jun 2005 14:19:23 +0900 (KST) Received: from daniel ([168.219.198.108]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IHW0061FMSAMR@mmp1.samsung.com>; Sat, 11 Jun 2005 14:19:23 +0900 (KST) Date: Sat, 11 Jun 2005 14:19:24 +0900 From: "Soohong Daniel Park@samsung.com" To: mobopts@irtf.org, mipshop@ietf.org, mip6@ietf.org Message-id: <000701c56e45$21c9a8b0$6cc6dba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: multipart/mixed; boundary="Boundary_(ID_VFVt5/+LVbnSDsMbZMDlxw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 2.4 (++) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Subject: [Mip6] [New I-D]FW: I-D ACTION:draft-daniel-mip-link-characteristic-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_VFVt5/+LVbnSDsMbZMDlxw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT fyi, All comments are highly welcome. Regards, --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Saturday, June 11, 2005 4:37 AM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-daniel-mip-link-characteristic-02.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Link Characteristics Information for Mobile IP > Author(s) : S. Park, et al. > Filename : draft-daniel-mip-link-characteristic-02.txt > Pages : 11 > Date : 2005-6-10 > > This document introduces a model for link characteristic information > delivery from the mobile node to the home agent and correspondent > node(s). This model allows the home agent and > correspondent node(s) > to know the characteristics of the link the mobile node is > currently > attached to. Based on this information, the home agent and > correspondent node(s) may shape ongoing traffics according to the > current available link capacity (e.g. bandwidth) to the > mobile node. > This model can be applicable for Mobile IPv4 as well as > Mobile IPv6. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-daniel-mip-link-characteristic-02. txt --Boundary_(ID_VFVt5/+LVbnSDsMbZMDlxw) Content-type: Message/External-body; name=ATT00215.dat Content-disposition: attachment; filename=ATT00215.dat Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-6-10154506.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-daniel-mip-link-characteristic-02.txt --Boundary_(ID_VFVt5/+LVbnSDsMbZMDlxw) Content-type: Message/External-body; name=draft-daniel-mip-link-characteristic-02.txt Content-disposition: attachment; filename=draft-daniel-mip-link-characteristic-02.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-6-10154506.I-D@ietf.org> --Boundary_(ID_VFVt5/+LVbnSDsMbZMDlxw) Content-type: text/plain; name=ATT00218.txt Content-disposition: attachment; filename=ATT00218.txt Content-Transfer-Encoding: 7BIT _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --Boundary_(ID_VFVt5/+LVbnSDsMbZMDlxw) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --Boundary_(ID_VFVt5/+LVbnSDsMbZMDlxw)-- From mip6-bounces@ietf.org Mon Jun 13 05:52:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhlcm-00048K-Rz; Mon, 13 Jun 2005 05:52:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhlcl-000489-I4 for mip6@megatron.ietf.org; Mon, 13 Jun 2005 05:52:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25061 for ; Mon, 13 Jun 2005 05:52:53 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dhlz0-0004GP-IY for mip6@ietf.org; Mon, 13 Jun 2005 06:15:56 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0II000N0SON72G@dns1.cselt.it> for mip6@ietf.org; Mon, 13 Jun 2005 11:49:56 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Jun 2005 11:55:56 +0200 Date: Mon, 13 Jun 2005 11:52:38 +0200 From: Gerardo Giaretta To: Christian Vogt Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: Review of draft-irtf-mobopts-ro-enhancements-00 Thread-Index: AcVtAfjfni8HNa0fTla5BNUAv1kucQC+fSiw content-class: urn:content-classes:message X-OriginalArrivalTime: 13 Jun 2005 09:55:56.0765 (UTC) FILETIME=[182918D0:01C56FFE] X-Spam-Score: 2.4 (++) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, Jari Arkko , mobopts@irtf.org Subject: [Mip6] RE: Review of draft-irtf-mobopts-ro-enhancements-00 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi Christian, thanks for your replay. Some comments below... >=20 > Hi Gerardo, >=20 > thanks again for reviewing the doc. Some responses below. You can=20 > check the new version at >=20 > http://doc.tm.uka.de/2005/draft-irtf-mobopts-ro-enhancements-0 > 1-pre.txt >=20 > - Christian >=20 > ++++ >=20 > > General comment: I think the draft is very well-written and=20 > provide a > > complete analysis of the topic. The unique general issue I found is > > that it is very long. I agree with James' comment that the draft > > could be shortened removing some sections that are not completely in > > the scope of the draft (e.g. section 5.13 and 5.14, more about these > > sections below). >=20 > Ok, will do that. >=20 > > More detailed comments: > >=20 > > - section 1, paragraph 4 "In the opposite direction, the mobile node > > may tunnel packets to the home agent". I think this sentence is not=20 > > completely correct, or at least a bit misleading. If route > > optimization is not used, the MN MUST tunnel packets to the HA. Is > > "MAY" used in this sentence to highlight that the MN can choose to > > use bidirectional tunneling or route optimization? >=20 > You are right, the text is misleading. The idea was that RO is the > alternative, and the MN may choose (provided the CN supports=20 > RO). But, > again, this is confusing, so I changed it. >=20 > > - section 1, paragraph 10 "This can lead to handover delay > > unacceptable for many real-time or interactive applications like > > Voice over IP (VoIP) and audio or video streaming". I'd suggest to > > remove audio/video streaming here. Streaming applications are not > > real-time nor interactive: they usually buffer few seconds of the > > movie/sound and thus are usually not affected by MIPv6 handover > > latency. At least this is what we have experimented in our labs. >=20 > Would you say that rapid handovers and small buffers in=20 > less-provisioned > devices can be an issue with streaming? >=20 Yes, it can be an issue. But this depends on the device capabilities and not on strong application requirements. Usually, in most streaming applications, buffer size is configurable and has a default value of few seconds.=20 > Anyway, I changed the text. >=20 Good. > > - section 3.1, paragraph 7 "The mobile node must compute a=20 > > message-authentication code keyed with the Home and Care-of Keygen=20 > > Token". Actually the MAC is keyed with the Kbm, that is a 20 octets=20 > > SHA-1 hash of the concatenation of Home and Care-of Keygen Token >=20 > Right, this was imprecise. Corrected it. >=20 > > - section 4.1, paragraph 1: I would mention explicitly that the > > handoff latency for a route-optimized communication is longer than > > for a bi-directional tunneled communication. >=20 > Yes, it's added. >=20 > > - section 4.1, paragraph 2: since the CN is not always required to > > send the BA, I wonder why the MN should by default wait for the BA. > > Or are you suggesting the MN asks the CN an ack? If so, I think the > > sentence should be rephrased. >=20 > Right. >=20 > > - section 4.1, paragraph 3 "But more generally, mobile=20 > nodes wait for > > the home registration to be completed and acknowledged before > > initiating the correspondent registration". Are you=20 > referring to some > > specific implementations? I'm asking this because the open source > > implementation we use in our labs does not wait the BA. >=20 > Kame-Shisa does it. We added the optimization not to wait for the BA > from the HA. >=20 > Actually, not waiting for the BA is not standard-conform. =20 > RFC 3775 says > that the lifetime of correspondent registrations must not=20 > exceed that of > the home registration. And the latter becomes known to the=20 > MN only with > the BA. >=20 > I don't think this requirement is critical, though. After=20 > all, it's up > to the MN to request the CN lifetime anyway. It could just ignore the > home-registration lifetime. >=20 I tend to agree on this. This implementation choice can improve performance.=20 > > - section 4.4, paragraph 2: I would add references to=20 > > draft-koodli-mip6-location-privacy-00 and to=20 > > draft-koodli-mip6-location-privacy-solutions-00 >=20 > Definitely a good idea. >=20 > > - section 5.2, paragraph 1: What do you mean by "close to=20 > the mobile > > node"? Shouldn't it be "on the path between MN and HA"? >=20 > The critical link on the patch between the MN and the HA is a wireless > first hop. >=20 > Anyway, the text is unclear. Rewrote that sentence. >=20 > > - section 5.3, paragraph 2: the sentence is not clear to=20 > me. The last > > BA is referred to BA from CN, I suppose. If so, I think it=20 > should be=20 > > mentioned explicitly. >=20 > Done. >=20 > > - section 5.13: as mentioned before I think this section is not > > really in the scope of the draft. If you think it is, I'd suggest to > > include some more text explaining how HMIPv6 influences RO=20 > operations > > (e.g. reduction of signaling overhead). The same applies to section > > 5.14. I think that FMIPv6 has even less impact on RO than HMIPv6. So > > I suggest you include some more text to explain how these protocols > > are tied to RO. >=20 > It seems there is pretty much agreement in that FMIPv6 and=20 > HMIPv6 should > be removed from this particular document. >=20 > > - section 5.16, last sentence: are there simulations that prove that > > RR can be too expensive? A reference could be helpful. >=20 > I don't have such a reference. Is your suggestion to remove=20 > the section > in this case? >=20 Not necessarily. However, even without any reference, some more details can be useful. As you mention RR was designed with low computational complexity in mind. If you state that it can be too expensive, you should at least provide some examples, scenarios or data. --Gerardo > > - section 6.2.1, last paragraph: HMIPv6 causes always a tunneling=20 > > overhead that is not present in plain MIPv6. Therefore, some > > localized mobility protocols always cause overhead and not only "in > > some situations". >=20 > That's right. But I have already removed that sub-section. >=20 > > - section 6.2.2, paragraph 1 "On the other hand, nodes that do share > > a common secret should be allowed to omit the home-address test". > > Isn't required that the common secret is tied to the Home Address > > used in order to remove the home address test? >=20 > You are right. Added that. >=20 > > Editorial comments: > >=20 > > - section 4.1, last paragraph: Section 6.3.1 should be in=20 > brackets or > > similar >=20 > Oops, it's done. >=20 > > - section 5.1, paragraph 2: s/IP-ddress/IP-address >=20 > Ok. >=20 > > - section 5.7, paragraph 5: s/its is the data/it is the data >=20 > Ok. >=20 > > - section 5.8, paragraph 2: s/it in general/it is in general >=20 > Ok. >=20 > > Hope this helps. >=20 > It did. ;) >=20 > Thanks, > - Christian >=20 > --=20 > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ >=20 >=20 >=20 > Gerardo Giaretta wrote: > > Hi Christian and Jari, > >=20 > > Raj requested me to review draft-irtf-mobopts-ro-enhancements-00. > > Here are some comments and question. > >=20 > > General comment: I think the draft is very well-written and=20 > provide a > > complete analysis of the topic. The unique general issue I found is > > that it is very long. I agree with James' comment that the draft > > could be shortened removing some sections that are not completely in > > the scope of the draft (e.g. section 5.13 and 5.14, more about these > > sections below). > >=20 > > More detailed comments: > >=20 > > - section 1, paragraph 4 "In the opposite direction, the mobile node > > may tunnel packets to the home agent". I think this sentence is not=20 > > completely correct, or at least a bit misleading. If route > > optimization is not used, the MN MUST tunnel packets to the HA. Is > > "MAY" used in this sentence to highlight that the MN can choose to > > use bidirectional tunneling or route optimization? > >=20 > > - section 1, paragraph 10 "This can lead to handover delay > > unacceptable for many real-time or interactive applications like > > Voice over IP (VoIP) and audio or video streaming". I'd suggest to > > remove audio/video streaming here. Streaming applications are not > > real-time nor interactive: they usually buffer few seconds of the > > movie/sound and thus are usually not affected by MIPv6 handover > > latency. At least this is what we have experimented in our labs. > >=20 > > - section 3.1, paragraph 7 "The mobile node must compute a=20 > > message-authentication code keyed with the Home and Care-of Keygen=20 > > Token". Actually the MAC is keyed with the Kbm, that is a 20 octets=20 > > SHA-1 hash of the concatenation of Home and Care-of Keygen Token > >=20 > > - section 4.1, paragraph 1: I would mention explicitly that the > > handoff latency for a route-optimized communication is longer than > > for a bi-directional tunneled communication. > >=20 > > - section 4.1, paragraph 2: since the CN is not always required to > > send the BA, I wonder why the MN should by default wait for the BA. > > Or are you suggesting the MN asks the CN an ack? If so, I think the > > sentence should be rephrased. > >=20 > > - section 4.1, paragraph 3 "But more generally, mobile=20 > nodes wait for > > the home registration to be completed and acknowledged before > > initiating the correspondent registration". Are you=20 > referring to some > > specific implementations? I'm asking this because the open source > > implementation we use in our labs does not wait the BA. > >=20 > > - section 4.4, paragraph 2: I would add references to=20 > > draft-koodli-mip6-location-privacy-00 and to=20 > > draft-koodli-mip6-location-privacy-solutions-00 > >=20 > > - section 5.2, paragraph 1: What do you mean by "close to=20 > the mobile > > node"? Shouldn't it be "on the path between MN and HA"? > >=20 > > - section 5.3, paragraph 2: the sentence is not clear to=20 > me. The last > > BA is referred to BA from CN, I suppose. If so, I think it=20 > should be=20 > > mentioned explicitly. > >=20 > > - section 5.13: as mentioned before I think this section is not > > really in the scope of the draft. If you think it is, I'd suggest to > > include some more text explaining how HMIPv6 influences RO=20 > operations > > (e.g. reduction of signaling overhead). The same applies to section > > 5.14. I think that FMIPv6 has even less impact on RO than HMIPv6. So > > I suggest you include some more text to explain how these protocols > > are tied to RO. > >=20 > > - section 5.16, last sentence: are there simulations that prove that > > RR can be too expensive? A reference could be helpful. > >=20 > > - section 6.2.1, last paragraph: HMIPv6 causes always a tunneling=20 > > overhead that is not present in plain MIPv6. Therefore, some > > localized mobility protocols always cause overhead and not only "in > > some situations". > >=20 > > - section 6.2.2, paragraph 1 "On the other hand, nodes that do share > > a common secret should be allowed to omit the home-address test". > > Isn't required that the common secret is tied to the Home Address > > used in order to remove the home address test? > >=20 > >=20 > > Editorial comments: > >=20 > > - section 4.1, last paragraph: Section 6.3.1 should be in=20 > brackets or > > similar > >=20 > > - section 5.1, paragraph 2: s/IP-ddress/IP-address > >=20 > > - section 5.7, paragraph 5: s/its is the data/it is the data > >=20 > > - section 5.8, paragraph 2: s/it in general/it is in general > >=20 > >=20 > > Hope this helps. > >=20 > > Regards, --Gerardo > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia > > S.p.A. > >=20 > >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > > CONFIDENTIALITY NOTICE This message and its attachments are=20 > addressed > > solely to the persons above and may contain confidential=20 > information. > > If you have received the message in error, be informed that any use > > of the content hereof is prohibited. Please return it immediately to > > the sender and delete the message. Should you have any questions, > > please send an e_mail to MailAdmin@tilab.com. Thank you=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=3D=3D=3D=3D >=20 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 13 10:50:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhqH2-0003UX-Bg; Mon, 13 Jun 2005 10:50:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhqH0-0003TS-Uh for mip6@megatron.ietf.org; Mon, 13 Jun 2005 10:50:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19299 for ; Mon, 13 Jun 2005 10:50:44 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhqdJ-0000d2-ER for mip6@ietf.org; Mon, 13 Jun 2005 11:13:49 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate7) with ESMTP id j5DEwvW9026438 for ; Mon, 13 Jun 2005 07:58:57 -0700 (MST) Received: from il02exm13.corp.mot.com (il02exm13.corp.mot.com [10.0.111.24]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j5DEsIQc009501 for ; Mon, 13 Jun 2005 09:54:18 -0500 (CDT) Received: by il02exm13 with Internet Mail Service (5.5.2657.72) id ; Mon, 13 Jun 2005 09:50:33 -0500 Message-ID: <1B631E11D496D711BB2800065BFCB6A11B7A70EB@il02exm13> From: Narayanan Vidya-CVN065 To: "'Christian Vogt'" Subject: RE: Vidyas Review of draft-irtf-mobopts-ro-enhancements-00 (was R e: [Mip6] Review Comments and Questions on draft-irtf-mobopts-ro-enhancem ents-00.txt) Date: Mon, 13 Jun 2005 09:50:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 2.4 (++) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi Christian, Thanks for incorporating my comments. No problem about leaving the security details in the document for now. It does give the reader a good background - perhaps it can be shortened in a later version if required. Regards, Vidya > -----Original Message----- > From: Christian Vogt [mailto:chvogt@tm.uka.de] > Sent: Thursday, June 09, 2005 8:28 AM > To: Narayanan Vidya-CVN065 > Cc: mip6@ietf.org; mobopts@irtf.org > Subject: Vidyas Review of > draft-irtf-mobopts-ro-enhancements-00 (was Re: [Mip6] Review > Comments and Questions on draft-irtf-mobopts-ro-enhancements-00.txt) > > > Hy Vidya, > > based on your review, I revised the RO Enhancements document. > You can check the new version at > > http://doc.tm.uka.de/2005/draft-irtf-mobopts-ro-enhancements-0 > 1-pre.txt > > Thanks again for your comments, > > - Christian > > ++++ > > > 1. The draft provides a good, comprehensive overview of the > security > > aspects of RO and the solution space in general. However, > given that > > there is already a draft on RO security, perhaps the > security aspects > > should be integrated with that draft and this draft should > attempt to > > cover the solution space alone? > > The security aspects discussed in the document certainly > cannot replace the RO Security Background. Nevertheless, > Jari and I thought we should put them in to give the reader > just enough of background she or he needs to understand the document. > > Definitely, if the Research Group decides to remove the > security section from this RO Enhancements draft, or move it > to the RO Security Background, we'll do that. > > Please don't mind that I leave the security section in the > document until we decide what to do. > > > 2. Need for "fast" RO - The draft mentions in a few places > (including > > section 4) that one of the objectives for RO is latency > optimization. > > I belong to the group that is yet to be convinced that > there is a real > > need for "fast" RO. In my mind, there is a need for fast > handoffs, but > > not necessarily fast RO. I don't think that RO is going to > satisfy the > > latency requirements of real-time applications. Link layer > mechanisms > > are defining methods to reduce the handoff latency to less > than 100ms > > or so. Such enhancements are useful during inter-subnet > handoffs only > > if the network layer latency can be reduced to adding very marginal > > latency on top of that. Do we really think RO is going to > buy us that? > > Given that any design for RO cannot control the relative > positions of > > the CN and the MN, it doesn't seem like any RO solution can claim > > that. The need for such applications really drives us towards > > FMIP-like approaches. > > What you identify is an exemplar for the trade-off between > good performance and high investment costs. ;) > > But there have also been comments (by James and Samita) to > remove the parts on FMIP and HMIP from the RO Enhancement > draft. The reason being that both may be combined, but are > not directly related to RO. > > Still, you are making a good point. I added this to the Conclusions. > > > I still think RO can be useful - when long periods of > traffic exchange > > happens between an MN and CN, it may be better to get away from > > triangular routing. I noticed that James brought up the point of > > almost ubiquitous wireline bandwidth perhaps eliminating > the need for > > RO. While that is a very valid argument against the real > need for RO, > > I think it will still be good to design the support for RO, before > > widespread deployment of CNs that don't support it. > > Yes, I agree. > > You may also want to avoid that all data goes through a > single of of failure, i.e., the home agent (unless you do HA > relocation, of course). > In fact, this contradicts the original Internet design > guideline to make communications robust to outages of some > network entities. > > > I am only questioning the need for latency reduction as a design > > objective for an RO solution. > > I think it's attractive, even for not-so-delay-sensitive > applications, to reduce global signaling delays from two RTT > to one RTT. > > > 3. One of the situations in which RO can be useful is when the RO > > solution allows the MN and CN to continue communication during a > > period of HA unavailability (failure, for e.g.). The current RR > > solution does not achieve this, due to the necessity for short > > lifetimes and hence the need for home address tests via the HA every > > so often. It may be worthwhile adding this to the design goals for > > the solution. > > That's an excellent comment. This affects both data packets > and signaling packets. (See my comment from above.) > > I added a sub-section on this to section 4. > > > 4. Section 3.3 (last paragraph) mentions the fact that the > current RR > > solution trades off protection against attacks on CN's processing > > capacity for protection against CN's memory. Perhaps an RO solution > > can be flexible enough to allow the CN to determine what trade off > > makes sense in a particular case? > > That's right. Added this to section 3.3. > > > 5. Section 6.2.1 talks about HMIP and FMIP-like proposals. I am not > > sure I understand how such proposals can replace RO. For > e.g., the use > > of FMIP will remove stringent latency requirements on RO, but not > > provide a solution for RO itself, right? > > You are right: One should emphasize that there are two > aspects of RO: Routing data packets the direct way, and > making end-to-end signaling efficient. This document talks > about the latter. > > I added this clarification to section 5.15. > > Ok, best regards, > - Christian > > -- > Christian Vogt, Institute of Telematics, University of > Karlsruhe www.tm.uka.de/~chvogt/pubkey/ > > > > Narayanan Vidya-CVN065 wrote: > > Here are some comments and questions I have from reviewing > the draft. > > > > > > Thanks, Vidya > > > > 1. The draft provides a good, comprehensive overview of the security > > aspects of RO and the solution space in general. However, > given that > > there is already a draft on RO security, perhaps the > security aspects > > should be integrated with that draft and this draft should attempt > > to cover the solution space alone? > > > > 2. Need for "fast" RO - The draft mentions in a few places > (including > > section 4) that one of the objectives for RO is latency > optimization. > > I belong to the group that is yet to be convinced that > there is a real > > need for "fast" RO. In my mind, there is a need for fast > handoffs, but > > not necessarily fast RO. I don't think that RO is going to > satisfy the > > latency requirements of real-time applications. Link layer > mechanisms > > are defining methods to reduce the handoff latency to less > than 100ms > > or so. Such enhancements are useful during inter-subnet > handoffs only > > if the network layer latency can be reduced to adding very marginal > > latency on top of that. Do we really think RO is going to > buy us that? > > Given that any design for RO cannot control the relative > positions of > > the CN and the MN, it doesn't seem like any RO solution can claim > > that. The need for such applications really drives us towards > > FMIP-like approaches. > > > > I still think RO can be useful - when long periods of > traffic exchange > > happens between an MN and CN, it may be better to get away from > > triangular routing. I noticed that James brought up the point of > > almost ubiquitous wireline bandwidth perhaps eliminating > the need for > > RO. While that is a very valid argument against the real > need for RO, > > I think it will still be good to design the support for RO, before > > widespread deployment of CNs that don't support it. > > > > I am only questioning the need for latency reduction as a design > > objective for an RO solution. > > > > 3. One of the situations in which RO can be useful is when the RO > > solution allows the MN and CN to continue communication during a > > period of HA unavailability (failure, for e.g.). The current RR > > solution does not achieve this, due to the necessity for short > > lifetimes and hence the need for home address tests via the HA every > > so often. It may be worthwhile adding this to the design goals for > > the solution. > > > > 4. Section 3.3 (last paragraph) mentions the fact that the > current RR > > solution trades off protection against attacks on CN's processing > > capacity for protection against CN's memory. Perhaps an RO solution > > can be flexible enough to allow the CN to determine what trade off > > makes sense in a particular case? > > > > 5. Section 6.2.1 talks about HMIP and FMIP-like proposals. I am not > > sure I understand how such proposals can replace RO. For > e.g., the use > > of FMIP will remove stringent latency requirements on RO, but not > > provide a solution for RO itself, right? > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 13 15:42:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhupZ-0006Ef-Eh; Mon, 13 Jun 2005 15:42:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhupU-0006Dd-CJ; Mon, 13 Jun 2005 15:42:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16653; Mon, 13 Jun 2005 15:42:38 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhvBp-0006GG-T7; Mon, 13 Jun 2005 16:05:46 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DhupN-0002ND-Eu; Mon, 13 Jun 2005 15:42:33 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 13 Jun 2005 15:42:33 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: mip6 chair , mip6 mailing list , Internet Architecture Board , mip6 chair , RFC Editor Subject: [Mip6] Protocol Action: 'Mobile IPv6 Management Information Base' to Proposed Standard X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org The IESG has approved the following document: - 'Mobile IPv6 Management Information Base ' as a Proposed Standard This document is the product of the Mobility for IPv6 Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-mipv6-mib-07.txt Technical Summary This document defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB , for use with network management protocols in the Internet community. In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent and correspondent node functions of a Mobile IPv6 (MIPv6) entity. Working Group Summary The working group had consensus to advance the draft to Proposed Standard. Protocol Quality An implementation of the specification is done in BSD as part of the Kame-MIP6 stack. Mike Heard performed an excellent MIB Doctor review. This document was reviewed for the IESG by Margaret Wasserman. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 14 00:32:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di36M-0001Gj-1J; Tue, 14 Jun 2005 00:32:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Di36K-0001Fr-6I for mip6@megatron.ietf.org; Tue, 14 Jun 2005 00:32:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15418 for ; Tue, 14 Jun 2005 00:32:29 -0400 (EDT) Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Di3Sg-00016t-CY for mip6@ietf.org; Tue, 14 Jun 2005 00:55:43 -0400 Received: from usdaln07347 (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j5E4WJCR005491; Mon, 13 Jun 2005 23:32:19 -0500 (CDT) Message-Id: <200506140432.j5E4WJCR005491@auds953.usa.alcatel.com> From: "Tim Ozugur" To: Date: Mon, 13 Jun 2005 23:32:15 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-index: AcVq1E4jGciaydskSnOx/KV3UZDgVAAAAgzAAAAxcdABcPq8IAAAO/mw X-Spam-Score: 0.2 (/) X-Scan-Signature: bc751b94b9e719c152b6b70b67620ccf Subject: [Mip6] Call For Participation: BWAN 2005 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0297915966==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0297915966== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C57070.223F0290" This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C57070.223F0290 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 (Apologies if you are receiving this message more than once) =20 ----------------------------------------------------------- CALL FOR PARTICIPATION International Workshop on Broadband Wireless Access=20 Network on fixed network (BWAN 2005) ( http://www.bwan.org/) ORLANDO, FL - JUNE 15, 2005 co-located with International Conference on=20 Multimedia Services Access Networks (MSAN'05)=20 CO_SPONSORED BY IEEE ------------------------------------------------------------------------ =20 Agenda:=20 =20 8h30-8h45 Welcome=20 8h45-9h00 Opening remarks and Introduction 9h00-9h30 Invited Paper : Flash OFDM technical=20 overview and business opportunities=20 =20 9h00-10h40 Session 1 Wireless access =20 Chaired by Lars Johnsson Senior Director, Product Marketing, Flarion Technologies - Performance Modeling of an Upstream Link =20 in Open Access Networks Olav-Norvald Osterbo =20 - Wireless LAN for Multimedia=20 Vivek S. Deshpande =20 - Performance Evaluation of a Hybrid LMDS Architecture =20 Chris Basios =20 - Comparative Study of Coding/Spreading Trade off in Adaptive = Decision Feedback Multiuser Detection Using Turbo and =20 Convolutional Codes =20 V. D. Trajkovic and P. B. Rapajic =20 =20 10h40-11h30 Break 11h30-11h35 Panel Introduction =20 11h35-13h00 Panel : Trends and strategies for broadband=20 wireless access on fix network for 2010 =20 Panelists : Jerry Power,=20 Marketing Director, Alcatel;=20 Patrick Leary,=20 Assist. V.P Marketing, Alvarion;=20 Lars Johnsson,=20 Senior Director, Flarion Technologies;=20 Olav-Norvald Osterbo,=20 Senior Researc Scientist, Telenor; =20 Pandraig Moran,=20 CTO, IPunplugged. =20 13h00-14h00 Lunch and Break =20 14h00-14h30 Invited Paper : Wimax technical=20 and business opportunities 14h30-15h45 Session 2 Wireless QoS =20 Chaired by Patrick Leary Assist. V.P Marketing, Alvarion - IEEE 802.16 based Radio Access Network with QoS =20 P. Manohar and S.H Srinivasan =20 - Optimization of IEEE 802.11 Resource-Sharing Infrastructures =20 with Interference Constraints=20 E. Costa-Montenegro, F.J Gonzalez-Castano,=20 P.S .Rodriguez-Hernadez, J.C Burguillo-Rial =20 - Performance issues of voice over wireless LAN and comparison=20 with wired LAN=20 A. Bhatia=20 =20 15h45-16h15 Break 16h15-16h45 Invited Paper : Mobility and security=20 in Broadband wireless access 16h45-18h Session 3 Security and mobility =20 Chaired by P=E1draig Moran=20 CTO, IPunplugged - Securing and Dynamic Mobility Management of the Wireless=20 Inter-Networks in Public and Private Places =20 N. Janakiraman =20 - Guaranteed Quality of Service and Seamless Continuity of an=20 end-user's sessions thanks to the IP Mobility Manager=20 Annelise Massiera, Adrian Duda, Helene Vigue =20 - Multilateral Security for IP-Service Provisioning Thomas J. Wilke, Tor Hjalmar Johannessen =20 =20 18h00 Conclusion =20 =20 ------------------------------------------------------------=20 ------=_NextPart_000_0024_01C57070.223F0290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
(Apologies if you=20 are receiving this message more than once)
 
-----------------------------------------------------------

       &nbs= p;         CALL=20 FOR PARTICIPATION

International Workshop on Broadband = Wireless=20 Access

       &nbs= p; Network=20 on fixed network (BWAN 2005)

       &nbs= p;          (http://www.bwan.org/)

       &nbs= p; =20 ORLANDO, FL - JUNE 15, 2005

     co-located = with=20 International Conference on

Multimedia Services Access Networks = (MSAN'05)=20

       &nbs= p;    =20 CO_SPONSORED BY IEEE

----------------------------------------------= --------------------------
 
Agenda: 
  &n= bsp;    =20
8h30-8h45   Welcome =
8h45-9h00  =20 Opening remarks and Introduction

9h00-9h30   Invited Paper = : Flash=20 OFDM technical
       &nbs= p;   =20 overview and business opportunities 
 
9h00-10h40   Session 1 = Wireless=20 access         =20
      &n= bsp;           &nb= sp;    =20 Chaired by  Lars=20 Johnsson
       &nbs= p;            = ;   =20 Senior Director, Product Marketing,=20 Flarion Technologies
     - = Performance=20 Modeling of an Upstream Link  
         &nb= sp;  =20  in Open Access=20 Networks
       &nbs= p;            = ;   =20 Olav-Norvald = Osterbo    
          - = Wireless=20 LAN for Multimedia
       &nbs= p;            = ;   =20 Vivek S. Deshpande     
       &nbs= p;  - Performance Evaluation of a Hybrid = LMDS=20 Architecture    
          &nbs= p;           &= nbsp;=20 Chris=20 Basios    
       &nbs= p; =20 - Comparative Study of = Coding/Spreading=20 Trade off in Adaptive  
         &nb= sp;  =20  Decision=20 Feedback Multiuser Detection Using Turbo and  
         &nb= sp;  =20  Convolutional Codes      =
       &nbs= p;            = ;   =20 V. D. Trajkovic and P. B.=20 Rapajic   
 
10h40-11h30 Break

11h30-11h35 Panel Introduction =20
11h35-13h00 Panel : Trends and strategies for=20 broadband
       &nbs= p;   =20 wireless access on fix network for = 2010   =20
Panelists : Jerry Power,=20
       &nbs= p;                   &nb= sp;  Marketing Director, = Alcatel;
       &nbs= p;             &nb= sp;  Patrick=20 Leary,
       &nbs= p;                   &nb= sp;  Assist. V.P Marketing, = Alvarion;
       &nbs= p;             &nb= sp;  Lars=20 Johnsson, =
       &nbs= p;                   &nb= sp;  Senior Director, = Flarion Technologies;
       &nbs= p;             &nb= sp;  Olav-Norvald Osterbo,
       &nbs= p;                   &nb= sp; =20 Senior Researc Scientist, Telenor;  
       &nbs= p;             &nb= sp;  Pandraig=20 Moran,
       &nbs= p;                   &nb= sp;  CTO,=20 IPunplugged.
 
13h00-14h00 Lunch=20 and Break
    =20
14h00-14h30 Invited Paper : Wimax technical=20
       &nbs= p;   =20 and business opportunities

14h30-15h45 Session 2=20 Wireless QoS           =
      &n= bsp;           &nb= sp;    =20 Chaired by  Patrick = Leary
                     &nbs= p;     =20  Assist. V.P Marketing,=20 Alvarion
         &nb= sp;-  IEEE 802.16 = based Radio=20 Access Network with QoS  
          =            &nb= sp; =20 P. Manohar and S.H=20 Srinivasan   
    -=20 Optimization of IEEE 802.11 Resource-Sharing=20 Infrastructures  
       &nbs= p;       with Interference=20 Constraints 
       &nbs= p;            = ;   =20 E. Costa-Montenegro, F.J Gonzalez-Castano, =
       &nbs= p;            = ;   =20 P.S .Rodriguez-Hernadez, = J.C=20 Burguillo-Rial   
    -=20 Performance issues of voice over wireless LAN and = comparison
       &nbs= p;       with wired=20 LAN 
       &nbs= p;            = ;   =20 A. Bhatia 
 
15h45-16h15 Break

16h15-16h45 Invited Paper : Mobility and security =
       &nbs= p;   =20 in Broadband wireless access

16h45-18h   Session 3=20 Security and=20 mobility          =20
     &nbs= p;            = ;     =20 Chaired by P=E1draig Moran
       &nbs= p;            = ;   =20 CTO,=20 IPunplugged
    -=20 Securing and Dynamic Mobility Management of the = Wireless=20
       &nbs= p;       Inter-Networks in Public and Private=20 Places   
       &nbs= p;            = ;   =20 N. Janakiraman  
    -=20 Guaranteed Quality of Service and Seamless = Continuity of=20 an
       &nbs= p;       end-user's sessions thanks to the IP Mobility Manager 
        &nbs= p;            = ;   Annelise=20 Massiera, Adrian Duda, = Helene Vigue   
     =20 - Multilateral = Security=20 for IP-Service = Provisioning              =           
       &nbs= p;            = ;   =20 Thomas J. Wilke, Tor = Hjalmar=20 Johannessen    
=
 
18h00      =20 Conclusion  
 
------------------------------------------------------------ 
------=_NextPart_000_0024_01C57070.223F0290-- --===============0297915966== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0297915966==-- From mip6-bounces@ietf.org Tue Jun 14 15:44:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHKk-0003OV-Om; Tue, 14 Jun 2005 15:44:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHKk-0003NU-6N for mip6@megatron.ietf.org; Tue, 14 Jun 2005 15:44:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24316 for ; Tue, 14 Jun 2005 15:44:24 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiHhH-0002dH-5T for mip6@ietf.org; Tue, 14 Jun 2005 16:07:44 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5EJftdX004906 for ; Tue, 14 Jun 2005 22:41:55 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Jun 2005 22:44:19 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Jun 2005 14:44:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Jun 2005 14:44:16 -0500 Message-ID: <456943D540CFC14A8D7138E64843F8530118B647@daebe101.NOE.Nokia.com> Thread-Topic: I-D Submission deadlines for IETF63 Thread-Index: AcVxGXGq3bSEx6QvToOaJHafFruwEg== To: X-OriginalArrivalTime: 14 Jun 2005 19:44:17.0551 (UTC) FILETIME=[737B51F0:01C57119] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Subject: [Mip6] I-D Submission deadlines for IETF63 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org There are two (2) Internet-Draft cutoff dates for the 63rd=20 IETF Meeting in Paris, France: July 11th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D All initial Internet-Drafts (version -00) must be submitted by Monday,=20 July 11th at 9:00 AM ET. As always, all initial submissions with a=20 filename beginning with "draft-ietf" must be approved by the=20 appropriate WG Chair before they can be processed or announced. The=20 Secretariat would appreciate receiving WG Chair approval by Tuesday,=20 July 5th at 9:00 AM ET. July 18th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D All revised Internet-Drafts (version -01 and higher) must be submitted=20 by Monday, July 18th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective=20 cutoff dates will not be made available in the Internet-Drafts=20 directory or announced until on or after Monday, August 1st at 9:00=20 AM ET, when Internet-Draft posting resumes. Please do not wait until=20 the last minute to submit. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 15 09:27:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiXvw-00061b-0q; Wed, 15 Jun 2005 09:27:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiO6C-0001bn-G3; Tue, 14 Jun 2005 22:57:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29452; Tue, 14 Jun 2005 22:57:50 -0400 (EDT) Received: from ms-smtp-02.nyroc.rr.com ([24.24.2.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiOSn-00068v-9Y; Tue, 14 Jun 2005 23:21:14 -0400 Received: from hpn307pc2 (cpe-69-204-120-221.rochester.res.rr.com [69.204.120.221]) by ms-smtp-02.nyroc.rr.com (8.12.10/8.12.10) with SMTP id j5F2ulIW027121; Tue, 14 Jun 2005 22:56:50 -0400 (EDT) Message-ID: <0c9101c57155$e68dd1e0$6401a8c0@hpn307pc2> From: "Wendi Heinzelman" To: "Wendi Heinzelman" References: Date: Tue, 14 Jun 2005 22:54:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 15 Jun 2005 09:27:54 -0400 Cc: Haiyun Luo , dirk.westhoff@netlab.nec.de, bettstetter@ieee.org Subject: [Mip6] Mobicom'05 student research competition deadline: June 20 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org -------------------------------------------- ACM Student Research Competition -------------------------------------------- For the first time, the annual SIGMOBILE MOBICOM conference is hosting the ACM Student Research Competition (SRC). Students submitting to the MOBICOM 2005 Poster Program can opt to have their posters considered also by the SRC committee. Selected competitors will receive up $500USD for their conference travel, depending on need and eligibility. Competitors should be prepared to attend the poster session and, if selected for further competition, give a short talk about their research projects. Winners will be announced at the conference. To participate: The Student Research Competition is open to graduate and undergraduate students whose submissions are accepted by the SRC committee. To be considered, complete a submission to the Student Poster Programm by June 20, 2005, and indicate that you would like to participate in the SRC. Current ACM student membership and student status as of the submission deadline are required for the lead student. Contact: Haiyun Luo, University of Illinois, (haiyun@cs.uiuc.edu) Dirk Westhoff, NEC Research Europe, (dirk.westhoff@netlab.nec.de) _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 16 14:17:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diyvp-0002Wk-De; Thu, 16 Jun 2005 14:17:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Diyvn-0002Wb-A7; Thu, 16 Jun 2005 14:17:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21855; Thu, 16 Jun 2005 14:17:28 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DizId-0002fn-BM; Thu, 16 Jun 2005 14:41:16 -0400 Received: from jurassic.eng.sun.com ([129.146.224.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j5GIHOKg007770; Thu, 16 Jun 2005 11:17:24 -0700 (PDT) Received: from eng.sun.com (vpn-129-150-28-24.SFBay.Sun.COM [129.150.28.24]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j5GIHOhF482305; Thu, 16 Jun 2005 11:17:24 -0700 (PDT) Message-ID: <42B1C232.2020209@eng.sun.com> Date: Thu, 16 Jun 2005 11:17:22 -0700 From: Samita Chakrabarti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Vogt References: <200506020323.j523N9bI548231@jurassic.eng.sun.com> <42A829BB.1060207@tm.uka.de> In-Reply-To: <42A829BB.1060207@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, jari.arkko@piuha.net, mobopts@irtf.org Subject: [Mip6] Re: Samitas Review of draft-irtf-mobopts-ro-enhancements-00 (was Re: Review of draft-irtf-mobopts-ro-enhancements-00) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Christian Vogt wrote: > Hi Samita, > > I incorporated your comments into the document. Responses are inline. > > Again, thanks a lot for the review. > > - Christian > > ++++ > Thanks for the update. > >> Section 5.3: >> >> After successful BU to HA, the MN-HA tunnel is created if it is not a >> refresh. So, how does the MN send optimistic RO to CN using Hoti msg >> while the tunnel is not configured yet ? > I see your point below on security association. However, I was asking whether this method assumes that the optimisitc RO (HOTI) is sent through the old MN-HA tunnel before the new tunnel is built between MN-HA with the new COA? Since HOTI does not depend on COA, it is doable. Otherwise, BU to HA needs to be done first and then re-config the tunnel and then HOTI through the new tunnel. > > The SA at the HA may point to an old CoA at the time the HoTI is > received because IPsec processing of the HoTI does not depend on the > CoA. RFC 2401 defines that source addresses of the outer IPv6 headers > are not checked. So the HoTI can pass even when sent from a new CoA. > > However, the SA must be up-to-date when processing the HoT. After all, > that message must be encapsulated somehow and eventually reach the MN at > its new attachment point. > > See also RFC 3776, section 3.2 (Return Routability Signaling), section > 5.2.2 (Return Routability Signaling; yes, the name is the same), and > section 6.6 (HoTI from the MN). > -Samita _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 17 01:27:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj9Nd-0002dT-Rp; Fri, 17 Jun 2005 01:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj9Na-0002d8-EJ; Fri, 17 Jun 2005 01:27:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22458; Fri, 17 Jun 2005 01:26:57 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1+zNoj8XrT+xWqSI10Lon/8W0xVJjx1Qig=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj9kb-0004C3-MC; Fri, 17 Jun 2005 01:50:47 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Dj9NL-0002WJ-2R; Fri, 17 Jun 2005 07:26:46 +0200 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uni-karlsruhe.de with esmtpsa id 1Dj9NK-0000HW-HI; Fri, 17 Jun 2005 07:26:42 +0200 Message-ID: <42B25F11.6020903@tm.uka.de> Date: Fri, 17 Jun 2005 07:26:41 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Samita Chakrabarti References: <200506020323.j523N9bI548231@jurassic.eng.sun.com> <42A829BB.1060207@tm.uka.de> <42B1C232.2020209@eng.sun.com> In-Reply-To: <42B1C232.2020209@eng.sun.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -23.9 (-----------------------) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, jari.arkko@piuha.net, mobopts@irtf.org Subject: [Mip6] Re: Samitas Review of draft-irtf-mobopts-ro-enhancements-00 (was Re: Review of draft-irtf-mobopts-ro-enhancements-00) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi Samita, yes, you are right. The HoTI needs to be sent through the *old* MN-HA tunnel when the MN chooses to send the HoTI/CoTI right after the BU for home registration. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Samita Chakrabarti wrote: > Christian Vogt wrote: > >> Hi Samita, >> >> I incorporated your comments into the document. Responses are inline. >> >> Again, thanks a lot for the review. >> >> - Christian >> >> ++++ >> > Thanks for the update. > >> >>> Section 5.3: >>> >>> After successful BU to HA, the MN-HA tunnel is created if it is not a >>> refresh. So, how does the MN send optimistic RO to CN using Hoti msg >>> while the tunnel is not configured yet ? >> >> > > > I see your point below on security association. However, I was asking > whether this method > assumes that the optimisitc RO (HOTI) is sent through the old MN-HA > tunnel before the new > tunnel is built between MN-HA with the new COA? Since HOTI does not > depend on COA, > it is doable. Otherwise, BU to HA needs to be done first and then > re-config the tunnel and then > HOTI through the new tunnel. > >> >> The SA at the HA may point to an old CoA at the time the HoTI is >> received because IPsec processing of the HoTI does not depend on the >> CoA. RFC 2401 defines that source addresses of the outer IPv6 headers >> are not checked. So the HoTI can pass even when sent from a new CoA. >> >> However, the SA must be up-to-date when processing the HoT. After all, >> that message must be encapsulated somehow and eventually reach the MN at >> its new attachment point. >> >> See also RFC 3776, section 3.2 (Return Routability Signaling), section >> 5.2.2 (Return Routability Signaling; yes, the name is the same), and >> section 6.6 (HoTI from the MN). >> > -Samita _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 17 05:16:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjCxS-0002rp-DP; Fri, 17 Jun 2005 05:16:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DivRo-0004vt-Am; Thu, 16 Jun 2005 10:34:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26844; Thu, 16 Jun 2005 10:34:18 -0400 (EDT) Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Divoh-0003e7-PC; Thu, 16 Jun 2005 10:58:05 -0400 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.11/8.12.9) with ESMTP id j5GELYbn026256; Thu, 16 Jun 2005 16:21:34 +0200 Received: from sophia.inria.fr (penguin.inria.fr [138.96.240.36]) by sophia.inria.fr (8.12.11/8.12.9) with ESMTP id j5GEHcTX025005; Thu, 16 Jun 2005 16:17:38 +0200 Message-ID: <42B18A02.2B1BCE1A@sophia.inria.fr> Date: Thu, 16 Jun 2005 16:17:38 +0200 From: Sara Alouf X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.23 i686) X-Accept-Language: en, fr, pt MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 To: undisclosed-recipients:; X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (sophia.inria.fr [138.96.64.20]); Thu, 16 Jun 2005 16:20:14 +0200 (MEST) X-Virus-Scanned: by amavisd-new at sophia.inria.fr Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sophia.inria.fr id j5GELYbn026256 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 17 Jun 2005 05:16:13 -0400 Subject: [Mip6] Performance 2005: Call for Participation X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org [Many appologies if you receive duplicates of this message] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D C A L L for P A R T I C I P A T I O N =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 *** PERFORMANCE 2005 *** The 24th IFIP WG7.3 International Symposium on Computer Performance Modeling, Measurement and Evaluation Juan-les-Pins, France October 3-7, 2005 http://www-sop.inria.fr/maestro/performance2005/ The IFIP WG7.3 International Symposium on Computer Performance Modeling, Measurement and Evaluation (PERFORMANCE 2005) will be held in Juan-les-Pins, France on October 5-7, 2005. The tutorials will be held on October 3 and 4, 2005. The list of accepted papers and tutorials and the conference registration form can be found on the conference website. Registrations are now *open*. Early conference registration: by September 3, 2005. Student travel grant: A number of student travel grants will be available. Details on how to apply can be found on the conference website. Conference hotel:=20 Rooms have been reserved at a negotiated rate at=20 Hotel Ambassador 50-52, chemin des Sables B.P. 49 - 06160 Juan-Les-Pins Cedex FRANCE Tel: +33 (0)4 92 93 74 10 - Fax: +33 (0)4 93 67 79 85 e-mail: manager@hotel-ambassadeur.com URL: http://www.hotel-ambassadeur.com/ A list of nearby hotels has been posted on the conference website. ------------------------------------------------------------------------ General Chair: =20 Philippe Nain (INRIA, France) Program Committee Co-Chairs: Cheng-Shang Chang (National Tsing Hua U., Taiwan) Daniel A. Menasc=E9 (George Mason U., USA) Tutorial Co-Chairs: Eitan Altman (INRIA, France) Zhen Liu (IBM T. J. Watson Reseach Center, USA) Proceedings Chair: Rudesindo Nunez Queija (CWI & U. Eindhoven, Netherlands) Posters Chair: Thomas Bonald (France Telecom R&D, France) Local arrangements: Ephie Deriche (INRIA, France) Dany Sergeant (INRIA, France) Finance Chair: Dany Sergeant (INRIA, France) Publicity Chair: Sara Alouf (INRIA, France) Corporate Sponsors: IBM T.J. Watson Research Center France Telecom R&D Texas Instruments=20 Institutional Sponsors: IFIP WG7.3 Computer Performance Foundation INRIA Conseil R=E9gional de la R=E9gion Provence-Alpes-C=F4te-d'Azur Conseil G=E9n=E9ral des Alpes-Maritimes ------------------------------------------------------------------------ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jun 17 05:16:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjCxS-0002sE-QF; Fri, 17 Jun 2005 05:16:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DizHi-0008Lq-KU for mip6@megatron.ietf.org; Thu, 16 Jun 2005 14:40:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23625 for ; Thu, 16 Jun 2005 14:40:09 -0400 (EDT) Received: from hkueee2.eee.hku.hk ([147.8.180.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dizef-0003yj-1J for mip6@ietf.org; Thu, 16 Jun 2005 15:03:57 -0400 Received: from se6000 (se6000.eee.hku.hk [147.8.180.36]) by hkueee2.eee.hku.hk (8.13.4/8.13.4) with ESMTP id j5GIdSKg025313; Fri, 17 Jun 2005 02:39:28 +0800 (HKT) Date: Fri, 17 Jun 2005 02:39:28 +0800 (HKT) From: Ka-Cheong Leung X-X-Sender: kcleung@se6000 To: mip6@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-HKUEEE-MailScanner-Information: www.eee.hku.hk/intranet/computer/faq/mailscanner.htm X-HKUEEE-MailScanner: Found to be clean X-HKUEEE-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.656, required 5, AWL 0.28, BAYES_00 -2.60, SUBJ_ALL_CAPS 0.67) Subject: [MIP6] [CFP] NASM 2005 X-Spam-Score: 0.6 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 X-Mailman-Approved-At: Fri, 17 Jun 2005 05:16:13 -0400 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kcleung@ieee.org List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org (We apologize if you receive multiple copies of this CFP.) CALL FOR PAPERS The First International Workshop on Network Architecture and Service Models NASM 2005 November 21-23, 2005 Fudan University, Shanghai, China http://www.elec.qmul.ac.uk/wharf/NASM-2005.htm Technically Co-Sponsored by: British Computer Society (BCS) Institution of Electrical Engineers (IEE) Queen Mary / Fudan Joint Laboratory in Mobile Networks and Ubiquitous Computing SCOPE Network architecture and service model are two key topics of network research and applications. With the rapid development of optical and wireless communications, chips and software, network architectures are changing and new service models are needed. Many research and technical challenges are being addressed by researchers from both industries and academia. It is viewed that through international collaboration among several experts in different parts of the globe, greater research excellence and achievements can be made. OBJECTIVE The objective of this workshop is to discuss new approaches and technologies in the field of next generation networks (NGN), ad hoc mobile networks, wireless sensor networks, and P2P networks. TOPICS OF INTERESTS The main topics of interests include, but not limited to: * Network architectures and services * Optical and wireless networks * Routing and scheduling * Application model and QoS * Mobile network architecture * MAC and QoS MAC in MANET * Mobile addressing * Mobile routing * Mobile applications PAPER SUBMISSIONS - Format: Submissions should include an abstract of 100 words, 5-7 keywords, the e-mail address of the corresponding author, and must not exceed 8 pages (in 2-column format), including tables and figures, with PDF, Postscript, or MS Word format. - Submission: Please submit your paper directly to the workshop chair or co-chair. E-mail: xinw@fudan.edu.cn - Review: Contributions will be reviewed by at least three reviewers from both program committee and external reviewers for relevance and technical contents on basis of papers. - Publication: Selected accepted papers will be published as special issues of International Journal of Ad Hoc and Ubiquitous Computing (IJHAUC). IMPORTANT DATES Paper Submission Due: August 31, 2005 Acceptance Notification: October 15, 2005 Final Camera-Ready Paper: October 22, 2005 Author Registration: October 22, 2005 Workshop Date: November 22, 2005 ORGANIZERS AND COMMITTEE Honorary Chair Prof. Jiangxing Wu, NDSC, China General Chair Prof. CK Toh, Queen Mary University of London, UK Technical Program Chair Prof. Xiangyang Xue, Fudan University, China TPC Members Prof. Victor Li, University of Hong Kong, China Prof. Laurie Cuthbert, University of London, UK Prof. Hong Shen, Japan Advanced Institute of Science and Technology, Japan Prof. Yoshiaki Kakuda, Hiroshima University, Japan Prof. Tadanori Mizuno, Shizuoka University, Japan Prof. Shuigeng Zhou, Fudan University, China Prof. Ke Xu, Tsinghua University, China Prof. Hai Jin, Wuhan University, China Prof. Jiandong Li, Xidian University, China Prof. Zhengbin Li, Peking University, China Prof. Y.-H. Choi, Seoul National University, Korea Prof. H.-K. Kahng, Korea University, Korea Prof. D.-K. Kim, Kyungpook National University, Korea Dr. Jiang Du, Queensland University, Australia Prof. Lai Xu, Vrije University, Netherlands Prof. Jun Zhang, National Chiao Tung University, China Prof. Qing'an Zeng, Southeast University, China Prof. H-C. Chao, National Dong Hwa University, Taiwan, China Prof. J.-C. Chen, National Hsing Hwa University, Taiwan, China Prof. Y. S. Chen, National Chung Cheng University, Taiwan, China Dr. Russell Hsing, Telcordia Technologies Inc., USA Prof. Wei K. Tsai, University of California Irvine, USA Prof. Joe Hui, Arizona State University, USA Local Arrangements Chair Prof. Wang Xin, Fudan University, China Publicity Chair Dr. K.-C. Leung, University of Hong Kong, China _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 20 12:31:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkPBH-0007cd-Pn; Mon, 20 Jun 2005 12:31:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkPBG-0007cY-E5 for mip6@megatron.ietf.org; Mon, 20 Jun 2005 12:31:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15584 for ; Mon, 20 Jun 2005 12:31:23 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkPYz-0006EW-P7 for mip6@ietf.org; Mon, 20 Jun 2005 12:55:59 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D69D089832; Mon, 20 Jun 2005 19:30:58 +0300 (EEST) Message-ID: <42B6EF4A.6030804@kolumbus.fi> Date: Mon, 20 Jun 2005 19:31:06 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles E.Perkins" Subject: Re: [Mip6] draft-ietf-mip6-precfgKbm-03.txt References: <42A0C7CE.9D079883@iprg.nokia.com> In-Reply-To: <42A0C7CE.9D079883@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi Charlie, I looked at http://people.nokia.net/~charliep/txt/mobilev6/precfg.txt since -03 does not appear in the I-D directories. Your new revision solves most of the issues I had. Thanks. However, the following issues don't seem to have been fixed (or I may have missed the change if it was in an unexpected place in the text): - A note about bidding down and why we can't allow other RO mechanisms if a config for a key exists, to be placed in the security considerations section - New text for the applicability text. I think we agreed to something in our original discussion, but I don't see it in the above URL... --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 20 12:45:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkPP3-0001DB-N9; Mon, 20 Jun 2005 12:45:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkPP2-0001Bv-3e for mip6@megatron.ietf.org; Mon, 20 Jun 2005 12:45:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17141 for ; Mon, 20 Jun 2005 12:45:37 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkPml-0006cZ-KZ for mip6@ietf.org; Mon, 20 Jun 2005 13:10:13 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j5KGElV19728; Mon, 20 Jun 2005 09:14:47 -0700 X-mProtect: <200506201614> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp160175.americas.nokia.com (10.241.160.175, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQB2rA5; Mon, 20 Jun 2005 09:14:45 PDT Message-ID: <42B6F29A.7060508@iprg.nokia.com> Date: Mon, 20 Jun 2005 09:45:14 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip6] draft-ietf-mip6-precfgKbm-03.txt References: <42A0C7CE.9D079883@iprg.nokia.com> <42B6EF4A.6030804@kolumbus.fi> In-Reply-To: <42B6EF4A.6030804@kolumbus.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hello Jari, Jari Arkko wrote: > > - A note about bidding down and why we can't allow > other RO mechanisms if a config for a key exists, to > be placed in the security considerations section I would say that other mechanisms are disallowed if they are vulnerable to bidding down. Is that correct? > > - New text for the applicability text. I think we agreed > to something in our original discussion, but I don't > see it in the above URL. I thought I caught all the agreed-upon text offered for this matter. I can look again, but if you have some particular text you notice is missing, I would much appreciate if you could send it to me. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 20 13:00:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkPdS-0002vk-3X; Mon, 20 Jun 2005 13:00:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkPdR-0002vf-13 for mip6@megatron.ietf.org; Mon, 20 Jun 2005 13:00:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18150 for ; Mon, 20 Jun 2005 13:00:30 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkQ1A-0006z1-NL for mip6@ietf.org; Mon, 20 Jun 2005 13:25:06 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 916DC89895; Mon, 20 Jun 2005 20:00:22 +0300 (EEST) Message-ID: <42B6F62E.70801@kolumbus.fi> Date: Mon, 20 Jun 2005 20:00:30 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles E. Perkins" Subject: Re: [Mip6] draft-ietf-mip6-precfgKbm-03.txt References: <42A0C7CE.9D079883@iprg.nokia.com> <42B6EF4A.6030804@kolumbus.fi> <42B6F29A.7060508@iprg.nokia.com> In-Reply-To: <42B6F29A.7060508@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Charles E. Perkins wrote: > > Hello Jari, > > Jari Arkko wrote: > >> >> - A note about bidding down and why we can't allow >> other RO mechanisms if a config for a key exists, to >> be placed in the security considerations section > > > I would say that other mechanisms are disallowed if they > are vulnerable to bidding down. Is that correct? No, the issue is switching between your scheme and something else. How about this: "Note that where a node has been configured to use the mechanism specified in this document with a particular peer, it SHOULD NOT attempt to use another mechanism, even if the peer requests this or claims to not support the mechanism in this document. This is necessary in order to prevent bidding down attacks." >> >> - New text for the applicability text. I think we agreed >> to something in our original discussion, but I don't >> see it in the above URL. > > > > I thought I caught all the agreed-upon text offered for > this matter. I can look again, but if you have some particular > text you notice is missing, I would much appreciate if you > could send it to me. > Sure. See http://www1.ietf.org/mail-archive/web/mip6/current/msg02921.html and search for "Overall applicability text" --jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 21 15:36:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkoYJ-0002ml-L9; Tue, 21 Jun 2005 15:36:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkoYH-0002mg-Gv for mip6@megatron.ietf.org; Tue, 21 Jun 2005 15:36:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23530 for ; Tue, 21 Jun 2005 15:36:51 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkowF-00074b-8r for mip6@ietf.org; Tue, 21 Jun 2005 16:01:40 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j5LJ5vL11705; Tue, 21 Jun 2005 12:05:57 -0700 X-mProtect: <200506211905> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGMRa2s; Tue, 21 Jun 2005 12:05:55 PDT Message-ID: <42B86C3B.347B668E@iprg.nokia.com> Date: Tue, 21 Jun 2005 12:36:27 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip6] draft-ietf-mip6-precfgKbm-03.txt References: <42A0C7CE.9D079883@iprg.nokia.com> <42B6EF4A.6030804@kolumbus.fi> <42B6F29A.7060508@iprg.nokia.com> <42B6F62E.70801@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Mobile IPv6 Mailing List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hello Jari, Jari Arkko wrote: > No, the issue is switching between your scheme and something > else. How about this: > > "Note that where a node has been configured to use the > mechanism specified in this document with a particular peer, > it SHOULD NOT attempt to use another mechanism, even > if the peer requests this or claims to not support the mechanism > in this document. This is necessary in order to prevent > bidding down attacks." Right -- I knew that! I will use your wording. If another mechanism is designed that does not subject the configured nodes to a bidding-down attack, then that mechanism should be allowed for use, but we don't have to worry about that right now. > Sure. See > http://www1.ietf.org/mail-archive/web/mip6/current/msg02921.html That was an awfully long e-mail... I updated the bullet points in the applicability statement, and expanded the following paragraph. I don't know why I overlooked this before, but thanks for the reminder. I have made the new text available at: http://people.nokia.net/charliep/txt/mobilev6/precfg.txt, and I will probably send it in later today or tommorrow. Regards, Charlie P. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 22 00:24:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkwme-0006D2-LQ; Wed, 22 Jun 2005 00:24:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkunM-0003by-67; Tue, 21 Jun 2005 22:16:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08840; Tue, 21 Jun 2005 22:16:49 -0400 (EDT) Received: from ms-smtp-01.nyroc.rr.com ([24.24.2.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkvBM-0006jG-45; Tue, 21 Jun 2005 22:41:42 -0400 Received: from hpn307pc2 (cpe-69-204-120-221.rochester.res.rr.com [69.204.120.221]) by ms-smtp-01.nyroc.rr.com (8.12.10/8.12.10) with SMTP id j5M2EbDX024922; Tue, 21 Jun 2005 22:14:38 -0400 (EDT) Message-ID: <046d01c576d0$293dd380$6601a8c0@hpn307pc2> From: "Wendi Heinzelman" To: "Wendi Heinzelman" Date: Tue, 21 Jun 2005 22:14:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 1.1 (+) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 22 Jun 2005 00:24:15 -0400 Cc: Subject: [Mip6] MobiCom 2005 Call for Participation X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org ******************************************************************* Call for Participation ACM MobiCom 2005 11th International Conference on Mobile Computing and Networking August 28 - September 2, 2005 Cologne, Germany http://www.sigmobile.org/mobicom/2005/ ******************************************************************* ACM MobiCom is a highly-selective international conference on mobile computing and networking. It serves as the premier forum for presenting and discussing research results on networks, systems, algorithms, and applications supporting the symbiosis of mobile computing and wireless networking. Each year, the conference attracts about 500 researchers, practitioners, students, and executives. MobiCom 2005 will be held in beautiful Cologne, Germany. Technical Program. The program consists of a single track with 26 papers. The authors present cutting-edge results on various topics, such as new architectures, content-based and geometric routing, self-management, cross-layer optimization. The papers cover ad hoc networks, mesh networks, wireless sensor networks, WLANs, and cellular networks. A list of accepted papers can be found at http://www.sigmobile.org/mobicom/2005/program.html. Panels and Demonstrations. The program also includes a number of panel discussions on hot topics and technical demonstrations of experimental systems. Tutorials. Four tutorials will be offered: (a) Wireless sensor and actuator networks, (b) 802.11 WLAN MAC and smart antennas: issues and directions, (c) Security in sensor and ad hoc networks: perspectives and status, (d) Wide area wireless networks: 3G and beyond. Student Poster Session. For the first time, MobiCom hosts the ACM Student Research Competition. Students submitting to the poster session can receive up to $500 for their travel, depending on need and eligibility. Workshops. One day is dedicated to workshops on specific technical areas in mobile and wireless networking. The following workshops take place: - Foundations of Mobile Computing (DIAL M-POMC) - Dynamic Interconnection of Networks (DIN) - Vehicular Ad Hoc Networks (VANET) - Wireless Security (WiSe) - Wireless Mobile Applications and Services on WLAN Hotspots (WMASH) Registration is available at http://www.regmaster.com/mobicom2005.html. There is a discounted rate until August 5, 2005. ---------------------------------------------------------- Wendi B. Heinzelman Assistant Professor of Electrical and Computer Engineering University of Rochester P.O. Box 270126, Hopeman Building, Room 307 Rochester, NY 14627-0126 Phone: 585-275-4053 Fax: 585-273-4919 http://www.ece.rochester.edu/~wheinzel ---------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 22 23:22:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlIIV-0002q0-FZ; Wed, 22 Jun 2005 23:22:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlDjS-00078b-2H; Wed, 22 Jun 2005 18:30:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13445; Wed, 22 Jun 2005 18:30:02 -0400 (EDT) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlE7e-0006Fx-VE; Wed, 22 Jun 2005 18:55:07 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j5MMSIpT027114; Wed, 22 Jun 2005 17:28:19 -0500 (CDT) Received: from [135.180.160.116] (thyaga-pcho.dnrc.bell-labs.com [135.180.160.116]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j5MMS8j14118; Wed, 22 Jun 2005 18:28:09 -0400 (EDT) Message-ID: <42B9E5F9.2000405@lucent.com> Date: Wed, 22 Jun 2005 18:28:09 -0400 From: Thyaga Nandagopal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: thyagu@crhc.uiuc.edu Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by hoemail2.lucent.com id j5MMSIpT027114 X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 22 Jun 2005 23:22:33 -0400 Cc: Subject: [Mip6] CFP: Deadline approaching - COMSWARE 2006 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Submission Deadline: June 24, 2005 (extended) (Our apologies if you receive multiple copies of this document) CALL FOR PAPERS *************** The First International Conference on Communication Systems Software and Middleware http://www.comsware.org ----------------------- January 8 - 12, 2006 Taj Palace Hotel, New Delhi, India Technical Co-Sponsor : IEEE Communications Society In Co-operation with : ACM SIGMOBILE Sponsored by: CreateNet (Italy), ICST (USA) Co-Sponsors: IBM, Microsoft Research, NOKIA, Lucent Technologies, Sasken University Co-Sponsor: Indian Institute of Technology, Delhi Paper Submission: June 24, 2005 (extended) (Instructions at http://www.comsware.org) (Proceedings to be published by IEEE and to appear in IEEE Explore) The convergence of the communications, information technologies and the Internet has ushered in a revolution in the way people communicate with each other. The key enabler for this convergence has been the advancement of software technology in various communication sectors, as evident by the high levels of activity in the industry, academia, and standards bodies, coupled with the increasing dependence of this convergence to sustain and improve growth rates in many countries around the world. This new international conference will provide a forum to exchange ideas, techniques, and applications, discuss best practices and challenging issues, raise awareness and share experiences among researchers, practitioners, standard developers and policy makers in the field of software techniques in communications. The conference will bring leading researchers and practitioners in areas ranging from communications software and software engineering aspects of communications software, to middleware and networking protocols. The objective of the conference is to provide a high degree of collaboration, participation and discussions of the various topics among multi-national participants from the industrial, governmental and academic sectors. COMSWARE will include a regular paper track and an industry track. The paper track will include a highly selective technical program. The conference solicits original, previously unpublished research work, experimental efforts, and practical experiences for the technical program. COMSWARE will also feature panel discussions from experts in academia and industry, workshops and tutorials featuring the state-of -the-art in various communications software and related areas. There will be demos and exhibits that will expose the delegates to exciting products and software solutions from industry and academia. Accepted papers will be published by IEEE Computer Society. The top papers accepted to the conference will be published in a reputed journal. Areas of interest include, but are not limited to: =B7 Communications Software =B7 Reconfigurable Software Stacks =B7 Software Engineering Aspects of Communications Software =B7 Context-Based and Implicit Computing =B7 Telecommunications Services and QoS =B7 Software for Billing and Pricing =B7 User Interfaces and Interaction Models =B7 Multi-Agent Systems =B7 Client-Server Applications =B7 Mobile and Intermittently Connected Applications =B7 Mobile Data Management =B7 Middleware Services and Agent Technologies =B7 Middleware for Wireless Sensor Networks =B7 Middleware for P2P Systems =B7 Middleware for Future Communication Networks =B7 Information Infrastructure and Security =B7 Security and Privacy Issues of Pervasive Computing Systems =B7 Network Operations and Management =B7 Policy and Workflow-based Network Operations =B7 Reliability Support Software =B7 Resource Management in Pervasive Computing Platforms =B7 Management Software for Optical Networks =B7 Network Monitoring Software =B7 Internet and IP based Services =B7 Dynamic Service Composition and Deployment =B7 Service Discovery Mechanisms =B7 Wireless/Mobile Service Management and Delivery =B7 Mobile / Wireless Computing Systems and Services =B7 Performance Evaluation Techniques =B7 Location Determination =B7 Positioning and Tracking Technologies =B7 Smart Devices and Smart Spaces =B7 Enterprise Networking =B7 Personal Area Networks =B7 Integration of Wired and Wireless Networks =B7 Next Generation Networks and Services Deadlines ********* Paper Submission: June 24, 2005 (Instructions at http://www.comsware.org= ) Notification of Acceptance: August 15, 2005 Camera-ready due: September 26, 2005 Conference Organizing Committee ******************************* General Chairs: Victor Bahl, Microsoft Research, USA Bijendra Nath Jain, IIT, Delhi, India Henning Schulzrinne, Columbia University, USA Alfred Spector, IBM Research, USA Steering Committee: Imrich Chlamtac, University of Trento, Italy=20 (Chair) Rajeev Shorey, IBM Research, India=20 (Co-Chair) Prasant Mohapatra, University of California,=20 Davis, USA =20 (Co-Chair) Program Chairs: Sanjoy Paul, Whenu, USA G. Venkatesh, SASKEN Technologies, India Jim Woodcock, University of York, UK Tutorial Chair: Archan Misra, IBM Research, USA Workshop Chairs: Ashwin Gumaste, Fujitsu Research, USA Gaurav Sharma, University of Rochester, USA Demos/Exhibit Chair: Huzur Saran, IIT, Delhi, India Demos/Exhibit Co-Chair: Jaijit Bhattacharya, Oracle, India Publicity Chair: Thyaga Nandagopal, Lucent Technologies, USA Publicity Co-Chairs: Sunghyun Choi, Seoul National University, Korea Marco Conti, IIT, Pisa, Italy Ben Lancini, LinLan, Brisbane, Australia Prashant Pradhan, IBM Research, USA Hemant Chaskar, Airtight Networks, India Local Arrangement Chair: Sudipta Maitra, IBM, Delhi _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 27 11:53:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmvvp-0007Ns-3W; Mon, 27 Jun 2005 11:53:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmvvn-0007Nl-L5 for mip6@megatron.ietf.org; Mon, 27 Jun 2005 11:53:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05128 for ; Mon, 27 Jun 2005 11:53:52 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmwKx-00007N-AV for mip6@ietf.org; Mon, 27 Jun 2005 12:19:56 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5RFnI13031817 for ; Mon, 27 Jun 2005 18:49:26 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Jun 2005 18:53:47 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Jun 2005 10:53:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Jun 2005 10:53:44 -0500 Message-ID: <456943D540CFC14A8D7138E64843F8530129D0CA@daebe101.NOE.Nokia.com> Thread-Topic: Soliciting agenda items for MIP6 WG meeting at IETF63 Thread-Index: AcV7MGWY5Aejv1BfT72RYZmlxdDe2g== To: X-OriginalArrivalTime: 27 Jun 2005 15:53:45.0680 (UTC) FILETIME=[666A0D00:01C57B30] X-Spam-Score: 0.3 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Soliciting agenda items for MIP6 WG meeting at IETF63 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org We have requested a 2.5 hour meeting slot for the MIP6 WG at IETF63. If you need a time-slot at the MIP6 WG meeting to discuss your I-D, please send a request to the chairs with the following details: 1. Title and I-D details 2. Amount of time needed 3. How does this I-D fit in the scope of the MIP6 charter?=20 Please try and ensure that there is some discussion on the WG ML in order to ensure productive use of the time at the meeting. -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jun 27 15:50:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmzca-00077n-T3; Mon, 27 Jun 2005 15:50:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmzcN-00073o-SF; Mon, 27 Jun 2005 15:50:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00211; Mon, 27 Jun 2005 15:50:05 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn01Y-0000gk-FX; Mon, 27 Jun 2005 16:16:08 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DmzcI-0002aC-Ej; Mon, 27 Jun 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 27 Jun 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-cn-ipsec-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Using IPsec between Mobile and Correspondent IPv6 Nodes Author(s) : F. Dupont, J. Combes Filename : draft-ietf-mip6-cn-ipsec-01.txt Pages : 8 Date : 2005-6-27 Mobile IPv6 uses IPsec to protect signaling between the mobile node and the home agent. This document defines how IPsec can be used between the mobile node and correspondent nodes, including home address option validation (aka. triangular routing), protection of mobility signaling for routing optimization and suitable configurations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-cn-ipsec-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-cn-ipsec-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-cn-ipsec-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-27150710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-cn-ipsec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-cn-ipsec-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-27150710.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Tue Jun 28 05:40:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnCZv-0006tN-O8; Tue, 28 Jun 2005 05:40:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnCZu-0006tH-01 for mip6@megatron.ietf.org; Tue, 28 Jun 2005 05:40:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17407 for ; Tue, 28 Jun 2005 05:40:23 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnCzC-0001AZ-97 for mip6@ietf.org; Tue, 28 Jun 2005 06:06:36 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E099189805; Tue, 28 Jun 2005 12:40:00 +0300 (EEST) Message-ID: <42C11AFB.8060906@kolumbus.fi> Date: Tue, 28 Jun 2005 12:40:11 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mobile IPv6 Mailing List , Vijay Devarapalli Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: Subject: [Mip6] review of draft-ietf-mip6-ikev2-ipsec-01 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org I read this draft. Overall, I liked it and I hope we can move it forward pretty soon. I did have some comments, however: o Imho, the draft reads too much like a "diff" to RFC 3776. In the light of eventually switching to only this, I think we want a more self-contained document, even if it means more text. o Question: do we want to keep the manually keyed case in this document? I mean we will always have RFC 3776 when we want to do that... o In some places (such as section 6 and how you explain the use of the AUTH payload) I got the feeling this repeats what IKEv2 spec already says. Not sure what to do here, just an observation. o I'd prefer seeing recommendations like [8] as orthogonal to what we need for Mobile IPv6 usage of IKEv2. That is, I agree with what [8] is saying, but it seems like a general IKEv2 issue rather than something specific to Mobile IPv6. In some cases you want to point to such work and in some other cases you can leave it out; in this case I think the draft is unfortunately not moving very fast so you might want to drop the discussion about it, as eventual approval of [8] might change the contents. o Security considerations should perhaps say something about rules regarding the allocation of home addresses, to avoid hijacking them. I think you said something about that already somewhere else, maybe that text could move here. o It would also be interesting to hear more about how NAT traversal feature of IKEv2 could be used in the connection of this new spec for v4 compatibility, or whether you want to continue to use the K bit or MOBIKE for moving the SAs. But perhaps these are out of scope, I know that at least for the v4-v6 compatibility there are other discussions and drafts. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 28 07:46:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEXj-00078n-Ev; Tue, 28 Jun 2005 07:46:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEXh-00078X-IK for mip6@megatron.ietf.org; Tue, 28 Jun 2005 07:46:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26333 for ; Tue, 28 Jun 2005 07:46:16 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnEx1-0000LU-RV for mip6@ietf.org; Tue, 28 Jun 2005 08:12:29 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j5SBjra14516; Tue, 28 Jun 2005 13:45:53 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j5SBjrix021679; Tue, 28 Jun 2005 13:45:53 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200506281145.j5SBjrix021679@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] Soliciting agenda items for MIP6 WG meeting at IETF63 In-reply-to: Your message of Mon, 27 Jun 2005 10:53:44 CDT. <456943D540CFC14A8D7138E64843F8530129D0CA@daebe101.NOE.Nokia.com> Date: Tue, 28 Jun 2005 13:45:53 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: We have requested a 2.5 hour meeting slot for the MIP6 WG at IETF63. If you need a time-slot at the MIP6 WG meeting to discuss your I-D, please send a request to the chairs with the following details: 1. Title and I-D details 2. Amount of time needed 3. How does this I-D fit in the scope of the MIP6 charter? => I'd like to discuss about a last call for draft-ietf-mip6-cn-ipsec-01.txt (I posted a new version with no modification yesterday) but this should be in general actions about WG items (so no specific time needed). draft-dupont-mipv6-rrcookie-01.txt can be considered as a companion document but if there is no real world need for this kind of mechanism (and IMHO it is the case) a publication as an experimental protocol should be enough. So the questions are: - is my hypothesis true? - what action is needed? This can be done in the list... I participated to other I-Ds but not as the main author, so I (only :-) support the co-authors if they request something. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 28 08:33:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnFHJ-0001vr-MT; Tue, 28 Jun 2005 08:33:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnFHI-0001uP-Az for mip6@megatron.ietf.org; Tue, 28 Jun 2005 08:33:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02024 for ; Tue, 28 Jun 2005 08:33:23 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnFgd-0005YR-4S for mip6@ietf.org; Tue, 28 Jun 2005 08:59:36 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j5SCWta18036; Tue, 28 Jun 2005 14:32:55 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j5SCWt7S021928; Tue, 28 Jun 2005 14:32:56 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200506281232.j5SCWt7S021928@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko Subject: Re: [Mip6] review of draft-ietf-mip6-ikev2-ipsec-01 In-reply-to: Your message of Tue, 28 Jun 2005 12:40:11 +0300. <42C11AFB.8060906@kolumbus.fi> Date: Tue, 28 Jun 2005 14:32:55 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Mobile IPv6 Mailing List , Vijay Devarapalli X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org In your previous mail you wrote: I read this draft. Overall, I liked it and I hope we can move it forward pretty soon. I did have some comments, however: o Imho, the draft reads too much like a "diff" to RFC 3776. In the light of eventually switching to only this, I think we want a more self-contained document, even if it means more text. => I fully agree: RFC 3776 has many problems which enforced a special way to specify and describe things, and at the other hand RFC 2401bis is a large improvement, it gives a syntax for SPD/SADB entries for instance. IMHO the document should be rewritten from scratch with the help of someone involved into the IKEv2/2401bis effort. o Question: do we want to keep the manually keyed case in this document? I mean we will always have RFC 3776 when we want to do that... => I already raised this concern. o It would also be interesting to hear more about how NAT traversal feature of IKEv2 could be used in the connection of this new spec for v4 compatibility, or whether you want to continue to use the K bit or MOBIKE for moving the SAs. But perhaps these are out of scope, I know that at least for the v4-v6 compatibility there are other discussions and drafts. => note that the K bit is a real thing today, cf draft-sugimoto-mip6-pfkey-migrate-00.txt... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 28 15:57:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnMDD-0002kB-19; Tue, 28 Jun 2005 15:57:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnMCW-0002Pv-GB; Tue, 28 Jun 2005 15:56:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13385; Tue, 28 Jun 2005 15:56:52 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnMVJ-0004Is-Lk; Tue, 28 Jun 2005 16:16:21 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DnM5q-00086c-4X; Tue, 28 Jun 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 28 Jun 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrapping-split-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 bootstrapping in split scenario Author(s) : G. Giaretta, et al. Filename : draft-ietf-mip6-bootstrapping-split-00.txt Pages : 32 Date : 2005-6-28 A Mobile IPv6 node requires a Home Agent address, a home address, and IPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a Mobile IPv6 node can bootstrap this information from non-topological information and security credentials preconfigured on the Mobile Node. The solution defined in this document solves the boostrapping problem from draft-ietf-mip6-bootstrapping-ps-02 when the Mobile Node's mobility service is authorized by a different service provider than basic network access, and is therefore generically applicable to any bootstrapping case. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-bootstrapping-split-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <2005-6-28113419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-bootstrapping-split-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-bootstrapping-split-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-28113419.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Tue Jun 28 17:10:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnNLn-0002gS-Pk; Tue, 28 Jun 2005 17:10:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnNLm-0002fN-04 for mip6@megatron.ietf.org; Tue, 28 Jun 2005 17:10:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26081 for ; Tue, 28 Jun 2005 17:10:30 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnNWK-0000a2-0F for mip6@ietf.org; Tue, 28 Jun 2005 17:21:29 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IIT00L8TATMQU@dns2.cselt.it> for mip6@ietf.org; Tue, 28 Jun 2005 22:41:46 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 22:53:31 +0200 Date: Tue, 28 Jun 2005 22:54:56 +0200 From: Gerardo Giaretta To: mip6@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: Bootstrapping DT solution draft Thread-Index: AcV8I6MYcEUHAdAnSueBzpu/XcTf6Q== Content-class: urn:content-classes:message X-OriginalArrivalTime: 28 Jun 2005 20:53:32.0015 (UTC) FILETIME=[7184B7F0:01C57C23] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Bootstrapping DT solution draft X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Dear WG, the bootstrapping DT has submitted a solution draft. The document defines how a Mobile Node can bootstrap MIPv6 operations from non-topological information and pre-configured security credentials. The solution solves the boostrapping problem when the Mobile Node's mobility service is authorized by a different service provider than basic network access (i.e. split scenario). The draft can be found at http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- 00.txt. The DT is currently working on optimized solutions for integrated scenario (i.e. mobility service and basic network access are authorized by the same entity). Please read the document and provide comments. Thanks and regards, --Gerardo (DT editor) Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jun 28 20:35:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnQXh-0008P7-A5; Tue, 28 Jun 2005 20:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnQXe-0008Ng-4S; Tue, 28 Jun 2005 20:35:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15766; Tue, 28 Jun 2005 20:35:00 -0400 (EDT) Received: from smtp.um.es ([155.54.212.105] helo=mail.um.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnQx5-0001yV-Tp; Tue, 28 Jun 2005 21:01:20 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 7493623C2A9; Wed, 29 Jun 2005 02:34:42 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21629-01-58; Wed, 29 Jun 2005 02:34:42 +0200 (CEST) Received: from [192.168.1.34] (dibulibu.um.es [155.54.1.250]) by mail.um.es (Postfix) with ESMTP id 2C85B23C2A8; Wed, 29 Jun 2005 02:34:41 +0200 (CEST) Message-ID: <42C1ECA0.3060005@dif.um.es> Date: Wed, 29 Jun 2005 02:34:40 +0200 From: "Pedro M. Ruiz" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'IETF Manet'" Content-Type: multipart/mixed; boundary="------------000907060201090408090005" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: mip6@ietf.org, tccc@cs.columbia.edu Subject: [Mip6] LOCAN2005: Deadline extended to July 7th X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --------------000907060201090408090005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, The deadline for the following workshop has been extended to July 7th, Please, find below the revised CFP. Regards, Pedro M. Ruiz University of Murcia http://ants.dif.um.es/staff/pedrom/ --------------000907060201090408090005 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="cfp.txt" Content-Disposition: inline; filename="cfp.txt" Content-Transfer-Encoding: 7bit We apologize if you receive multiple copies of this CFP ---------------------------------------------------------------------------- CALL FOR PAPERS - LOCAN 2005 1st International Workshop on Localized Communication and Topology Protocols for Ad hoc Networks in conjunction with MASS-2005 (www.mass05.wpi.edu) Washington, DC, USA, November 7-10, 2005 --------------------------------------------------------------------------- Submission deadline extended to July 7th. SUBJECT AND SCOPE ----------------- This workshop covers comprehensively the algorithmic issues in the hot area of ad hoc and sensor networking. The design of data communication techniques in multi-hop ad hoc networks has challenges at all layers of communication. This workshop concentrates on the network layer problems like data communication (routing, QoS-routing, geocasting, multicasting, broadcasting, etc.) and topology control (neighbor discovery, power adjustment, neighbor elimination, etc.). Additionally, sensor networks are currently recognized as one of the priority research areas by NSF. The area of sensor networking is gaining momentum within the researh community. This workshop will address ongoing research on this field, including problems such as: physical properties, sensor training, security through intelligent node cooperation, medium access, sensor area coverage with random and deterministic placement, object location, sensor position determination, energy efficient broadcasting and activity scheduling, routing, connectivity, data dissemination and gathering, sensor centric quality of routing, temporal message ordering, path exposure, tree reconfiguration, topology construction, and transport layer. The main paradigm shift is to apply localized (or greedy) schemes as opposed to existing protocols requiring global information. Localized algorithms are distributed algorithms where simple local node behaviour achieves a desired global objective. Localized protocols provide scalable solutions, that is, solutions for wireless networks with an arbitrary number of nodes, which is the main goal of this plan. Sensor and rooftop/mesh networks, for instance, have hundreds or thousands of nodes. The main objective of the workshop is to present state of the art research results on data communication and topology control in rapidly growing area of ad hoc and sensor networks, with emphasizes on localized techniques. Topics of interest include, but are not limited to: *Medium access control *Analytical, mobility and validation models for ad hoc networks *Hybrid networks and wireless Internet *Security in ad hoc networks *Data management issues, query processing, and data delivery *Routing, broadcasting and multicasting in ad hoc networks *Energy-efficient protocols for ad hoc networks *Quality of service in medium access control and routing *Topology construction and maintenance in ad hoc networks *Neighborhood discovery and mobility management IMPORTANT DATES --------------- Manuscript Submission: July 7, 2005 (Extended deadline) Acceptance Notification: July 29, 2005 Final Manuscript Due: August 26, 2005 PAPER SUBMISSION ---------------- Papers must not exceed 10 single-spaced and two-column pages using at least 10 point size type on 8.5 x 11 inches pages. See style files, author guidelines and instructions at the conference website. Accepted papers will be published by IEEE Computer Society Press, as proceedings of the MASS2005 workshops. For submission details, please visit the LOCAN 2005 website (http://ants.dif.um.es/locan2005/). PROGRAM CO-CHAIRS ----------------- Dr. Pedro M. Ruiz Dept. Information and Comms. Engineering, University of Murcia, Spain pedrom@dif.um.es Dr. David Simplot-Ryl IRCICA/LIFL, Univ. Lille 1, INRIA Futurs, France David.Simplot@lifl.fr ADDITIONAL INFORMATION AND PC MEMBERS ------------------------------------- The list of PC members and additional information about the workshop will be continuously updated at the LOCAN 2005 website. http://ants.dif.um.es/locan2005/ --------------000907060201090408090005 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --------------000907060201090408090005-- From mip6-bounces@ietf.org Wed Jun 29 13:05:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dng04-0004pk-FV; Wed, 29 Jun 2005 13:05:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dng02-0004p1-Ss; Wed, 29 Jun 2005 13:05:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11467; Wed, 29 Jun 2005 13:05:20 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DngPd-0005ZE-Hf; Wed, 29 Jun 2005 13:31:50 -0400 Message-ID: <083701c57ccc$e2e99a60$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , , , Date: Wed, 29 Jun 2005 10:06:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.4 (++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Subject: [Mip6] BOF on Network-based Localized Mobility Management at IETF 63 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Phil Roberts and I are organizing a BOF on network based localized mobility management (netlmm) for IETF 63. The idea is to provide support in the local access network for mobility management so that a mobile node doesn't have to change its IP address so frequently. The BOF description is at: http://www.geocities.com/kempf42/netlmm-bof.txt There's a mailing list: netlmm@ngnet.it https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm, to subscribe Currently, the list is being used by co-authors of the problem statement and requirements drafts, but please subscribe and join in discussion if you would like. Please don't respond to this message, since any discussion on the proposed BOF should be on the BOF list. The problem statement draft is available from the Internet Drafts repository: https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=13248 The requirements draft is about complete and will be posted to the Internet Drafts repository by the end of the week. I'll send email to the list about it when its posted. Phil and I are working on a proposed WG charter, we'll post the charter to the list when its complete. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 29 21:16:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnnet-00073A-6E; Wed, 29 Jun 2005 21:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnner-00072j-3f for mip6@megatron.ietf.org; Wed, 29 Jun 2005 21:16:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22257 for ; Wed, 29 Jun 2005 21:15:59 -0400 (EDT) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dno4V-0003TF-9D for mip6@ietf.org; Wed, 29 Jun 2005 21:42:32 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 228FE8000AC for ; Thu, 30 Jun 2005 04:15:47 +0300 (EEST) Date: Thu, 30 Jun 2005 04:15:47 +0300 (EEST) From: Wassim Haddad To: mip6@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 2.0 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Mip6] I-D ACTION:draft-haddad-privacy-omipv6-anonymity-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi all, FYI, A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Anonymity and Unlinkability Extension for CGA-OMIPv6 Author(s) : W. Haddad, et al. Filename : draft-haddad-privacy-omipv6-anonymity-00.txt Pages : 16 Date : 2005-6-29 The Optimized Mobile IPv6 with CGA [CGA-OMIPv6] protocol specifies a new route optimization (RO) technique. This document describes a new extension to be added to the CGA-OMIPv6 protocol in order to provide the anonymity and the unlinkability at the IP layer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haddad-privacy-omipv6-anonymity-00.txt Regards, Wassim H. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 29 21:34:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnnx9-0005QX-65; Wed, 29 Jun 2005 21:34:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnnx7-0005QO-Hd for mip6@megatron.ietf.org; Wed, 29 Jun 2005 21:34:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23415 for ; Wed, 29 Jun 2005 21:34:51 -0400 (EDT) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnoMl-0004hq-TQ for mip6@ietf.org; Wed, 29 Jun 2005 22:01:25 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 178E88000BB for ; Thu, 30 Jun 2005 04:34:43 +0300 (EEST) Date: Thu, 30 Jun 2005 04:34:43 +0300 (EEST) From: Wassim Haddad To: mip6@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Mip6] Micro Mobility X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi all, FYI, A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Optimizing Micromobility Management Author(s) : W. Haddad, S. Krishnan Filename : draft-haddad-mipshop-omm-00.txt Pages : 24 Date : 2005-5-18 Micromobility protocols address mobile nodes (MN) movements within a particular IP network domain. This document introduces a new protocol "Optimized Micromobility Management" (OMM), to manage Micromobility. The suggested solution is based on the Hierarchical Mobile IPv6 (HMIPv6) proposal and aims to increase the mobility performance by reducing the handover latency and the packet loss. Comments are appreciated. Regards, Wassim H. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jun 29 23:36:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnprG-0003xg-Pu; Wed, 29 Jun 2005 23:36:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnprE-0003xK-Jo for mip6@megatron.ietf.org; Wed, 29 Jun 2005 23:36:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02232 for ; Wed, 29 Jun 2005 23:36:54 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnqGu-0005hG-Eu for mip6@ietf.org; Thu, 30 Jun 2005 00:03:29 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j5U3aow3002111; Thu, 30 Jun 2005 12:36:50 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j5U3aokJ007010; Thu, 30 Jun 2005 12:36:50 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j5U3aofN007005; Thu, 30 Jun 2005 12:36:50 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j5U3anGl021586; Thu, 30 Jun 2005 12:36:49 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j5U3anjC021583; Thu, 30 Jun 2005 12:36:49 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j5U3an4M004560; Thu, 30 Jun 2005 12:36:49 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j5U3amb4016730; Thu, 30 Jun 2005 12:36:48 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (ime0.m.ecl.ntt.co.jp [129.60.5.143]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j5U3amnQ016725; Thu, 30 Jun 2005 12:36:48 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id MAA23762; Thu, 30 Jun 2005 12:36:48 +0900 (JST) Message-ID: <42C368D1.3000504@lab.ntt.co.jp> Date: Thu, 30 Jun 2005 12:36:49 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Mip6] Bootstrapping DT solution draft References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tama5.ecl.ntt.co.jp id j5U3aow3002111 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi Gerardo and solution DT members, First, I'd like to express my appreciation for your work. I have a comment about dynamic DNS update in this draft. In section6, it is described that dynamic DNS update function is=20 important to keep IP reachability when MN is assigned HoA dynamically.=20 I agree this. But, is it essential function for MIPv6 bootstrapping? I think we can use FQDN assigned by a domain name provider, which is=20 different from MSP/MSA, for IP reachability even if we get HoA from MSP. I understood that DT has selected the split scenario, which was simpler=20 scenario, in order to make the first solution generic. In the split=20 scenario, we don=92t assume that there is relationship between MSP and=20 access service provider. Should we assume that there is relationship=20 between MSP and DNS provider? Best Regards, --Mayumi > Dear WG, >=20 > the bootstrapping DT has submitted a solution draft. The document > defines how a Mobile Node can bootstrap MIPv6 operations from > non-topological information and pre-configured security credentials. Th= e > solution solves the boostrapping problem when the Mobile Node's mobilit= y > service is authorized by a different service provider than basic networ= k > access (i.e. split scenario). >=20 > The draft can be found at > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split= - > 00.txt. >=20 > The DT is currently working on optimized solutions for integrated > scenario (i.e. mobility service and basic network access are authorized > by the same entity). >=20 > Please read the document and provide comments. >=20 > Thanks and regards, >=20 > --Gerardo (DT editor) >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p= .A. >=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=3D=3D=3D=3D > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 --=20 *++++++++++++++++++++++++++++++++++++++++++ NTT Network Service Systems Laboratories Mayumi Yanagiya tel: +81 422 59 6783 fax: +81 422 59 5631 E-mail: yanagiya.mayumi@lab.ntt.co.jp +++++++++++++++++++++++++++++++++++++++++++* _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 30 06:17:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnw6V-0003Wz-Of; Thu, 30 Jun 2005 06:17:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnw6T-0003Wu-Ok for mip6@megatron.ietf.org; Thu, 30 Jun 2005 06:17:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22544 for ; Thu, 30 Jun 2005 06:17:02 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnwWB-0004Kx-KM for mip6@ietf.org; Thu, 30 Jun 2005 06:43:41 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IIW00EBO72Z40@dns1.cselt.it> for mip6@ietf.org; Thu, 30 Jun 2005 12:13:47 +0200 (MEST) Received: from iowa2k01b.cselt.it ([163.162.242.202]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Jun 2005 12:19:56 +0200 Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Jun 2005 12:04:29 +0200 Date: Thu, 30 Jun 2005 12:05:43 +0200 From: Gerardo Giaretta Subject: RE: [Mip6] Bootstrapping DT solution draft To: Mayumi Yanagiya Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Bootstrapping DT solution draft Thread-Index: AcV9JT5YAluqJBqkRWiORtEOXevv5wAMGHDw content-class: urn:content-classes:message X-OriginalArrivalTime: 30 Jun 2005 10:04:29.0265 (UTC) FILETIME=[1AA82410:01C57D5B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi Mayumi, thanks for your comments. Please see below.. >=20 > Hi Gerardo and solution DT members, >=20 > First, I'd like to express my appreciation for your work. >=20 > I have a comment about dynamic DNS update in this draft. >=20 > In section6, it is described that dynamic DNS update function is=20 > important to keep IP reachability when MN is assigned HoA=20 > dynamically.=20 > I agree this. But, is it essential function for MIPv6 bootstrapping? The DT thinks that this is essential for IP reachability and thus for Mobile IPv6. However there has been a lot of discussion about this topic even within the DT. We can consider it as a possible open issue to be solved within the WG.=20 > I think we can use FQDN assigned by a domain name provider, which is=20 > different from MSP/MSA, for IP reachability even if we get=20 > HoA from MSP. >=20 Could you please describe a scenario where the domain name provider is different from the MSP or MSA? > I understood that DT has selected the split scenario, which=20 > was simpler=20 > scenario, in order to make the first solution generic. In the split=20 > scenario, we don't assume that there is relationship between MSP and=20 > access service provider. Should we assume that there is relationship=20 > between MSP and DNS provider? I think that, if there is a trust relationship between MSP and DNS provider (whatever it can be), the solution described in the draft may also be applied in this scenario (it needs a AAA communication between MSP and the domain name provider to authorize the usage of a particular name and to update the DNS entry). But, let's discuss about the scenario first. Regards, --Gerardo >=20 > Best Regards, > --Mayumi >=20 > > Dear WG, > >=20 > > the bootstrapping DT has submitted a solution draft. The document > > defines how a Mobile Node can bootstrap MIPv6 operations from > > non-topological information and pre-configured security=20 > credentials. The > > solution solves the boostrapping problem when the Mobile=20 > Node's mobility > > service is authorized by a different service provider than=20 > basic network > > access (i.e. split scenario). > >=20 > > The draft can be found at > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp ing-split- > 00.txt. >=20 > The DT is currently working on optimized solutions for integrated > scenario (i.e. mobility service and basic network access are authorized > by the same entity). >=20 > Please read the document and provide comments. >=20 > Thanks and regards, >=20 > --Gerardo (DT editor) >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. >=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=3D=3D=3D=3D > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 --=20 *++++++++++++++++++++++++++++++++++++++++++ NTT Network Service Systems Laboratories Mayumi Yanagiya tel: +81 422 59 6783 fax: +81 422 59 5631 E-mail: yanagiya.mayumi@lab.ntt.co.jp +++++++++++++++++++++++++++++++++++++++++++* Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 30 11:58:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do1QT-0005su-Ly; Thu, 30 Jun 2005 11:58:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do1QS-0005sm-5c for mip6@megatron.ietf.org; Thu, 30 Jun 2005 11:58:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27252 for ; Thu, 30 Jun 2005 11:58:00 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do1qB-00065f-L3 for mip6@ietf.org; Thu, 30 Jun 2005 12:24:42 -0400 Message-ID: <005101c57d8c$a6713e60$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Mayumi Yanagiya" , "Gerardo Giaretta" References: <42C368D1.3000504@lab.ntt.co.jp> Subject: Re: [Mip6] Bootstrapping DT solution draft Date: Thu, 30 Jun 2005 08:59:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Mayumi, What is the "domain provider"? A separate administrative entity from the = MSP or MSA? If so, then what network entity will be updating the DNS server with the = HoA (which the MN will get from the MSP)? jak ----- Original Message -----=20 From: "Mayumi Yanagiya" To: "Gerardo Giaretta" Cc: Sent: Wednesday, June 29, 2005 8:36 PM Subject: Re: [Mip6] Bootstrapping DT solution draft Hi Gerardo and solution DT members, First, I'd like to express my appreciation for your work. I have a comment about dynamic DNS update in this draft. In section6, it is described that dynamic DNS update function is important to keep IP reachability when MN is assigned HoA dynamically. I agree this. But, is it essential function for MIPv6 bootstrapping? I think we can use FQDN assigned by a domain name provider, which is different from MSP/MSA, for IP reachability even if we get HoA from MSP. I understood that DT has selected the split scenario, which was simpler scenario, in order to make the first solution generic. In the split scenario, we don=92t assume that there is relationship between MSP and access service provider. Should we assume that there is relationship between MSP and DNS provider? Best Regards, --Mayumi > Dear WG, > > the bootstrapping DT has submitted a solution draft. The document > defines how a Mobile Node can bootstrap MIPv6 operations from > non-topological information and pre-configured security credentials. Th= e > solution solves the boostrapping problem when the Mobile Node's mobilit= y > service is authorized by a different service provider than basic networ= k > access (i.e. split scenario). > > The draft can be found at > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split= - > 00.txt. > > The DT is currently working on optimized solutions for integrated > scenario (i.e. mobility service and basic network access are authorized > by the same entity). > > Please read the document and provide comments. > > Thanks and regards, > > --Gerardo (DT editor) > > > > > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p= .A. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > --=20 *++++++++++++++++++++++++++++++++++++++++++ NTT Network Service Systems Laboratories Mayumi Yanagiya tel: +81 422 59 6783 fax: +81 422 59 5631 E-mail: yanagiya.mayumi@lab.ntt.co.jp +++++++++++++++++++++++++++++++++++++++++++* _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 30 15:10:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do4QN-00077M-At; Thu, 30 Jun 2005 15:10:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do4QJ-0006wP-Kj; Thu, 30 Jun 2005 15:10:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13223; Thu, 30 Jun 2005 15:10:05 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do4q8-0006yW-B2; Thu, 30 Jun 2005 15:36:48 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1Do4QF-0001xV-5u; Thu, 30 Jun 2005 15:10:03 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 30 Jun 2005 15:10:03 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: mip6 chair , mip6 mailing list , Internet Architecture Board , mip6 chair , RFC Editor Subject: [Mip6] Document Action: 'Mobile IP version 6 Route Optimization Security Design Background' to Informational RFC X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org The IESG has approved the following document: - 'Mobile IP version 6 Route Optimization Security Design Background ' as an Informational RFC This document is the product of the Mobility for IPv6 Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-ro-sec-03.txt Technical Summary This document describes the security rational behind the Mobile IPv6 design. Working Group Summary There was support in the WG for this document. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 30 15:42:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do4w4-0003TP-W7; Thu, 30 Jun 2005 15:42:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do4w3-0003Sf-P6 for mip6@megatron.ietf.org; Thu, 30 Jun 2005 15:42:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17281 for ; Thu, 30 Jun 2005 15:42:53 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do4i4-0004yG-FE for mip6@ietf.org; Thu, 30 Jun 2005 15:28:29 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Do47f-0007NI-1g for mip6@ietf.org; Thu, 30 Jun 2005 14:50:51 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j5UIJFx12565 for ; Thu, 30 Jun 2005 11:19:15 -0700 X-mProtect: <200506301819> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdphy7m6; Thu, 30 Jun 2005 11:19:13 PDT Message-ID: <42C43EDF.FE60798B@iprg.nokia.com> Date: Thu, 30 Jun 2005 11:50:07 -0700 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IPv6 Mailing List Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [Mip6] "Securing Mobile IPv6 Route Optimization Using a Static Shared Key" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hello folks, I have sent a revision of the aforementioned draft which I think resolves all issues that have been raised. I have made the new text available at: http://people.nokia.net/charliep/txt/mobilev6/precfg.txt Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jun 30 18:50:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do7rh-0003Cn-Iz; Thu, 30 Jun 2005 18:50:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do7rE-00034h-3s; Thu, 30 Jun 2005 18:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02741; Thu, 30 Jun 2005 18:50:04 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do8H2-0007gR-QS; Thu, 30 Jun 2005 19:16:49 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Do7r8-0002Q3-L7; Thu, 30 Jun 2005 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 30 Jun 2005 18:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-precfgkbm-03.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Securing Mobile IPv6 Route Optimization Using a Static Shared Key Author(s) : C. Perkins Filename : draft-ietf-mip6-precfgkbm-03.txt Pages : 6 Date : 2005-6-30 A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-precfgkbm-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-precfgkbm-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-precfgkbm-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-30170833.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-precfgkbm-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-precfgkbm-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-30170833.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart--