Thierry Ernst wrote:
Since we are opening the discussion on the combination of shim6 with a mobility solution
Well for "we" being equal to the SHIM6 WG, then no, I don't think that was the intent - it certainly was not my intent in my initial response.
I thought that the token was over to the ENABLE project to investigate this a little further and report back.
, I would like to remind about the multihoming analysis
of NEMO and MIPv6 where issues related to shim6 are mentioned: NEMO: http://www.ietf.org/rfc/rfc4980.txtMIPv6: http://www.ietf.org/internet-drafts/draft-ietf-monami6-mipv6-analysis-03.txtI just wonder if these documents are being considered in the ENABLE project.
I trust that the ENABLE folk will pick up these pointers.
We are looking for comments from the shim6 WG on the MIPv6 analysis.
Right now we are in the process of working through the AD's initial comments leading to IESG review of the core documents.
ThierryThere was a pretty long-standing design objective in shim6 that it did no deliberate harm to mobility solutions (and indeed did no deliberate harm to IPv6 at all of course!), but equally that it did not attempt to position itself as an alternative approach to mobility to mobileipv6 and that shim6's objective was the multihoming case where the agility across addresses was across space rather than across time - i.e. the alternative potential addresses were simultaneously available and explorable rather than sequentially available and potentially singly explorable.Right now the core specification of SHIM6 has passed working group last call and the document editors are resolving comments from the area director prior to submitting this as a proposed standard to the IESG for publication.So right now this possibility of making changes to the UPDATE REQUEST message is not readily "open" at this point in time in terms of adding this into the working group's agenda of study for this activity as a procedural matter.However the invocation of procedure should not necessarily preclude consideration of good ideas and if the ENABLE project is willing to undertake further analysis of the issue to figure out the full extent of changes to shim6 for their intended application to mobility, and come to a conclusion that a particular set of changes would be necessary and sufficient for their use in this context, and that such changes would completely benign for the intended shim6 multihoming case from the perspective of performance and security, then I suspect that the case to adopt such a change to shim6 would be stronger. So I would encourage the ENABLE project to undertake more investigation of this and provide a report to the shim6 working group when such a study is complete.On the other hand you need to be aware that the documents are well advanced along the track now, so time is an important consideration if the ENABLE project wanted to head down such a path.wg chair hat off:..... As a purely personal comment:However I am a little surprised at this request given that I read from the ENABLE site "ENABLE will concentrate on the following main areas of work: Enhancement of Mobile IPv6...Enrichment of the basic mobility service provided by Mobile IPv6 ..This activity will investigate scalability and performance issues that Mobile IPv6 might raise " Given that shim6 is not mobileipv6 and shim6 really has not been designed to operate efficiently within the timing constraints that we conventionally believe to be associated with mobility then it is not altogether obvious that further refinement of shim6 would necessarily produce a solution that was superior to mobileipv6 in any case.regards, Geoff Alvaro Vives Martinez wrote:Hi Marcelo,Within the ENABLE project (www.ist-enable.org) SHIM6 has been evaluated as a possible mobility solution. The fact that UPDATE REQUEST message that comesfrom an unknown locator is not accepted was a problem in this context.So, if this possibility is still open I would like to push for it, at least for the UPDATE REQUEST message and if no security risks are introduced, ofcourse.This would open the field for SHIM6 as a mobility solution, there are other missing pieces being evaluated as well, because of its LOC/ID split nature.This would be in addition to the multihoming support. We will follow with attention whatever is said about this issue. Regards, Alvaro Vives Consulintel-----Mensaje original-----De: owner-shim6@psg.com [mailto:owner-shim6@psg.com] En nombre de marcelobagnulo braun Enviado el: viernes, 28 de septiembre de 2007 8:48 Para: Brian E Carpenter CC: Jari Arkko; shim6 Asunto: Re: shim6 control packets coming from unkown locators Hi Brian, El 27/09/2007, a las 21:51, Brian E Carpenter escribió:Marcelo, On 2007-09-28 02:45, marcelo bagnulo braun wrote: <big snip> ...For the R1bis message, it would result in a reduction of security, since anyone knowing the context tag value could tear down a context even if he is not located along the path. this could be enough, though So, the question is general for all the spec, should we support control messages from unknown locators?This makes me very nervous that we'd be opening a fairly big security hole that would be quite painful to close.agree that security issues should be addressed carefully, but i think this is possible, at least for UPDATE packets. Probe packets may require a bit more thought, and will require an UPDATE before actually sending packets to the locators, but i think it should work. Regards, marceloBrian********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.orgThis electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.