This is a collection of questions which people asked me during the yet short life of this still young project.
If you need further help or have further, you can ask me at :
Miredo is available and usable right now. You can track new releases through Freshmeat.
At the moment, it is distributed under the terms of the GNU General Public License. I understand that this might not suit everyone’s need. If you are interested in obtaining Miredo under different licensing conditions, please contact me so we can discuss the issue and hopefully meet an agreement.
The name is not particularly interesting nor meaningful :
Yes. Miredo version 0.2.0 and higher include client support.
Teredo relays are not supposed to have a global Teredo IPv6 address. Because they don’t perform Teredo qualification and maintenance, they can’t reliably determine a valid Teredo address anyway.
Teredo relays MUST have a non-Teredo global IPv6 address, otherwise, there are not electible as relay. In other words, Teredo relays must have an IPv6 connectivity besides their Teredo tunnel, such as a native IPv6 attachment, a 6to4 pseudo-tunnel or a point-to-point IPv6 tunnel.
To use the Teredo tunnel for IPv6 connectivity, you must configure miredo as a Teredo client.
Currently, Miredo cannot serve as a Teredo client behind a symmetric NAT. However, in preparation for this to eventually become possible, Miredo can accept other clients behind a symmetric NAT (as of version 0.9.8). It's a matter of time before Miredo supports symmetric NATs to a larger extent (however in any case, support for symmetric NATs will never be equal to support for other NATs due to limitations of symmetric NATs).
Microsoft has written extensions to its Teredo client so that it can contact other Teredo peers, so long as not both of them are each behind a symmetric NAT. At the time of writing, implementation details of this extension are yet to be disclosed. If you have access to these informations or feel capable of helping reverse engineer them, please contact miredo dash devel at remlab dot net. Note that if you are in contract with Microsoft for protocol licensing, you are most likely not allowed to do that, as the Microsoft license might be incompatible with the licensing terms of Miredo.
The NICI-Teredo authors have written a paper entitled Enhancing Teredo IPv6 Tunneling to Traverse the Symmetric NAT. My understanding is that it does not fully address the problem, and propose a fairly insecure solution to the problem.
The primary development and test platform is GNU/Linux, but it also supports most common open-source BSD kernels and derivatives (Darwin).
Please refer to the README file section “System requirements” for more up-to-date and platform-specific support informations.
Any system capable of running of the supported operating systems should be sufficient. Latest stress tests (with version 0.9.4) show that Miredo can process one gigabit/s with a 1.5 GHz PC. Memory should not be an issue for a limited number of simultaneous Teredo peers.
Included stress testing program seems to indicate that Miredo can easily handle one hundred thousands simultaneous distinct peers, given enough RAM (about 300 Mb for 5,000,000 peers). To achieve these scalability figures, Miredo can leverage Judy dynamic arrays.
Miredo is known to run fine on cheap hardware such as Linksys WRT54G wireless-enabled router (based on a 200 MHz MIPS processor) running OpenWrt. µClibc is supported.
Make sure you have Service Pack 2, and update the TCP/IPv6 network stack from Windows Update if not already done. You need to reboot after updating.
It should work out-of-the-box with Vista releases. Do not use beta versions.
The Teredo relay discovery is a procedure through which Teredo clients can determine which Teredo relay they must use in order to communicate with a given non-Teredo host on the IPv6 Internet.
When a client wants to contact a "new" IPv6 node, it crafts an IPv6 echo request toward that node IPv6 address and sends to its Teredo server, encapsulated over UDP/IPv4. The Teredo server decapsulate and forwards the packet to native IPv6 (it only do so for echo requests). At some point, the echo request should reach the node.
The node should consequently send an IPv6 echo reply with the client’s Teredo address as destination. That packet will eventually reach the "nearest" Teredo relay as far as IPv6 routing is concerned.
The Teredo relay then encapsulates and forwards the echo reply to the Teredo client. At that point, the Teredo client learns which Teredo relay should be used to reach the IPv6 node.
Further IPv6 packets will be encapsulated to the relay which will in turn, forward to the node, and the way back.
First, there’s a short explanation of the Teredo tunneling protocol on Wikipedia. Then, there’s the Teredo overview from Microsoft. And finally, there’s the full Internet standard specification (RFC 4380).