Hi,
Does any body maintain a list of Teredo servers and Teredo relays?
Thanks!
Kind regards,
A list of public Teredo servers might be useful. But a list of public relays - not so much.
If you google around you'll eventually stumble across the following public servers:
teredo.ipv6.microsoft.com
teredo.remlab.net
teredo2.remlab.net
debian-miredo.progsoc.org
teredo.ginzado.ne.jp
teredo.iks-jena.de
The first is the default for Windows. The second is the initial default for most Miredo installs. The fourth is supposedly the default for the Debian Miredo package.
You can get an idea of where some public relays might be at:
http://www.bgpmon.net/teredo.php
But there may be a bunch of others not listed. The relay used varies on a per-connection basis. It'll generally be the closest relay to the non-teredo host.
Antonio Querubin
808-545-5282 x3003
e-mail/xmpp: tony@lava.net
I would be careful actually using teredo, as some of them (eg: Microsoft) have swaths of native IPv6 networks that are unreachable.
I'm hoping they will correct some of the problems with it, but it makes IPv6 harder to use for some people as the Microsoft one does not appear to be well supported/connected. I'm not sure if there is an effort under way on Microsofts behalf to correct this, but I hope so.
- Jared
Even Micr0$0ft refers to Teredo as "The absolute last resort for IPv6 connectivity".
Owen
Yeah, but "they'll take it over IPv4 if they can get it" 
Jeff
I would be careful actually using teredo, as some of them (eg: Microsoft) have swaths of native IPv6 networks that are unreachable.
While I would agree in principle, in practice we have little control over what customers use.
I'm hoping they will correct some of the problems with it, but it makes IPv6 harder to use for some people as the Microsoft one does not appear to be well supported/connected. I'm not sure if there is an effort under way on Microsofts behalf to correct this, but I hope so.
This could be a host or relay-specific problem which may not be under Microsoft control at all. All the more reason for ISPs to run their own local Teredo relay.
Antonio Querubin
808-545-5282 x3003
e-mail/xmpp: tony@lava.net
I would be careful actually using teredo, as some of them (eg:
Microsoft) have swaths of native IPv6 networks that are unreachable.While I would agree in principle, in practice we have little control
over what customers use.
I don't agree, if you are an accessproivder I think it would there is
one very important thing you can do or if you not yet able to do the
next best thing:
1. provide native IPv6 to customers
2. setup your own tunnelservice or if you think people won't use your
tunnelservice, setup relays
The more IPv6 the accessprovider provides the bettter the results.
Native or the closer the transition point the better.
Atleast that is the theory. 
What makes you think we're not already doing all of the above? 
As I said, the problem is an ISP doesn't have control over what their customers choos to purchase and run in their own network. An ISP can setup a fully dual-stack network everywhere in their own infrastructure but if the customer chooses to use only NATed IPv4 (for whatever reason) on their own equipment, it would be a foolish ISP that insists the customer must change out all their equipment. Users will migrate to IPv6 in their own time and their own way. But if they happen to be behind some $50 NATed IPv4 router, it behooves the ISP to accomodate those out-of-the-box-running-Teredo devices as best as possible instead of relying on somebody elses Teredo relay.
Antonio Querubin
808-545-5282 x3003
e-mail/xmpp: tony@lava.net
While I would agree in principle, in practice we have little control
over what customers use.
You won't have a good time at Disneyland if you ride Space Mountain in the unsupported configuration of 'not belted in'. An ISP has no control over what I set my MTU to, and they won't support me if I change it.
Users will migrate to IPv6 in their own time and their own way.
An object at rest tends to remain at rest until outside force is applied.
The lifetime of many of the IPv4 SOHO NAT devices out there exceeds both the exhaustion timer and the most optimistic depletion estimates for the RIRs. For most people, generally only a failed NAT device comprises the outside force required to buy new equipment. Most users won't actively migrate to IPv6 in their own time and their own way; the ISP needs to take an active stance that starts with "we're only supporting IPv4/6 devices starting $date", and ends with "we're terminating all legacy IPv4 support on Jan 1, 2350 at 1:30PM.'
Nathan
2350 is about an accurate date considering how quickly migration is happening in most places