Il y a deux erreurs à corriger dont une de ma part...
- Tout d'abord, il n'y a aucun problème pour utiliser des jumbo frames sur de l'ethernet, c'est même un de leurs principaux intérêts. Ça permet de correctement utiliser des liens ethernet 1Gb ou 10Gb. Et l'on ce limite aux réseaux locaux car en cas de passage via internet, il y a peu de chances qu'il n'y ait pas un routeur sur le chemin qui demande la fragmentation du paquet.
- Dans le cas d'IPv6, le header supplémentaire ne concerne pas les jumbo frames mais les jumbo grammes. Ils permettent de repousser encore plus loin les limites.
Aussi bien en IPv4 que en IPv6, la taille maximum de la charge est de 64k vu que le champs qui l'encode est codé sur 16bits. Cette taille est déjà très dure à atteindre car il faut que les couche du dessous en soient capable.
On parle de jumbo frame lorsque le paquet fais plus de 1500 octets mais on reste limité par la taille max de la charge d'un paquet et d'autres considération techniques. Tant que l'on reste en dessous de 64k de charge, on continue de parler de jumbo frame et en IPv6 on reste avec juste le header standard. Si l'on veux passer au dessus, on passe aux jumbo grammes et dans ce cas on ajoute un header supplémentaire qui permet de spécifier une taille de charge allant jusqu'à 4Go.
Le truc c'est que actuellement c'est déjà le bordel pour utiliser des jumbo frame avec 8k de charge, donc on a encore le temps avant de passer au dela de 64k...
Et dans la pratique, les applications qui peuvent réellement tirer profit de frame de plus de 64k sont très spécifiques et vont rarement entrer dans le circuit de routage classique, donc pour les routeurs sur internet il n'y a pas trop à ce préoccuper de ce header et donc il n'impose pas de problèmes de perfs.
On reviens donc bien à header de taille fixe...
[^] # Re: Questions naïves
Posté par beagf . En réponse à la dépêche IPv4 est mort, vive IPv6 !. Évalué à 1.
- Tout d'abord, il n'y a aucun problème pour utiliser des jumbo frames sur de l'ethernet, c'est même un de leurs principaux intérêts. Ça permet de correctement utiliser des liens ethernet 1Gb ou 10Gb. Et l'on ce limite aux réseaux locaux car en cas de passage via internet, il y a peu de chances qu'il n'y ait pas un routeur sur le chemin qui demande la fragmentation du paquet.
- Dans le cas d'IPv6, le header supplémentaire ne concerne pas les jumbo frames mais les jumbo grammes. Ils permettent de repousser encore plus loin les limites.
Aussi bien en IPv4 que en IPv6, la taille maximum de la charge est de 64k vu que le champs qui l'encode est codé sur 16bits. Cette taille est déjà très dure à atteindre car il faut que les couche du dessous en soient capable.
On parle de jumbo frame lorsque le paquet fais plus de 1500 octets mais on reste limité par la taille max de la charge d'un paquet et d'autres considération techniques. Tant que l'on reste en dessous de 64k de charge, on continue de parler de jumbo frame et en IPv6 on reste avec juste le header standard. Si l'on veux passer au dessus, on passe aux jumbo grammes et dans ce cas on ajoute un header supplémentaire qui permet de spécifier une taille de charge allant jusqu'à 4Go.
Le truc c'est que actuellement c'est déjà le bordel pour utiliser des jumbo frame avec 8k de charge, donc on a encore le temps avant de passer au dela de 64k...
Et dans la pratique, les applications qui peuvent réellement tirer profit de frame de plus de 64k sont très spécifiques et vont rarement entrer dans le circuit de routage classique, donc pour les routeurs sur internet il n'y a pas trop à ce préoccuper de ce header et donc il n'impose pas de problèmes de perfs.
On reviens donc bien à header de taille fixe...