Subject: Re: SoC: Teredo IPv6 [was: Re: Google summer of code]
To: Hubert Feyrer <hubert@feyrer.de>
From: David Young <dyoung@pobox.com>
List: tech-net
Date: 06/05/2005 11:11:44
On Sat, Jun 04, 2005 at 01:41:30PM +0200, Hubert Feyrer wrote:
> 
> On Sat, 4 Jun 2005, Dima Yakobchuk wrote:
> >http://www.netbsd.org/contrib/projects.html#teredo
> >
> >Hello!
> >May I try to work on this project?
> 
> Why not. ;) What ideas do you have?
> 
> Questions from the top of my head, after reading the draft:
> 
> How will the project integrate into NetBSD? will it be a seperate 
> (userland) server process, or part of the kernel like stf(4)? How will 
> configuration of a client/server/relay work? How to specify the various 
> ports? What kind of documentation do you suggest - manpage, maybe a few 
> words for the NetBSD Guide's networking section, which already describes 
> 6to4[1]?

I will chime in here, since I proposed the Teredo project.

I think a stf(4)-like pseudo-interface is appropriate for Teredo.
The server/relay functions may require a very simple userland daemon; it
may be possible to re-use some daemon we already have, such as rtadvd(8).

For configuration, some combination of ifconfig/"teredoctl" is suitable.

> Oh, and: are there any implementations already existing under a BSD 
> license, e.g. from KAME, FreeBSD, OpenBSD or DragonflyBSD that may be 
> used?

Under BSD license, there is a Netgraph implementation for FreeBSD,
ng_teredo.  That code may be a good starting point.  I strongly prefer
that Teredo for NetBSD does not depend on Netgraph.

I also strongly prefer that the tunneling encapsulation/decapsulation
occurs in the kernel, instead of in a userland process (e.g., GPL-licensed
Miredo), for performance reasons.  I am open to demonstrations that the
overhead of a userland implementation is negligible.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933