[Olsr-dev] SmartGW: GW side

[Henning Rogge]

Am Sonntag 25 April 2010 15:06:12 schrieb Alina Friedrichsen:
> > I told you that I would like some technical reasons why we need the back
> > tunnel.
> 
> The first technical reason is, that if we have the tunnel back, we don't
> need "NIIT" (unstandardized 4to6 tunnels) in a IPv6 mesh, to go into the
> IPv4 internet.
NIIT use the same IPIP tunnels as defined in the RFC. It's just an easier way 
to "create" them.

> A standardized 4in6 tunnel is enough. Without "NIIT" we
> don't have the need for a global IPv4 address in the mesh.
No endpoint of the NIIT tunnels needs an IPv4 address. Even the normal IPIP 
tunnels for the default gateway need no IPv4 addresses.

You just need an address for the local IPv4 network. Unless you want to run 
DHCP over the IPIP tunnel to get your IPv4 address from the gateway it will 
stay this way. And doing it this way would make IPv4 connectivity between mesh 
nodes very difficult.

> The IPv4
> address could be gateway-local. So we have not the problem with the
> autoconfiguration of this address. So that the IPv6 mesh with IPv4
> internet access could be completely autoconfigured.
> 
> The second technical reason is, that build the back-tunnel is in the
> most cases faster then advertise a now HNA in the mesh. Is would be nice
> if we use dynamic a IPv6 address in the prefix of the current gateway.
> (The alternative in IPv6 to avoid NAT. :)
This is the first real argument (it only applies for IPv6 networks with IPv6 
uplinks)... but I think it's not good enough to replace the current working 
code with an untested new one (that does not even exist at the moment) for 
0.6.0.

But I think we have to see how we can improve the gateway feature for 0.7.0.

Henning Rogge

-- 
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/20100425/ad3afdf4/attachment.sig>