Why do some providers require IPv6 /64 PA space to have public whois?

Tue Dec 11 02:53:42 UTC 2012

On 8 December 2012 23:10, Owen DeLong <owen at 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.