[Olsr-dev] SmartGW: GW side

[Henning Rogge]

On Mon April 26 2010 19:11:42 Alina Friedrichsen wrote:
> > NIIT use the same IPIP tunnels as defined in the RFC. It's just an easier
> > way to "create" them.
> 
> At least the 4to6 tunnel address space must be standardized, before it
> can be used. The current used address space conflicts strongly with
> other RFCs, implemented e.g. in the Linux kernel.
The tunnel entry-point and exit-point must be a 'valid ipv6 unicast address' 
of the corresponding entry and exit node. So we are not in violation of the 
RFC. It would just be nicer if we have an unique IPv6 address range for 4in6 
tunnels, but it's not strictly necessary.
(See http://tools.ietf.org/html/rfc2473)

There are some 6in4 and 6over4 tunnel sollutions with special IP ranges, but I 
was unable to track down other RFCs for 4in6 tunneling except 2473.

> > No endpoint of the NIIT tunnels needs an IPv4 address. Even the normal
> > IPIP tunnels for the default gateway need no IPv4 addresses.
> 
> But a least the client need a globally routed IPv4 address. With my
> concept it don't. It only need private IPv4 addresses between the
> gateway and the client.
Unless you want to change the client IPv4 address when changing the gateway 
this address should be unique in the whole mesh, even with your tunnel 
solution. If it's not unique you might get an IP collision on the gateway.
 
> > 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.
> 
> Your DHCP concept need a globally routed IPv4 address, too.
Or just give each mesh node a static IPv4 address as it's happening now.

> > And doing it this way would make IPv4 connectivity between mesh
> > nodes very difficult.
> 
> Not all mesh networks need IPv4 connectivity between the nodes. In
> Berlin I have never seen such connectivity, that can't easily converted
> to IPv6 traffic.
I don't see this as an argument that we should not allow this connectivity in 
meshes. Limiting the options during IPv4/6 migration or for dualstack meshs is 
a BAD idea.
 
> And 4to6 tunnels aren't a migration path for old IPv4 mesh networks like
> Berlin. In this mesh networks you need to run IPv6 and old IPv4 routing
> parallel.
> 4to6 tunnels are only a migration path for new mesh networks that need
> IPv4 inter node connectivity like the *censored*.
A good mesh should allow both IPv4 and IPv6 connectivity between all nodes 
with a pure IPv6 core mesh in between.

> > 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.
> 
> Not replace, extend the current code.
You are talking about changing the smartgw code AND removing the NIIT code. 
The NIIT codepath in OLSRd 0.6.0 has nothing to do with internet gateways, 
it's used for all other routes (except the 0.0.0.0/0 one).
 
> > But I think we have to see how we can improve the gateway feature for
> > 0.7.0.
> 
> OLSRv2 like "NIIT" would be never a real option for lazy Berlin. Only
> for research networks, like BATMAN is.
I disagree. Most Freifunk networks have problems with their meshes. One of the 
problem with OLSRd is that we cannot change some basic stuff without changing 
the packet format each times. With OLSRv2 we will be able to add stuff to the 
packet format later WITHOUT breaking the meshes again. In my oppinion this is 
the best argument for moving to OLSRv2.

Henning Rogge
-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:(spam-protected) http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20100427/f1c95b27/attachment.sig>