Subject: Re: SoC: Adding teredo support to NetBSD
To: None <tech-net@netbsd.org>
From: Rui Paulo <rpaulo@fnop.net>
List: tech-net
Date: 05/03/2006 03:05:18
David Young <dyoung@pobox.com> writes:

> On Mon, May 01, 2006 at 06:47:46PM +0200, Arnaud Lacombe wrote:
>> Hi,
>> 
>> 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[1] support to NetBSD. After searching over
>> different site, it seems that an implementation already exist for
>> FreeBSD[2], 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[3] (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).
>
> Hi Arnaud,
>
> 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.

Besides all the kernel magic you will also need to create a userland
utility for controling the Teredo tunnel parameters, but I guess you
already know that.

-- 
  Rui Paulo			<rpaulo@{NetBSD{,-PT}.org,fnop.net}>