RE: [74attendees] The great emphasis on IPv6 - a positive look

[Christian Huitema <huitema@windows.microsoft.com>]

> From: Jeroen Massar, Thursday, March 26, 2009 8:42 AM

> Indeed. Though there are lots of users also happily using anycasted-
> 6to4. The reason being that the services they are using from their 6to4
> address are located at ISPs that are either clueful and pro-active in
> fixing issues or that they are located closely to the relay which is
> their anycast node. In that case one basically has an automatically
> set-up proto-41 tunnel directly to the service you are using, and then
> things work quite smoothly.
>
> The moment though that other networks, who did setup 6to4 but who don't
> really check their service get involved, then things start to break
> miraculously. And as a content-provider on native IPv6 there is not
> much to do about those kind of networks, but they do affect
> connectivity to the enduser.

Jeroen gives a good description of the problem. Anycast is convenient, but unpredictable. In theory, anycast allows 6to4 nodes to always use the relay closest to them, which should provide for a good service. In practice, that works well when the relay is actually close, e.g. managed by the local provider, but not so well when the relay is remote and the route to it obtained through several BGP hops.

There are several possible mitigations to this issue.

An obvious mitigation is, "deploy more relays." The hope when writing RFC 3068 was that many providers would deploy many relays for local use, and thus users would be mostly be using local relays. When there are many relays, the reliance on BGP is minimal, and the service becomes much more reliable. Of course, I realize that if the IETF recommend deploying more relays, providers may or may not follow the recommendation. The cost of deploying relays is not very high, but the benefits are also not very high, essentially a slight reduction in the amount of tunneled traffic through the providers interconnections and probably also a slight reduction in the number of support calls. Even so, clear messages from the IETF would certainly help.

Another mitigation is to "avoid 6to4 when it does not work" -- and presumably use another technology in these cases. This is the approach documented in Nathan Ward's draft. It makes a lot of sense from an operational point of view, but it requires that the end systems implement test procedures. This will probably happen over time. On the other hand, if we consider updating end system, we can also consider changes to end system that increase the reliability of 6to4.

Since RFC 3068 was published, there have been several suggestions for improvements. One possibility is to explicitly provision a 6to4 gateway in the 6to4 node. This is obviously a tradeoff, as sending traffic to a remote gateway may be less efficient than sending traffic to the closest anycast gateway -- but it is also much more predictable. An interesting possibility would be to combine this provisioning with the test procedure, maybe testing several gateways and selecting the one that works best.

-- Christian Huitema