[WLANware] GSoC 2010: Project IP/UDP encapsulation Kernel module

[Mitar]

Hi!

> I agree, and in fact, the learning process update the forwarding table
> automatically ( I guess I didn't specify that in the proposal :) ).
> I think that there are scenarios in which you have the tunnel
> established with a node, but you don't know the (inner - virtual) address
> of the node that established the tunnel (it is a matter of the specific
> signaling protocol used in the tunnel negotiation). In this case, you need
> an explicit rule for the node initiating the flow, while the "responder" can
> still automatically update the forwarding table.

Signaling protocol used in the tunnel negotiation? You would negotiate
tunnel? I thought it would be much simpler to do it without
negotiation. Whatever comes on the UDP port you push into kernel IP
stack of virtual interface and this is it. You do not need even to
check what it is. Just on the sender side you decide over which
tunnel(s) (to which destination UDP ports) you send a packet. Why
would be need negotiation if we will not have encryption?

I think we could see this as a virtual switch, except that for cables
you have UDP packets between UDP ports (and not hardware ports).

Maybe easier would be to imagine if we would have virtual hub.
Whatever would come to virtual interface would be send to all
configured destinations encapsulated in UDP packets. On destination
UDP would be simply stripped of and feed to virtual interface.

The only problem with this is that a lot of packets would be sent just
to be discarded by destination's IP stack. So it is better to decide
to which UDP destination(s) send each packet. And this is it?

> 1- (as for the inner packets) not all applications are supposed to have IPv6
> support

But I think that IPv6-only meshes (internally) are something which
will be probably used for those of us who do not have public IPv4
addresses. (And we will then to some magic for clients so that they
will be able to use IPv4.)

> 2- (as for the tunnel header) few ISPs provide IPv6 connectivity.

Our main server, high speed Internet gateway, is IPv6 connected. And
also some of our nodes (like at university) are also connected to IPv6
network. Currently we use IPv4, but it would be at least interesting
to play with IPv6. :-)

But I completely agree. From coding perspective first do IPv4 version.
But from planning perspective we should already plan IPv6.


Mitar