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 :
The name is not particularly interesting nor meaningful :
Teredo relays are not supposed to have a global Teredo IPv6 address. Because they do not perform Teredo qualification and maintenance, a valid Teredo address cannot be defined.
Teredo relays MUST have a non-Teredo global IPv6 address, otherwise, there are not eligible as relay. In other words, Teredo relays must have an IPv6 connectivity besides their Teredo tunnel, typically native IPv6 but a 6to4 pseudo-tunnel or a point-to-point IPv6 tunnel is also possible.
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). In any case, support for symmetric NATs will never be as good as support for other NATs due to limitations of symmetric NATs.
Any system capable of running of the supported operating systems should be sufficient. Stress tests (with version 0.9.4) showed that Miredo can process one gigabit/s with a single 1.5 GHz x86-32 processor core.
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).
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.
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. For precise details, please refer to the IETF RFC 4380 specification and two official extensions, RFC 5991 and RFC 6081.