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
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.
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).
- _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
- 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
- September 1, 2008: Final evaluation deadline; Google begins issuing
student and mentoring organization payments provided forms and evaluations are
Mandatory (must-have) components:
Optional (would-be-nice) 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`.
- Teredo Overview on Microsoft TechNet.
- RFC4380 --- Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
| Arnaud Lacombe <email@example.com> |
| $Id: index.html,v 1.3 2008/04/28 22:28:57 lacombar Exp $ |