Will droplets created from custom images support IPv6 in the future?

  • Posted October 10, 2018
  • IPv6

I’m hoping to be able to use custom images with IPv6 at some point. So wondering if it is planned, or in the works.


Submit an answer
You can type!ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

I find it unbelievable that here we are in 2022, 4 years after this thread has been started, and DO still does not support something that should be a basic feature by now.

In that time they have added a lot of other bells and whistles and the majority of them are not nearly as fundamentally needed as this one.

I may be missing something, but I don’t see the problem with DHCP not working - yes, if somebody has no clue what they’re doing, then fair enough, but if somebody’s running a custom image, then aren’t they more likely to going to want to configure things manually anyway. In my case, why would I not be able to set the VM up with just DHCPv4 and then manually add a v6 address as a static? We’re currently on a trial and this is a real show-stopper for us - if we can’t run IPv6 on custom images, then we won’t bother testing anything else.

Hey @aboron and everyone else in the comments :) I know this is an old question but I came across it and wanted to provide some context.

Custom image Droplets use DHCP for IP address assignment (versus “manually” assigned IP addresses for traditional Droplet types), and our internal DHCP service only supports IPv4 at the moment. We are working on adding support for IPv6, but we don’t have a solid timeline yet.

I have no idea why it’s not allowed, but I do know that I have a very pivotal custom image DO server that as time goes on becomes more and more needy of being IPV6 capable. I sure hope someone will update us on future plans or if we need to starting thinking about migrating these to AWS?

Any idea what the reason for the limitation is? Maybe the prefix is based on a unique guest OS specific value or something, which is not easily adapted to cloud-init?

same hope here :)