Subject: Re: SoC: Adding teredo support to NetBSD
To: None <tech-net@NetBSD.org>
From: David Young <firstname.lastname@example.org>
Date: 05/02/2006 20:28:13
On Mon, May 01, 2006 at 06:47:46PM +0200, Arnaud Lacombe wrote:
> After searching on the NetBSD project's page I find two project which
> interested me. The first one was adding mDNS support to NetBSD, the
> second was adding teredo support. After few research, I find that work
> left on mDNS was not really clear (it was a part of last year SoC
> (zeroconf), the responderd works, the nss module almost works too,
> nothing at first sight would justify nearly three month of work).
> So I chose my second choice: adding teredo support to NetBSD.
> About the project
> The main goal is add teredo support to NetBSD. After searching over
> different site, it seems that an implementation already exist for
> FreeBSD, this implementation is a kernel module using the netgraph
> framework, but it is quite broken by now (does not compile on FreeBSD
> 6.0, maybe also not on 5.x due to API change) [maybe M. Kabassanov could
> confirm, as he is one of the autors of this module].
> An implementation also exists for Linux (which works also on FreeBSD
> and NetBSD), after looking at sources, it seems to be a userland
> implementation. It is released under the GPL.
> The project will be a complete rewrite under G^HBSD license, done in
> three parts: the server will be done first (as it is the central
> component of teredo), then the relay, and finaly the client. The two
> first part will be mandatory, maybe not the last part (depending on
> comments, mentors opinion ...). It's aim will be to be integrated into
> NetBSD (4.99.x at least, as 4.0 release is not so far).
You should program the client, first, both because it is most useful
to the greatest number of potential users, and because servers already
exist for you to test with.
> I think that the best choice for portability is to make a userland
> program, which won't be dependant of specific OS' API. I guess it will
> use socket & related framework.
I strongly prefer an in-kernel implementation, because I believe it
will perform better on low-end machines (486-class, like the Soekris
net45xx) than a userland implementation. I have something in mind like
the pseudo-device, stf(4).
I agree with Michael Richardson that the Teredo pseudo-device and the
stf(4) can probably share a lot of code.
David Young OJC Technologies
email@example.com Urbana, IL * (217) 278-3933