Subject: Re: [mobile-ip] Mobile Routers support without optimization

From: Erik Nordmark <[email-masked]>
Date: Fri, 7 Sep 2001 10:11:22 +0200 (CEST)

[Catching up on old mail ...]

> Regarding your first proposal to have MR adjacent to all routers on the
> home link when it is home, and then make it reachable behind the HA when
> not at home: how fast can routing protocols reflect this change? If the
> other routers are not updated quickly when the MR moves away, they will
> keep sending packets to MR's link-local address (according to routing
> protocol). The HA has sent proxy NA for MR's link-local address, and the
> packets will end up at the HA, which will tunnel them to the MR. This
> way will work.

Apart from the fact that the MIPv6 spec says that the link local
packets will not be forwarded over the tunnel.

On the convergece time, I think most IGPs can be tuned to detect routers
coming and going in a second or less.

But I suspect that it causes unnecessary churn to have the MR be adjancent
to a set of routers while at home and a different set of
routers while away from home (the different set being just the HAs).
So it is presumably simpler to have the MR always be only adjancent to
two or more (for redundancy) HAs on its home link and use BUs to
merely update the CoA associated with the tunnels between the HAs and the MR.

Effectively this is what you get if you declare the the MR's home link
is a virtual link.

> Either, synchronize the BUs with the routing protocol updates, or use a
> tunnel to the HA, also when the MR is at home.

I agree on the latter.

> > > Maybe Mobile IPv6 should be changed to tunnel *all* packets.
> > 
> > But that means that the MN will see e.g. all mulicast ND packets which might
> > not be that good use of bandwidth. From an architectural perspective this
> > would make the HA an L2 bridge instead of a L3 router.
> > If there are different links the thing that connects them is a router
> > and link-locals don't cross between links.
> > 
> 
> Ok.
> 
> Or maybe ND packets can be filtered out.

Don't mess with the transparency of the network please ...
Filtering packets based on the content of the packets is acceptable
to implement security policies and the like, but we shouldn't have to
hard-code this in order to make the network work.

   Erik