Re: Move forward

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

Hi Iljitsch,

Thanks you very much for your feedback. Comments below...

> 
> Ok, some comments:
> 
> - It looks like you want to authenticate the secondary address
>   beforehand when there is still return routability. 

Right. That is what MIPv6 does and the idea is to try to use without
modifications (if possible)

> But can you then
>   simply keep the secndary address in some kind of "hot standby" state
>   untill it is time to start using it and then use it for some
>   considerable amount of time without re-authentication? Does this work
>   and is it secure? Oh wait: "This is a major limitation for this
>   application, since the binding can not be refreshed until the original
>   route is restored and outages can last longer than 420 seconds."
> 
There are two issues here that need to be differentiated:
- First the Return Routability procedure provides BU authorization data
that has a limited lifetime, so it is not permitted by the spec that you
have an alternative address in "standby" as you reasonably suggest.
MIPv6 spec demands the HoTI CoTI exchange to be performed periodically.
This is cumbersome, but i think it can be used as a failure detection
mechanism, which would provide an added value to the RR procedure in its
application to multi-homing.
- The second and really major problem is that you can only use the
alternative address for a limited period (420 secs). Then you have to
perform the RR procedure again to obtain new valid authorization data
that is to be used for extending the lifetime of the new address. THis
is a major problem since you can not perform the RR procedure because
the HoA is no longer available. The solution for this would be to extend
the lifetime of the binding but this may have security implications that
have to be studied

> - ICMP echo for keepalive wouldn't work. Not so much because of all the
>   broken firewalls that block them, but because the only thing an echo
>   reply tells you is that there is _someone_ present at the address, it
>   doesn't tell you who it is. (Ie dial user may have logged out and
>   another logged in and gotten the same address.)
> 
Agree. I guess that the HoTI CoTI exchange is better suited for this
application then.

> - Why don't you look at the return traffic to see if the path is still
>   viable? If you keep (re)sending data but there is no reply from the
>   other side, something must be broken. This probably needs per-session
>   state, though.
> 

A proposed extension for MIPv6 is the piggybacking of mobility messages
in regular traffic. In this case you would use return traffic to
transport signaling data. This kind of optimizations can be done.
However this mechanism allows the it is used also in unidirectional
traffic, which i guess is a good feature 

> - "If a failure   has occurred along the path, the attempt to initiate
>   the communication will fail and the CN will try again with another
>   address. Eventually, a packet from CN will reach MHH." As this is
>   application-dependent you can't count on this. Worse: the all-time
>   most popular networked application typically chokes if the first address
>   tried doesn't work.
> 
Good point. I do not have much data about how applications normally
behave in this case. But if this is the case, this is an issue. However,
AFAIK this is probably the case for IPv4 where interfaces usually have
only one address configured. However in IPv6, considering "Default
Address Selection mechanism" i was hoping that application used the list
of addresses generated by the mechanism and try to use them to
communicate

> - Having to interact every 70 seconds may break sessions that would
>   otherwise remain intact. For instance, I often put my laptop to sleep
>   in the middle of a session to conserve the battery. When it wakes up,
>   my session is still ok because there was no communication during the
>   nap so the fact that my laptop was effecitvely disconnected didn't
>   matter. So lack of a HoT my not be an outage but simply saving
>   energy...

Good point again. Perhaps additional intelligence could be included in
the mechanism to cope with this, i will think it over. 
> 
> This is excellent work. It shows multihoming in IPv6 is just around the
> corner, and not impossible as some people seem to believe.
> 

Thanks :-)

> However, I do see a problem: as this solution isn't well suited to
> medium-sized and larger sites,

indeed

>  and provides no compatibility with other
> solutions that do cater to larger sites,

I am not certain about this. We could study compatibility between
solutions and see what happens. I guess that there is no compatibility
problems between this solution and the classical IPv4 solution... :-)
Really, This is very relevant point to consider seriously and i 'll try
to study it. What solutions do you think i should consider?

>  implementing this as-is may not
> bring as much benefit as we hope. After all, the majority of all
> communication is with at least one non-small site. And I don't think
> Google or some other huge site really wants to start doing MIP as a
> mattoer of course on all those 200 msec TCP sessions just because the
> other side is multihomed.

Not so sure about that. I mean, Google only has to do the CN RO support,
which will be probably included in most stacks (besides, probably Google
will want to be accessed by mobile hosts) So, it will really won't be
able to tell the difference whether this is a multi-homed host or a
mobile host.

> 
> So what I'd like to see is compatibility with one or more solutions that
> are more suited for larger sites. But I guess the first thing we need
> for that is one or more solutions that are ore suited for larger sites.  :-)
> 
Again i think this a very valid point and i will try to study
compatibility with some of the solutions that we have

Thanks again for your valuable feedback. marcelo

> Iljitsch
-- 
marcelo bagnulo <marcelo@it.uc3m.es>
uc3m