Je travaillais sur un projet qui inclut le développement d'une application utilisant des sockets Java. Cependant, tout en lisant des principes fondamentaux et un nouveau paradigme IPv6 qui m'a motivé à poser ci-dessous la question,
Quels sont les avantages de l'élimination de la fragmentation de IPv6?
Il serait utile que quelqu'un puisse me donner la compréhension de pourquoi?
J'ai recherché sur Internet mais je n'ai trouvé aucune description utile.
3 Réponses :
Je n'ai pas la réponse "officielle" pour vous, mais simplement basée sur la lecture Comment IPv6 gère des datagrammes trop volumineuses, je suppose que je suppose que la charge sur les routeurs. La fragmentation et le remontage incontournable au-dessus du routeur. IPv6 déplace ce fardeau vers les nœuds de fin et nécessite qu'ils effectuent la découverte de MTU pour déterminer la taille maximale de datagramme qu'ils peuvent envoyer. Il s'agit de raisonner que les nœuds finaux conviennent mieux à la tâche car ils ont moins de données à traiter. Efficacement, les routeurs ont assez sur leurs plaques; Il est logique de forcer les nœuds à y faire face et de laisser les routeurs simplement déposer quelque chose qui dépasse leur seuil MTU.
Idéalement, le résultat final serait que les routeurs peuvent gérer une charge plus grande sous IPv6 (toutes les choses étant égales) qu'elles ne l'ont fait sous IPv4 car il n'y a pas de fragmentation / réassemblage qu'ils doivent s'inquiéter. Ce pouvoir du processeur peut être dédié au trafic de routage.
" La fragmentation et le réassemblage entraînent des frais généraux au routeur " Pourquoi un routeur traite-t-il un réassemblage?
Il est une mauvaise compréhension commune qu'il ya pas fragmentation IPv6 parce que l'en-tête IPv6 ne pas le champ de décalage fragment qui ne IPv4; Cependant, ce n'est pas tout à fait exact. IPv6 ne permet pas aux routeurs de paquets fragment; cependant, les nœuds finaux peut insérer un en-tête fragmentation IPv6 1 .
RFC 5722 états 2 , l'un des problèmes de fragmentation est qu'il tend à créer des trous de sécurité. Au cours de la fin des années 1990, il y avait plusieurs attaques bien connues sous Windows 95 qui a exploité chevauchement des fragments IPv4 3 ; En outre, la fragmentation en ligne de paquets est risqué de graver sur Internet routeur silicium en raison de la longue liste des questions qui doivent être traitées. L'un des plus grands problèmes est que des fragments qui se chevauchent en mémoire tampon dans un routeur (en attente de réassemblage) pourraient causer une vulnérabilité de sécurité sur cet appareil si elles sont mal manche. Le résultat final est que la plupart des implémentations de routeur poussent les paquets nécessitant une fragmentation des logiciels; cela ne suivent pas à grande vitesse.
L'autre problème est que si vous les fragments Assemblez à nouveau, vous devez les tampons pendant une période de temps jusqu'à ce que le reste sont reçus. Il est possible pour quelqu'un de tirer parti de cette dynamique et envoyer un très grand nombre de fragments IP inachevés; forçant le dispositif en question à dépenser beaucoup de ressources en attendant l'occasion de rassembler. implémentations intelligentes limitent le nombre de fragments exceptionnels pour empêcher un déni de service de cette; Toutefois, la limitation des fragments en suspens pourraient affecter de manière légitime le nombre de fragments valides qui peuvent être réassemblés.
En bref, il y a trop de problèmes de poilus pour permettre un routeur à la poignée fragmentation. Si les paquets IPv6 exigent la fragmentation, les hôtes doivent être mises en œuvre assez intelligent pour utiliser TCP Chemin découverte de MTU . Cela implique aussi que plusieurs messages ICMPv6 doivent être autorisés de bout en bout; Il est intéressant de nombreux administrateurs de pare-feu IPv4 bloquent ICMP pour se prémunir contre la cartographie de réseau hostile (puis bloquer naïvement tout ICMPv6), sans se rendre compte que le blocage de toutes les choses pauses ICMPv6 de façon subtile 4 .
Voir la section 4.5 de la Internet Protocol, version 6 (IPv6) Spécification
De RFC 5722: Traitement des fragments IPv6 Chevauchement:
pare-feu couramment utilisés utilisent l'algorithme spécifié
dans [RFC1858] pour éliminer les paquets malveillants qui tentent
pour remplacer des parties de l'en-tête de couche de transport dans
afin de contourner les contrôles de connexion entrants. [RFC1858]
empêche une attaque de fragments se chevauchant sur une
protocole de couche supérieure (dans ce cas, TCP) en recommandant
que les paquets avec un fragment de décalage de 1 soient abandonnées. RFC 4890: Recommandations pour le filtrage des messages ICMPv6 dans Firewalls < / p>
** FIN-NOTES: **
Bien que cela fonctionne bien pour les fragments IPv4, il ne fonctionnera pas
des fragments IPv6. En effet, la partie fragmentable
du paquet IPv6 peut contenir des en-têtes d'extension avant
l'en-tête TCP, ce qui rend ce contrôle moins efficace.
+1, c'est incroyable à quel point les routeurs plus rapides peuvent être quand ils peuvent tout faire dans le matériel
Blocage de tout V4 ICMP est tout aussi néfaste - la fragmentation nécessaire aux réponses sont tout aussi importantes pour PMTUD dans IPv4.
IPv4 a un MTU minimum garanti de 576 octets de 576 octets, IPv6 est 1 500 1 280 octets et la recommandation est de 1 500 octets, la différence est fondamentalement performance. À mesure que la plupart des segments LAN d'utilisateur final sont de 1 500 octets, il réduit les frais de stockage des infrastructures de réseau pour stocker l'état en raison de la fragmentation supplémentaire de ce qui sont des réseaux existants efficacement nécessitant des tailles plus petites.
pour UDP Il n'y a aucune définition dans les normes IPv4 sur la reconstruction de paquets fragmentés, ce qui signifie que chaque plate-forme peut le gérer différemment. IPv6 affirme que la fragmentation et l'ensemble se produiront toujours dans la pile IP et les fragments ne seront pas présentés aux applications.
Je suis désolé, il n'est pas correct que IPv6 nécessite 1500 octets. RFC 2460 permet à la couche2 MTUS aussi bas que 1280 octets, voir la section 5.
Pourquoi est-il important de savoir si le fragment est TCP ou UDP? La fragmentation IPv4 est traitée sur la couche IP.
@ Mike Datagramment Assembly n'est pas garanti. De nombreux piles middleware de messagerie comprennent le code spécifiquement pour la reconstruction lorsque la pile IP sous-jacente ne le garantit pas.
Ma suspicion est que vous mélangez séquençage TCP et re-assemblage pour un octet flux ; Par opposition à UDP (un service de datagramme), ce qui signifie que les charges utiles sont atomiques, par définition. En conséquence, il peut y avoir un code de plate-forme pour construire un flux de messages UDP, mais il est indépendant de la fragmentation IPv4.
@MIKE En fait, je risquez peut-être de mélanger des datagrammes IP bruts avec des datagrammes UDP, des datagrammes UDP peuvent être garantis mais les datagrammes IP ne sont pas. C'est-à-dire que lors de la mise en œuvre d'un protocole personnalisé au-dessus de la propriété intellectuelle.