
Digital Ocean: Limited Public IPv6 Beta Release - jgillich
https://assets.digitalocean.com/email/ipv6-grandfathered.html
======
Hello71
Now, _how_ long has this been "coming soon" with absolutely no word
whatsoever?

[https://digitalocean.uservoice.com/forums/136585-digitalocea...](https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/2639897-ipv6-addresses?page=4)

Oh, only _nine months_ having an entire customer base entirely forgotten. This
does not good support make.

DO has a history of doing this; see Allow Custom Images [0], with over a year
of no comment, and Give option to use the Droplet's own bootloader [1], with
14 months of no comments; not even a "we're working on this". The latter shows
DO's utter lack of technical competence; if they cannot even properly prepare
a system image [2] or actually _use their virtualization platform_ , what the
hell can they do? Apparently, only marketing.

[0]
[https://digitalocean.uservoice.com/forums/136585-digitalocea...](https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/3276477-allow-
custom-images?page=5)

[1]
[https://digitalocean.uservoice.com/forums/136585-digitalocea...](https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/2814988-give-
option-to-use-the-droplet-s-own-bootloader?page=3)

[2] [https://missingm.co/2013/07/identical-droplets-in-the-
digita...](https://missingm.co/2013/07/identical-droplets-in-the-digitalocean-
regenerate-your-ubuntu-ssh-host-keys-now/)

~~~
raiyu
That's a great point and we totally missed our roadmap in 2013, by about 9-12
months. This is something that Zach Holman at Github addresses in why Github
doesn't really communicate about their roadmap:

[https://github.com/holman/feedback/issues/534](https://github.com/holman/feedback/issues/534)

In our case it was because we were basing all of our roadmap on how we
operated in 2012 when we were a much smaller company, think 5 people,
servicing a much smaller customer base, say 500 customers.

It was early 2013 that our growth really started and we tried to remain
optimistic about our ability to launch features. This turned out to be
completely unrealistic. We had to scale our customer support department which
at that time was basically myself and Etel who is our community director from
0 full-time people to 17 today. Our engineering team was all cofounders which
we have since scaled to 10, and we had no SRE team which we've since also
built out and recently hired Mark Imbriaco from Github as our VP of Ops.

Our tremendous growth was very exciting but it stressed every single area of
the business. We had to raise two rounds in 2013. Though we closed our Series
A in 2014 we actually began that process in early November of 2013.

As the customer base grew and began we also started to encounter more scale
issues which began to shift our engineering focus away from feature and
product development to bug fixes, refactoring, and re-engineering.

We would have wished that we could move faster and pay down technical debt so
that we could move into developing features sooner but given our tremendous
growth last year of scaling from 500-1,000 customers at the start of the year
to close to 100,000 by the end of the year it simply wasn't possible.

Along the way we completely broke a few promises about when we would release
new updates and features. Now we are finally at the point that we feel
confident that we are able to develop and roll out new features and we have
begun doing so.

We've certainly learned some valuable lessons along the way such as being very
careful about the public promises that we make. It's hard to say at the
moment, but I don't think that we will follow Github's model of being
secretive with our roadmap, but we will certainly be more cautious with our
estimates given how we have seen so many different factors play into our
ability to release features.

I think any startup that has scaled has gone through similar problems and so
it's a story which I'm sure has been repeated many times in history. We could
have done a better job of staying ahead of these changes and more pro-actively
communicating that we would be falling behind our product roadmap as a result
and that's a personal failure on my end as I lead product in the organization.

Much like a startup evolves, matures, and changes overtime, I too have had to
go through a similar process of learning and re-learning my role both as a
cofounder and also as a product lead.

It's been very dynamic and interesting and certainly has been a tremendous
growing experience and I've finally been catching up with the rest of my work
now that we've settled so many different problem areas in just scaling a
company and a business.

One of the first things was to get back on top of UserVoice and begin to
provide more updates and visibility into the things that we've been working on
and what's coming up. For other items we are still in the process of hashing
out the details and providing better estimates so in those cases we are
holding off before we make another public statement so that we can ensure we
set the correct expectations.

Believe me that there is nothing more troubling to us as a company than
letting down our customers, it is never our intention, and it is never out of
ill-will, often times it happens out of being too optimistic. Like any trait
there is a negative and positive aspect to it. As a cofounder you need that
boundless optimism because there will be hard times. We had hard times when we
spent 18 months with zero to little traction, and I'm sure we'll need that
optimism in the future as well when we hit hard times or when the landscape
shifts. During these periods it is essential. However, like anything else in
life there is a balance. And, as essential as this optimism is to a startup it
can also lead to issues such as these. In cases like that its a matter of
being open and honest and saying yes we messed up, here is why, and here is
how we are thinking about this problem in the future.

Hopefully that sheds some clarity on this area, especially since I was the one
who was personally responsible for this in our company.

Thanks, Moisey Cofounder DigitalOcean

~~~
jt2190

      > It's hard to say at the moment, but I don't think that 
      > we will follow Github's model of being secretive with 
      > our roadmap, but we will certainly be more cautious 
      > with our estimates given how we have seen so many 
      > different factors play into our ability to release 
      > features.
    

Unless your customers have a really long budgeting process, or otherwise need
time to prepare for coming features, don't bother publicizing your road map.
In the best case you'll only "meet expectations", and in the worst you'll
disappoint people when you're late.

------
InclinedPlane
This sort of thing is a big problem with IPv6 adoption. There's a lot of churn
in internet software, server software, and hosting providers, and often many
of the new guys delay IPv6 support in favor of other features. That makes it
very possible for IPv6 adoption to stall or even reverse depending on the
success of different hosting providers and software. Imagine a worst case
scenario of a next generation web server which becomes hugely popular but
which doesn't support IPv6. Fortunately that's an unlikely scenario, but
unfortunately it can't be entirely ruled out. IPv6 is still a "nice to have"
feature, and has been since it's introduction, that's always been it's major
weakness.

------
Sir_Cmpwn
Now if only they'd reconsider their decision not to deprecate Arch Linux
images. I'm moving my stuff over to Linode because of it.

~~~
agildehaus
I run an Arch droplet and this is the first I've heard of this. Certainly
makes me want to take my business elsewhere. Suddenly they don't have any
bleeding edge distros.

Linode just seems to care more about their customers.

~~~
RoliSoft
Well... If you really want, you could run Debian Sid or Fedora Rawhide, by
creating a droplet form their stable version and upgrading.

It is still no excuse for not having a proper bleeding edge distro.

------
dfc
What policy does "grandfathered customers" refer to?

~~~
raiyu
Grandfathered users are our early adopter customers.

When we do large rollouts we usually release new features to them first in a
limited public beta test so we can collect feedback. They have been extremely
helpful in helping us to find and resolve bugs before we move a feature to
general release.

Thanks, Moisey Cofounder DigitalOcean

~~~
dfc
In my opinion you need to use a better term than grandfathered. I think you
have a different understanding of the term than the general population.
Grandfathered is not used to distinguish early adopter, developer partner,
platinum/double diamond customer loyalty card, etc from the general customer
pool. As witnessed in the comment below grandfathered users are the population
of users that do not get screwed by a new policy.

I think you should take a look at the wikipedia page for grandfather clauses
and reassess if you think this is a word you want to associate with a new
feature:
[https://en.wikipedia.org/wiki/Grandfather_clause](https://en.wikipedia.org/wiki/Grandfather_clause)

Thanks, dfc. English speaking potential customer

~~~
asb
Initially they had no bandwidth charges. Upon introducing them, the customer
base was "grandfathered" in to free bandwidth. I assume this is the set of
customers they are referring to, so it doesn't kind of make sense...but only
if familiar with the history of DO.

~~~
dfc
Here is the deal: You cannot "grandfather" a newly created privilege to a
select population--a population that never received the privilege before--if
for no other reason than the privilege did not exist in the past. The
grandfather bit is not only a connection to the origin of the term but also a
hint about proper usage: people in the past (grandma could not vote) must have
been able to and did enjoy the privilege at some point in the past.

I did not want to come off like a strict scrutiny word maven (synonym:
dickhead) when I wrote my first comment because it would obscure the larger
point: "grandfathered clauses" have negative connotations for new/potential
customers. My goal was to be helpful and not to strut my lexicographic tail
feathers.

~~~
neom
pedantic might be a better synonym. ;)

------
SudoAlex
Any details on exactly what you get with Digital Ocean IPv6? The page doesn't
really go into much detail - and the implementation can make or break things.

Is this a single static IPv6 address with a /64 (or /56 or /48) subnet routed
to it? Or is it something else?

~~~
raiyu
We are rolling out IPv6 initially with a single IP address to see how the
network side of things handles that since we have already a large deployment
of IPv4 and then evaluate from there.

Thanks, Moisey Cofounder DigitalOcean

~~~
SudoAlex
Is this a single IPv6 address sharing the same /64 with stateless auto-
configuration, or static?

The implementation is important, over the years I've had annoying experiences
with certain providers trying to do IPv6 - but not getting things quite right:

Hetzner - Gave customers a /64, but using additional IPv6 addresses required
setting up proxy NDP - which at the time was annoying as only more recent
Linux kernels supported it. I believe they've improved on this since though.

OVH - Requires setting up a default route outside of your normal netmask -
this isn't fun. We don't do this with IPv4 - so why do some providers do it
with IPv6?

Linode - Enables IPv6 auto-configuration, so many servers share the same /64
by default, and they give accounts "pools" of /116 allocations. Sites like
Google considers all of them to be part of the same /64 network - so your
server will probably have trouble accessing certain resources if another
server is doing excessive queries.

~~~
akerl_
Only tangentially related, but Linode gives each server a /128 by default, and
gives out /56, /64, and /116 for free on request. I use a /56 to do my own
subnetting and other fanciness.

~~~
SudoAlex
Sorry, forgot to mention that Linode does give more options now.

------
davidcelis
Received this email earlier, though I don't have any droplets running in their
Singapore center. Wish I could test this out, but I usually keep my servers in
the US.

------
akerl_
Can somebody who has a "grandfathered" account shed light on what makes an
account "grandfathered" in this sense, and also what size allocations they're
giving out?

(I'm aware what grandfathering is in a general sense, but unless they mean
"we're releasing IPv6 as a beta to all users who were users before we made
this announcement", it doesn't seem to fit here. And that would be strange)

~~~
raiyu
Answered below, grandfathered users are our early adopters and we release
features to them in a limited public beta test first to collect feedback
before a general release.

There is no correlation to size allocation, it's just that they are first to
be able to assign IPv6 to droplets in the Singapore region.

Thanks, Moisey Cofounder DigitalOcean

~~~
akerl_
Thanks. I didn't think the type of account was linked to the allocation size,
sorry for not being clear. I was just curious what allocation sizes were being
given out at all.

Edit: and I see that in the interim that's been answered. Looking forward to
seeing larger allocations appear as the beta progresses :)

------
asb
Fingers crossed custom kernels are next.

~~~
atmosx
What do you mean?! You can't have a custom kernel on a DO VPS?

~~~
asb
Correct, there's no current official support. You can kexec to your own kernel
which is kind of ok as a workaround.

------
Havoc
General IPv6 question...is this a case where there is a benefit in being on of
the early adopters? i.e. are there specific "good" addresses. Kinda like
money.com is better than asoef.com.

~~~
justincormack
No. The only benefit is that ipv6 is useful as you get addresses.

------
zokier
It seems to me bit crazy that a hosting provider launched in 2011 did not have
full IPv6 support on day 0, especially when the provider in question was not
some shoe-string garage operation.

~~~
nextweek2
Not really, the issue of deployment hasn't been lack of hardware support but
lack of knowledge on the part of architects and engineers. A greenfield site
has enough issues getting up and running without doubling the IP stack as
well.

What's really surprising is the lack of mature service provider's who are not
performing incremental roll outs.

------
2bluesc
Speedtest: [http://ipv6.speedtest-
sgp1.digitalocean.com/](http://ipv6.speedtest-sgp1.digitalocean.com/)

Of course you need to be on IPv6 to reach that page :)

~~~
lucb1e
Is my v6 so slow or is it their site? I'm getting about 300-400KB/s
(unstable).

Edit: Nevermind, their v4 goes at 100KB/s.

~~~
kbar13
assuming that you're in .nl, I feel like 400KB/s from on the other side of the
world is not terrible.

------
funkyy
I am actually interested in IPv6 - will you release 1 IP per Droplet? Do they
cost similar to IPv4 for hosting company, they are cheaper or are they free?

~~~
zAy0LfpBZLC8mAC
I'd also like to know that, especially as there are lots and lots of hosters
out there who don't grasp IPv6 and are already breaking it before it has
really taken off by creating pointless bureaucratic overhead and thus
incentive to create bad network setups that will hurt us all.

As for the cost for the hosting company: No, one major reason for IPv6 is that
it has a huge address space with 128 instead of v4's 32 bit addresses, so they
are a lot cheaper - as it should be, there is no point in artifically making
addresses scarce. RIPE members, for example, are billed for an IPv6 /32 (about
4 billion /64 subnets) like for an IPv4 /21 (2048 addresses).

In short: You should generally avoid any hosting company that allocates
anything smaller than a /56, they probably haven't understood the internet.

------
booruguru
Can someone explain the meaning and value of IPv6 (and the hurdles for using
it)?

~~~
booruguru
Yes. I read the wiki page, but I was asking for a more conversational
explanation. I really don't see why I was downvoted for asking a question.

