[lwip-devel] LWIP and LWIPv6 projects

[Renzo Davoli]

Dear LWIP designers and developers,

this is just a "call for brainstorming" message.
The meaning of this message is to discuss if two projects (LWIP and LWIPv6)
can cooperate, to which extent and which can be the common goals.
Each one of the project has pros and cons, the focus is different but we have
a lot of common ideas and code.

A good meeting opportunity is the devroom named "new challenges in
virtualization" at FOSDEM 2011 (Bruxelles, February 5-6 2011).
I invite you to join the devroom and propose talks.
The devroom wiki is here:

http://nciv2011.v2.cs.unibo.it

Maybe there can be a synergy to share ideas and code: both projects
could benefit from a cooperation. At the end we could decide to merge some code,
the entire projects, or to start a new joint development... or nothing
at all.
Any result starts with a proposal, no proposal implies no results.

                renzo

--------------------------------
The VirtualSquare Lab is a container of research projects about
virtuality.

We have developed VDE, the virtual distributed ethernet, and we are working
on the idea of partial virtual machine: a new kind of VM that does not boot
an OS (they are not architecture/system machine) and support several
processes (out of the definition of process/application VM).
View-OS implementations (umview/kmview) are virtual machine where the
user can virtualize just what he/she needs, e.g. a subtree of the
file system, devices, networking...

For networking virtualization we needed a tcpip stack as a library
and then back in 2004 we started a fork of your project named LWIPv6.

LWIPv6 has several new features including:
- IPv6: the stack has one "engine" for IPv6 packets, it manages also
IPv4 packets by creating a "pseudo-header" just for the packet management
(v4 a.b.c.d addresses are converted into IPv4 mapped ::ffff:a.b.c.d)
- definition of several addresses per interface (lwip_{add,del}_addr)
- management of prefix-based packet routing (lwip_{add,del}_route)
- IPv6 autoconfiguration
- multi stack: the library is able to manage several stacks at the
same time
- VDE interfaces
- (socket api) AF_PACKET for raw packets and AF_NETLINK for configuration 
- (socket api) lwip_{pselect, poll, ppoll} to manage event driven 
programs using both lwip connections and non-lwip device/sockets
- a very clean interface:
http://wiki.virtualsquare.org/index.php/LWIPv6_programming_guide

there are also other features in our experimental version:
- packet filtering
- NAT (v4 and v6)
- slirpV6
- radvd (autoconfiguration server)

we are planning to add (some day):
- management of OOB traffic
- icmp notifications of errors as ancillary messages for UDP/TCP

LWIP and LWIPv6 have two different domains of application: LWIP is
(also? primarily?) for embedded systems, then the main focus is to be
"light weight". Our focus is to the "enough" light to stay in a library,
but we need a number of features that are useless on embedded systems.

LWIPv6 was created because we needed a stack for our partial virtual
machines, I understand that some feature are partially implemented and
others could be implemented in a better way.
On the other hand, it works, it is quite stable, it is distributed
in Debian and Ubuntu afaik, maybe in other distros.
People using Debian can create applications having an embedded IPv4/IPv6
stack (like our vdetelweb, the telnet and web configuration interface
for our VDE switches).

I think, and I have read in many mail threads, that your project LWIP need
a more complete IPv6 support. On the other hand it is hard for us to
port new features and bugfixes from LWIP to LWIPv6.
A tcpip-stack-in-a-library has many uses.
I think that a more complete implementation of LWIPv6 can become standard
for partial virtual machines, for applications with embedded stacks and
maybe for microkernels (or millikernels, another proposal of ours that
I'll describe to you if you are interested).
The two communites (I know your one is much larger than ours) could benefit
from features/bug report of the other.
e.g. it is uncommon to run a radv server on an embedded system, but if the
code is just under a #if configuration constant, your user could have a stack
which is a bit heavier but includes just the feature he/she needs.

Happy hacking to all, and I am really looking forward to hearing your ideas.