Re: [lwip-devel] RE: IPv6 development status

[address@hidden]

This is a really interesting topic and I would very much like to 
actively contribute code here. However, I'm afraid I won't find the time 
for that for some months... Nonetheless, I'd very much appreciate it if 
we could discuss v4/v6 integration on this list to make sure anyone's 
work on this is easy to integrate into the current (v4-) source.

Ivan Delamer wrote:
> Bill,
>
> Mapping IPv6 addresses to IPv4 addresses is an interesting v6 transition
> approach, however this suggests that LwIP should be a native IPv6 stack
> with legacy support for IPv4. I don't think this is what most users would
> like, so I think we need to find a different approach to coexistence.
I would have thought it's best to define a set of functions common to 
IPv4/v6, let both versions implement these functions and (if both 
versions are enabled), add a "decision" layer (that is called instead of 
the real v4/v6 fuctions) that decides which version to call for each stack.

I'd suggest to change the prefix ip_* to ipv4_/ipv6_* and define it to 
the correct implementation through a configuration option.

That way, there would be no runtime overhead when compiling a 
single-version stack. The runtime overhead for a dual-version stack 
would be minimal.
> Another interesting feature of IPv6 is that an interface can (and usually
> does) have multiple addresses.
Well, that's already the case for IPv4 with AutoIP, and is normally 
supported by many operating systems, too. Up to now, lwIP did not 
support it, unfortunately. However, for a dual-version stack, I guess 
this is a must-have.

I stumbled over the fact that debian seems to ship lwIPv6. Maybe the 
idea to start backporting their efforst is not so bad after all?

In fact, just a month ago, Renzo Davoli (one of the lwIPv6 
developers/maintainers, supposedly) sent an email with the proposal to 
join efforts between the two projects. I'll forware the mail below.

Simon



Renzo Davoli wrote:

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.
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.