From mobopts-bounces@irtf.org Wed Apr 12 04:04:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTaKq-00074w-CT; Wed, 12 Apr 2006 04:04:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTaKo-00074r-Mx for mobopts@irtf.org; Wed, 12 Apr 2006 04:04:18 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTaKl-0003Jd-80 for mobopts@irtf.org; Wed, 12 Apr 2006 04:04:18 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FTaKO-0002il-Vt; Wed, 12 Apr 2006 10:04:06 +0200 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id BA068853F; Wed, 12 Apr 2006 10:03:52 +0200 (CEST) Message-ID: <443CB468.1050305@tm.uka.de> Date: Wed, 12 Apr 2006 10:03:52 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: John R Levine Subject: Re: [Mobopts] Review of draft-irtf-mobopts-ro-enhancements-06 References: <4419B218.1080106@piuha.net> In-Reply-To: <4419B218.1080106@piuha.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.7 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Jari Arkko , Mobopts X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi John, thanks again for reviewing draft-irtf-mobopts-ro-enhancements-06! > My only suggestion is that I would have found it useful in section > 3 to have a paragraph or two summarizing the salient > characteristics of the mobile environment, such as power > limitations that leadi to a desire to minimize traffic when a > device is not moving. [...] This makes sense. I added the first three paragraphs of section "Objectives for Route Optimization Enhancement". This was section 3 in version 06 of the draft, which you reviewed, and it is now section 2. You find an updated version of the draft here: http://doc.tm.uka.de/2006/draft-irtf-mobopts-ro-enhancements-07.txt Best regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ > John R Levine wrote: > > The new IRTF publication process for research group documents > includes peer review by chairs of other RGs. I'm the chair of the > ASRG, and I claim no great expertise in mobile IP, so my review is > primarily about the readability and utility of this document for a > technical but non-specialist audience. > > Basically, I think it's quite good, and could be published as is > although I have a few minor suggestions. > > The document starts with an description of the mobile IP > environment and the goals of mobile optimization, and then > enumerates a toolbox of techniques that might be used to improve a > node's migration process from one address to another. Some of the > techniques are fairly tricky, but I didn't have any trouble > following them, even the dread ASCII art. > > My only suggestion is that I would have found it useful in section > 3 to have a paragraph or two summarizing the salient > characteristics of the mobile environment, such as power > limitations that leadi to a desire to minimize traffic when a > device is not moving. These all come up in the discussions of the > techniques, but for those of us not steeped in mobile-thought, it > would have been useful to see a list of them before starting into > the toolbox so I could more easily understand the tradeoffs in > using the techniques. > > Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The > Internet for Dummies", Information Superhighwayman wanna-be, > http://www.johnlevine.com, Mayor "More Wiener schnitzel, please", > said Tom, revealingly. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Apr 12 04:16:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTaWG-0004Kd-9D; Wed, 12 Apr 2006 04:16:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTaWF-0004KY-DM for mobopts@irtf.org; Wed, 12 Apr 2006 04:16:07 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTaWE-0003wW-F9 for mobopts@irtf.org; Wed, 12 Apr 2006 04:16:07 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FTaW7-0003LV-Uv; Wed, 12 Apr 2006 10:16:04 +0200 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id B6546853F; Wed, 12 Apr 2006 10:15:59 +0200 (CEST) Message-ID: <443CB73F.6020009@tm.uka.de> Date: Wed, 12 Apr 2006 10:15:59 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de Subject: Re: [Mobopts] review of References: <20060327151042.GC24815@boskop.local> In-Reply-To: <20060327151042.GC24815@boskop.local> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.7 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Cc: irsg@icir.org, Jari Arkko , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Juergen, thanks for your detailed review. I revised draft-irtf-mobopts-ro-enhancements-06.txt according to your suggestions. Below are some comments and change logs, and here is a link to the updated draft version: http://doc.tm.uka.de/2006/draft-irtf-mobopts-ro-enhancements-07.txt > I have reviewed and I > believe this document is basically ready for publication. It contains > a nice survey of MIPv6 optimizations which I consider useful. Note > that I am not an MIPv6 expert - I understand its basic principles, > but my expertise clearly lies in other areas. > > Given my background, I would have loved to see also some discussion > of operational issues of the various approaches (kind of management > considerations), that is, how difficult will it be to debug problems, > what needs to be configured where, when and by whom, what needs to > be monitored to detect abuse or ongoing attacks, etc. On the > operational side, simplicity usually wins and hence understanding the > management impact of the various proposals is IMHO an important > criterium for the evaluation. While the main focus of this document is an analysis of the pros and cons of different mechanisms with respect to handoff latency, security, and signaling overhead, it also weighs the mechanisms' efficiency with administrative requirements and deployment costs. So, yes, the document needs to consider administrative issues. The trade-off between the mechanisms' effectiveness (small handoff latency, strong security, reduced signaling overhead) and their deployment and administration costs is already considered in different parts of the document. But this may not always be as prominent as it should be. Especially, the introduction of section 4 was lacking some more attendance to this matter. Here is how I modified it: 4. Discussion Common to the proposals discussed in Section 3 is that all of them affect a trade-off between effectiveness on one hand and economical deployability, administrative overhead, as well as wide applicability on the other. Effectiveness may be equated with low latency, strong security, reduced signaling, or increased robustness. Economicalness implies no, or only moderate, requirements in terms of hardware upgrades and software modifications. Administrative overhead relates to the amount of manual configuration and intervention that a technique needs. The standard return-routability procedure avoids costly pre- configuration or new network entities. This minimizes both deployment investments as well as administrative expenses. Variants with optimistic behavior and proactive or concurrent IP-address tests have these advantages as well. CBIDs allow for public-key authentication without a public-key infrastructure. They constitute a more secure alternative to home-address tests and are as such most effective when combined with concurrent reachability verification. CBID-based authentication may require nodes to be programmed with a mapping between human-readable identifiers and the corresponding CBIDs. Pre-configuration is another approach to avoid home address tests. It does without computationally expensive public-key algorithms, but requires pair-wise credentials and, therefore, administrative maintenance. Where suitable infrastructure is available, end nodes may delegate authentication and encryption tasks to trusted network entities which, in turn, vouch for the end nodes. Delegation could resurrect the use of certificates for the purpose of mobility support. But it introduces a dependency on the delegatees, adds the provisioning costs for new network entities, and is likely to be limited to communities of authorized nodes. > I have a more general observation I like to raise: I counted 29 > citations of Internet Drafts out of 62 citations in total, which > means almost 47% of all citations are "work in progress". I checked > up to reference 22 and it seems that 5 out of the 17 cited IDs among > the first 22 references have already expired. How much should we be > concerned about publishing an RFC which points to quite a bit of > documents not really archived (in the sense that there is not a > defined entity in charge of maintaining access to the cited > documents)? This issue clearly has a wider scope and may require some > discussion or a policy within the IRTF as a whole. I did not go back > to the document to check what the purpose of those citations are, > that is, whether the main optimization idea is sufficiently > summarized in the mobopts draft under review so that the reference > more serves as a way to give credits. In such cases, I would not see > a problem. If, however, a reference is really needed to fully grasp a > proposal, then having dangling pointers is kind of problematic. Many of the discussed mechanisms were published only as Internet Drafts. This is unfortunate, given that the mechanisms are quite interesting and would deserve more lasting documentation. I went through the references and replaced the drafts to be journal articles or conference papers wherever possible. Authors of the mechanisms under consideration may know better references, in which case I would be happy to receive a note with a suitable BibTeX entry (or, even better, Xref entry for the xml2rfc tool). > Next to these quite general comments, I do have a few concrete > comments and editorial suggestions: > > a) I suggest to move the first paragraph of section 1 to the end of > section one. I find it a bit strange to start an introduction by > explaining who has reviewed the document. Not sure if it's a policy to have the consensus statement at the beginning of the Introduction. But you are right that the section becomes more readable when the paragraph is at the end of the section. So I moved it. > After moving the paragraph, the first sentence in the now first > paragraph should be reworded so that it does start a bit more reader > friendly and not just "RFC 3775 [42] specifies". Done. > b) Section 1.1 page 4 last line: Do you really mean "not reluctant"? Thanks, yes. s/not...reluctant/unwilling/ > c) Section 1.1 page 5 last bullet: s/in the certifications/in > certificates Ok. > d) Section 1.2 page 6: introduce acronym BU the first time you use it > Spelled out now. > e) Section 2 surprises me. The usual convention is to acknowledge > contributors and reviewers at the end of an RFC but not in the > middle. I suggest to move this section to the very end. Note that > this also requires changes in the introduction. Hmm, we put this section after the Introduction before we added the consensus statement to the Introduction. Should be ok to move the Acknowledgments section down now that we have the consensus statement. > f) Section 4.7 talks about the credit-based authorization approach > while 4.8 talks about heuristics. I am wondering whether credit-based > authorization is no just another heuristic approach. No, it's not. CBA prevents amplification during a redirection-based flooding attack. In this, CBA is proactive and bullet-proof. In contrast, heuristics are by definition reactive. They seek to identify illegitimate behavior based on specific properties, and they may produce false positives and/or false negatives. > g) Section 5.2: I would like to know whether there are "standard" > scenarios people use in the community to compare the various > approaches. Ideally, such "standard" scenarios would be derived from > real-world measurements. If such "standard" scenarios exist, it might > be useful to point to them so that researchers can easily publish > comparable results. If such "standard" scenarios do not exist, you > might want to raise the construction of such things in order to > produce comparable results as a potential future work item. That's a good point. Actually, there was a bullet item in section 5.2 that was somewhat related to this, namely: OLD: o Measurements of a realistic network scenario, enabling all features that would likely be needed in a commercial deployment. These features include link-layer access control, for instance. I modified this in the following way to also reflect your point: NEW: o Conception of a set of standard scenarios that can be used as a reference for comparable measurements and experimentation. Ideally, such standard scenarios ought to be derived from real- world environments, and they should include all features that would likely be needed in a commercial deployment. These features include link-layer access control, for instance. > h) idnits complains that the document does not distinguish between > normative and informative references. I guess all references are > informative and I have no idea how strict today's rules are. Yes, all references are of informative nature, except for RFC 3775. Changed that. > i) Reference [48] says "to be presented" and the date is November > 2004 - perhaps this actually got meanwhile presented? Hmm, this is quite right. :-) > j) Given my background, I would have loved to see also some > discussion of operational issues of the various approaches (kind of > management considerations), that is, how difficult will it be to > debug problems, what needs to be configured where, when and by whom, > what needs to be monitored to detect abuse or ongoing attacks, etc. Yes, see my comments from above. > k) Reference [45] seems to be a bit screwed up. Yes, thanks. > l) How useful is it to cite mailing list messages (I am referring to > references [59] and [60])? Are there no other suitable references for > the "optimistic" approach? I changed the references to a conference paper which, hopefully, describes quite well what the optimistic approach is compared to the conservative approach. I have to emphasize that I am a co-author of this paper, however. > m) Where was [8] published? This was re-published as draft-ietf-dna-protocol-00.txt. Changed that. Juergen, thanks again for your review. It's greatly appreciated! Regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ Juergen Schoenwaelder wrote: > Hi, > > I have reviewed and I > believe this document is basically ready for publication. It contains > a nice survey of MIPv6 optimizations which I consider useful. Note > that I am not an MIPv6 expert - I understand its basic principles, > but my expertise clearly lies in other areas. > > Given my background, I would have loved to see also some discussion > of operational issues of the various approaches (kind of management > considerations), that is, how difficult will it be to debug problems, > what needs to be configured where, when and by whom, what needs to > be monitored to detect abuse or ongoing attacks, etc. On the > operational side, simplicity usually wins and hence understanding the > management impact of the various proposals is IMHO an important > criterium for the evaluation. > > I have a more general observation I like to raise: I counted 29 > citations of Internet Drafts out of 62 citations in total, which > means almost 47% of all citations are "work in progress". I checked > up to reference 22 and it seems that 5 out of the 17 cited IDs among > the first 22 references have already expired. How much should we be > concerned about publishing an RFC which points to quite a bit of > documents not really archived (in the sense that there is not a > defined entity in charge of maintaining access to the cited > documents)? This issue clearly has a wider scope and may require some > discussion or a policy within the IRTF as a whole. I did not go back > to the document to check what the purpose of those citations are, > that is, whether the main optimization idea is sufficiently > summarized in the mobopts draft under review so that the reference > more serves as a way to give credits. In such cases, I would not see > a problem. If, however, a reference is really needed to fully grasp a > proposal, then having dangling pointers is kind of problematic. > > Next to these quite general comments, I do have a few concrete > comments and editorial suggestions: > > a) I suggest to move the first paragraph of section 1 to the end of > section one. I find it a bit strange to start an introduction by > explaining who has reviewed the document. > > After moving the paragraph, the first sentence in the now first > paragraph should be reworded so that it does start a bit more reader > friendly and not just "RFC 3775 [42] specifies". > > b) Section 1.1 page 4 last line: Do you really mean "not reluctant"? > > c) Section 1.1 page 5 last bullet: s/in the certifications/in > certificates > > d) Section 1.2 page 6: introduce acronym BU the first time you use it > > > e) Section 2 surprises me. The usual convention is to acknowledge > contributors and reviewers at the end of an RFC but not in the > middle. I suggest to move this section to the very end. Note that > this also requires changes in the introduction. > > f) Section 4.7 talks about the credit-based authorization approach > while 4.8 talks about heuristics. I am wondering whether credit-based > authorization is no just another heuristic approach. > > g) Section 5.2: I would like to know whether there are "standard" > scenarios people use in the community to compare the various > approaches. Ideally, such "standard" scenarios would be derived from > real-world measurements. If such "standard" scenarios exist, it might > be useful to point to them so that researchers can easily publish > comparable results. If such "standard" scenarios do not exist, you > might want to raise the construction of such things in order to > produce comparable results as a potential future work item. > > h) idnits complains that the document does not distinguish between > normative and informative references. I guess all references are > informative and I have no idea how strict today's rules are. > > i) Reference [48] says "to be presented" and the date is November > 2004 - perhaps this actually got meanwhile presented? > > j) Given my background, I would have loved to see also some > discussion of operational issues of the various approaches (kind of > management considerations), that is, how difficult will it be to > debug problems, what needs to be configured where, when and by whom, > what needs to be monitored to detect abuse or ongoing attacks, etc. > > k) Reference [45] seems to be a bit screwed up. > > l) How useful is it to cite mailing list messages (I am referring to > references [59] and [60])? Are there no other suitable references for > the "optimistic" approach? > > m) Where was [8] published? > > /js _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Apr 12 04:29:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTaje-0001tb-2f; Wed, 12 Apr 2006 04:29:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTajc-0001ss-Gm for mobopts@irtf.org; Wed, 12 Apr 2006 04:29:56 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTajb-0004dF-7A for mobopts@irtf.org; Wed, 12 Apr 2006 04:29:56 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id D2A2B55CD9; Wed, 12 Apr 2006 10:29:53 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 05935-02; Wed, 12 Apr 2006 10:29:52 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id EAE0555DF6; Wed, 12 Apr 2006 10:29:32 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 9BF7A6A3778; Wed, 12 Apr 2006 10:29:30 +0200 (CEST) Date: Wed, 12 Apr 2006 10:29:30 +0200 From: Juergen Schoenwaelder To: Christian Vogt Subject: Re: [Mobopts] review of Message-ID: <20060412082930.GC7792@boskop.local> Mail-Followup-To: Christian Vogt , mobopts@irtf.org, irsg@icir.org, Jari Arkko References: <20060327151042.GC24815@boskop.local> <443CB73F.6020009@tm.uka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <443CB73F.6020009@tm.uka.de> User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: irsg@icir.org, Jari Arkko , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org On Wed, Apr 12, 2006 at 10:15:59AM +0200, Christian Vogt wrote: > Hi Juergen, > > thanks for your detailed review. I revised > draft-irtf-mobopts-ro-enhancements-06.txt according to your > suggestions. [...] I had a quick look and the changes look good to me. Thanks for taking my comments into account. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Sun Apr 16 16:21:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVDkK-00010u-PD; Sun, 16 Apr 2006 16:21:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVDkJ-00010p-Mm for mobopts@irtf.org; Sun, 16 Apr 2006 16:21:23 -0400 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVDkI-0005qq-Cu for mobopts@irtf.org; Sun, 16 Apr 2006 16:21:23 -0400 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FVDk7-0005W7-2m; Sun, 16 Apr 2006 22:21:17 +0200 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id D736F853F; Sun, 16 Apr 2006 22:21:10 +0200 (CEST) Message-ID: <4442A736.1080906@tm.uka.de> Date: Sun, 16 Apr 2006 22:21:10 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: mobopts@irtf.org Subject: Re: [Mobopts] review of References: <20060327151042.GC24815@boskop.local> <443CB73F.6020009@tm.uka.de> <20060412082930.GC7792@boskop.local> In-Reply-To: <20060412082930.GC7792@boskop.local> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.7 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Jari Arkko X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi, this email is for those folks whose proposals are discussed in draft-irtf-mobopts-ro-enhancements-07.txt. In case the references given for your proposals are Internet Drafts, and you have a good paper or journal article that could substitute for these Internet Drafts, I'd be happy if you sent me a BibTeX entry. [This is just a reminder. I already mentioned it in my response to Juergen Schoenwaelder's review, but maybe it got lost in that lengthy email.] Thanks, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ Juergen Schoenwaelder wrote: > On Wed, Apr 12, 2006 at 10:15:59AM +0200, Christian Vogt wrote: >> Hi Juergen, >> >> thanks for your detailed review. I revised >> draft-irtf-mobopts-ro-enhancements-06.txt according to your >> suggestions. > > [...] > > I had a quick look and the changes look good to me. Thanks for taking > my comments into account. > > /js _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Apr 20 14:29:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWdu0-0002cA-KE; Thu, 20 Apr 2006 14:29:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWdtz-0002c2-S2 for mobopts@irtf.org; Thu, 20 Apr 2006 14:29:15 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWdtz-0006sj-HJ for mobopts@irtf.org; Thu, 20 Apr 2006 14:29:15 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k3KHrnX31698 for ; Thu, 20 Apr 2006 10:53:49 -0700 X-mProtect: <200604201753> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp16696.americas.nokia.com (10.241.166.96, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdOQsGDi; Thu, 20 Apr 2006 10:53:48 PDT Message-ID: <4447D2DF.2030002@iprg.nokia.com> Date: Thu, 20 Apr 2006 11:28:47 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "mobopts@irtf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Mobopts] Dallas minutes and presentations X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org at.. people.nokia.net/~rajeev/mobopts Regards, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Apr 21 04:51:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWrM2-00019O-P1; Fri, 21 Apr 2006 04:51:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWrKY-0000ey-EP for mobopts@irtf.org; Fri, 21 Apr 2006 04:49:34 -0400 Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWr8e-0000hU-1k for mobopts@irtf.org; Fri, 21 Apr 2006 04:37:17 -0400 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly32d.srv.mailcontrol.com (MailControl) with SMTP id k3L8bEWP018631 for ; Fri, 21 Apr 2006 09:37:14 +0100 Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 4701_c23d8e90_d10b_11da_8608_0030482aac25; Fri, 21 Apr 2006 09:52:18 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2006042110371219-399462 ; Fri, 21 Apr 2006 10:37:12 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de for mobopts@irtf.org; Fri, 21 Apr 2006 10:40:26 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Mobopts] Dallas minutes and presentations X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mobopts] Dallas minutes and presentations Thread-Index: AcZkqF3eoubp59m5Q++v2beFxeZbVQAaoysg To: Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4FA1BF7D@lan-ex-01.panasonic.de> Date: Fri, 21 Apr 2006 10:37:08 +0200 From: "Kilian Weniger" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-06-00-05 (www.mailcontrol.com) on 10.68.0.142 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Rajeev, I have some corrections to the minutes about MIP6 location privacy discussion. From my notes it was more as follows: --- 5. MIP6 Location Privacy ... Discussion: Kilian: The draft seems to focus on the case of hiding the HoA from eavesdroppers. For the case of hiding the CoA from CN, the draft proposes bidirectional tunnling. This is a really simple solution, but it is not very efficient in many scenarios. Optimized routing should be considered also for the case of hiding the location from CN. There are drafts out providing solutions for this. Rajeev: This draft is about adding location privacy support to MIPv6 without changing MIPv6 much. The approach you are proposing (ROTA) introduces a new entity. Kilian: There are multiple solutions for this problem, some of them require more changes, some of them less changes.=20 --- Regards, Kilian > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]=20 > Sent: Donnerstag, 20. April 2006 20:29 > To: mobopts@irtf.org > Subject: [Mobopts] Dallas minutes and presentations >=20 >=20 > at.. >=20 > people.nokia.net/~rajeev/mobopts >=20 > Regards, >=20 > -Rajeev >=20 >=20 >=20 >=20 > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts >=20 >=20 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Apr 21 11:57:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWy0a-00033M-4a; Fri, 21 Apr 2006 11:57:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWy0Y-00032E-HT for mobopts@irtf.org; Fri, 21 Apr 2006 11:57:22 -0400 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWy0X-0007oB-8G for mobopts@irtf.org; Fri, 21 Apr 2006 11:57:22 -0400 Received: from rodin.i2r.a-star.edu.sg (localhost [127.0.0.1]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id k3LFv6Al000681 for ; Fri, 21 Apr 2006 23:57:06 +0800 (SGT) Received: from newmailhost.i2r.a-star.edu.sg ([192.122.134.76]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id k3LFv43R000662 for ; Fri, 21 Apr 2006 23:57:05 +0800 (SGT) Received: from SwitchFirst (Switch-First.i2r.a-star.edu.sg [192.168.137.164]) by mailhost.lit.org.sg (Sun Java System Messaging Server 6.1 HotFix 0.06 (built Nov 11 2004)) with SMTP id <0IY200AM9XNED830@mailhost.lit.org.sg> for mobopts@irtf.org; Fri, 21 Apr 2006 23:57:15 +0800 (SGT) Date: Fri, 21 Apr 2006 23:59:48 +0800 From: QIU Ying Subject: Re: [Mobopts] Dallas minutes and presentations To: mobopts@irtf.org, Kilian Weniger Message-id: <012c01c6655c$9e0a9c90$a489a8c0@SwitchFirst> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4D2F935F08D41A4C8866693F4F0D7C4FA1BF7D@lan-ex-01.panasonic.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: fanzhao828@gmail.com, Rajeev Koodli X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi, Kilian Thanks for your comments. Please refer to my response inline. ----- Original Message ----- From: "Kilian Weniger" To: Sent: Friday, April 21, 2006 4:37 PM Subject: RE: [Mobopts] Dallas minutes and presentations > > >Hi Rajeev, >I have some corrections to the minutes about MIP6 location privacy >discussion. From my notes it was more as follows: > >--- >5. MIP6 Location Privacy >... > >Discussion: > >Kilian: The draft seems to focus on the case of hiding the HoA from >eavesdroppers. Not exactly. If the CN does not care MN's identity, such as CN is a public webserver, MN can negotiate with CN through a fake HoA. The main idea of the solutions is to break the relationship among HoA, CoA, HA and CN. >For the case of hiding the CoA from CN, the draft >proposes bidirectional tunnling. This is a really simple solution, but >it is not very efficient in many scenarios. It is ture that tnnling mode is not very efficient, but it is tradeoff. In order to hide the CoA from CN, you must use a 3rd-party to hand over. >Optimized routing should be >considered also for the case of hiding the location from CN. The purpose of Optimized Routing is to let the packets transfer from CN to MN directly. Therefore, CN must know the CoA. If a packet is handed over by a third-party, it hardly say it were still a Optimized Routing mode. In order to hide the location from CN, a fake HoA could be employed if the CN accepts. >There are drafts out providing solutions for this. > >Rajeev: This draft is about adding location privacy support to MIPv6 >without changing MIPv6 much. The approach you are proposing (ROTA) >introduces a new entity. > >Kilian: There are multiple solutions for this problem, some of them >require more changes, some of them less changes. Yes. This draft combines 3 of them: draft-koodli-mip6-location-privacy-solutions- draft-qiu-mip6-mnprivacy- draft-zhao-mip6-rr-ext- Regards Qiu Ying >--- > >Regards, > >Kilian > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Donnerstag, 20. April 2006 20:29 > To: mobopts@irtf.org > Subject: [Mobopts] Dallas minutes and presentations > > > at.. > > people.nokia.net/~rajeev/mobopts > > Regards, > > -Rajeev > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts ------------ Institute For Infocomm Research - Disclaimer ------------- This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you. -------------------------------------------------------- _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Apr 26 23:45:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYxR6-0008FC-Aa; Wed, 26 Apr 2006 23:45:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYxR5-0008F7-8l for mobopts@irtf.org; Wed, 26 Apr 2006 23:44:59 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYxR3-0005Vg-RC for mobopts@irtf.org; Wed, 26 Apr 2006 23:44:59 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k3R396m04257; Wed, 26 Apr 2006 20:09:06 -0700 X-mProtect: <200604270309> Nokia Silicon Valley Messaging Protection Received: from danira-pool05316.americas.nokia.com (10.241.53.16, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpd9BmfEp; Wed, 26 Apr 2006 20:09:05 PDT Message-ID: <44503E1E.5030505@iprg.nokia.com> Date: Wed, 26 Apr 2006 20:44:30 -0700 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kilian Weniger Subject: Re: [Mobopts] Dallas minutes and presentations References: <4D2F935F08D41A4C8866693F4F0D7C4FA1BF7D@lan-ex-01.panasonic.de> In-Reply-To: <4D2F935F08D41A4C8866693F4F0D7C4FA1BF7D@lan-ex-01.panasonic.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Killian, I agree with your recollection of the discussion. I have updated the minutes and put them on the URL below. Regards, -Rajeev Kilian Weniger wrote: > Hi Rajeev, > > I have some corrections to the minutes about MIP6 location privacy > discussion. From my notes it was more as follows: > > --- > 5. MIP6 Location Privacy > ... > > Discussion: > > Kilian: The draft seems to focus on the case of hiding the HoA from > eavesdroppers. For the case of hiding the CoA from CN, the draft > proposes bidirectional tunnling. This is a really simple solution, but > it is not very efficient in many scenarios. Optimized routing should be > considered also for the case of hiding the location from CN. There are > drafts out providing solutions for this. > Rajeev: This draft is about adding location privacy support to MIPv6 > without changing MIPv6 much. The approach you are proposing (ROTA) > introduces a new entity. > Kilian: There are multiple solutions for this problem, some of them > require more changes, some of them less changes. > --- > > > Regards, > > Kilian > > > >>-----Original Message----- >>From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] >>Sent: Donnerstag, 20. April 2006 20:29 >>To: mobopts@irtf.org >>Subject: [Mobopts] Dallas minutes and presentations >> >> >>at.. >> >>people.nokia.net/~rajeev/mobopts >> >>Regards, >> >>-Rajeev >> >> >> >> >>_______________________________________________ >>Mobopts mailing list >>Mobopts@irtf.org >>https://www1.ietf.org/mailman/listinfo/mobopts >> >> > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Apr 27 03:00:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ0UR-00026a-D6; Thu, 27 Apr 2006 03:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ0UQ-00026V-9a for mobopts@irtf.org; Thu, 27 Apr 2006 03:00:38 -0400 Received: from cluster-d.mailcontrol.com ([217.69.20.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ0UP-0007fN-Su for mobopts@irtf.org; Thu, 27 Apr 2006 03:00:38 -0400 Received: from rly05d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly05d.srv.mailcontrol.com (MailControl) with ESMTP id k3R70XVE017259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Apr 2006 08:00:34 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [212.158.48.250]) by rly05d.srv.mailcontrol.com (MailControl) id k3R6xxqJ016601 for mobopts@irtf.org; Thu, 27 Apr 2006 07:59:59 +0100 Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly05d-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id k3R6xuAB016554; Thu, 27 Apr 2006 07:59:59 +0100 (BST) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 1cd9_3919597e_d5b5_11da_8c51_0030482aac25; Thu, 27 Apr 2006 08:15:27 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.2) with ESMTP id 2006042708595390-668697 ; Thu, 27 Apr 2006 08:59:53 +0200 Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Thu, 27 Apr 2006 09:03:07 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Mobopts] draft-irtf-mobopts-location-privacy-solutions-01.txt X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mobopts] draft-irtf-mobopts-location-privacy-solutions-01.txt Thread-Index: AcZlXE5eEE6Mf4qnQ/uqQ0Mgjg8nEgCGOmrQ To: Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4FAEB09C@lan-ex-01.panasonic.de> Date: Thu, 27 Apr 2006 08:59:48 +0200 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-06-00-05 (www.mailcontrol.com) on 10.68.1.115 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: fanzhao828@gmail.com, Rajeev Koodli X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Qiu, see comments inline. Sorry for the late response. Note that the purpose of my mail was to correct the minutes, hence I opened a new thread for discussion of the the draft. > >Kilian: The draft seems to focus on the case of hiding the HoA from > >eavesdroppers. >=20 > Not exactly. If the CN does not care MN's identity, such as=20 > CN is a public=20 > webserver, MN can negotiate with CN through a fake HoA. The=20 Yes, hiding the MN's HoA from CN is one possible solution (see, e.g., draft-dupont-mip6-privacyext-02.txt), but I couldn't find a description of a corresponding procedure in your draft.=20 > main idea of the=20 > solutions is to break the relationship among HoA, CoA, HA and CN. >=20 > >For the case of hiding the CoA from CN, the draft > >proposes bidirectional tunnling. This is a really simple=20 > solution, but > >it is not very efficient in many scenarios. >=20 > It is ture that tnnling mode is not very efficient, but it is=20 > tradeoff. In=20 > order to hide the CoA from CN, you must use a 3rd-party to hand over. yes, it requires infrastructure support. However, in my opinion this is not a reason to rule a solution out. I think more important criteria are performance, security, and how many changes to MIPv6 are required. >=20 > >Optimized routing should be > >considered also for the case of hiding the location from CN. >=20 > The purpose of Optimized Routing is to let the packets=20 > transfer from CN to=20 > MN directly. Therefore, CN must know the CoA. If a packet is=20 > handed over by=20 > a third-party, it hardly say it were still a Optimized Routing mode. You are talking about MIPv6 "Route Optimization mode". I was talking about "optimized routing", which from my understanding means that the route is somehow shortened/optimized (does not mean that packets are routed on the optimal/direct path between MN and CN).=20 >=20 > In order to hide the location from CN, a fake HoA could be=20 > employed if the=20 > CN accepts. >=20 > >There are drafts out providing solutions for this. > > > >Rajeev: This draft is about adding location privacy support to MIPv6 > >without changing MIPv6 much. The approach you are proposing (ROTA) > >introduces a new entity. > > > >Kilian: There are multiple solutions for this problem, some of them > >require more changes, some of them less changes. >=20 > Yes. This draft combines 3 of them: > draft-koodli-mip6-location-privacy-solutions- > draft-qiu-mip6-mnprivacy- > draft-zhao-mip6-rr-ext- No, I meant solutions for the problem of simultaneously providing optimized routing and hiding MN's location from CN. AFAIK, all the drafts you mentioned don't address this problem.=20 Regards, Kilian =20 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts