Good day,
Where/how can we petition for better IPv6 support on these instances?
They only have a single IPv6 IP, and I need more per instance. I can have up to 7 IPv4s but I'm looking/needing for IPv6 IPs ;(
)Same trouble with the 2016 VPss, while the previous generation I recall had a full /64)
IPv6 subnet/extra IPv6 IPs on cloud instances/VPS
Related questions
- Problem with Windows Server 2019 activation
3817
30.12.2020 04:04
- Is the Plesk License included?
3641
02.01.2018 11:56
- Ubuntu 20.04 image in OVH has been marked as DEPECRATED
2418
04.12.2020 23:28
- Automatic Block storage backup - how?
2078
06.05.2020 17:31
- Private Network shared between two or more Public Cloud projects
2059
11.03.2021 13:19
- CORS in Object Storage
1866
03.11.2020 06:02
- [ALPHA] On-demand bare metal instances in Public Cloud
1844
14.05.2019 07:08
- Error has occurred creating your Public Cloud project
1784
08.10.2021 08:52
- Nested virtual machines
1576
18.10.2018 14:33
+1
A /64 per customer/server is a must!
I have 17 (!) IPv4 addresses on my VPS instance but only 1 (!) IPv6 address in a shared /64 subnet.
Considering the fact, that IPv4 addresses are very rare on the one hand and the minimum of an IPv6 allocation is a /64 subnet and IPv6 addresses are fare numerous than sand at the beach on the other hand, I cannot understand this policy.
+1 for real IPv6 support.
Hello all,
We understand the inconveniences caused by this and we have raised this with the relevant department to review. Rest assured we will consider changing our IPv6 service on Public Cloud and VPS.
For now this is with the relevant department to continue exploring our options and how we can improve on providing better service to our customers.
Unfortunately, at the moment we do not have an ETA on this subject, but we do our best to speed things up.
Thanks for that response @AdamO, and I hope they also provide beter IPv6 support on the vRacks and dedicated servers in the same breath ;)
>12months later, any progress @AdamO ??
and 36 months later?
what makes this even more "urgent", is the new draft proposal with IETF that makes 127.1/16-127.255/16 public routable, leaving only 127.0/16 as "localhost/loopback" - watch several "fun" problems inside ISPs that used the 127/8 "loopbacks" as identifiers for their routers
https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
Would be great to see this finally picked-up asap. The standard ( https://www.1editor.org/rfc/rfc4291#section-2.5.1editor.org/rfc/rfc4291#section-2.5.1 ) should always be to assign a /64 for a server. For a DSL or FttH connection it is even /56. @AdamO or @OVHSupport, can you please provide an update on this? This can cause neighboring VPS's that misbehave to get your /128 being on a blocklist such as Spamhaus that will only look at /64 blocks which should be the case for all.
Looking forward to seeing a positive reply.
Kind regards,
Joris.
And then: https://twitter.com/olesovhcom/status/1536734786236063744
7 years old, and no progress.
For what it's worth, discovering the lack of rdns configurability for ipv6 and the silly allocation of one ip is the sole reason I'm not moving my servers here from other providers.
A shame.
Hi,
As ipv4 prices are officially increasing (fair enough), as VPS prices are also increasing (still fair enough), and as we are invited to use FREE IpV6, it's not acceptable nor manageable that we do not get the official /64 specs for IPv6, and still do not have an ETA.
Best
+1
A https://www.drjaneclinic.com/ /64 per customer/server is a must!
+1
We're 2023, and still /64 on VPS :frowning:
The Faceit system assigns the ELO ranking to each player depending on factors such as winning percentage, kill or death ratio, competitor’s ranking level, etc. which can be checked using faceitfinder.
https://faceitaccount.com/
To add another reason why this is an important issue, some service providers (like the docker.io container registry) do rate-limiting per /64 blocks, which means that being put into one subnet with other users will result in constant "429 rate limit exceeded" errors, which is extremely disruptive.