Auteur Sujet: IPv6 fallback to IPv4 (Lu 7308 fois)

cali · « **Réponse #12 le:** 03 mai 2022 à 12:30:40 »

Citation de: f1oren le 03 mai 2022 à 05:37:16

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.

vivien · « **Réponse #13 le:** 03 mai 2022 à 12:40:05 »

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".

f1oren · « **Réponse #14 le:** 04 mai 2022 à 11:42:22 »

Citation de: cali le 03 mai 2022 à 12:30:40

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 ;-)

vivien · « **Réponse #15 le:** 15 mars 2023 à 12:52:22 »

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.

renaud07 · « **Réponse #16 le:** 24 avril 2023 à 14:30:04 »

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.

vivien · « **Réponse #17 le:** 24 avril 2023 à 14:38:57 »

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

renaud07 · « **Réponse #18 le:** 24 avril 2023 à 15:46:23 »

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.

vivien · « **Réponse #19 le:** 24 avril 2023 à 16:10:57 »

Il y a aussi ce sujet de 2016: Tutoriel : Désactiver ByteMobile.

Citation de: Boris de Bouygues Telecom le 06 octobre 2016 à 09:02:40

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.

Citation de: renaud07 le 24 avril 2023 à 14:30:04

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) :

Citation de: vivien le 25 juin 2020 à 22:45:09

Le rapport explique que le DPI (Deep packet inspection) est interdit, même pour catégoriser le trafic :

Extrait de la 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, 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.

renaud07 · « **Réponse #20 le:** 24 avril 2023 à 16:35:46 »

Citation de: vivien le 24 avril 2023 à 16:10:57

Il y a aussi ce sujet de 2016: Tutoriel : Désactiver ByteMobile.

C'est ce message que je cherchais. J'y suis passé sur le sujet en plus, mais il m'a échappé. Merci.

Citation de: vivien le 24 avril 2023 à 16:10:57

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.

vivien · « **Réponse #21 le:** 24 avril 2023 à 23:00:59 »

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).

hwti · « **Réponse #22 le:** 25 avril 2023 à 00:13:42 »

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é.

renaud07 · « **Réponse #23 le:** 25 avril 2023 à 15:52:56 »

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)

En vrai c'est prévu dans les CGV, ou juste un bug de connexion ?