La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: kgersen le 20 février 2019 à 12:15:42
-
Ceci est un hors-sujet extrait de celui qui annonce l'IPv6 SLAAC chez Online (https://lafibre.info/scaleway/ipv6-dedibox-scaleway/)
IPv6 enfin activé par défaut sur les Dedibox
Mickael Marchand, directeur technique de Scaleway annonce que IPv6 est maintenant activé par défaut sur les nouvelles Dedibox.
Je reproduis ici mon échange sur Twitter :
Moi : "Ah si #IPv6 pouvait être ACTIVÉ PAR DÉFAUT chez @online_fr: Deux sujets avec 100 messages où des clients se battent pour configurer #IPv6 leur #Dedibox:
- https://lafibre.info/scaleway/configurer-une-ipv6-sur-un-serveur-dedibox-avec-ubuntu-18-04/
- https://lafibre.info/scaleway/configurer-une-ipv6-online-net-sur-ubuntu-18-04/
C'est tout sauf simple, ni bien documenté."
Mickael Marchand : "c le cas sur les nouveaux serveurs ;)"
Moi : "Félicitations ! Tous les nouveaux serveurs Dedibox (Start/Pro/Core/Store) ont IPv6 activé par défaut ?
Dans ce cas Scaleway AS12876 devrait rapidement monter sur https://stats.labs.apnic.net/cgi-bin/v6pop?c=FR
(aujourd'hui 1,09% de AS12876 est estimé en #IPv6 par @apnic)"
Source : twitter (https://twitter.com/lafibreinfo/status/1093796789424214019), le 8 février 2019.
Je n'ai malheureusement pas eu de réponse à cette dernière question.
Si vous ré-installez votre Dedibox, je suis intéressé pour savoir si vous avez de l'IPv6 activé automatiquement après l'installation.
Edit : IPv6 n'est pas activé par défaut, il faut activer l'IPv6 SLAAC, qui attribue une ipv6 /128 sur votre serveur.
Pour activer IPv6, c'est simple: il faut aller sur la page d'administration du serveur concerné, puis cliquer sur le bouton “activer l'IPV6 SLAAC”
'activé par défaut' ... ça veut dire quoi précisèment ?
Vu le choix d'OS pré-installés https://www.online.net/en/dedicated-server/operating-system on présume que tous sont activés IPv6 ?
Même si je prend un ESXi ou un Windows server ou FreeBSD ?
-
Activé par défaut, signifie que le client n'a rien à faire pour joindre un site en IPv6.
Cela ne signifie pas pour autant qu'un site web hébergé sur ce serveur sera accessible en IPv6, car il faut rajouter un enregistrement AAAA dans les DNS (opération qui doit être réalisée par le client), mais la partie la plus compliqué du travail est réalisée.
Concrétement chez OVH, c'est ce type de configuration :
OVH fournit ses serveurs avec de l'IPv6 par défaut depuis un petit moment (IPv6 configuré sans que le client n'ait rien à faire, au moins sous Linux)
Voici le /etc/network/interfaces fourni par OVH sur un serveur dédié :
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 37.187.131.220
netmask 255.255.255.0
network 37.187.131.0
broadcast 37.187.131.255
gateway 37.187.131.254
iface eth0 inet6 static
address 2001:41D0:A:41dc::1
netmask 64
gateway 2001:41D0:A:41ff:ff:ff:ff:ff
post-up /sbin/ip -f inet6 route add 2001:41D0:A:41ff:ff:ff:ff:ff dev eth0
post-up /sbin/ip -f inet6 route add default via 2001:41D0:A:41ff:ff:ff:ff:ff
pre-down /sbin/ip -f inet6 route del default via 2001:41D0:A:41ff:ff:ff:ff:ff
pre-down /sbin/ip -f inet6 route del 2001:41D0:A:41ff:ff:ff:ff:ff dev eth0
-
oui donc c'est juste la config par défaut quand on choisi un 'Linux' comme OS ?
-
Ou Windows / FreeBSD. Cela serait triste de limiter IPv6 à Linux, surtout que cela permet ensuite de mettre une IPv4 publique en option, ce qui permet de baisser les prix pour ceux qui n'ont pas besoin d'une IPv4 publique.
J'imagine que Scaleway a fait des modifications sur la façon dont le bloc IPv6 est routé par défaut (plus besoin de requête DHCPv6 ?)
Bref, je suis intéressé des retours de ceux qui ont commandé une nouvelle machine ou ré-installé une machine existante.
-
Voici la réponse :
Hello Vivien, Sur le parc le plus récent, l'IPv6 SLAAC est disponible nativement et s'implèmente donc plus naturellement en effet. Il n'y a pas "d'exception" sur le nouveau matériel. :) -MM source (https://twitter.com/Scaleway_Help/status/1098181635076485122)
Il faut donc du "nouveau matériel".
Nouveau hardware serveur compatible SLAAC ?
Nouveau hardware switch/routeur compatible SLAAC ?
A priori, cela sera une /128 pour chaque serveur :
L'activation de l'IPv6 SLAAC attribue une ipv6 /128 sur votre serveur, cette IP sera fixe sur le serveur et ne pourra pas être attribué à un autre
Source : https://documentation.online.net/fr/dedicated-server/network/ipv6/slaac
-
c'est plutôt "Nouveau hardware switch/routeur compatible SLAAC" c'est le switch/routeur qui fournit le SLAAC.
Le hardware serveur n'est pas concerné par cela.
Donc vu que cela correspond juste a https://documentation.online.net/fr/dedicated-server/network/ipv6/slaac, ce n'est pas 'nouveau nouveau'...
Bref ca permet le minimum si on ne veut pas ou ne sait pas utiliser DHCPv6-PD.
Il faut encore que l'image de l'OS qu'on a pré-installé supporte SLAAC par défaut sinon il faudra quand meme utilisé IPv4 pour configuré SLAAC dans le serveur...
J'ai commandé un Dedibox pour faire des tests avec chaque image proposé par Online.
-
Chez Scaleway (un ARM), IPv6 automatiquement configurée: 2001:bc8:4400:2700::2269
Chez Online.net (sur AMS1), ESXi et IPv6 automatiquement configurée: 2001:bc8:6010:204:ec4:7aff:fe86:7b18
-
Quelques précisions :
L'IPv6 stateless (SLAAC) est disponible sur tout ce qui a été racké depuis un peu plus d'un an et demi.
Ça concerne à peu près (désolé j'ai pas la liste précise) tous les serveurs de DC5-A et DC5 (et quelques autres dans les autres DC).
On a pour projet de l'étendre à d'autres offres déjà en production avant (toutes les anciennes SX/XC 2016 au moins [START-2-S maintenant]).
L'assignation de l'IPv6 est automatique dans le sens où il n'y a rien à configurer sur l'OS (ce dernier doit juste supporter SLAAC), l'OS reçoit un Router Advertisement et calcul tout seul l'IPv6 à partir de la MAC.
Par contre ce n'est pas tout à fait "par défaut", pour l'instant il faut que le client clique sur "Activer l'IPv6" dans sa console.
On est en train de voir pour que ça soit fait par défaut à la livraison du serveur (peut être pas pour tout de suite, on est assez chargés en ce moment).
-
ah gah y'a rien de nouveau quoi, je me suis fais avoir par Vivien et son titre 'vendeur' :) ah la comm instantanée via Twitter c'est le mal.
-
Je viens d'éditer mon premier message.
Le tweet de Mickael Marchand laissait à penser que c'était activé par défaut.
Pour la team Scaleway : Il est important d'activer par défaut l'option IPv6 SLAAC, car peu de clients vont activer l'option, ce qui ne fait pas avancer la transition vers IPv6.
Si on prend coté FAI, on a 4 cas possibles :
- IPv6 non disponible : c'est le cas de Free en zone non dégroupée
- IPv6 disponible mais non activé par défaut : c'est le cas de SFR dégroupé / non dégroupé depuis des années, avec moins de 1% des clients qui activent IPv6.
- IPv6 activé par défaut et désactivable : c'est le cas de Free en zone dégroupée
- IPv6 activé par défaut et non désactivable (il y a 2 FAI dans cette catégorie : Coriolis Telecom dans les DSP compatible IPv6 et OrneTHD.
Pour que Scaleway et les autres n'aient plus besoin d'acheter des IPv4 hors de prix, il faut que la transition IPv6 avance plus rapidement que les 20 dernières années. Pour avancer rapidement, il faut qu'un maximum activent IPv6 par défaut.
Il y a toujours des récalcitrants à IPv6, mais il faudra les contraindres dans une seconde étape, une fois IPv6 proposé par la majorité des acteurs.
Exemple d'OrneTHD qui passe de 0 à près de 100% de clients avec IPv6 suite au recrutement d'une personne motivée ;)
OrneTHD bascule tous ses clients en quelques jours sur IPv6 !
OrneTHD est devenu en quelque jour le FAI de France métropolitaine à avoir le plus de pourcentage de clients IPv6
Petite explication : AS41114 = nouvelle AS de Orne THD, sur https://bgp.he.net/AS41114 elle apparait bien avec le nom "Orne THD SPL"
(https://lafibre.info/images/ipv6/201902_ipv6_france_OrneTHD.png)
Source : Statistiques Apnic (https://stats.labs.apnic.net/ipv6/AS41114?a=41114&c=FR&x=1&s=1&p=1&w=12&s=0)
-
Pour la team Scaleway : Il est important d'activer par défaut l'option IPv6 SLAAC, car peu de clients vont activer l'option, ce qui ne fait pas avancer la transition vers IPv6.
Je ferais attention a distinguer FAI grand public et hébergeur comme Scaleway/Online.
Les problématiques ne sont pas les memes. L'impact non plus.
L'IPv6 chez Online est très bien (block /48, découpable en /56 avec distribution du routage par DHCPv6-PD). Techniquement c'est quasi le mieux.
Le souci c'est le manque de compétence et d'informations des clients d'Online. Leur faciliter les choses avec SLAAC peut aider mais ce n'est pas la bonne solution a long terme. Ce qu'il manque c'est une bonne documentation qui explique "comme ca marche" de leur coté et pas l'actuelle qui se contente de survoler la configuration de tel ou tel OS sans expliquer les choses et sans utiliser les bons termes.
Le SLAAC tel que présent dans la console Online c'est juste bon pour avoir un accès 'technique' en IPv6 (= ssh ) a son serveur pour ensuite le configurer correctement avec DHCPv6.
Apres pour un usage simpliste d'un serveur, le SLAAC peut suffire aussi mais a moyen/long terme je ne suis pas convaincu que l'avenir soit la. L'avenir pour ce type d'usage sera plutôt supporté par un serveur managé ou un service managé (web ou autre) par le provider. C'est donc ce dernier qui gérera la conf de l'IPv6.
Maintenant si 99% des clients d'Online ont un usage 'simpliste' de leur serveur l'impact peut-être grand...si c'est le cas, on est dans une situation de 'mauvais ciblage': l'ingénierie a mis au point un beau système IPv6 (/48, /56 et DHCPv6-PD) mais totalement disproportionné par rapport a la cible...
Dans tout les cas, je vois mal les gens continuer a gérer eux meme leur serveur Linux (ou autre) au niveau OS comme une tendance positive du marché, c'est plus un truc du passé. Les efforts d'investissement d'un hébergeur ne doivent plus aller dans ce sens, d'ailleurs ce n'est pas pour rien que Scaleway (Cloud) englobe maintenant Online (plus traditionnel).
-
Et le reverse IPv6 personnalisable pour les instances scaleway ? :D
+1 à kgersen
-
Je ferais attention a distinguer FAI grand public et hébergeur comme Scaleway/Online.
Les problématiques ne sont pas les memes. L'impact non plus.
L'IPv6 chez Online est très bien (block /48, découpable en /56 avec distribution du routage par DHCPv6-PD). Techniquement c'est quasi le mieux.
Le souci c'est le manque de compétence et d'informations des clients d'Online. Leur faciliter les choses avec SLAAC peut aider mais ce n'est pas la bonne solution a long terme. Ce qu'il manque c'est une bonne documentation qui explique "comme ca marche" de leur coté et pas l'actuelle qui se contente de survoler la configuration de tel ou tel OS sans expliquer les choses et sans utiliser les bons termes.
Le SLAAC tel que présent dans la console Online c'est juste bon pour avoir un accès 'technique' en IPv6 (= ssh ) a son serveur pour ensuite le configurer correctement avec DHCPv6.
Apres pour un usage simpliste d'un serveur, le SLAAC peut suffire aussi mais a moyen/long terme je ne suis pas convaincu que l'avenir soit la. L'avenir pour ce type d'usage sera plutôt supporté par un serveur managé ou un service managé (web ou autre) par le provider. C'est donc ce dernier qui gérera la conf de l'IPv6.
Maintenant si 99% des clients d'Online ont un usage 'simpliste' de leur serveur l'impact peut-être grand...si c'est le cas, on est dans une situation de 'mauvais ciblage': l'ingénierie a mis au point un beau système IPv6 (/48, /56 et DHCPv6-PD) mais totalement disproportionné par rapport a la cible...
Dans tout les cas, je vois mal les gens continuer a gérer eux meme leur serveur Linux (ou autre) au niveau OS comme une tendance positive du marché, c'est plus un truc du passé. Les efforts d'investissement d'un hébergeur ne doivent plus aller dans ce sens, d'ailleurs ce n'est pas pour rien que Scaleway (Cloud) englobe maintenant Online (plus traditionnel).
De la à dire très bien, je sais pas. Je préfère que l'on me donne un block comme OVH et que je puisse attribuer moi même les IPv6 sur les VM. Chez Online tu essais de mettre une IPv6 sur tes VM derrière un pfsense, c'est un parcours du combattant avec l'ancien système (DHCP IPv6)
-
c'est un parcours du combattant avec l'ancien système (DHCP IPv6)
ancien système ?!
-
Oui système toujours actuel. C’était juste historiquement parlant par rapport à SLAAC chez Online.
-
Moi je vois par défaut un /128 sur chaque serveur avec possibilité pour ceux que ont le besoin de demander un /48.
C'est une méthode qui fonctionnera même quand IPv4 n'existera plus.
L'idée est de se limiter à faire ce que fait IPv4 aujourd'hui.
Je note par contre une régression par rapport à IPv4 : pas de reverse-DNS sur ce /128 SLAAC.
Cela pose problème pour envoyer des mails : par défaut les mails vers Gmail partent en IPv6 et seront classés comme du SPAM (j'en ai fait l'expérience avec uniquement un reverse sur l'IPv4 sur ce forum il y a quelques années)
-
C'est une méthode qui fonctionnera même quand IPv4 n'existera plus.
L'idée est de se limiter à faire ce que fait IPv4 aujourd'hui.
sauf qu'IPv6 SLAAC sur un /128 est bien plus limité qu'une seule IPv4. C'est tout le problème. L'equivalent d'une seul IPv4 est au minimum un /64, c'est ce que propose Vultr par exemple ( cf https://www.vultr.com/docs/configuring-ipv6-on-your-vps ) et que devrait proposer n'importe quel hébergeur avec un peu de bon sens...pourquoi OVH et Online limitent a un /128 ?! c'est juste incompréhensible.
Donc a l'arrivée, c'est soit trop compliqué pour l'utilisateur 'qui ne veut pas faire d'effort pour aborder IPv6 proprement' soit c'est trop restrictif.
bref ca n'aide pas la "cause d'IPv6"
-
J'étais persuadé que le SLAAC ne fonctionnait que sur des /64. Je vois tout le monde parler de /128 attribué en SLAAC, J'ai loupé qqch ? :)
-
Le masque est en /64, mais tu n'as qu'un /128 qui t'est alloué.
-
Le principe du SLAAC c'est que c'est pas une allocation (comment en DHCP), mais une auto-configuration.
Le routeur fournis via les RA les 64 bits de poids fort du subnet. L'hôte choisi/génère les 64 bits de poids faible.
Du coup je comprends pas du tout cette notion "d'allouer" un /128 en SLAAC, y compris donnée dans la doc Scaleway.
Pour moi le SLAAC ne fonctionne qu'en /64, et donc on a forcèment tout un /64 de dispo.... a moins qu'ils ne mettent plusieurs serveurs, appartenant à des clients différents, dans le même /64 ??! (avec un filtre pour n'autoriser que les adresses générés avec comme base l'EUI-64 (dérivées de l'adresse mac) à accéder au réseau (ou entrée ndp en statique)) ?
Si c'est ça, c'est quand même assez triste...
-
Ils t'allouent la v6 correspondant à ta MAC. Tu ne peux pas en avoir d'autre
Si c'est ça, c'est quand même assez c'est triste...
Nope, c'est exactement comme ça qu'on doit gérer des assignations SLAAC :-)
Si tu veux plus d'IP, tu fais du DHCPv6-PD !
-
Ouai, sauf qu'il n'y a pas qu'une seule et unique manière de générer des adresses SLAAC. Il y a des méthodes qui n'utilisent pas l'adresse mac. Privacy extension, toussa. +rfc7217
Mais bon, c'est vrai que pour un serveur, c'est pas bien grave de faire fuiter son adresse MAC, ni d'avoir tout le temps les même 64 bits de poids faible ! Et effectivement, du moment que la méthode propre en DHCPv6-PD est disponible, ça va. Pas de quoi crier au scandale :-*
-
Nope, c'est exactement comme ça qu'on doit gérer des assignations SLAAC :-)
euh non pas du tout. D'ailleurs il me semble que leur /128 ne respectent pas les RFC et autres recommendations du SLAAC.
Et en pratique, la meilleur méthode pour SLAAC sur serveur c'est l'ip token...et/ou les privacy extensions.
-
Je voulais parler de SLAAC en utilisant juste EUI-64.
On ne va pas laisser des Privacy Extensions et autres joyeusetés inutiles sur un serveur, dans un LAN partagé. EUI-64 rend les IP prédictibles, c'est facile à implèmenter côté ACL, etc...
-
Ya vraiment rien côté réseau pour SLAAC, le routeur annonce juste le subnet /64 via un RA, et c'est l'OS qui fait tout le travail.
La seule chose qu'il y a en plus sur dedibox c'est une ACL IP qui restreint ton IPv6 à celle correspondant à la MAC de ton serveurs (ou aux MACs de ton serveur s'il y en plusieurs, pour les Virtual MAC notamment), calculé selon EUI-64.
-
dans un LAN partagé. EUI-64 rend les IP prédictibles,
Mais c'est un LAN partagé le SLAAC Online ?
Soit c'est pas partagé et je vois pas l’intérêt de réduire à un /128. Soit c'est partagé mais ça voudrait dire que les différents serveurs sont sur le même L2 ? Ce qui serait assez étrange
-
Mais c'est un LAN partagé le SLAAC Online ?
Soit c'est pas partagé et je vois pas l’intérêt de réduire à un /128. Soit c'est partagé mais ça voudrait dire que les différents serveurs sont sur le même L2 ? Ce qui serait assez étrange
Oui, il peut y avoir jusqu'à 253 serveurs sur le même L2 sur dedibox.
-
Oui, il peut y avoir jusqu'à 253 serveurs sur le même L2 sur dedibox.
Ah Ok... merci de l'info. C'est vrai que dans le cas de serveur physiques dédiés, ça doit pas être évident de faire autrement que de partager le L2. Du coup je comprends mieux pourquoi SLAAC limité au /128 issu de la mac !
-
J'ai fait quelques tests. Curieusement il y a 2 préfix annoncés chez Online...
un /64 qui correspond a l'IPv6 SLAAC autorisée (cf post de Twister; on ne peut utiliser qu'une seule IPv6 dans ce /64, les autres sont bloquées).
et
curieusement aussi un /128 (qui est ignoré par SLAAC car de longueur pas standard) par contre il est 'on link' donc une route s'installe pour cette IP...(c'est un truc de management ?l 2001:bc8:2::5:x:y)
Oui, il peut y avoir jusqu'à 253 serveurs sur le même L2 sur dedibox.
donc je peux èmettre des RA pour polluer les 252 autres serveurs ou y'a une protection ?:p
-
Il doit tout de même avoir du First Hop Security chez Online pour contrer cela.
Non ?
-
Je pense qu'il y a une sécurité mise en place par Scaleway pour que tu n'utilise pas l'IPv6 d'un autre serveur.
C'est d'ailleurs une problématique : certains hébergeurs (switchs) savent protéger uniquement l'IPv4.
Donc je résume : En IPv6 SLAAC 253 serveurs (un /24 IPv4) partagent un même /64, c'est bien ça ?
Cela serait possible de reverse DNS comme proposé en IPv4 ?
sauf qu'IPv6 SLAAC sur un /128 est bien plus limité qu'une seule IPv4. C'est tout le problème. L'equivalent d'une seul IPv4 est au minimum un /64
Ok quand tu as des machines virtuelles ou des containers, mais pour une utilisation sans VM / Container, un /128 est équivalent à une IPv4
-
Ok quand tu as des machines virtuelles ou des containers, mais pour une utilisation sans VM / Container, un /128 est équivalent à une IPv4
Tu fais comment un serveur VPN IPv6 avec un /128 ?
Je trouve surprenant qu'un défenseur et promoteur de l'IPv6 comme toi trouve 'acceptable' l'existence meme de ces /128 ....Si on commence par accepter ce genre de chose , on va bientôt accepter le NAT sur IPv6 aussi.
Le minimum c'est /64, on devrait être dogmatique et inflexible la dessus.
-
Tu fais comment un serveur VPN IPv6 avec un /128 ?
Justement, par défaut c'est du SLAAC.
Et si tu en veux plus pour un usage plus avancé (comme l'exemple du VPN), il y a du DHCPv6-PD :)
-
Justement, par défaut c'est du SLAAC.
'par défaut' ?! qui ? quoi ?
Et on parlais en général des /128 pas du cas spécifique d'Online qui fournit un /48.
le point de Vivien:
pour une utilisation sans VM / Container, un /128 est équivalent à une IPv4
-
@kgersen, si tu as une doc pour la méthode DHCPv6-PD, je suis preneur.
Merci
-
@kgersen, si tu as une doc pour la méthode DHCPv6-PD, je suis preneur.
Merci
quel OS et version ?
sur Linux, le 'bout de doc' d'online: https://documentation.online.net/en/dedicated-server/network/ipv6/prefix peut suffire si tu suis a la lettre en partant qu'une config propre.
-
C'est pour du Debian 9 ( la dernière version stable quoi )
Merci pour le lien :)
-
C'est pour du Debian 9 ( la dernière version stable quoi )
Merci pour le lien :)
sur debian 9:
l'interface sera surement enp1s0 au lieu de eth0 (a changer dans les fichiers donc).
dhclient sera /sbin/dhclient et pas /usr/sbin/dhclient
apres le "sudo systemctl enable dhclient.service", fait un "sudo systemctl start dhclient.service" pour démarrer sans reboot. puis un "sudo systemctl status dhclient.service" pour voir si tu reçoit bien un lease pour le /56 du DUID.
Tu peux consulter le journal du client avec "sudo journalctl -b -u dhclient.service" (le -b = depuis le dernier reboot, enleve cette option pour voir depuis toujours). c'est tres utile pour voir le renew et/ou des erreurs de DUID.
Comme indiqué dans la doc il faut aussi activé SLAAC dans l'interface. Pour ne pas configurer d'adresse SLAAC, cf la fin de https://documentation.online.net/en/dedicated-server/network/ipv6/slaac (c'est juste un choix ce n'est pas génant d'avoir aussi une IPv6 SLAAC en plus du bloc /56, faut juste pas mélanger les 2).
-
Tu fais comment un serveur VPN IPv6 avec un /128 ?
Je trouve surprenant qu'un défenseur et promoteur de l'IPv6 comme toi trouve 'acceptable' l'existence meme de ces /128 ....Si on commence par accepter ce genre de chose , on va bientôt accepter le NAT sur IPv6 aussi.
Le minimum c'est /64, on devrait être dogmatique et inflexible la dessus.
Ok, c'est vrai qu'un /128 c'est plus limité que une seule IPv4, je n'avais pas pensé à un VPN et les container vont se développer à l'avenir.
Ikoula a fait un choix intermédiaire assez curieux : /96.
C'est expliqué dans leur documentation https://support.ikoula.com/index-1-2-219-2564-IPV6-serveur-d%C3%A9di%C3%A9%20calcule.html
L'ipv6 se calcul de la manière suivante :
2a00 :c70 :1 :XXX :XXX :XXX :XXX : YYYY /96 où
- « XXX:XXX:XXX:XXX : » sera l’adresse IPv4 actuelle de votre serveur
- « YYYY » sont vos adresses disponibles allant de 0000 à FFFF
L’adresse de votre passerelle sera 2a00:c70:1:XXX:XXX:XXX::1
Ce type d'implèmentation a un inconvénient supplèmentaire : elle est dépendante d'IPv4 et toutes les machines doivent avoir une IPv4 publique, même celles où c'est inutile.
-
et les container vont se développer à l'avenir.
C'est surtout que les développeurs actuels, qui travaillent sur les applications de demain, utilisent des containers.
Si avec leur choix foireux les hébergeurs comme OVH, Online, Ikoula, etc rendre l'utilisation d'IPv6 avec les containers difficiles voir impossibles (cas d'un /128), les développeurs ne vont pas pousser non plus pour IPv6 et souvent ne vont meme pas tester leur applications avec IPv6... C'est un peu la poule et l’œuf...
Si on veut pour demain un avenir radieux a IPv6 , il faut aider les développeurs maintenant notamment par des infrastructures a destination des développeurs qui soient bien conçues et 'propres' au niveau IPv6.
-
Côté Apple, ils imposent une compatibilité IPv6 des applis qui sont publiées sur le Store.
Cela va faire les pieds aux devs les plus paresseux.
-
Bof, l'appli doit juste pouvoir passer un NAT64, pas besoin d'avoir de la vraie compat v6...
-
Apple interdit juste d'utiliser des IP littérales (par exemple http://46.227.16.8/) : il faut mettre un nom de domaine.
Point problématique : de nombreuses applications emploient des IPv4 littérales et sont quand même validées, ce sui fait que ces applications ne fonctionnent pas en IPv6 only (je ne citerais pas de nom, mais la plupart des applications de domotique ou pour visualiser une caméra de surveillance installée à la maison)
Mais depuis iOS 12, Apple intègre enfin CLAT / 464XLAT et donc il est possible d'utiliser des IPv4 latérales comme sous Android (je ne dis pas que c'est bien de le faire, c'est clairement pas une bonne pratique et cela ne permet pas le https, mais cela permet de passer à IPv6 only sans aucune régression (excepté la régression liée à la réduction de MTU en IPv4 ?).
-
bon comme d'hab la théorie et la pratique ... j'ai donc pris un Dedibox en test pour IPv6. le SLAAC marche mais c'est tout et comme déjà discuté c'est très limité.
Impossible de faire fonctionner un /56. Le support d'Online est dessus et c'est a priori déjà escaladé...
J'ai tenté avec Debian et je constate des erreurs dans le tuto qu'ils fournissent. Notamment a la fin de: https://documentation.online.net/fr/dedicated-server/network/ipv6/slaac
Les serveurs compatible SLAAC devront impérativement avoir cette option activée pour que l'IPv6 DUID fonctionne Préfixe IPv6 /48.
Si vous souhaitez desactiver la configuration via SLAAC, vous pouvez rajouter la ligne suivant dans votre configuration réseau: pre-up /sbin/sysctl -w net.ipv6.conf.eth1.accept_ra=0. Assurez-vous de remplacer eth1 par le nom correct de votre interface.
mais accept_ra=0 ca coupe aussi l’établissement du routage car la gateway est obtenue par ca...Le mec qui a écrit cela n'a clairement pas testé sa solution...Ce n'est pas le seul, car je croise pas mal de gens qui confondent accept_ra et autoconf a cause du comportement par défaut.
Une bonne version serait :
accept_ra=1 (ou 2 si on a des VM ou plusieurs réseaux) - pour obtenir la gateway donc le routage
autoconf=0 - pour pas que l'interface s'autoconfigure une IP
Autre constatation qui montre le peu de soin vis a vis d'IPv6, c'est que ceci ne fonctionne pas si on veut le faire avec https://wiki.debian.org/NetworkConfiguration malgrés leur doc.
On devrait pouvoir faire un truc du genre:
iface eth0 inet6 static
address 2001:0bc8:xxxx:xxxx::1/64
netmask 64
autoconf 0
accept_ra 1 # ou 2
mais la ligne "autoconf 0" n'est pas considérée donc SLAAC se fait quand meme..on est donc obligé d'utiliser des sysctl dans un pre-up ou dans sysctl.conf
Autre probleme, dhclient arrive bien a obtenir un bail du prefix mais quand il fait cela il 'supprime' les addresses IPv6 déja configurées statiquement sur l'interface si elles sont dans le prefix...du coup on doit utiliser le script de hook dhcp pour reconfigurer l'interface...du coup la doc d'online n'est pas bonne non plus a ce niveau (ou j'ai loupé un truc).
Je tenterais une solution full systemd/networkd quand Online m'aura rendu le serveur (ils l'ont bloqué pour comprendre le problème).
Mais sur Ubuntu a cause de Netplan on sait que cette solution ne'est pas envisageable pour l'instant (ou alors faut virer netplan ce qui n'est pas un mal mais plus vraiment 'une config par défaut') (raison: https://bugs.launchpad.net/netplan/+bug/1771886 )
Bref l'impression que cela donne c'est que quasi personne n'utilise IPv6 chez Online et qu'aussi les devs des OS et logiciels ne testent pas a fond leur trucs sur IPv6...pourtant des softs importants comme Debian et ISC DHCP client...
-
Merci de ton retour.
La solution proposée par OVH pour l'IPv6 est donc l'exemple à suivre ?
-
Merci de ton retour.
La solution proposée par OVH pour l'IPv6 est donc l'exemple à suivre ?
OVH a 2 solutions. leur /128 des VPS est clairement non pas un exemple a suivre.
l'autre c'est un bloc statique /64 ... c'est que sur les dédiés. oui c'est plus simple mais du tout dynamique . OVH n'a pas d'annonce de route via RA et oblige d'utiliser a des gateway avec IP public. par contre OVH préconfigure le block quand ils fournissent l'OS, c'est un plus.
A pres c'est plus une question de 'cible' visée. Le pro qui sait configuré lui-meme IPv6 aura plus de souplesse/sécurité avec Online et son /48 (quand ca marche...).
Pour l'amateur/semi-pro sera plus OVH.
Mais pour les trucs simple (amateur, usage pro simple) aucun des 2 n'est un exemple a suivre... Je préfère Vultr.com qui propose un full /64 avec SLAAC/RA (on n'est pas obligé de SLAAC l'IP mais on a la gateway automatiquement). bref la meme config qu'on trouve derriere une box comme Orange ou Free. Mais Vultr limite a un /64 ce qui peut réduire les usages aussi (on est obligé de faire du ND proxy pour le VPN par exemple).
mon classement:
usage grand public: Vultr, OVH, Online
usage pro/semi-pro: Online, Vultr, OVH
apres si on ne compare que les VPS et pas les dédiés, OVH et Scaleway/Online sont tout les 2 a la rue avec leur limitation a /128 (et OVH bon dernier car le /128 est statique et pas SLAAC mais Online ne fait pas de reverse donc en fait ils se battent pour le fond du classement...).
Je n'ai testé IPv6 sur d'autre providers/hébergeurs (je mets a part GCP/AWS/Azure c'est pas le meme niveau) et je me méfie de la "théorie" des docs/marketing.
-
OVH et Online/Scaleway, chez les deux c'est merdique.
Chez OVH il y a un /64, ce qui est bidon puisqu'on peut pas router de sous-réseaux.
Chez Online/Scaleway il y a le dhcp, ce qui est bidon puisque le dhcp est censé être utilisé dans les conditions où on ne connait pas les paramètres réseaux. Et pas dans un environnement où on s'attend à de la stabilité. En plus de ça leurs routeurs ne route pas si le dhcp n'est pas utilisé, il y a quelques jours le serveur dhcp était hors ligne ce qui rendait l'IPv6 complètement indisponible contrairement à l'IPv4. La page incidents ne faisait même pas état de l'IPv6.
-
Chez OVH il y a un /64, ce qui est bidon puisqu'on peut pas router de sous-réseaux.
Hum si, ça va de /65 à /127.
Alors oui tu ne peux pas avoir un sous réseau avec de l'autoconf dedans, mais... who cares ?
-
who cares ?
Genre, ceux qui font attention aux standards.
-
Franchement, pour un sous réseau interne d'hyperviseur, c'est inapproprié.
-
C'est pas glorieux car les autres hébergeurs coté IPv6, c'est pas mieux ou l'IPv6 est provisionné à la main ou il n'y a pas du tout d'IPv6...
-
Hum si, ça va de /65 à /127.
Alors oui tu ne peux pas avoir un sous réseau avec de l'autoconf dedans, mais... who cares ?
c'est avec ce genre de raisonnement 'who cares' qu'on en arrive au /128.
IPv6 a plein mais plein d'adresses, au point que 87% de l'espace d'adressage est pour le moment meme pas considéré.
Pourtant on a déjà des comportements comme ca, qui se satisfont de devoir utiliser des subnet a 65 ou plus, sous prétexte que 'ca marche'.
Je trouve cela tres dommage pour l'avenir et surtout pour la formation des jeunes et l'èmergence d'une "mentalité différente" de ce qu'on a connu avec les restrictions d'IPv4.
J'ai l'impression qu'on est en train de raté les débuts d'IPv6 a cause d'un manque d'effort et de rigueurs. C'est juste dommage.
On peut dire aussi que c'est la faute du standard, ils auraient du arrêter le subnetting a 64 et pas autoriser plus. On sait que laisser la moindre liberté c'est ouvrir la porte a toute sorte de bidouilles pour certains.
-
Je suis le premier a respecter les standards, mais à un moment faut se contenter d'un /64 si c'est le choix d'archi, c'est déjà des milliards d'adresses de plus que ceux qui ne font rien.
-
Je suis le premier a respecter les standards, mais à un moment faut se contenter d'un /64 si c'est le choix d'archi, c'est déjà des milliards d'adresses de plus que ceux qui ne font rien.
"faut se contenter d'un /64 si c'est le choix d'archi" tout est dit...
si OVH ou Online ou n'importe qui d'autre font de la merde faut s'en contenter au lieu de les tanner, leur faire de la mauvaise pub sur le Net, etc ?
et déjà commencez par spammer leur SAV... ca fera peut-être bouger les choses;D
-
Drôle de vision de la vie, harceler les gens, c'est pas spécialement mon truc.
-
y'a un monde entre harcèlement idiot et faire un tweet ou ouvrir un ticket pour se plaindre d'une limitation. prend pas tout au 1er dégré.
-
Je pense que le RIPE aurait du être plus ferme et mettre plus la pression sur l'IPv6 activé par défaut pour distribuer des IPv4 à l'époque où il y en avait encore.
Un pays, la Belgique a réussi à rapidement migrer vers l'IPv6 grâce a une gentille pression du gouvernement qui a demandé aux opérateurs de signer des engagements.
Mon principal espoir aujourd'hui est le fait d'imposer IPv6 activé par défaut sur les smartphones compatibles (pour faire simple Android 5+) dans les licences 5g.
J’espère que cela fera bouger tout l’écosystème comme ce qu'il s'est passé en Belgique.
-
2 jours que le ticket est ouvert...toujours pas d'IPv6 fonctionnelle (hormis le SLAAC). Au vue des échanges sur le ticket, je ne suis meme pas sur qu'ils aient compris le probleme ...
-
Si tu veux une réponse plus rapide, tu peux aller faire coucou sur leur canal IRC/Slack.
-
a priori c'est bon maintenant. je vais continuer mes tests de config...
par contre l'IPv4 du serveur se fait bombarder de tentative de connection ssh (brute force?):
le top 3 (nombre de tentatives, ip distante) depuis 16h30 ce jour (soit depuis 4 heures):
4524 218.92.1.169 = chine
850 58.242.83.28 = usa
616 193.201.224.232 = urkaine
obtenu avec:
sudo journalctl -b -u ssh | grep "Failed password for" | sed -e 's/.*from //' -e 's/ port.*//' | sort | uniq -c | sort -nr | head -3
-
Même pas un petit sshguard ?
-
C'est l'image Debian 9 fournit par Online. Je n'y ai rien configuré a part IPv6.
-
Debian 9 n'a toujours pas la version de fail2ban qui supporte IPv6...
-
Même pas un petit sshguard ?
Pour le coup, passer simplement à une authentification par clé asymétrique, avec pourquoi pas l'ajout d'un second facteur (token hardware type YubiKey) sera plus efficace contre les bruteforce, que d'ajouter une énième parseur de logs potentiellement poutrable :)