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

[marco bonola]

Hi,

>Yes. There should be only one interface. But I do not understand what
>you mean by forwarding rule? I would like to configure only
>destination IPs and ports of all peers I would like to communicate
>with and interface itself should handle to which peer it should send a
>packet. Like switch is doing.

I think we are saying the same thing. In fact, with "forwarding rule" I mean
a rule
that binds the packet to be encapsulated (i.e.: the inner packet) to the
tunnel we want
to use (i.e.: the proper encapsulation header).
This can be done in different ways. In my proposal I considered
"per-application"
filtering rules. For example:

if inner packet has (IP.src = 1.2.3.4, IP.dst = 1.2.3.5, IP.proto=tcp,
TCP.sport= 3000, TCP.dport=40000)
use tunnel X, where tunnel X has:

IP.src = 160.80.103.147, IP.dst = 90.0.0.1, UDP.sport = 20000, UDP.dport =
30000

Now, I'm doing this because I considered a more complex scenario. If we want
to consider only the destination IP address (of the inner packet), the
"Forwarding Table"
will be simpler. For example:

if IP.dst = 1.2.3.5 ==>> TunnelX
if IP.dst = 1.2.3.6 ==>> TunnelY

and so on...


>You will define new netlink protocol? Special for this virtual interface?

Yes, new protocol over a generic netlink socket (so we don't need a new
family).

>In which sense? Virtual interface should be fully configurable with ip
>and ifconfig from the point of view of virtualized interface. Or do
>you think that also internal configuration (links to peers and such)
>would be configured with those tools?
The basic configuration (IP address, netmask, MTU, ecc) is possible with ip
and ifconfig. As you said, the "internal configuration" needs a new tool.
Anyway,  if we want, we can extend "ip" to support this.

Marco

On Thu, Apr 15, 2010 at 10:59 AM, Mitar <mmitar at gmail.com> wrote:

> Hi!
>
> On Thu, Apr 15, 2010 at 10:37 AM, marco bonola <marco.bonola at gmail.com>
> wrote:
> > "One or more virtual interfaces can be export to user-space
>
> From that I thought you will be doing only point-to-point connections
> and that you will have to make multiple virtual interfaces for each.
>
> > What I mean with "Dynamic virtual interface" is a iface for which I can
> > dinamically configure a set of different encapsulating/forwarding rules
> in a table.
> > In this way if we have 50 peers we are communicating with (and thus 50
> > different IP/UDP tunnels), we don't need 50 virtual ifaces.
>
> Yes. There should be only one interface. But I do not understand what
> you mean by forwarding rule? I would like to configure only
> destination IPs and ports of all peers I would like to communicate
> with and interface itself should handle to which peer it should send a
> packet. Like switch is doing.
>
> > will be provided by a generic NETLINK socket.
>
> You will define new netlink protocol? Special for this virtual interface?
>
> > Moreover, integration with standard configuration tools (e.g: ip,
> ifconfig)
> > is possible."
>
> In which sense? Virtual interface should be fully configurable with ip
> and ifconfig from the point of view of virtualized interface. Or do
> you think that also internal configuration (links to peers and such)
> would be configured with those tools?
>
> > Does this support your idea?
>
> It seems so. This is really great! Just some scrambling added and it is
> perfect.
>
> (I am sorry if I am using bad terminology.)
>
>
> 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/cec13f1f/attachment.html>