How Did HE Implement Its Teredo Relays?

[leewalk]

Not sure if this is the right forum, but I'm looking for any information around how HE implemented its Teredo relay service.  Does anyone know if this information is available, maybe in a whitepaper, etc?

Thanks! Lee

[kasperd]

I can think of two reasons for you to be asking that question. Either you are just about to deploy something similar yourself. Or you think there is something unusual about the HE deployment, which you'd like to know more about.

So far I haven't noticed anything unusual about the way HE has deployed Teredo relays. They are announcing 2001::/32 a bit broader than other Teredo relay deployments. But according to bgp.he.net, there are eight different ASes, which announce a route to 2001::/32.

If you are about to deploy Teredo relays yourself, I think Miredo is a good starting point. I wrote a few lines about how to setup the Miredo Teredo relay in another post earlier today.

The important questions to ask when deploying 6to4 or Teredo relays are. How do you provision the right capacity. And how widely do you announce the anycast prefixes. The answers to those questions have little to do with the specific service, one should apply roughly the same principles regardless of the service. The exact hardware and software needed may differ, and the prefixes to announce also differ.

As far as announcing the presence of your relay goes, there are different scopes you can announce it to

• Not announce it at all and only have traffic going to it because it is running on a router, which is already on the default route for some IPv6 hosts
• Set up static routes for the prefix because you are not running the relay directly on the default gateway, but rather on a node connected to it.
• Announce the prefix on your own network (being an AS or smaller network) using some internal routing protocol.
• Announce it to your downstreams using BGP. If your downstreams are already using you as a default route, this announcement may not be necessary.
• Announce it to your peers. But beware that you may be forwarding other people's traffic for free, potentially at a cost to yourself.
• Announce it to your upstreams. But I have no idea why you would want to do that, unless you had some economic incentive to push forward adoption of the protocol.

Running a Teredo relay always comes with some risk that you are going to be forwarding other people's traffic for free. If you were to announce 2001::/32 over BGP to your upstreams, it is almost guaranteed to happen. But even if you don't, there is still some risk.

When your Teredo relay receives an IPv6 packet, it hopefully came from somebody who is paying you to forward that IPv6 packet. And whether you send that IPv6 packet to your own Teredo relay or to somebody else's Teredo relay, you do have to forward the packet one way or another. But if you are using your own Teredo relay, you are attracting the return traffic as well. In the typical deployment scenario, that return traffic would be going through your network anyway, so attracting it by running your own Teredo relay is not a problem, it is a service to your customers.

However in the less typical scenario, it is possible that your customers will send you traffic to the Teredo prefix with a source address, which they are not announcing to you. They could be doing some traffic engineering and only be announcing the traffic through some other upstream. If you are not running your own Teredo relay, you will simply take the packets from your downstream and pass them on to your upstream, and the return traffic takes a different route, which never touches your network.

But in that case, if you run your own Teredo prefix, you will still forward the traffic from your customer. It may leave your network through a different path. But the return traffic is however guaranteed to come back through your Teredo relay, at which point you'll have to send it upstream, because the customer wasn't announcing that prefix to you. Instead of your customer paying you for the traffic, you end up paying your own upstream twice.

That scenario is unlikely, and there are multiple easy solutions, if it was to happen. So I wouldn't worry about that before it happens. You do however need to pay attention to the traffic patterns through your Teredo relays. And you need to monitor the reliability of them. You don't want to send the packets to a Teredo relay, which stopped working. If you aren't going to have proper monitoring of your relays, you shouldn't be deploying them in the first place.

I don't know more about the specifics of the HE deployments, than what can be learned from simply observing it from outside their network. I do however know quite a bit about the Teredo protocol, so if you have some more specific questions, I'd be happy to answer those.