Bonjour,

Ca fait pas mal de temps que je galère avec OVH et IPv6.

Il y a à peu près 6 ans j'avais réussi à faire fonctionner malgré les embûches. Mais depuis 8 mois OVH a du faire n'importe quoi.

Premier problème de conception:
C'est la seul réseau et la seul société où j'ai vu une recommandation qu'une passerelle doit être configurée alors qu'elle n'est pas sur mon réseau.
J'imagine qu'ils veulent réduire le nombre de passerelles à maintenir.
Donc OVH propose des bidouilles.

Deuxième problème (mon problème actuel depuis 6 mois):
Lorsque leurs passerelles Cisco font des neighbor sollicitations et qu'on ne répond pas ils déclarent mon host down et tous mes flux sont coupés.
Ce n'est que lorsque mon serveur fait le neighbor sollicitation et qu'il reçoit un neighbor advertisement que le flux revient pendant 8 secondes.
Impossible sur VMWare ESXi de faire en sorte de répondre aux neighbor sollicitations, j'ai du essayer 15 mille paramètres.

Troisième problème:
Le support OVH, je ne sais pas à quoi ils servent vraiment. Ils renvoient vers des liens pourris qui ne correspondent pas au problème remonté.
Ils se défaussent quand à leur responsabilité de résoudre le problème et d'apporter la connectivité IPv6: ils renvoient soit vers la communauté soit vers des partenaires OVH.
Mais ni la communauté ni les partenaires n'ont la main sur leur design et leur configuration pourrie.
Sans compter que leur support sait à peine ce qu'est un réseau ou même IPv6. Les 3/4 des questions que je leur pose restent sans réponse. C'est comme si on écrivait à un bot qui nous sort des réponses en mode "fortune cookie"
Je vous épargne les problèmes quand on commande un KVM et que l'équipe de proximité oublie de connecter le clavier ou qu'ils connectent mal le port video. 100% des fois où je fais appel à eux ca foire.

Bref, OVH pour IPv6 ou y installer de la prod, c'est même pas la peine.

Une des dernières confs OVH au FRNOG, c'était clairement assumé : l'IPv6 c'est secondaire, car il n'y a pas de demande.

Donc il ne faut rien lâcher et leur casser les noix avec ça.

Pas de souci avec ça, c'est dans les normes, et dans un réseau partagé c'est même une bonne pratique.

D'ailleurs, pour IPv4 c'est pareil chez Online.

Et cela fonctionne bien.

Je suis en dual stack chez eux sur un OPNSense.

Deuxième problème (mon problème actuel depuis 6 mois):
Lorsque leurs passerelles Cisco font des neighbor sollicitations et qu'on ne répond pas ils déclarent mon host down et tous mes flux sont coupés.
Ce n'est que lorsque mon serveur fait le neighbor sollicitation et qu'il reçoit un neighbor advertisement que le flux revient pendant 8 secondes.
Impossible sur VMWare ESXi de faire en sorte de répondre aux neighbor sollicitations, j'ai du essayer 15 mille paramètres.

OVH fournit un /56 qui est rendu inutile puisqu'ils ne savent pas faire de routage, cela signifie que pour mettre en place des machines virtuelles ou fournir des adresses à d'autres hôtes il faudra faire proxy NDP.

Oui oui ils sont mauvais.

Pas de souci avec ça, c'est dans les normes, et dans un réseau partagé c'est même une bonne pratique.

Ben voyons.

Je parle d'avoir la gateway en dehors du subnet, pas d'assigner un bloc v6 en mode sagouin sans routage, qu'on soit bien en phase

C'est aussi mauvais et certainement pas une norme.

Mais il me semble qu'OVH ne fait pas ça. La passerelle est à la dernière adresse du préfixe alloué ce qui est tout aussi inutile mais qui correspond à leur documentation pourrie et confuse ainsi qu'à la configuration que j'ai pu mettre en place sur une machine chez eux.

Absolument pas, on utilise les link local pour router des blocs en IPv6, vouloir mettre un sous-réseau pour ça est une relique d'IPv4.

Non c'est une mauvaise idée. Le routage WAN sur l'Internet doit se faire avec des adresses globales uniques.

Ce n'est certainement pas une relique d'IPv4 puisque l'abondance d'adresses le permet justement.

In the case of a router on the end customer side, the route for the assigned prefix is pointed towards the link-local address on the CPE/router WAN port and the default route on the CPE/router is pointed towards the link-local address on the upstream network equipment port. This method may be seen as easier to implement, but it also brings some drawbacks such as difficulties with troubleshooting and monitoring that need to be considered. For example, link local addresses do not appear in traceroute, the most common troubleshooting tool used, so you will not be able to easily locate the exact point of failure.

Source : https://www.ripe.net/publications/docs/ripe-690#4-1-2--unnumbered

Ça ne veut pas dire que ça ne fonctionne pas, juste que c'est une mauvaise pratique.