List of Teredo servers and teredo relays
Hi, Does any body maintain a list of Teredo servers and Teredo relays? Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
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
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 On Sep 10, 2010, at 7:11 PM, Antonio Querubin wrote:
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
Even Micr0$0ft refers to Teredo as "The absolute last resort for IPv6 connectivity". Owen On Sep 11, 2010, at 9:28 AM, Jared Mauch wrote:
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
On Sep 10, 2010, at 7:11 PM, Antonio Querubin wrote:
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 Sat, 11 Sep 2010, Jared Mauch wrote:
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
On 09/12/2010 08:42 AM, Antonio Querubin wrote:
On Sat, 11 Sep 2010, Jared Mauch wrote:
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. :-)
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
On Sun, 12 Sep 2010, Leen Besselink wrote:
On 09/12/2010 08:42 AM, Antonio Querubin wrote:
On Sat, 11 Sep 2010, Jared Mauch wrote:
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 :) -----Original Message----- From: Nathan Eisenberg <nathan@atlasnetworks.us> Date: Sun, 12 Sep 2010 20:54:49 To: nanog@nanog.org<nanog@nanog.org> Subject: RE: List of Teredo servers and teredo relays
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
participants (8)
-
Antonio Querubin -
Fernando Gont -
Jared Mauch -
Jeff Kell -
khatfield＠socllc.net -
Leen Besselink -
Nathan Eisenberg -
Owen DeLong