Re: List of Teredo servers and teredo relays
Thanks for the explanation. And Owen: thanks, I just thought most networks/facilities (colo/private) should be close to ipv6 now days. At least capable, maybe not configured. I think I was just making an assumption so thanks for the info. ------Original Message------ From: Jeff Kell To: Kevin Hatfield Cc: NANOG Subject: Re: List of Teredo servers and teredo relays Sent: Sep 11, 2010 3:22 PM 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 Sep 11, 2010, at 3:18 PM, khatfield@socllc.net wrote:
Thanks for the explanation.
And Owen: thanks, I just thought most networks/facilities (colo/private) should be close to ipv6 now days. At least capable, maybe not configured.
Would that it were so. The ones I work on all are.
I think I was just making an assumption so thanks for the info.
Any time. Life will get more interesting in February. Life will get very interesting somewhere around August of next year. Owen
------Original Message------ From: Jeff Kell To: Kevin Hatfield Cc: NANOG Subject: Re: List of Teredo servers and teredo relays Sent: Sep 11, 2010 3:22 PM
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
participants (2)
-
khatfield＠socllc.net -
Owen DeLong