Pages: 1 [2] 3   En bas

Auteur Sujet: Négociation MTU MSS: comment ça fonctionne ?  (Lu 48814 fois)

0 Membres et 1 Invité sur ce sujet

vivien

  • Administrateur
  • *
  • Messages: 48 042
    • Twitter LaFibre.info
Négociation MTU MSS: comment ça fonctionne?
« Réponse #12 le: 28 février 2016 à 14:56:26 »
Les précédentes captures Wireshark datent de 2008, j'ai refait des captures en 2016 avec IPv4 et IPv6.

La capture consiste à télécharger un fichier "1Mo.iso" remplis de zéros, donc facilement compressible pour que les captures ne prennent pas trop de place.

Voici les url utilisées dans les fichiers Wireshark ci-dessous :
- IPv4 : http://ipv4.lafibre.info/fichiers/1Mo.iso (IP du serveur : 46.227.16.8 sur le VLAN 74)
- IPv6 : http://ipv6.lafibre.info/fichiers/1Mo.iso (IP du serveur : 2a01:6e00:10:410::2 sur le VLAN 74)

Le serveur utilise le VLAN 74 pour sa connexion à Internet, ce qui rajoute 4 octets, toutefois, le VLAN est en dessous de TCP/IP (couche N°2) => il ne change rien à la MSS : les paquets simplement ont une taille de 4 octets supplèmentaire. Quand on parle d'un de MTU de 1500 octets, c'est la taille au niveau IP (couche N°3).

Le client, comme le serveur sont des Linux, donc avec l'option TCP Timestamps est activé (qui prend de la place, mais qui permet au serveur d'être plus agressif, via une connaissance fine de la latence).

Les captures wireshark : (ces fichiers avec l’extension .pcapng.gz sont directement lisibles sous Wireshark, sans avoir à faire une décompression)
- SFR câble en IPv4 : MTU de 1500 / MSS de 1460 => capture coté client et capture coté serveur
- SFR ADSL en IPv4 : MTU de 1492 / MSS de 1452 => capture coté client et capture coté serveur
- SFR ADSL en IPv6 : MTU de 1453 / MSS de 1393 => capture coté client et capture coté serveur
- Ikoula en IPv6 : MTU de 1500 / MSS de 1440 => capture coté client et capture coté serveur


MSS TCP :
  • MTU 1500 (Ethernet) : MSS TCP de 1460 octets
  • MTU 1500 (PPPoA) : MSS TCP de 1460 octets
  • MTU 1500 (PPTP) : MSS TCP de 1460 octets
  • MTU 1492 (PPPoE) : MSS TCP de 1452 octets
  • MTU 1460 (Connexion ADSL qui utilise L2TP) : MSS TCP de 1420 octets

MSS UDP :
  • MTU 1500 (Ethernet) : MSS UDP de 1472 octets
  • MTU 1500 (PPPoA) : MSS UDP de 1472 octets
  • MTU 1500 (PPTP) : MSS UDP de 1472 octets
  • MTU 1492 (PPPoE) : MSS UDP de 1464 octets
  • MTU 1460 (Connexion ADSL qui utilise L2TP) : MSS UDP de 1432 octets


Niveau 4 : En-tête TCP : 20 octets + option timestamps activé par défaut (12 octets) => 32 octets


Niveau 3 : En tête IPv4 sans option : 20 octets




Niveau 2 : En-tête Ethernet : 30 octets (Wireshark ne prend en compte que 14 octets sans VLAN et 18 octets avec VLAN)
8 octets pour le préambule + SFD (invisible avec Wireshark)
6 octets pour l'adresse de destination
6 octets pour l'adresse source
2 octets pour la longueur en octets du champ de données (champ EtherType).
4 octets pour le Frame Control Sequence qui contient un CRC [Cyclic Redundancy Check] (invisible avec Wireshark)
4 octets pour le VLAN (Optionnel mais souvent utilisé)


Niveau 1 : Inter Frame Gap: 12 octets
12 octets (96 bits) pour l'Inter Frame Gap. Ce délai normalisé (spécification IEEE 802.3) est fixé à 96 bits (soit 9,6 µs sur un Ethernet 10Mbps), il détermine le temps pendant lequel une station doit attendre entre l'émission de deux trames successives.
IP archivée

vivien

  • Administrateur
  • *
  • Messages: 48 042
    • Twitter LaFibre.info
Négociation MTU MSS: comment ça fonctionne?
« Réponse #13 le: 28 février 2016 à 16:23:44 »
En IPv4, sur une box SFR ADSL :

Citation de: vivien le 28 février 2016 à 14:56:26
Les captures wireshark : (ces fichiers avec l’extension .pcapng.gz sont directement lisibles sous Wireshark, sans avoir à faire une décompression)
- SFR ADSL en IPv4 : MTU de 1492 / MSS de 1452 => capture coté client et capture coté serveur[/size]

Voici les captures d'écran de ce fichier capture coté client et capture coté serveur :

Le client èmet un [SYN] avec une MSS de 1460 octets :




La box ADSL a modifié le MSS à la volée pour mettre 1452 octets, c'est ce que reçoit le serveur pour le même paquet :  (diminution de 6 octets à cause du PPPoE)




La réponse du serveur avec un [SYN, ACK] avec une MSS de 1460 octets :




La box ADSL modifie là aussi le paquet reçu du serveur pour lui mettre un MSS à 1452 octets :



Le connexion va donc s’établir à 1452 octets de MSS (diminution de 6 octets à cause du PPPoE).
IP archivée

vivien

  • Administrateur
  • *
  • Messages: 48 042
    • Twitter LaFibre.info
Négociation MTU MSS: comment ça fonctionne?
« Réponse #14 le: 28 février 2016 à 16:41:27 »
En IPv6, sur une box SFR ADSL :

Citation de: vivien le 28 février 2016 à 14:56:26
Les captures wireshark : (ces fichiers avec l’extension .pcapng.gz sont directement lisibles sous Wireshark, sans avoir à faire une décompression)
- SFR ADSL en IPv6 : MTU de 1453 / MSS de 1393 => capture coté client et capture coté serveur

Voici les captures d'écran de ce fichier capture coté client et capture coté serveur :

Le client èmet un [SYN] avec une MSS de 1440 octets soit une MTU de 1500 => MSS  = 1500 - (40 octets pour IPv6 + 20 octets pour TCP) :




La box ADSL ne  modifie pas le MSS en IPv6 (contrairement à IPv4à, le serveur reçoit donc un MSS de 1440 (= MTU 1500) :




La réponse du serveur avec un [SYN, ACK] avec une MSS de 1393 octets soit une MTU de 1453 octets :




La box ADSL reçoit le paquet tel que :

IP archivée

vivien

  • Administrateur
  • *
  • Messages: 48 042
    • Twitter LaFibre.info
Négociation MTU MSS: comment ça fonctionne?
« Réponse #15 le: 28 février 2016 à 16:43:10 »
A noter que la Neufbox utilisée est pas un modèle top récent : c'est un NeufBox v4 qui date de l'époque de Neuf Telecom :

Le protocole indique mixte PPPoE + DHCP : PPPoE est pour Internet, DHCP est utilisé pour les service TV et est priorisé sur le tunnel PPPoE.

IP archivée

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
Négociation MTU MSS: comment ça fonctionne?
« Réponse #16 le: 28 février 2016 à 20:22:39 »
Citation de: vivien le 28 février 2016 à 16:41:27
Je cherche a comprendre comment le serveur à conclut que la MSS était de seulement 1393 octets.
Bizarre, je n'observe pas la même chose.
J'envoie MSS=1420 (car PMTU=1480 à cause du 6rd), qui n'est je suppose pas modifié par la Freebox.
Je reçois MSS=1440, donc une MTU de 1500 ce qui veut dire que :
 - le serveur a donné cette valeur
 - la Freebox ne l'a pas modifiée, ce qui est étonnant : si mon PC en tenait compte (ce qui n'est pas le cas, j'ai vérifié en faisant un POST) il y aurait de la fragmentation en upload à cause du 6rd
« Modifié: 29 février 2016 à 01:35:10 par hwti »
IP archivée

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 602
  • La Madeleine (59)
Négociation MTU MSS: comment ça fonctionne?
« Réponse #17 le: 28 février 2016 à 20:24:30 »
Aucune fragmentation n'est possible en ipv6
IP archivée

vivien

  • Administrateur
  • *
  • Messages: 48 042
    • Twitter LaFibre.info
Négociation MTU MSS: comment ça fonctionne?
« Réponse #18 le: 28 février 2016 à 20:41:03 »
hwti, j'ai un peu de mal à comprendre pourquoi ton PC client n’envoie pas une MSS de 1440, il ne sait pas qu'il y a du 6rd...

Pour montrer que le serveur a bien une MSS de 1440 en IPv6, un test avec un client IPv6 qui gère une MTU de 1500 (donc MSS de 1440 en IPv6) :

En IPv6, un client Ikoula (connexion directe depuis le datacenter) :

Citation de: vivien le 28 février 2016 à 14:56:26
Les captures wireshark : (ces fichiers avec l’extension .pcapng.gz sont directement lisibles sous Wireshark, sans avoir à faire une décompression)
- Ikoula en IPv6 : MTU de 1500 / MSS de 1440 => capture coté client et capture coté serveur

Voici les captures d'écran de ce fichier capture coté client et capture coté serveur :

Le client èmet un [SYN] avec une MSS de 1440 octets soit une MTU de 1500 => MSS  = 1500 - (40 octets pour IPv6 + 20 octets pour TCP) :




Le serveur reçoit ce même paquet :




La réponse du serveur avec un [SYN, ACK] avec une MSS de 1440 octets soit une MTU de 1500 octets :



Le client reçoit le paquet [SYN, ACK] tel que :

IP archivée

hwti

  • Abonné Orange Fibre
  • *
  • Messages: 2 237
  • Chambly (60)
Négociation MTU MSS: comment ça fonctionne?
« Réponse #19 le: 28 février 2016 à 20:50:21 »
Citation de: jack le 28 février 2016 à 20:24:30
Aucune fragmentation n'est possible en ipv6
C'est vrai, j'oubliais.
Donc c'est vraiment bizarre que la Freebox n'ajuste pas le MSS envoyé par le serveur.
Il faut donc que le PC tienne bien compte du MTU donné par la Freebox (voir plus bas), ou du PMTU Discovery (cad des ICMPv6 packet too big).

Citation de: vivien le 28 février 2016 à 20:41:03
hwti, j'ai un peu de mal à comprendre pourquoi ton PC client n’envoie pas une MSS de 1440, il ne sait pas qu'il y a du 6rd...
En fait la route link-local fe80::/64 a une MTU de 1480, qui vient du paquet Router Advertisement de la Freebox : il contient une option MTU.
La MTU locale est donc réduite, ce qui n'est pas optimal : seule la route par défaut, pour les accès distants, en a réellement besoin.
« Modifié: 28 février 2016 à 21:33:03 par hwti »
IP archivée

  • Invité
Négociation MTU - comment ça fonctionne?
« Réponse #20 le: 29 février 2016 à 00:53:17 »
Citation de: vivien le 31 mars 2014 à 09:49:40
En DNS, dès que la taille augmente on passe en TCP.
augmente par rapport à quoi?
IP archivée

vivien

  • Administrateur
  • *
  • Messages: 48 042
    • Twitter LaFibre.info
Négociation MTU MSS: comment ça fonctionne?
« Réponse #21 le: 29 février 2016 à 07:44:15 »
Il y a 15ans, la taille maximale des paquets UDP port 53 utilisée par DNS était de 512 octets. Si une réponse dépassait cette taille, la norme prévoit que la requête doit être renvoyée sur le port TCP 53.

Depuis 1999, cette limite n'existe plus : Il y a très longtemps, lorsque les ministres ne parlaient pas de l'Internet à la télévision, la taille des paquets DNS était limitée à 512 octets (RFC 1035, section 2.3.4). Cette limite a été supprimée par le RFC 2671 en 1999. source: Stéphane Bortzmeyer

Attention, en DNSSEC, la taille peut dépasser 1500 octets, donc là c'est sur qu'il faudra passer en TCP.

Je ne sais pas comment fait DNS pour connaître la taille maximale en UDP. J'imagine qu'il y a une marge, comme un maximum à 1400 octets de données, ce qui i fait qu'on est sur que cela passe, même avec des tunnels comme chez SFR (MTU de 1453 en IPPv6)

A moins que la MTU IPv6 en zone non dégroupée soit de 1421 octets (tunnel L2TP + IPv6 encapsulé dans IPv4)
IP archivée

  • Invité
Négociation MTU MSS: comment ça fonctionne?
« Réponse #22 le: 29 février 2016 à 08:33:34 »
Un serveur DNS peut envoyer des réponses UDP fragmentées.
IP archivée

vivien

  • Administrateur
  • *
  • Messages: 48 042
    • Twitter LaFibre.info
Négociation MTU MSS: comment ça fonctionne?
« Réponse #23 le: 29 février 2016 à 08:51:52 »
Effectivement, tout semble passer en UDP qui sera fragmenté (même en IPv6) :

Le protocole IPv6 a un mécanisme de fragmentation des paquets. L'en-tête d'un fragment contient un champ « Identification » (RFC 2460, section 4.5) qui, avec les deux adresses Source et Destination, identifie de manière unique un paquet fragmenté (tous les fragments de ce paquet ont le même identificateur), et permet donc le réassemblage à la destination. La façon la plus simple d'affecter ces identificateurs est d'avoir, dans chaque machine, un compteur global incrèmenté à chaque paquet qu'on fragmente (section 1 du RFC). Une telle façon de faire mène à des identificateurs prévisibles : un observateur qui se connecte à cette machine peut prévoir quel sera l'identificateur du paquet suivant. Cela a de sérieuses conséquences en terme de sécurité. Ce RFC explore ces conséquences, et propose des solutions.

Petit rappel au passage sur la fragmentation IPv6 : contrairement à la fragmentation IPv4, elle ne peut se faire que dans la machine èmettrice, pas dans les routeurs intermédiaires. Voici un exemple de paquet fragmenté, vu par tcpdump, la réponse DNS, trop grosse, a été fragmentée en deux :

Code: [Sélectionner]
10:45:24.818912 IP6 (hlim 56, next-header Fragment (44) payload length: 432) 2001:4b98:dc2:45:216:3eff:fe4b:8c5b > 2001:67c:1348:7::86:133: frag (0x000079cc:0|424) 53 > 37407: 25110*- q: ANY? . 24/0/1 . [1d] DNSKEY, . [1d] DNSKEY, . [1d] DNSKEY[|domain]
10:45:24.819008 IP6 (hlim 56, next-header Fragment (44) payload length: 1458) 2001:4b98:dc2:45:216:3eff:fe4b:8c5b > 2001:67c:1348:7::86:133: frag (0x000079cc:424|1450)
Source : Stéphane Bortzmeyer, le 7 février 2016
IP archivée
Pages: 1 [2] 3   En haut