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.