Show 43 – Microsoft Teredo is Crap

A shorter show this week as Greg gets ready to go to Interop in Las Vegas next week. We look at recent events and talk generally about network with Tom Hollingsworth, Brandon Carroll and Greg Ferro.

Amazon AWS outage.

People need to start realizing that just parking your infrastructure in the cloud doesn’t make it redundant. There is additional planning and design work. Network engineers and architects don’t just make this stuff up, as the people who undoubtedly lost their jobs because of this fiasco are now learning.

According to this post by Jeremy Gaddis, it would appear that a wayward engineer was attempting to upgrade IOS on a device and jumped the gun on downing another section of the network, triggering a waterfall of failure. A cautionary reminder that you can never anticipate the human element:

Sony Playstation Network

Playstation Network goes down and gets pwned. If you thought AWS was bad, Sony managed to exposed 77 million people in one shot. The whole backbone of their online distribution network went down and they couldn’t do anything about it. To add insult to injury, it appears customer data was readily available from the hack. As of today, there are approximately 2.2 million credit cards up for sale, all with the critical CVV codes. Compartmentalization, anyone?

IPv6 / IPv4 NAT – Hang our Heads in Shame

RFC 6146 – Stateful NAT64 and RFC 6147 – DNS64. I think there’s a lot of discussion around these two. It appears that someone is of the opinion that the transition from IPv4 to IPv6 won’t happen without a little hand holding. I think these people are the same ones that still take chewable vitamins. Yes, it’s a bitter pill but you had best get used to swallowing it.

IPv6 and Microsoft Teredo

  • Host to Host, Host to Router, Router to Router.
  • Teredo is Host to Host, relies on public gateways of someone elses/anyones servers
  • not HA
  • not reliable

Teredo is described in a Microsoft technical note –

Teredo uses what has become a relatively conventional approach to NAT traversal, using a simplified version of the STUN active probing approach to determine the type of NAT, and uses concepts of “clients”, “servers” and “relays”

The choice between the terms “transition” versus “coexistence” has engendered long philosophical debate. “Transition” carries the sense that one is going somewhere, while “coexistence” seems more like one is sitting somewhere. Historically with the IETF, “transition” has been the term of choice [RFC4213] [RFC5211], and the tools for interoperability have been called “transition mechanisms”. There is some perception or conventional wisdom that adoption of IPv6 is being impeded by the deficiency of tools to facilitate interoperability of nodes or networks that are constrained (in some way, fully or partially) from full operation in one of the address families. In addition, it is apparent that transition will involve a period of coexistence; the only real question is how long that will last.

Thus, coexistence is an integral part of the transition plan, not in conflict with it, but there will be a balancing act. It starts out being a way for early IPv6 adopters to easily exploit the bigger IPv4 Internet, and ends up being a way for late/never adopters to hang on with IPv4 (at their own expense, with minimal impact or visibility to the Internet). One way to look at solutions is that cost incentives (both monetary cost and the operational overhead for the end user) should encourage IPv6 and discourage IPv4. That way natural market forces will keep the transition moving — especially as the legacy IPv4-only stuff ages out of use. The end goal should not be to eliminate IPv4 by fiat, but rather render it redundant through ubiquitous IPv6 deployment. IPv4 may never go away completely, but rational plans should move the costs of maintaining IPv4 to those who insist on using it after wide adoption of IPv6.

Hosts / Guests

Tom Hollingsworth | Twitter: @NetworkingNerd

Brandon Carroll | Twitter: @brandoncarroll

and last, and the very least:

Greg Ferro| Twitter @etherealmind


Follow the Packet Pushers on Twitter (@packetpushers | Greg @etherealmind | Tom Hollingsworth), and send your queries & comments about the show to [email protected].  We want to hear from you!

Subscribe in iTunes and RSS

You can subscribe to Packet Pushers in iTunes by clicking on the logo here.

Media Player and MP3 Download

You can subscribe to the RSS feed or head over to the Packet Pushers website to download the MP3 file directly from the blog post for that episode.


Greg Ferro
Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count. He is a host on the Packet Pushers Podcast, blogger at and on Twitter @etherealmind and Google Plus.
Greg Ferro
Greg Ferro
Greg Ferro
Greg Ferro

Latest posts by Greg Ferro (see all)

  • @whfsdude

    I'm not sure I agree with your comments about NAT64/DNS64. Sure if you have an existing infrastructure it makes sense to stay dual stack rather than use NAT64/DNS64.

    For infrastructure it probably does not make sense to support IPv4 except at the edge (which is what NAT64/DNS64 allows).

    Another example is mobile operators. T-Mobile USA is using NAT64/DNS64 for their IPv6 only network. Dual stacking would require a phone to maintain two data sessions IPv4 PDP + IPv6 PDP.

    In both cases having no IPv4 access isn't feasible. Maintaining an IPv4 infrastructure all the way to the end user doesn't make sense.

  • Michael

    I too can see a need for NAT64.

    E.g. I know of a US carrier who has a shiny new content system that is IPV6 enabled only (doing the right thing). Their customers (millions of them) have IPv4 cable boxes only.

    Using NAT64 they can bridge from their customers to the new system and still deliver content, without having to replace all the cable boxes.

    Over time the cables boxes can be replaced but I would think NAT64 will be needed for about another 5 years. Then they should self explored.