La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: vivien le 13 août 2017 à 22:16:42
-
Voici de quoi tester l'IPv6 fallback to IPv4
http://www.portlane.com est un site qui annonce un AAAA (IPv6) mais qui est indisponible en IPv6 (seul IPv4 fonctionne)
Ce ne semble pas lié à un opérateur en particulier, car j'ai testé avec 3 FAI : Orange, Bouygues Telecom et Adeli ⇒ Aucun n'arrive à le joindre en IPv6
Avec certains navigateurs, comme w3m, le fallback (temps pour que le navigateur change de protocole, et utilise IPv4) n'existe pas : le site web ne se charge pas !
-
Salut,
Ce genre de cas, y compris en cas de panne IPv6, vont se multiplier.
Les nouveaux (avenants de) contrats en mutualisé OVH inclus de l'IPv6.
Et même mon petit hébergeur (Obambu) prépare l'IPv6, en interne, sur le mutualisé. Mais pas encore de records AAAA, mais dans certains cas, l'IPv6 est annoncé "ready" via FTP. Et le service client confirme (via ticket support).
-
La présence du fallback dans les navigateurs n'incitent pas non plus ces hébergeurs a la rigueur...
Il faut espérer qu'un jour les navigateurs retire le fallback.
-
Presque 5 ans plus tard, je déterre ce sujet.
Le fallback vers IPv4 est toujours présent dans les navigateurs web et de nombreux autres logiciels, mais ils ne fonctionnent pas quand le réseau possède une "plateforme d'optimisation".
Je vais donner un exemple avec le site de l'opérateur Zeop à la Réunion https://www.zeop.re/ qui est depuis plusieurs semaines inaccessibles depuis les mobiles Orange, Bouygues et SFR qui ont de l'IPv6 (que ce soit de l'IPv6 only ou de l'IPv6 en double pile IPv4+IPv6).
C'est quoi cette "plateforme d'optimisation" ?
C'est une plateforme sur le réseau des opérateurs Orange, Bouygues et SFR qui vise à accélérer le trafic sur certains ports (le port 80 et 443 généralement) en coupant la connexion TCP (que TCP, http/3 sur UDP n'est pas concerné).
Les connexions TCP, initiées par le mobile, ne se terminent pas sur le serveur, mais sur la "plateforme d'optimisation". Cette dernière va contacter le serveur. L'avantage introduit est que la connexion est coupée en deux : une perte de paquet sur la partie internet n'impactera pas le client : c'est la plateforme d'optimisation qui va redemander le paquet en avance de phase de sorte que cela n'aura pas d'impact coté flux mobile.
Autre intérêt, le mobile va avoir le droit à des paramètres (buffers, algorithme de congestion TCP, ETC) optimisé par l'opérateur. Les buffers et algorithme de congestion TCP du serveur ne serviront que sur la partie entre le serveur et la plateforme d'optimisation. C'est appréciable pour des serveurs mal configurés.
Du côté des inconvénients, le fait que la connexion TCP empêche le serveur de pouvoir pousser certaines optimisations et bloque le fallback vers IPv4, car la plateforme d’optimisation gère IPv4 et IPv6.
Free est un opérateur qui n'a pas de "plateforme d'optimisation" : le fallback vers IPv4 fonctionne parfaitement.
Ci-dessous, j'ai testé deux sites qui n'avaient pas d'IPv6 fonctionnel depuis plusieurs jours :
- https://soft.lafibre.info/ (ou la version http http://soft.lafibre.info/) à noter que depuis j'ai rétabli l'IPv6.
- https://www.zeop.re/ (toujours inaccessible en IPv6 quel que soit l'opérateur)
Le test a été fait avec Firefox 99 sous Ubuntu 21.10 connecté en partage de connexion sur un mobile.
-
Free mobile en IPv6 (mobile configuré en IPv6 only en partage de connexion)
Chargement de https://soft.lafibre.info/ : Le serveur commence par initier sa connexion en IPv6, faute de réponse, il bascule 250 ms plus tard en IPv4.
Le temps de chargement de la page est juste retardé de 250 millisecondes.
Cliquer sur l'image pour télécharger la capture Wireshark
(https://lafibre.info/images/wireshark/202204_surf_soft_depuis_free_apn_ipv6.png) (https://lafibre.info/images/wireshark/202204_surf_soft_depuis_free_apn_ipv6.pcapng.gz)
Chargement de la page Zeop en http : Le serveur commence par initier sa connexion sur le port 80 en IPv6, faute de réponse, il bascule 250 ms plus tard en IPv4 sur le port 80.
La page chargée en IPv4 est une redirection vers le site de Zeop en https. Il faut donc initier une nouvelle connexion sur le port 443.
La nouvelle connexion sur le port 443 est mis en attente, le temps d'avoir une réponse en IPv6 de sa connexion sur le port 80 (pour moi, c'est un bug de Firefox).
Il faudra attendre 3 secondes après le début de cette connexion sur le port 80 sans réponse pour que le client lance une connexion en IPv6 sur le port 443.
Là, le fallback fonctionne bien et 250 ms plus tard, il bascule en IPv4 pour la connexion sur le port 443.
Le temps de chargement de la page est retardé de 3 secondes et 250 millisecondes, ce n'est pas rien.
Cliquer sur l'image pour télécharger la capture Wireshark
(https://lafibre.info/images/wireshark/202204_surf_zeop_depuis_free_apn_ipv6.png) (https://lafibre.info/images/wireshark/202204_surf_zeop_depuis_free_apn_ipv6.pcapng.gz)
-
SFR en IPv6 (mobile configuré en double pile IPv4+IPv6 en partage de connexion)
Chargement de https://soft.lafibre.info/ : Le serveur commence par initier sa connexion en IPv6, et là, il y a une réponse.
Ce n'est pas le serveur qui répond, mais la "plateforme d'optimisation" : La plateforme répond tout de suite sans attendre la réponse du serveur, ce qui permet de gagner du temps.
L'échange avec la "plateforme d'optimisation" démarre bien en IPv6, le client envoie son "Client Hello" pour initier le https et la plateforme acquitte sa demande, mais ne répond pas à ce "Client Hello" : Cela ne peut être que le serveur qui peut répondre (la connexion https est elle établie de bout en bout).
Toutes les 10 secondes, le client maintient la connexion ouverte en envoyant un "TCP Keep-Alive" pour éviter qu'elle ne se ferme.
La "plateforme d'optimisation" répondra au premier "TCP Keep-Alive", après 10 secondes, mais pas au suivant à T=20 secondes : pour moi, la "plateforme d'optimisation" a mis à la poubelle cette connexion où le serveur ne répond pas.
Le client va relancer plusieurs "TCP Keep-Alive" vu qu'il n'obtient plus d’acquittement de sa demande et 10 secondes plus tard, il va recommencer une nouvelle connexion en IPv6, sans tenter d'IPv4 vu que le serveur IPv6 lui répond (mais ce n'est pas le serveur, mais la "plateforme d'optimisation").
La page ne se chargera finalement pas. Pas de fallback IPv4.
Cliquer sur l'image pour télécharger la capture Wireshark
(https://lafibre.info/images/wireshark/202204_surf_soft_depuis_sfr_apn_ipv6.png) (https://lafibre.info/images/wireshark/202204_surf_soft_depuis_sfr_apn_ipv6.pcapng.gz)
Chargement de la page Zeop en https : Là le fallback IPv4 va fonctionner, mais c'est un coup de chance : À cause de mauvaise réception radio (je ne captais pas bien le réseau SFR), le paquet de réponse de la "plateforme d'optimisation" arrive 252ms après la demande, ce qui a laissé le temps au client d'ouvrir la connexion en IPv4 via le fallback.
Le client envoie un "Client Hello" en IPv6 (à la plateforme) et en IPv4 (à la plateforme aussi, mais là, il y aura une réponse du serveur) et la connexion se fera la première connexion à répondre au "Client Hello" par un "Server Hello", soit celle en IPv4.
Le temps de chargement de la page est juste retardé de 250 millisecondes, mais c'est un coup de chance. Habituellement, la page ne se charge pas.
Cliquer sur l'image pour télécharger la capture Wireshark
(https://lafibre.info/images/wireshark/202204_surf_zeop_depuis_sfr_apn_ipv6.png) (https://lafibre.info/images/wireshark/202204_surf_zeop_depuis_sfr_apn_ipv6.pcapng.gz)
-
Orange en IPv6 (mobile configuré en IPv6 only avec DNS64 en partage de connexion)
Chargement de https://soft.lafibre.info/ : Ici, on est en IPv6 only avec un DNS64, mais c'est presque comme SFR, sauf que chez SFR, c'est le client qui va couper [RST] la connexion IPv6, car le serveur ne répond plus.
Chez Orange, c'est la "plateforme d'optimisation" qui va après 20 secondes couper la connexion par un [RST]. Là où SFR à fait le choix sur sa plateforme de détruire la connexion et ne plus répondre, Orange, quand un serveur ne répond pas après 20 secondes envoi un [RST].
Le [RST] va faire que le client va immédiatement recommencer l'opération (toujours en IPv6, pas de fallback IPv4, car la plateforme répond).
Chez SFR on avait donc une tentative de connexion toutes les 30 secondes, chez Orange, ce sera toutes les 20 secondes.
La page ne se chargera finalement pas. Pas de fallback IPv4.
Cliquer sur l'image pour télécharger la capture Wireshark
(https://lafibre.info/images/wireshark/202204_surf_soft_depuis_orange_apn_ipv6.png) (https://lafibre.info/images/wireshark/202204_surf_soft_depuis_orange_apn_ipv6.pcapng.gz)
Chargement de la page Zeop en HTTP : Même situation, même cause, c'est similaire. La page ne se chargera pas.
Cliquer sur l'image pour télécharger la capture Wireshark
(https://lafibre.info/images/wireshark/202204_surf_zeop_depuis_orange_apn_ipv6.png) (https://lafibre.info/images/wireshark/202204_surf_zeop_depuis_orange_apn_ipv6.pcapng.gz)
-
Bouygues Telecom en IPv6 (mobile configuré en IPv6 only, avec DNS64 en partage de connexion)
Chargement de https://soft.lafibre.info/ :
On est comme dans le cas Orange, c'est la "plateforme d'optimisation" qui va couper la connexion, mais ce ne sera pas fait après 20 secondes, mais après seulement 10 secondes, en réponse au "TCP Keep-Alive" envoyé par le client pour éviter que la connexion TCP ne se ferme.
Le [RST] va faire que le client va immédiatement recommencer l'opération (toujours en IPv6, pas de fallback IPv4, car la plateforme répond).
- Chez SFR, on avait donc une tentative de connexion toutes les 30 secondes
- Chez Orange, ce sera toutes les 20 secondes.
- Chez Bouygues Telecom, ce sera toutes les 10 secondes.
La page ne se chargera finalement pas plus. Pas de fallback IPv4.
Cliquer sur l'image pour télécharger la capture Wireshark
(https://lafibre.info/images/wireshark/202204_surf_soft_depuis_bouygues_apn_ipv6.png) (https://lafibre.info/images/wireshark/202204_surf_soft_depuis_bouygues_apn_ipv6.pcapng.gz)
Chargement de la page Zeop en HTTP : Même situation, même cause, c'est similaire. La page ne se chargera pas.
Cliquer sur l'image pour télécharger la capture Wireshark
(https://lafibre.info/images/wireshark/202204_surf_zeop_depuis_bouygues_apn_ipv6.png) (https://lafibre.info/images/wireshark/202204_surf_zeop_depuis_bouygues_apn_ipv6.pcapng.gz)
-
À noter que les plateformes d'optimisation ne concernent que TCP.
C'est justement pour éviter toutes ces bidouilles sur les connexions TCP et suivit d'une connexion que http/3 sur UDP (QUIC) a été crée
=> HTTP-over-QUIC s'appellera HTTP/3 (https://lafibre.info/cryptographie/http-over-quic-sappellera-http3/)
Enfin, si le client désactive IPv6, en configurant un APN IPv4 cela fonctionne.
Exemple avec Zeop depuis un mobile Orange avec APN IPv4 only : Le site se charge normalement.
Cliquer sur l'image pour télécharger la capture Wireshark
(https://lafibre.info/images/wireshark/202204_surf_zeop_depuis_orange_apn_ipv4.png) (https://lafibre.info/images/wireshark/202204_surf_zeop_depuis_orange_apn_ipv4.pcapng.gz)
En conclusion, je trouve dommage qu'il ne soit pas possible de désactiver cette plateforme d'optimisation dans son espace client ou mieux qu'elle cesse de répondre pour les IPv6 qui ne répondent pas (elle pourrait être en mode transparent pour une liste d'IPv6 où il n'y a pas eu de réponses lors des précédentes demandes).
Enfin Zeop, pensez à corriger votre IPv6.
-
C'est intéressant, en voyant ça j'aurais d'abord pensé à un problème avec le CLAT, ou un réglage qui empêche sur usage.
Sur ces IP, la présence d'une IPv6 fait que le DNS64 n'en génère pas une à partir de l'IPv4.
-
Non, ce n'est pas lié au CLAT, c'est lié à la plateforme d'optimisation qui répond en IPv6 alors qu'il n'y a aucun serveur en IPv6 qui répond.
SFR n'a pas de DNS64, ni d'IPv6 only et est impacté (sauf dans le cas où le paquet [SYN-ACK] de la plateforme d’optimisation arrive après 250ms)
-
Salut @Vivien,
Concernant zeop.re, merci pour le signalement, l'enregistrement AAAA qui pointait vers une IPv6 invalide a été supprimé. Le site est joignable nativement en IPv4.
-
Concernant zeop.re, merci pour le signalement, l'enregistrement AAAA qui pointait vers une IPv6 invalide a été supprimé. Le site est joignable nativement en IPv4.
Réparer IPv6 aurait été une méilleure solution.
-
Oui, mettre de l'IPv6 serait mieux, mais l'urgence était de retirer l'IPv6 défectueuse.
C'est venu à mes oreilles sous la forme d'un "C'est inacceptable, Orange bloque le site de son concurrent Zeop".
-
Réparer IPv6 aurait été une méilleure solution.
Je suis bien d'accord qu'il serait souhaitable que le site soit joignable aussi en IPv6, après ce n'était pas « réparer l'IPv6 » vu que le serveur n'a jamais été joignable en IPv6, c'était une erreur au niveau DNS ;-)
-
Je remonte ce sujet, car certains sont impactés : https://lafibre.info/os-mobile/modifier-les-reglages-operateurs-sur-un-iphone/msg1007290/#msg1007290
Quand l'opérateur a une "plateforme d'optimisation", une plateforme qui répond au [SYN] envoyé par le client vers une IPv6 sans savoir si le serveur IPv6 est fonctionnel, on bloque le fallback IPv4.
Cette plateforme qui bloque le fallback IPv4 concerne Bouygues Telecom, Orange et SFR.
Faudrait-il prévoir une possibilité de désactiver la plateforme ?
Où de manière plus intelligente, la plateforme ne pourrait pas ne plus répondre pour une liste d'IPv6 où elle n'a pas enregistré de réponse juste avant. Le terminal faisant plusieurs tentatives (toutes en IPv6), l'absence de réponse lors de la seconde tentative permettrait au fallback IPv4 de fonctionner sur cette seconde tentative.
-
Je réagis un peu en retard mais ça me rappelle une vieille plateforme chez bouygues qui a mis du temps à être retirée et qui compressait les images en http je crois. Je n'arrive plus à retrouver le sujet.
Pour moi, oui il faut que ça puisse gicler. C'est fou qu'avec les réseau qu'on a aujourd'hui on en soit encore à faire du "MITM" de la sorte et que l'ARCEP n'y trouve rien à redire.
Si on faisait pareil sur le fixe, je parie que tout le monde crierait au scandale.
-
La compression des images a été retirée avec l'arrivée de la 4G, car elle ralentissait l'affichage des pages (la compression à la volée prend du temps, en 3G le temps réseau gagné permet d'avoir un affichage plus rapide, en 4G, c'est plus lent)
Le sujet de mars 2013 : 3G: SFR viole la neutralité du Net (https://lafibre.info/4g-sfr/3g-sfr-viole-la-neutralite-du-net/)
-
Je ne me rappelais plus que SFR l'utilisait aussi. En fait tout le monde en avait un.
C'était bien bytemobile, par contre, impossible de retrouver le message de Boris je crois, qui annonçait sa disparition du réseau. Enfin, c'est pas très important.
-
Il y a aussi ce sujet de 2016: Tutoriel : Désactiver ByteMobile (https://lafibre.info/qos-mobile/desactiver-bytemobile/).
J'ai une bonne nouvelle à vous annoncer :
Concernant Bouygues Telecom, il ne sera bientôt plus nécessaire de désactiver ByteMobile, vu qu'il va être supprimé de notre réseau les prochains mois.
Pour moi, oui il faut que ça puisse gicler. C'est fou qu'avec les réseau qu'on a aujourd'hui on en soit encore à faire du "MITM" de la sorte et que l'ARCEP n'y trouve rien à redire.
Si on faisait pareil sur le fixe, je parie que tout le monde crierait au scandale.
Concernant les plateformes d'optimisation, cela ne me semble pas enfreindre la neutralité, on ne touche pas au contenu particulier, mais au contenu générique.
Le principal reproche est de bloquer le fallback IPv4 en HTTP/1.x et HTTP/2 (pas d'optimisation possible en HTTP/3) :
Le rapport explique que le DPI (Deep packet inspection) est interdit, même pour catégoriser le trafic :
Extrait de la page 66 (https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020.pdf#page=66) : Le règlement Internet ouvert permet aux FAI d’accéder qu’aux informations contenues dans l’en-tête du parquet IP et dans l’en-tête du protocole de la couche transport (par exemple l’en-tête TCP ou l’en-tête UDP) dont les noms de domaine et URL sont exclus. Par ailleurs, dans une lettre rendue publique (https://edpb.europa.eu/sites/edpb/files/files/file1/edpb_letter_out2019-0055_berecnetneutrality2.pdf), le Comité européen de la protection des données (EDPB) qui a été saisi pour avis, précise que le nom de domaine et l’URL peuvent être qualifiés de données à caractères personnels et à ce titre sont protégées par les dispositions de la directive vie privée et communications électroniques et du règlement général sur la protection des données. Ainsi, les FAI qui utiliseraient le nom de domaine ou les URL à des fins de catégorisation de trafic ou de facturation s’exposeraient non seulement à une violation potentielle du règlement internet ouvert, mais aussi à une possible violation de la protection des données à caractère personnel de leurs clients.
(https://lafibre.info/images/doc/202006_arcep_rapport_etat_internet_2020_4_neutralite_2.png)
-
Il y a aussi ce sujet de 2016: Tutoriel : Désactiver ByteMobile (https://lafibre.info/qos-mobile/desactiver-bytemobile/).
C'est ce message que je cherchais. J'y suis passé sur le sujet en plus, mais il m'a échappé. Merci.
Concernant les plateformes d'optimisation, cela ne me semble pas enfreindre la neutralité, on ne touche pas au contenu particulier, mais au contenu générique.
Le principal reproche est de bloquer le fallback IPv4 en HTTP/1.x et HTTP/2 (pas d'optimisation possible en HTTP/3) :
Même si ça ne touche pas à la couche application, je ne suis pas sûr qu'on y gagne réellement. Sait-on s'ils on fait des tests avant de déployer ? Sans compter que ça fait de la maintenance supplémentaire. Je ne sais pas combien de serveurs sont nécessaires, mais ça doit pas être négligeable avec des millions de clients.
-
Les plateformes d'optimisation permettent d'accélérer, l'accès, pas que dans les territoires à forte latence (territoires ultra-matins), c'est un fait.
Pour moi, une solution pour ne pas bloquer le fallback devrait être développée. Avec la généralisation d'IPv6, c'est nécessaire, car on ne s'aperçoit pas facilement qu'un hébergement IPv6 est défectueux aujourd'hui et le retrait d'IPv4 n'est pas pour tout de suite.
Certains opérateurs n'optimisent que certains ports : TCP 80, TCP 443 et TCP 8080 (ce dernier est utilisé par SpeedTest).
-
Autour du 20-21/12, Ikoula avait un de ses serveurs d'hébergement mutualisé qui ne répondait plus en IPv6.
A cause de la plateforme d'optimisation, depuis un téléphone sur le réseau Orange :
- Chrome bloquait, puis rapidement affichait ERR_CONNECTION_RESET.
- Firefox réussissait à charger la page après quelques secondes d'attente.
En wifi, pas de problème, le fallback IPv4 était instantané.
-
En parlant d'ipv6 cassé, j'ai eu un bug curieux sur la ligne de mon routeur 4G hier : je n'arrivais plus à accéder à archive.org qui est en v4 only.
En faisant un nslookup, j'ai vu que le DNS ne retournait que l'ipv4 et plus l'ipv6 DNS64. Il a fallut que je déconnecte/reconnecte pour que ça revienne. Sur le coup, je me suis dit c'est bouygues qui m'a bloqué l'accès au site, car j'upload en continu pendant des heures en ce moment (je dois être le seul à occuper la B28) ;D
En vrai c'est prévu dans les CGV, ou juste un bug de connexion ?
-
C'était juste vers archive.org, ton souci de connectivité? Je doute que Bouygues te limite comme ca, ils ont un réseau assez neutre.
C'est pas simplement un timeout DNS pour archive.org AAAA qui aurait été mis en cache par le forwarder du routeur ($100 que c'est dnsmasq) ? J'ai assez souvent des timeouts DNS avec bouygues mobile (2001:860:d002:1201::129:201).
-
Oui c'était que vers archive.org. Et je pense aussi au routeur qui a bugé, je n'avais plus en tête le DNS de bouygues pour essayer.
Je crois que je vais finir par me servir de mon propre DNS. Même si ouvrir le 53 sur le web je sais pas si c'est une bonne idée. Ou alors passer par WG ou DoH (encore que, ça marche avec des certificats auto signés) ?
-
Où tourne ton propre resolveur DNS?
J'utilise unbound sur OpenWRT (avec son module dns64), ca marche au poil. Il n'est pas exposé sur internet par contre, bien entendu :)
-
Sur mon raspberry et en slave sur mon serveur/NAS (debian) Pas de soucis non plus avec bind, ça marche très bien.
C'est juste le moyen d'y accéder qui pose question