[Olsr-dev] SmartGW client side questions

[Henning Rogge]

Am Mittwoch 28 April 2010 15:51:22 schrieb Teco Boot:
> Sorry for not responding earlier. I think this smart-gw is
> very useful. I don't have cycles to check it right now.
> 
> Op 28 apr 2010, om 14:43 heeft Sven-Ola Tuecke het volgende geschreven:
> > Yes - of course. A question: do we need that tnl_$%abcd name for the
> > smargw-client tunnel interface? I only expect one iface (because only one
> > default-route-via-tunnel at a time").
> 
> One tunnel doesn't provide multi-path transport protocols. And cannot
> support seamless handover. For this, we need source address based routing,
> for outgoing tunnel selection. It's a next step.
Or we need to use multiple tunnels. One for the old gateway, one for the new 
one. With a src-based policy routing in the local node.

That's why there is already the option for IPv6 gateways to announce their 
external IPv6 prefix. It allows a client (with the right plugin and scripts) 
to reconfigure it's local IP to fit the external gateway prefix. It just have 
to set a new HNA so that the backward route is established.

But that (or the src-ip based policy routing) is future work. :)

> I proposed BRDP based routing, where instead of a default route,
> packets are routed to a GW that "owns the source address prefix".
> This is proposed for IPv6 / Autoconf and more a long term solution.
> http://tools.ietf.org/id/brdp
> http://www.inf-net.nl/brdp.html
> I think BRDP-based-routing can be used with the smart-gw-tunnels.
> It solves ingress filter problems.
Yes, we dicussed a similar thing... but it cannot be done for kernel 2.4, 
because we cannot do IPv6 policy routing with kernel 2.4.

Henning

-- 
1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100428/4b73c735/attachment.sig>