Auteur Sujet: FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)  (Lu 122296 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 47 079
    • Twitter LaFibre.info
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #96 le: 28 février 2016 à 21:58:02 »
Pour le débit en IPv6 en tout cas il semblait y avoir une limitation à ~9 Mb/s / thread, confirmé par les téléchargements FTP simultanés sur 1.testdebit.info et le test de neutralité. Maintenant, c'est vrai qu'il aurait été intéressant de tester un autre serveur en IPv6, car les différents tests ont visé la même destination.

Voici d'autres serveurs, dispo sur https://testdebit.info/ Online, OVH, ... il y a du choix.

et même l'hébergeur ikoula : remplace le "1" de 1.testdebit.info par "ikoula"

alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 168
  • Delta S 10G-EPON sur Les Ulis (91)
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #97 le: 28 février 2016 à 22:12:33 »
Vivien, Slotthy a fait les tests chez un voisin qui vient juste d'avoir la fibre en ZMD, donc il n'a peut-être pas la possibilité d'y retourner de sitôt...

corrector

  • Invité
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #98 le: 28 février 2016 à 22:30:33 »
Le fait de découper les paquets et les reconstituer à l'autre bout génère une forte charge CPU sur les routeurs qui font ce travail.
Et surtout cela demande de stocker un temps indéfini les fragments qui arrivent, avec un timeout "raisonnable", on arrive à un charge mémoire maximum énorme.

En pratique les paquets arrivent plutôt rapidement et proche les uns des autres, mais ça permet de faire une attaque DOS très facilement ce qui va au moins forcer des purges mémoires plus fréquentes (au pire saturer toutes la mémoire et faire bugger la passerelle) et rendre la défragmentation moins efficace.

C'est un défaut générique de la fragmentation IP. Le fait que ce soit une passerelle au cœur du réseau ne ferait qu'empirer le problème.

Un autre problème de la fragmentation IP est pour les NAPT : il faut défragmenter pour avoir les paquets TCP/UDP/... complets afin de faire correspondre chaque paquet à une règle de NAT.

De même de façon plus générale, c'est le cas dès qu'on veut faire du suivi de connexions (conntrack sous linux) : l'activation de conntrack active la défragmentation de tous les paquets automatiquement.

De même de façon encore plus générale, quand on veut appliquer un filtre sur les ports dans le pare-feu. Mais là on peut éventuellement tolérer que les fragments supplèmentaires ne soient pas filtrés, vu qu'ils ne seront jamais complétés si le premier paquet est rejeté.

Cela génère aussi de la gigue, les petits paquets qui ne nécessitent pas d'être découpés arrivent avant les plus gros qui sont passé par l'étape fragmentation / reconstitution.
Pas forcèment.

Les gros paquets n'arrivent pas après les petits en Wifi, que je sache.

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #99 le: 29 février 2016 à 01:03:57 »
Il y a quelque chose de bizarre dans le test de MTU de Slothy : normalement le ping trop gros devrait sortir "Le paquet doit être fragmenté mais paramétré DF.".
Peut-être que la Freebox ne répond pas, au lieu d'envoyer un ICMP type 3 (Destination Unreachable) code 4 (fragmentation needed and DF set).
Si c'est le cas, ça pourrait expliquer les problèmes sous Linux en IPv4 (https://tools.ietf.org/html/rfc2923), si la Freebox n'ajuste pas le MSS non plus.
Peut-être que Windows détecte ce genre de situations et désactive le PMTU Discovery (et donc ne positionne plus DF sur les paquets de la connexion TCP), ce qui fait que ça fonctionne, mais en fragmentant.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #100 le: 29 février 2016 à 14:50:21 »

corey

  • Abonné Free fibre
  • *
  • Messages: 20
  • Saint Ouen l'Aumône (95)
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #101 le: 01 mars 2016 à 10:22:40 »
Bon, voici les résultats des tests réalisés sur la connexion Free de mon voisin.

Machine utilisée : DELL Precision M6600, i7 quadri coeur, 8 Gb de RAM et SSD connectée en direct en câble à la Freebox.

Speedtest :



-Le débit IPv6 est ridicule, de ce fait je n'ai pas pu terminer le test de neutralité

-Le débit du Speedtest est bien limité par la connexion et non le PC, qui fait 950 Mb/s en FTTH SFR.

Avec un PC (Windows 7 et Firefox) moins performant j'ai les mêmes résultats que toi.
Quel OS et navigateur utilises tu?

Slothy

  • Abonné Bbox fibre
  • *
  • Messages: 1 169
  • 2x FTTH 1 Gb/s sur Le Plessis-Trévise (94)
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #102 le: 01 mars 2016 à 15:58:23 »
Windows 10 et Firefox.

didjee34

  • Abonné Free fibre
  • *
  • Messages: 90
  • Castelnau-le-Lez (34)
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #103 le: 01 mars 2016 à 17:24:06 »
Hello,

Je n'ai pas eut le temps ce week end de m'y remettre, mais concernant sous Linux le Path MTU Discovery, il faut je pense tester ça :

TCP MTU Probing

0 = disabled
1 = enabled when a black hole router is detected
2 = always enabled

# Enable TCP MTU probing to deal with black hole routers:
echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing
echo 1024 > /proc/sys/net/ipv4/tcp_base_mss

Je vais essayer de faire un test de mise en place d'un tunnel OpenVPN full IPV6 dans la semaine + retester la freebox en bridge sur mon ERLite avec mtu 1472 et avec MTU 1500 + PMTU Discovery

Didier

serge.31

  • Expert (serge.31.free.fr)
  • Abonné Free adsl
  • *
  • Messages: 204
  • Saint-Orens-de-Gameville (31)
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #104 le: 20 mars 2016 à 18:00:08 »
ai-je raté quelque chose ???

Un scan exhaustif en 91.160.x.y ne détecte aucune freebox.
J'ai vérifié qu'il y a des utilisateurs en ip v6 ZMD dont la conversion en v4 s'effectue sur la plage 1/4 des ports (celle qui répond au ping)

le ping serait-il bloqué par free en 91.160 ?

Merci

s3phy

  • Abonné FreeMobile
  • *
  • Messages: 375
  • St Laurent des Hommes (24)
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #105 le: 20 mars 2016 à 18:27:42 »
Laquelle des 4 boxes derrière l'IPv4 doit répondre ?
Ou alors est-ce que c'est l'infra 4rd qui doit répondre ?

Dans les deux cas ça n'avance pas à grand chose que ça réponde, de mon point de vue !

alain_p

  • Abonné Free fibre
  • *
  • Messages: 16 168
  • Delta S 10G-EPON sur Les Ulis (91)
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #106 le: 20 mars 2016 à 18:36:29 »
En plus, l'IPv4 est transportée dans une trame IPv6 (4rd). Vivien avait vu qu'un traceroute sur ces adresses s'arrêtait à l'entrée du tunnel, un routeur à Courbevoie. Donc un scan sur les adresses 91.160 ne mène à rien.

serge.31

  • Expert (serge.31.free.fr)
  • Abonné Free adsl
  • *
  • Messages: 204
  • Saint-Orens-de-Gameville (31)
FTTH ZMD: Free ferait du 4rd (IPv4 portée par IPv6 et NAT sur le réseau)
« Réponse #107 le: 20 mars 2016 à 23:28:37 »
OK