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

[Owen DeLong <owen () delong com>]

On Dec 10, 2012, at 6:53 PM, Constantine A. Murenin <mureninc () gmail com> wrote:

> 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?

Let me be clear. We offer free IPv6 transit on all IPv6 peering sessions.

We do that by advertising all known IPv6 prefixes to you. We fully expect
you will not point default at us. However, there is no need to do so as
we will, by default and unless you ask otherwise, advertise all IPv6
prefixes known to you.

> (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.

I don't know of anyone doing so, but I really can't see a reason why
they would. We'll happily accept all traffic to all valid IPv6
destinations known in our routing tables over any peering connection.

> 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).

Correct. We will always localpref the paid connection, but we are
happy to simultaneously peer and sell bandwidth to our customers.

> 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. :-)

Well, I can't give out all of the details, but, what I can say is that
there is monetary value in being well liked by your customers and your
potential customers.

> 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.

There are MTU and performance penalties. They may be small in your
specific situation. They may not be so small on the return path in
some cases. If tunnels are working well for you, then who cares
what anyone else has to say about it. Use a tunnel. However, there's
no cost difference between native and tunneled if you are present
at an HE connected exchange point, so, it's entirely up to your
ISP how they want to do it.

> > > 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.

My point is that the free transit through tunnel broker and the free
transit through an exchange point are roughly equivalent in terms of
that driver.

Owen