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.
Actus fibre Free