&

NetBSD-SoC: Implementation of RFC4380 (Teredo)

What is it?

Teredo, as detailed in RFC4830, is a last resort protocol to allow IPv4 client
to gain IPv6 connectivity. This protocol is designed to be used by host behind
NAT. It encapsulates IPv6 packet in UDP/IPv4 packet for NAT traversal. It also
allows host behind the same NAT to communicate directly through their Teredo
IPv6 address.

The goal of the project is add Teredo[RFC4380] support to NetBSD. The basis of
Teredo is to add IPv6 connectivity to hosts located behind NAT which is not
possible using 6to4.

The protocol is composed of three main part: a client, a server and a relay. The
client is a node which access the IPv4 internet and want to gain IPv6
connectivity. The server is a node used as a helper by the client to gain IPv6
connectivity. It is mostly used during the qualification procedure.  The relay
is a node the client will use to access a specific range in the IPv6 world.

The project will be a full rewrite, done in three parts: the client will be done
first, then the relay, and finally the server. Its aim is be to be integrated
into NetBSD (targetting stable integration for 6.0) as a kernel speudo-interface
based on the stf(4) pseudo-interface and a userland part.

Status

Right now ... still Work In Progress :) 

I'm currently studying the RFC and the technical notes from Microsoft to have a
globals understanding of the protocol and the way it works. The Next
step is to do live network capture to confirm the theoritical protocol.

While doing this I'll be discussiong with my mentor, David Young to design the
architecture of each part of the protocol. The server will certainly be in
userland only while the client and the relay will certainly be done both in
kernel and userland. Data-path belongs to the kernel, but control path belongs
to userland. Further details will be on the blog I started (URL posted here as
soon as interresting entry will be posted).

Timeline

_April 21, 2008: Community Bonding Period -- Students get to know mentors,
read documentation, get up to speed to begin working on their projects.
 May 26, 2008: Students begin coding for their GSoC projects; Google
begins issuing initial student payments
 July 7, 2008: Mentors and students can begin submitting mid-term
evaluations.
 July 14, 2008: Mid-term evaluation deadline; Google begins issuing
mid-term student payments provided passing student survey is on file.
 August 11, 2008: Suggested 'pencils down' date. Take a week to scrub
code, write tests, improve documentation, etc.
 August 18, 2008: Firm 'pencils down' date. Mentors, students and
organization administrators can begin submitting final evaluations to
Google.
 September 1, 2008: Final evaluation deadline; Google begins issuing
student and mentoring organization payments provided forms and evaluations are
on file.

Deliverables

Mandatory (must-have) components:

 For the client and the relay: the kernel pseudo-interface and userland
tools to configure them.
 For the server: the userland implementation based on 'rtadvd`.

Optional (would-be-nice) components:

 [...]

Documentation

Teredo Overview on Microsoft TechNet.
RFC4380 --- Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)

Technical Details

Arnaud Lacombe <lacombar@gmail.com> $Id: index.html,v 1.3 2008/04/28 22:28:57 lacombar Exp $