Re: how mobile do we want to be

[Margaret Wasserman <margaret@thingmagic.com>]

Hi Avri,

At 1:07 PM -0500 3/14/05, avri@psg.com wrote:
> The point I raised there, was that it did not make sense to make the 
> kind of major surgery we are doing to the IP, the so called stem of 
> the hourglass, without also considering the implications and 
> opportunities for mobility.  During the years of Multi6, this was 
> out of scope.  As we are currently discussing a new charter, a 
> charter for a major change to IP, I think it is important to take 
> system motion, or non MIP mobility, into account.

Personally, I consider the subjects of mobility and renumbering to 
both be somewhat tangential to the subject of multihoming. 
Certainly, they are all related in some ways, but they are not the 
same problem and may not have the same solution.

To my way of thinking, the following definitions apply:

Mobility:  Changing a node's point of attachment to the Internet 
without losing L3 sessions. Depending on the mechanism employed, 
mobility may or may not involve changing the topological location of 
the node within the Internet (i.e. the IP address prefix of the node).

There are two subtypes of mobility:  mobility within a campus (under 
a single administrative domain) and mobility across the Internet. 
Mobility within a campus is most often handled by layer 2 protocols, 
such as dynamic VLANs, that require no change to the node's 
topological location (IP prefixes or addresses).  Mobility across the 
Internet does require some change to the topological information, at 
least at some level, and is handled by MIP (v4 or v6).

Renumbering:  Changing a node's topological location within the 
Internet.  A node that previously had one topological location (IP 
address prefix) is reconfigured to have a new topological location.

Multihoming:  Allowing a node that has more than one topological 
location within     the Internet to use its redundant paths for 
efficient or reliable Internet connectivity. Note that multihoming 
_does not_ involve changing the node's point(s) of attachment to the 
Internet and/or changing the node's topological locations within the 
Internet; the node has more than one topological location on an 
ongoing basis.

Now, clearly the above definitions are related, particularly if you 
view renumbering and mobility as the process of adding a new 
topological location and removing an old one (perhaps very quickly in 
some situations).  However, there is a very important difference:

*** In shim6, two nodes can exchange their full set of topological 
locations at the beginning of the session and they are not expected 
to change during the lifetime of the session. ***

The shim6 mechanism might be a useful tool to soften the blow of 
renumbering.  A new address prefix (topological location) could be 
added, and hosts could be multihomed for a while during which 
longer-lived connections and associations could be migrated to the 
new topological location (manually, or using some other solution). 
Then, the old topological information could be deprecated and removed 
on a schedule that allows the completion of shorter lived 
connections.  So, shim6 is not a renumbering solution, but it might 
be usefully applied to the problem of renumbering.

It is not easy to see how shim6 (as defined) could apply directly to 
mobility, as described above.  Using shim6 as a mobility mechanism 
would (at minimum) involve adding new topological information in 
mid-session and might involve adding new topological information at a 
time when the node is unreachable using the old topological 
information.  This creates a universe of protocol issues and security 
concerns that are not present in the simpler multihoming case, and I 
would prefer that we don't try to solve this problem right now as 
part of the shim6 solution.

Personally, I respect all of the work that has gone into the Mobile 
IP solutions, and I think that we would be underestimating the 
difficulty and subtlety of that problem space if we assume that it 
can be solved by a simple variant of the shim6 approach.  I do think 
it is important for shim6 to co-exist peacefully with MIPv4 and v6, 
and I think that is sufficient, at least for our first step.

Margaret