Re: List of Teredo servers and teredo relays
I may be missing the point here completely but to me Teredo just seems like a glorified hack/workaround for a bigger problem. Isn't is better (yes less cost-effective) to just upgrade equipment? I really don't see the advantage here. Maybe someone can explain away my ignorance to the concept? ------Original Message------ From: Antonio Querubin To: Fernando Gont Cc: NANOG Subject: Re: List of Teredo servers and teredo relays Sent: Sep 10, 2010 6:11 PM On Fri, 10 Sep 2010, Fernando Gont wrote:
Does any body maintain a list of Teredo servers and Teredo relays?
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
On 9/11/2010 3:29 PM, khatfield@socllc.net wrote:
I may be missing the point here completely but to me Teredo just seems like a glorified hack/workaround for a bigger problem. Isn't is better (yes less cost-effective) to just upgrade equipment?
I really don't see the advantage here. Maybe someone can explain away my ignorance to the concept?
Teredo is a "last-ditch" solution, but unfortunately in the Microsoft world, and acceptable and preferable solution over IPv4. Pure speculation, but the IPv6 efforts of many (looking at current MacOS, Windows, and a growing segment of PDAs/phones) are making tremendous effort to obtain "some" form of IPv6 connectivity. This makes sense if there were (a) only IPv6 connectivity at the client endpoint, or (b) only IPv6 connectivity at the service endpoint. That would insure things would work if either case were true. What is currently "breaking" things is the preference of IPv6 over IPv4. If you're running a default Win2K8 active directory, it's publishing all of it's goodies for login in IPv6 form complete with AAAA address records. If your network isn't end-to-end IPv6 compliant, but some Win7 client across the hall (on another subnet) has found *any* IPv6 connectivity (6to4, Teredo, doesn't matter how good/bad/ugly/slow), it is going to try to communicate with the domain controller over that IPv6 connection. I have seen this in action, and stacks of trouble tickets of slow / intermittent / no connectivity with the domain. As it currently stands, if you're not 100% end-to-end IPv6 ready with compliant transport, these "preferences" break or cripple things. Of course, this all may be by IPv6 design (make it so horribly painful not to accomodate to push you to provide better alternatives) :-) Jeff
On 2010-09-11 22:22, Jeff Kell wrote: [..]
What is currently "breaking" things is the preference of IPv6 over IPv4. If you're running a default Win2K8 active directory, it's publishing all of it's goodies for login in IPv6 form complete with AAAA address records. If your network isn't end-to-end IPv6 compliant, but some Win7 client across the hall (on another subnet) has found *any* IPv6 connectivity (6to4, Teredo, doesn't matter how good/bad/ugly/slow), it is going to try to communicate with the domain controller over that IPv6 connection. I have seen this in action, and stacks of trouble tickets of slow / intermittent / no connectivity with the domain.
It would be nice that if you make these kind of statements that you would have actually read up on things which are active already for a long long time. Please try google and read up on RFC 3484. Indeed, Teredo is prioritized AFTER native IPv4. Greets, Jeroen
participants (3)
-
Jeff Kell -
Jeroen Massar -
khatfield＠socllc.net