Basic setup of Proxmox in an OVH environment (Kimsufi example) with NAT and IPv6 enabled containers

fredo1664

@Maounique said:

@blanehol said: Is there any idea how ipv6 ovh could work in vmware esxi?

I would be making a router VM for IPv6 in that case. Messing with proxmox is one thing, with esxi that would be a whole different ball game.

Could you though? I don't know if you can set esxi to forward ipv6 traffic to a VM? It's not like proxmox where you have a Debian behind the scene.
Anyway, that's not the topic of this thread.

Maounique

@fredo1664 said: Could you though?

Absolutely.
By bridging the external interface of the routing VM to the main connected one (the esxi internet-facing interface). Of course, the esxi itself would not be accessible through IPv6 (because we would not give it one, just IPv4 and even that is not actually required, the same trick can be used there too, I mean give the IPv4 to a bridged router VM instead) unless you give it another interface to the router vm.
The OVH router would see the IPv6 we will be using for routing (belonging to the routing VM, but bridged there) on the MAC your server has registered with it, so would not "see" any problem in giving it access and the rest would be done inside our routing VM.

It might not be the topic here, but discussing it could bring another view on how OVH does the routing.

rexum

@fan said:

@JerryHou said: somehow it gives the container ipv6 after a traceroute

Here's ChatGPT's answer:

Why mtr “unblocks” IPv6
mtr/traceroute sends packets with incrementing hop-limit (TTL), eliciting ICMPv6 Time Exceeded replies from each hop, which creates inbound traffic toward the container address right away.​

With an on-link /64 and NDP proxy, the upstream only performs Neighbor Discovery for a destination when it actually has a packet to deliver; before that, it has no L2 mapping for your container’s IPv6 and can’t return the ping replies, so the first outbound pings appear to fail.​

Once mtr generates those inbound ICMPv6 replies, the upstream issues Neighbor Solicitations, ndppd answers with proxy Neighbor Advertisements, and a reachable neighbor entry is installed until it ages out per NDP timers, after which the cycle repeats if no traffic refreshed it.

did you find a solution that does not require running mtr inside of the containers?

tux

There are SYS servers with better network setup available with Black Friday discount.