Long and unabbreviatable IPv6 addresses with random overloaded bits, vs. tunnelbroker

Sun Nov 18 22:53:47 UTC 2012

Dear NANOG@,

I came across an interesting problem in trying to find an affordable
KVM provider with IPv6 support.

It seems like several rather major and reputable providers in the
value sector do claim to have IPv6 support, but once you get your IPv6
addresses or subnets from them, you might be rather disappointed.

== Example of edis.at ==

edis.at gives you an IPv4 address of, for example, 158.255.21x.xxx,
and the IPv6 /112 that you get is 2a03:f80:ed15:158:255:21x:xxx:0/112
(really a /48), with 2a03:0f80:ed15::1 as the gateway.

I've tried contacting them in an effort to receive any kind of a
"proper" IPv6 address without the plaintext IPv4 embedment, but
they've given me all sorts of crazy and (IMHO) far-sketched excuses;
from not wanting to maintain a separate database of IPv6
addresses/subnets, and from lack of software provisioning support; to
supposedly RIPE and/or edis' upstream providers requiring public whois
entries for any /64's that edis.at would allocate for their customers,
and to not having control of the underlying routers/switches/firewalls
in any but one of their 13+ datacentres that thus makes creating 2^16
separate routes problematic.  ???

All I'm asking for, are sane and short addresses and/or a saner /112,
don't really care if it's still a shared /48 underneath.

== Example of buyvm.net ==

On the other hand, buyvm.net claims to give you 16 IPv6 addresses.
This is the kind of addresses that they give out (some consecutive 4
out of the 16 provided addresses listed):

2607:f358:0001:fed5:0022:a124:fe56:xxxx,
2607:f358:0001:fed5:0022:f6a6:dffe:xxxx,
2607:f358:0001:fed5:0022:c6a3:7826:xxxx,
2607:f358:0001:fed5:0022:654f:964d:xxxx.

This is the response I've got from buyvm.net when trying to ask for
some reasonable (shorter) addresses or a whole subnet instead:

<< We cannot offer that at this time as we have to store these IPs in
MySQL which would slow down the database. >>

WTF?  Surely offering some 16 random addresses that are 128-bits long
doesn't slow down MySQL, but offering one single, short and
abbreviatable /64 or /112 subnet would.  I'm puzzled!

== ==

(HE's tunnelbroker.net, on the other hand, has no problem in giving
out IPv6 addresses that, when abbreviated, can be represented by the
same number of ASCII characters as an IPv4 address; for free, might I
add.)

== ==

Am _I_ supposed to have a MySQL database with the list of the IPv6
addresses that my virtual private servers have been assigned?
Wouldn't it "slow down MySQL", so to speak?  :-)

What's your take on this?  Since IPv6 is still a very low priority for
many of the hosting providers (edis.at cited a rather negligible
amount of IPv6 traffic, so, they argue that, as a small shop, they
simply can't justify spending much R&D on further improving something
that they consider already supported and not broken in the first
place), would I be crazy to opt-out of such pathetic IPv6 support, and
sign back up with a tunnelbroker from HE.net instead?

(In fact, my preliminary tests show that IPv6 latency between Austria
and Fremont, London and Moscow are either the same or slightly better
when using the HE.net tunnelbroker in Prague, instead of edis.at
native IPv6 support; bandwidth doesn't seem to be affected, either.)

A little extra latency (only potentially) and MTU reduction by 20
bytes are the only negatives, right?

Yet on the positive side, I'll get a proper and short /64 or /48
subnet, proper rDNS support, guaranteed proper intermediate hops with
proper rDNS entries and no stupid hops impeding traceroute,
potentially much better IPv6 routing/peering/latency, and short or
custom ...:face:b00c::-style addresses to my liking; and, last but not
least, a higher number of potential KVM providers to choose from,
since I wouldn't require any native IPv6 support with such an
arrangement.

Comparing these options, seems like on the KVM hoster side, a blanket
"IPv6 support" (with no /48 or /64 promises) is thus basically a
useless concept anyways, and, at this time, should not even be sought?
 Any thoughts?  Did I miss anything?

In summary, I thought I have to have native IPv6 support in any new
VPS that I buy, but looks like using a tunnelbroker might just be a
much cleaner and better solution anyways.

P.S.  Does anyone other than me object to calling /48 subnets with
allocations such as 2a03:f80:ed15:158:255:21x:xxx:0/112 as native IPv6
in this context of VPS hosting?  How should such
addresses/subnets/arrangements be called?

Best regards,
Constantine.