Brian E Carpenter wrote:
Well, I disagree. This may amount to asking for the impossible. We can properly require a shim6 implementation to co-exist with mobility implementations, but we cannot require it to operate simultaneously with them; that may turn out to be simply impossible. As I wrote a few days ago, it may be necessary to instruct shim6 to switch itelf off when some other functions are switched on.
While I don't have a problem with the charter not committing to solving this problem, I don't see it as being as hard as you think.
We have shim6, which says it will be transparent to what runs of top of it, be it TCP, UDP, ICMP, or anything else.
We have MIPv6, which is transparent to what runs on top of it the same way.
Thus both layering shim6 over mipv6, and layering mipv6 over shim6, should work in the sense that the protocol mechanisms continue to function. Whether either or both combinations provide a useful combined "service" is a different matter, but it seems to me that the shim6 layered over mipv6 can be quite useful in the case of a mobile IPv6 node which has multiple home addresses, perhaps from independent home agents, where the shim6 overlay would could be used to create a system where a home agent (or the network in which the home agent resides) is not a single point of failure.
Well, I'd want to see a walkthrough to be sure that there aren't tricky cases where the change of locators forced by shim6 would cause perverse routing due to MIP6, or where a change of c/o address due to MIP6 would confuse shim6. (Incidentally there are similar questions if we try to run SCTP over shim6.) I just don't want charter language that later proves to be mathematically impossible to meet. It goes without saying that interworking is highly desirable.
Brian