Où se trouve le bit non fragmenté des drapeaux IP utilisé?

Je suis curieux de savoir où le bit “Ne pas fragmenter” [DF] des drapeaux IP est utilisé. Comme la fragmentation est invisible pour les couches supérieures et qu’elles ne s’en soucient pas trop.

Je cherche aussi un exemple.

Merci beaucoup d’avance.

La fragmentation n’est pas toujours invisible pour toutes les couches supérieures. Certaines stacks TCP / IP de microcontrôleur anciennes (et probablement même actuelles) n’ont pas mis en oeuvre toutes les fonctionnalités telles que la gestion de la fragmentation. L’utilisation du drapeau dans cette situation permettrait de s’assurer que le paquet est arrivé dans sa forme originale au lieu d’un grand nombre de fragments que l’autre extrémité ne pourrait pas gérer.

De plus, lorsque vous utilisez UDP, il n’est pas nécessaire que tous les fragments arrivent à la destination. Par conséquent, pour éviter la fragmentation, le message doit arriver ou ne pas arriver – il est impossible qu’un peu du datagramme UDP atteigne la destination. . Je ne me souviens plus combien de temps la stack TCP / IP restait en attente de paquets IP non assemblés en attente de fragments manquants, mais l’utilisation de l’indicateur DF signifiait qu’aucune ressource inutile n’était bloquée pendant cette période.

Enfin, vous pouvez l’utiliser pour tester le comportement de l’infrastructure réseau, par exemple ce qui se passe lorsqu’un paquet est plus grand que l’unité de transmission maximale (DF empêchera ce paquet d’être fragmenté pour «passer au travers» du trou).

En plus de la réponse de @ Pax (ou peut-être dans le cadre des tests qu’il a mentionnés), l’indicateur DP est également utilisé dans la découverte du chemin MTU . C’est à ce moment-là que vous essayez de déterminer quel est le plus gros paquet pouvant être envoyé sans fragmentation, pour un lien donné.

Il est souvent utile d’éviter la fragmentation, même si, en théorie, les protocoles de niveau supérieur sont isolés de la mécanique, ils peuvent néanmoins en “ressentir” les conséquences. Si une seule write() au niveau du socket réseau finit par être fragmentée car trop volumineuse et si l’un des fragments est perdu dans le réseau, le paquet IP entier sera perdu. Cela affecte bien sûr le débit.

Pour cette raison, il est souvent souhaitable de connaître l’ unité de transmission maximale , c’est-à-dire le plus gros paquet pouvant être envoyé à une destination sans être fragmenté. La découverte de MTU par chemin est utilisée pour trouver cette taille, en définissant simplement le bit DF et en envoyant successivement des paquets plus volumineux jusqu’à ce que le réseau signale une défaillance (via ICMP ).

Notez qu’il n’existe pas de méthode standard pour définir DF en C. Sous Linux, ce code fonctionne:

 result = setsockopt(mysocket, IPPROTO_IP, IP_MTU_DISCOVER, IP_PMTUDISC_DO, sizeof(int)); 

mais cela ne fonctionne pas sur FreeBSD 6

En outre, la découverte du chemin MTU est extrêmement peu fiable sur le véritable Internet. Trop de pare-feu et de boîtiers intermédiaires cassés filtrent les messages ICMP “Paquet too big” (voici un bon moyen de tester un administrateur réseau candidat lors d’une interview: demandez-lui d’arrêter de faire un ping et il / elle bloquera probablement complètement ICMP.) Voir RFC 2923: “Problèmes TCP avec la découverte de MTU de chemin”

C’est la raison pour laquelle l’IETF propose désormais une nouvelle méthode pour tester le MTU, sans s’appuyer sur Path MTU Discovery: RFC 4821: “Packetization Layer Path MTU Discovery”.