On 8 December 2012 23:10, Owen DeLong <owen@delong.com> wrote:
Frankly, the more I think about this, the less it's clear why someone like hetzner.de would actually want you to be using their native IPv6 support, instead of the one provided by HE.net through their free tunnelbroker.net service. HE has an open-peering policy (AFAIK);
Yes, HE has a one-word peering policy… "YES!"
However, that means that if hetzner peered IPv6 native with us, we would provide them every thing you get through tunnel broker still at no cost and without any limitations on bandwidth.
We don't artificially limit the bandwidth on tunnel broker, but, each tunnel broker server has a single network interface that it hairpins the v4/v6 traffic on and the bandwidth is what it is. I don't expect that will be an issue any time soon, but for planning purposes, people should understand that tunnel broker is a where-is-as-is service on a best effort basis with no SLA.
We do offer production grade tunnel services for a fee and people are welcome to contact me off-list for more information.
which basically means that tunnelbroker.net traffic is free for hetzner.de, whereas for native IPv6 traffic they might have to be paying for transit costs, depending on the destination. HE.net
We would really rather see such traffic come native across our peering links as much as possible. It allows us to provide a higher quality of service.
Are you suggesting that it's an official/semi-official policy to allow IPv6 peering clients to use HE.net as their default route for IPv6? (To no surprise, that seems to contradict http://he.net/peering.html.) Because, essentially, if you allow settlement-free peering with IPv4, and include tunnelbroker.net into it, then, indeed, a major hosting provider, by having a poor native IPv6 support, can indirectly save a few pennies by forcing some clients to instead use tunnelbroker.net and thus bypass having to pay for any kind of IPv6 transit on behalf of such clients, since any traffic requiring transit when native, will qualify for peering once tunnelled. I'm curious if anyone actually does now, or have attempted in the past, any such traffic laundering by design and on purpose. :-) I guess in the end, the scenario is more hypothetical and conspiracy-driven, since such attempts will either never be statistically significant enough to be noticed, or would be obvious enough to warrant some immediate manual intervention against the misbehaving peer. To HE's credit, I do recall hearing from someone that HE.net is nice enough to not restrict other network operators to choose whether they want to do settlement-free peering or transit, and is very flexible to allow doing both at the same time (unlike AT&T, which explicitly documents that they will never peer with anyone who buys transit from them). As an end user, I still don't understand how you can afford to carry all that traffic globally between the POPs for free; but I'm not complaining. :-) I guess it's a great way to be spending most of your marketing budget in house. :-) You obviously have to justify the need for native connectivity; but, honestly, for my situation (one value server in a given DC) I still see it as a marketing talk that native IPv6 is somehow better than tunnelled. As an end user, I honestly think I have more flexibility with the tunnelled service (and without any extra price). And, as people have pointed out, tunnelled service is usually as reliable as the underlying connection; meaning, in the hosting setting there should really be no problems with tunnels whatsoever. On the other hand, native IPv6 would be quite easy to get wrong; in fact, very easy to get wrong, as I have personally learnt.
probably wins, too; since being the place-to-go-for-IPv6 might make it easier for them to have more settlement-free peering with big transit providers such as AT&T (Bay-Area-wise, they still have IPv6 traffic going through their peering in Los Angeles).
Being a popular IPv6 peer and having so many tunnel broker users has been a great success story for us, yes. However, in terms of how this affects our standing for peering, I think that the effect is the same regardless of whether we are passing the traffic from/to a peering link or a tunnel broker.
Yes; but I was referring to the free transit that you effectively offer through the tunnel broker; such traffic would otherwise go to AT&T through a transit provider, which may or may not be HE. C.