infrastructure-roadmap
infrastructure-roadmap copied to clipboard
ovh
One IPv6 /48 or /56 per customer
Currently, a /64 is assigned per server, which is against RFC 6177
https://datatracker.ietf.org/doc/html/rfc6177
At the same time, it might be tempting to give home sites a single /64, since that is already significantly more address space compared with today's IPv4 practice. However, this precludes the expectation that even home sites will grow to support multiple subnets going forward. Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either.
A much better implementation, which would render the need of IPv6 failover moot, would be to give each nichandle a /48, /56 or similar. OVH has a /32, so giving each customer a /56 would still allow a whooping 2**24 customers, more than enough. And since not everybody uses IPv6, this could be a "service" that the customer would enable in her manager.
while ovh has to provide ipv6 failover for it to be even remotely useful, you undercomplicate the matter here. A big network has to segment IPs to be scalable, so just handing out a bigger prefix wouldn't solve the problem of failover for OVH, there is more logic involved.
"Currently, a /64 is assigned per server" that is true for dedicated machines but not for VPS's which get a ridiculous /128 assignment. Hence they are sitting in the same network (/64) as surrounding customers. So if you have a neighbour spamming using it's IPv6 he can get the whole /64 block blacklisted (which is normal practice, blacklisting should not occur below the /64 level) and you are taken down with him...
Assigning a /56 or even /48 per NIC-handle would be great but will probably take OVH a long time to integrate. The real urgent problem here is not assigning /128 to any VPS anymore but only /64's. Address space is not an issue, there's more than enough of that (OVH having at least a /32 and a /31) and the service would already be a lot better.
So it would probably be best/quickest to go in stages. I have created a separate issue #120 so as not to mix up both taks which remain still valid and can be implemented separately.
Getting a decent /56 and some working routing functionalities for VMs on the bare metal (for example) might even decrease the need of having tons of IPv4 addresses.
@KlaasT No it wont, I think you never tried using the internet without an IPv4 Address at all.
And natting IPv4 wont make it due to rate limitings everywhere on the internet.
@KlaasT No it wont, I think you never tried using the internet without an IPv4 Address at all.
You have no idea what I am talking about. If you don't understand what I am up about you can ask but don't need to throw in unnecessary comments.
@KlaasT I agree but this might take "some" (read "a lot of") time for OVH to implement. Hence my intermediate proposal in #120 to at least starting allocating proper /64s as opposed to poor and totally non-standard /128s for VPSs for example.
Given the announced price increases for IPv4 addresses for SoYouStart customers I would encourage OVH to look at a more sensible IPv6 implementation that allows for more flexibility for the customer. Specifically also eliminating the need for Proxy NDP in virtualization scenarios, which would be achieved if this proposal was implemented and allowing the customer to route portions of their subnet to specific servers.
Having experience with some other hosters as well I would suggest getting some inspiration from Scaleway as their implementation using DHCPv6-PD to "pull" a subnet works extremely well and allows for flexibility.
Yes, providing a proper way to delegate prefixes from the /56 prefix currently assigned to SCALE and HIGH GRADE servers is a must. Right now, all of those just have a single /56 prefix directly routed to their public network interface, which is useless, and still requires NDP hacks to do anything useful with.
Since this is quite different than having an account-wide prefix, I have created #150 for it. It would also be useful for when IPv6 will return in the vrack, since vrack 1.0 also had a /56 prefix which was pretty much useless over a /64.
Agreed @thias but this is not moving forward since many years now and OVH to continues to provide services with a /128 which is totally not good of course. Hence I created #120 to add least we have a workable solution and can then even get better on the routing level. But let's encourage to start with the simplest and most urgent stuff please.
Glad to notice this has been moved from Prioritized to Planned. Any ETA? If not doable in the very near future, I propose that at least that you stop assigning /128s to VPS customers and give them a /64. While not completely perfect, this will already be a great help.
Awesome to see there is some movement here, routed /56 on dedicated servers would be a godsend
Around March we plan to release in Beta /56 blocks available to our customers in a form of Additional IPv6. Such blocks can be attached in specified location to a vRack network for the most flexibility (thus the widest range of products supported). Users will be able to route smaller subnets inside it. We will start with SLAAC and manual IP distribution for simplicity.
Thanks for your answer @jslocinski . Will it be possible to attach VPS's to such a vRack? As per current documentation, it is not the case and that is were the biggest problem lies with current /128 assignments.
Nope, VPS infrastructure doesn't allow to interconnect with vRack. IPv6 address/block change may be a subject of another stream, thus communicated separately.
Hope than that ticket #120 can finally be picked up since this continues to be a real pain...
🚀 I'm pleased to announce early release of OVHcloud's Additional IPv6 offering a flexible way to manage next-gen IP addressing with vRack-enabled products! 👉 Register now and grab one of the first /56 blocks during Alpha product stage: https://labs.ovhcloud.com/en/additional-ipv6-with-vrack/
Excellent news, still really hoping for general availability without vrack though; unfortunately my server doesn't support it