RE: MIPv6 hopeless

["marcelo bagnulo" <marcelo@it.uc3m.es>]

> > The basic protocol, i.e. the packet formats required to provide 
> > multi-homing support are similar to those required to 
> provide mobility 
> > support (BU, BA), so the protocol itself can be reused (i am not 
> > talking about node behaviors or even roles defined by MIPv6)
> 
> are you saying, can be reused?

Yes.

I mean, suppose you (host1) are in a multi-homed site and you have
multiple addresses. You are currently using one to communicate with
host2.
Suddenly a outage occurs along the path that you are using to
communicate. What you need is a signaling mechanism that allows you to:
1- Inform host2 that an alternative address is to be used to continue
with the communication. This is what BU message is for in mobility, so
it seems reasonable that it is suitable for this task)
2- A mechanism to enable the end of the communication to identify
packets with alternative addresses as belonging to the initial
communication (this is what the Type 2 Routing header and Home address
option is used for in mobility, so again they are good candidates)

Clearly, you need to build alternative triggering mechanism. I mean, in
mobility, BUs are triggered by movement detection mechanism. In this
case you are not moving so this is not useful. What is needed is a
failure detection mechanism that is the one that will trigger the BUs.
This mechanism is not provided by MIP. Important benefits are achieved
if this mechanism does not impose modification in host2 

> 
> Ones between MN and CN? How is the security, then?
> 

This is the difficult part, i guess.

MIP security is based in the RR procedure, which implies connectivity
through both paths. However in the multi-homing scenario, you want to
use an alternative path because the former path is no longer available,
so you cannot perform the RR procedure once that the outage has
occurred. However, there is another relevant difference between
multi-homing and mobility that is that the multihomed host knows all the
available addresses in advance. So, it is possible to perform the RR
procedure authorizing future bindings with all the alternative addresses
available, so that in case of an outage, there is BU authorization data
available for all the alternative addresses. 
The problem with this is that the authorization data has a limited
lifetime, so you need to acquire valid authorization data periodically.
This may not be problem, since you could use the RR procedure packet
exchange as a failure detection mechanism if the frequency is increased.
Another problem is that the binding information in the CN has a limited
lifetime also in order to prevent time shifting attacks (yes, time
shifting attacks do exist and no, i am not inventing new terminology
here)
IMHO this issue cannot be solved without introducing some (minor)
changes in host2 behavior.
The problem here is that time shifting attacks prevention is based in
probing that the communication end is still there. However in the
multi-homing case, the other node is not there (i mean, it is there but
there is no path to it), so you need to differentiate the case of a time
shifting attack where the other end is not there and the case where the
host is still there but there is no path to it. The tool that can be use
to cope with this is ICMP messaging, since when there is no route to the
hosts, an ICMP message is generated. This way, the communication parties
can tell whether they are victims of a time shifting attack (there is an
available route, but the host is no longer there) or there is no route
to the host.

Regards, marcelo 

> > I agree with you that the mobile node behavior (in particular the
> > timers) are not suitable to be used to provide multi-homing support.
> 
> It should be noted that the behavior is not suitable to be 
> used to provide mobility (because it is not suitable for any 
> application), either, which is one of a reason among many why 
> I say MIPv6 hopeless.
> 
> 							Masataka Ohta
>