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

Mailman List Mirror (Read Only)
1

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

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.

2

How do you define "sane," and why do you care?

Doug

3

IIRC, EDIS, at least, will give you large blocks and delegate reverse
DNS authority (+ assign your v6 block to your RIPE handle/info) if you ask.

4

Hi,

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

I can guarantee you that RIPE does *not* require public whois records for individual /64s (or even for separate /48s in PA space).

- Sander

5

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

Does "affordable" mean cheap?...

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;

So you've contacted cheapo providers and you are now surprised that they can't afford to hire people who know what they are talking about?

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

Clearly HE has people who know what they are doing when it comes to IPv6, probably because they have made a MAJOR investment in both people and infrastructure to do so.

Explain again why you aren't using HE for your services?

6

Vote with your dollars and find a provider with clue? It's the only way
you'll get the service you want.

And also, dear god a /112. It's giving me a flash back to a tier 2 carrier I
consulted for about 2 years ago. Their guy (who was a CCNP :rolleyes:), threw
out my plans as being wasteful of space (each site a /48 out of a /40
reservation, each network a /64, etc.). The entire thing was done out of a
/112 at each site with /120's for subnets.

Course this same guy asked why we needed oc-48's between locations, he wanted
to get bonded gigE's of IP transport and do a VPN......

7

By "KVM", I assume he's talking about cloud or VPS, i.e. a KVM based virtual machine. With cloud in particular, I've been trying to decide how to dole out IPv6 space. Because we're doing bridged networking for the VMs, we've been giving out IPv4 /32s to each VM and all VMs are in the same VLAN.

It seems insane to try to setup a proper IPv6 subnet and unique gateway for each VM, so I've been thinking something similar to what the host being complained about here has done is the only way to go. Not down to the detail of making the IPv6 ip based on the IPv4 IP, but giving out "very small" v6 blocks, (i.e. maybe /120 or /124), out of a /48 with the prefix::1/48 IP as everyone's gateway. Sure, IPv6 is big enough that we could give out /64s from that /48 and not run out of numbers, but I'm concerned about what happens when an abusive customer turns up 2^64 addresses and overloads the neighbor discovery cache on our gear. What's anyone really going to do with more than a few IP addresses on a VPS anyway? Just as we do with additional v4 IPs, if someone really has a need for additional v6 subnets, those could be provided, likely for a fee.

8

What's anyone really going to do with more than a few IP addresses on a VPS
anyway?

Give every web site its own IP address, rather than using virtual
hosts, I expect.

On the other hand, I suppose if someone has more than a a few dozen web sites
on a single VPS, more likely than not something peculiar is going on.

R's,
John

PS: For something peculiar, see http://wild.sp.am/ which broke the
bingbot, and Google's been spidering for months, emptying out the
queue they built up before I put in a robots.txt saying to go away.

9

Hi Jon,

Why not assign a single IPv6 address to each VM and then for those
folks who need more, *route* a /64 to the original address? With
Linux, I think you can then attach the whole /64 to a loopback alias
(lo:1) and the host will understand that it has the entire /64 without
creating neighbor table entries or any other chancy things.

Regards,
Bill Herrin

10

Setting up a proper IPv6 subnet and unique gateway for each VM is probably insane, but, potentially less insane than some other alternatives. Setting one up for each customer's collection of VMs, OTOH, might not be so insane. Remember, you can have multiple IPv6 subnets on the same link without much penalty. Since you probably want the ability to have VPS portable across physical servers, you probably don't want to set up a subnet per physical server with all the VPS on a given PS sharing that subnet which is the numerically simplest approach.

I'd have to review your actual architecture (physical and overlaid virtual) to really know what would be best for your particular circumstance. Contact me off-list if you're interested in something like that.

Owen

11

I second that! I give out a proper configured /64 to every "customer"
regardless of he has one, two or more VMs in his network. The
alternatives did not work for us, furthermore scaling the networks is
reduced to drop in more VMs until the /64 runs out of addresses (read:
never) OR the situation calls for other setups anyway.

Receiving a /112 should make one at least thinking about the underlying
network design for a minute. It just looks awkward!

Cheers

Dan