New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
RFC 6177.
Simply put, you need a /64 for some features of IPv6 to work (e.g. stateless address autoconfiguration), so that RFC designates a /64 as the longest sensible prefix for end-user assignments.
You won't need address autoconfig on your static-IP server, but you'll need it in other cases, so the recommendation is a generic one. That way, blacklists can (and do) assume that all addresses in a /64 belong to the same person.
So if you're sharing your /64 with someone else, you're likely to have a bad time at some point when one of your neighbours gets blacklisted.
Clouvider is correct, of course: you don't need to be able to use all addresses (and what would you do with 2^64 addresses anyway, except pick ones that says b00b:1e5), you just want to be sure that no-one else is going to use them either.
DigitalOcean block IPv6 SMTP precisely because running mail on sub-/64 assignments is bound to cause problems:
https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/7190053-allow-smtp-over-ipv6
… and rather than fix their shit, they just block the port and tell you to move on (and have been doing that for years).
The only reason I'm even still looking at DO is because I have a ton of promo credit left. After that it's Vultr all the way.
Update: just eliminated dediserve - poor network uptime.
Still in the running:
Linode
ExpertVM
You could give VPS247 a shot. @venatha
I've got a box in the UK with them and they struggle to keep ipv6 up and working properly. Too many routing issues to chance anything in SG with vps247.
@NodePing try upcloud. They just had their SG location this year.
How much downtime? I thought they had a 100% uptime gurantee.
I started a box there 4 days ago. Today, after 10 minutes of being down (both ipv4 and ipv6), I just cancelled the service.
We always test new services for 30-45 days before we use them in our production stack and if simple ICMP ping uptime falls below a certain threshold during that testing time, we cancel the service rather than open tickets. It's not very fair to providers to not give them a chance to iron out issues but our experience has shown that if we have to open a ticket for network or host issues in the first 45 days, we're going to continue to have issues with that service and it's not going to be stable enough for our use. So we simply move on. Sucks for the provider having a rare bad day, but it saves a lot of time and effort on our end. And with plenty of supply, we're usually able to find stable providers in the locations we need. We have to kiss a lot of frogs before finding our prince though.
I learned a long time ago that a guarantee means little to nothing about actual performance. We have providers with SLAs and others without. Proven working history is better than a guarantee any day.