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

[marco bonola]

Hi,

>Why would be need negotiation if we will not have encryption?
I was thinking of a scenario with both nodes behind NATs. In this
case is still possible to establish direct tunnels, but we need a ICE-like
procedure. In many cases we will just need to tell on wich
(IP addr, UDP port) pair we are expecting tunneled packets.

>So it is better to decide
>to which UDP destination(s) send each packet. And this is it?
Yes.

>But from planning perspective we should already plan IPv6.
OK. I totally agree.

Marco

On Thu, Apr 15, 2010 at 4:01 PM, Mitar <mmitar at gmail.com> wrote:

> 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
> _______________________________________________
> WLANware mailing list
> WLANware at freifunk.net
> Abonnement abbestellen? -> https://freifunk.net/mailman/listinfo/wlanware
>
> Weitere Infos zu den freifunk.net Mailinglisten und zur An- und Abmeldung
> unter http://freifunk.net/mailinglisten
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.freifunk.net/pipermail/wlanware-freifunk.net/attachments/20100415/9dad3055/attachment.html>