- État Fermée
- Pourcentage achevé
- Type Anomalie
- Catégorie Routeur
- Assignée à Personne
- Système d'exploitation Tous
- Sévérité Haute
- Priorité Très Basse
- Basée sur la version 1.2.4
- Due pour la version Non décidée
-
Échéance
Non décidée
-
Votes
1
- xroche (05/06/2017)
- Privée
Ouverte par fenyo - 20/06/2016
Dernière modification par mbizon - 06/08/2020
FS#20358 - IPv6 : le Path MTU Discovery ne fonctionne pas, donc perte de connectivité (sauf pour TCP)
IPv6 est acheminé dans le réseau Free via une encapsulation 6rd. Le MTU est donc de 1480 au lieu de 1500.
La FreeBox envoie bien ce MTU de 1480 dans ses annonces ICMPv6 de type router advertisement.
Donc les machines des clients, derrière leur FreeBox, annoncent un MSS adapté à ce MTU pour leurs connexions TCP sur IPv6.
Donc tout semble marcher, en TCP sur IPv6.
Mais si on fait autre chose que du TCP, ça ne marche plus.
En effet, si on reçoit un paquet non TCP, en IPv6 depuis une machine sur Internet nativement sur IPv6 (sans encapsulation 6rd ou autre type d’encapsulation), ce paquet ne peut pas arriver à la FreeBox et l’émetteur initial n’est pas informé qu’il doit ajuster le MTU pour cette destination routée par la FreeBox.
Voici pourquoi : l’interconnexion IPv6 de Free avec les autres systèmes autonomes constituant Internet n’envoie pas, ou filtre (ce qui revient au même), les paquets IPCMv6 de type “Packet Too Big” qui doivent pourtant être renvoyés lorsqu’un paquet IPv6 de 1500 octets entre dans le réseau IPv6 de Free. Donc l’algorithme PMTUD ne fonctionne pas et l’émetteur continuera à envoyer des paquets de 1500 octets qui n’arriveront jamais à la FreeBox destinataire.
Voici la preuve en analysant deux cas :
1er cas :
Si on lance des gros paquets ICMP depuis une machine chez un opérateur nativement sur IPv6 (cloud BrightBox dans cet exemple), vers une machine chez un opérateur qui encapsule IPv6 (www.tames.eu dans cet exemple), on reçoit alors correctement des ICMP “Packet Too Big” :
fenyo@brightbox# ping6 -s 1440 www.tames.eu PING www.tames.eu(2001:7b8:3f4::152) 1440 data bytes
From gw-524.ede-01.nl.sixxs.net icmp_seq=1 Packet too big: mtu=1280
From gw-524.ede-01.nl.sixxs.net icmp_seq=2 Packet too big: mtu=1280
From gw-524.ede-01.nl.sixxs.net icmp_seq=3 Packet too big: mtu=1280
[...]
2ième cas :
Mais si on fait la même chose depuis cette même machine nativement sur IPv6 (cloud BrightBox) vers une machine IPv6 derrière une FreeBox (fenyo.net), on ne reçoit pas les “Packet Too Big” qui devraient pourtant être envoyés par le routeur Free qui fait l’encapsulation 6rd vers la FreeBox (l’opérateur de www.tames.eu le fait, Free devrait aussi le faire, les conditions sont les mêmes) :
fenyo@brightbox# ping6 -s 1440 fenyo.net
PING fenyo.net(2a01:e35:8aae:bc60:222:15ff:fe3b:59a) 1440 data bytes
— fenyo.net ping statistics — 5 packets transmitted, 0 received, 100% packet loss, time 4030ms
Conclusion : IPv6 chez les clients de Free derrière une FreeBox :
- fonctionne pour TCP dans tous les cas ;
- mais ne fonctionne en UDP (ou autre protocole hors TCP) qu’avec des machines distantes chez des opérateurs qui font aussi de l’encapsulation pour apporter IPv6 au CPE (6rd ou autre). Il est impossible d’échanger de l’IPv6 autre que TCP avec des machines sur Internet nativement en IPv6 (sans encapsulation). C’est pourtant la majorité des machines sur IPv6, c’est donc un gros problème pour tous les protocoles hormis TCP : DNS sur UDP notamment.
Chargement...
Activer les raccourcis clavier
- Alt + ⇧ Shift + l Se connecter/Se déconnecter
- Alt + ⇧ Shift + a Ouvrir une tâche
- Alt + ⇧ Shift + m Mes recherches
- Alt + ⇧ Shift + t Rechercher par ID de tâche
Liste des tâches
- o Ouvrir la tâche sélectionnée
- j Déplacer le curseur vers le bas
- k Déplacer le curseur vers le haut
Détails de la tâche
- n Tâche suivante
- p Tâche précédente
- Alt + ⇧ Shift + e ↵ Enter Modifier cette tâche
- Alt + ⇧ Shift + w Surveiller
- Alt + ⇧ Shift + y Fermer cette tâche
Édition de la tâche
- Alt + ⇧ Shift + s Enregistrer la tâche
Problème confirmé (qui m'oblige a faire un "sudo ifconfig eno1 mtu 1480" sur tous les device concernés) et très gênant
Le pb c'est que Free ne fait rien du tout pour corriger ce problème Pas sérieux, de la part de Free.
Des nouvelles à propos de ce ticket ?
Demande de pare-feu manquant en IPv6 : https://dev.freebox.fr/bugs/task/4110
Demande de reverse DNS en IPv6 : https://dev.freebox.fr/bugs/task/12749
16 avril 2019 à 12:57, le changement : IPv6 par défaut.
→ https://dev.freebox.fr/blog/?p=5382
"Note additionnelle:
L'IPv6 est délivré aujourd'hui sous forme de tunnel (6RD) au dessus l'IPv4 (dit natif). En raison des évolutions internes de notre réseau, le système va progressivement être inversé, et c'est désormais l'IPv6 qui sera natif, et l'IPv4 délivré sous forme de tunnel.
Pour cette raison, désactiver l'IPv6 complètement sur une Freebox revient à potentiellement diminuer les performances réseaux, donc nous enlevons la possibilité de désactiver celui-ci globalement. Cette fonction avait été introduite il y a plus de 10 ans au même moment que la fonction IPv6 de la Freebox, afin d'éviter les problèmes d'interopérabilité avec les systèmes d'exploitation de l'époque.
Notez qu'il est toujours possible de désactiver l'IPv6 sur le périphérique lui-même."
Eh bien, depuis une semaine environ, ce problème est résolu : Free a inversé l'encapsulation, sur ma ligne ADSL (et celles de nombre d'autres clients), c'est désormais de l'IPv6 natif et le MTU est de 1500 en IPv6. Cela n'a pas été sans mal, puisque ce changement est intervenu dans le cadre de modifications plus importantes, qui ont conduit au changement des IP en principe fixes et des préfixes IPv6 normalement aussi fixes... Tout est décrit ici : https://www.thesiteoueb.net/actualite/article-7533-free-victime-d-un-probleme-d-ip-fixe-qui-se-transforme-en-ip-partagee.html
@mbizon: Ce ticket peut être fermé, résolu non ?