La fragmentation IP

Introduction

Arrivé à ce stade du cours, vous commencez à être très instruits ! Vous savez :

  • qu’IP est un protocole de niveau 3 qui est donc encapsulé dans un protocole de niveau 2 (voir le chapitre 4 du modèle OSI)
  • qu’IP est conçu pour fonctionner sur divers types de réseaux physiques (Liaisons Louées, Réseaux locaux Ethernet, Token Ring, FDDI voir même liaisons satellites)
  • que chaque réseau physique implémente un protocole de niveau 2 qui lui est propre (MAC Ethernet, MAC Token Ring, HDLC pour les liaisons louées, etc.). Si vous n’en êtes plus convaincu, rendez vous aux chapitre 4 et chapitre 7 du cours sur le modèle OSI.

Que se passe-t-il quand un paquet IP est routé à travers plusieurs réseaux de types différents ? Il est encapsulé dans diverses couches de niveaux 2 successives. Mais ces couches peuvent mettre en oeuvre des protocoles de niveau 2 différents, si les réseaux physiques sont différents. Par exemple, en passant d’un LAN Ethernet à un LAN Token Ring vous changez de protocole de niveau 2. L’un utilise le MAC Ethernet et l’autre le MAC Token Ring, qui sont totalement différents.

Si ces protocoles sont différents, leurs caractéristiques le sont également (la palisse !). Une des caractéristiques qui risque fort de différer et qui nous intéresse ici est la taille de la MTU !

Qu’est-ce donc encore que ce truc ? La MTU, pour Maximum Transmission Unit est la taille du champ information de la trame. C’est à dire la taille du champ où l’on va placer le paquet IP ! Vous voyez où je veux en venir ?

Si au cours du transfert du paquet IP une passerelle doit le ré-encapsuler dans une trame ayant un champ information plus petit que la taille du paquet IP, elle va devoir sortir la presse ou la tronçonneuse !

IP n’a pas choisi la presse, il préfère la tronçonneuse ! Mais rassurez-vous, il est respectueux de vos paquets de données chéris ! Il fait ça bien, sans effusions de sang inutiles ! C’est propre, net et sans cicatrice !

IP a donc prévu un mécanisme de fragmentation qui lui permet de découper un paquet en plusieurs fragments, puis lui permet de reconstituer le paquet original à l’arrivée !

IP : un protocole en mode non connecté !

Mais avant d’étudier la méthode de fragmentation, il faut se rappeler un point important : IP est un protocole de niveau 3 en mode non connecté. Je vous invite à réviser cette notion dans le chapitre 8 du cours OSI.

Un protocole non connecté, comme son nom l’indique, n’établi pas de connexion avec son correspondant avant d’entamer un transfert de données. Le chemin parcouru par les données dans le réseau n’est donc pas préalablement fixé ! Pire ! Ce chemin peut varier d’un paquet à l’autre !

A chaque chemin correspond un délai d’acheminement qui lui est propre. Celui-ci est fonction du nombre de passerelles à traverser, des débits et de la charge des liaisons, des délais de transit sur ces liaisons (surtout sensible dans le cas des liaisons satellites 2*36 000 Km = 72 000 Km de long. Vous savez que l’altitude d’un satellite géo-stationnaire est de 36 000 Km n’est ce pas ?).

En conséquence, il est possible qu’un paquet IP émis après un autre, arrive à destination avant l’autre (je vous accorde que ce n’est pas souvent, mais ça peut arriver !). On dit qu’en mode non connecté le séquencement des paquets en réception n’est pas garanti identique au séquencement des paquets à l’émission. En vérité, comme on aime pas les phrases longues on dit : il n’y a pas de garantie du séquencement ! (c’est plus court non ?).

Retenez-bien cette contrainte ! Parce que dans le cas de la fragmentation, c’est loin de nous simplifier la vie !

Fragmentation et en-tête IP

Rappelez-vous le format du paquet IP (je sais … C’est loin déjà !). Les octets 5 à 8 de l’entête se nomment Identificateur, Flag et Fragment Offset. Nous avions dit que ces octets étaient réservés à la fragmentation (ou segmentation, comme vous voulez !).

Expliquons un peu mieux à quoi servent ces octets :

  • le champ Identificateur (2 octets) : c’est un numéro d’identification inscrit par l’émetteur du paquet. Tous paquets émis par une même machine à l’attention d’un même destinataire porte un numéro d’identification différent. En cas de fragmentation, ce numéro d’identification est recopié dans tous les fragments du paquet d’origine. Ceci permettra au destinataire de repérer tous les fragments d’un même paquet et de reconstituer le paquet d’origine.
  • le champ Flag (3 bits) : il permet de gérer la fragmentation :
    • bit 0: réservé – toujours positionné à 0
    • bit 1 : dit bit DF (Don’t Fragment) – S’il est positionné à 0, la fragmentation est autorisée – S’il est positionné à 1 la fragmentation est interdite. Dans ce dernier cas, si le paquet est trop volumineux pour être encapsulé dans une trame, dont le MTU est inférieur à la taille du paquet, la passerelle qui devrait réaliser la fragmentation retournera à l’émetteur du paquet un ICMP « Paquet non fragmentable ».
    • bit 2 : dit bit MF (More Fragment) – S’il est positionné à 0 il indique que le paquet reçu est le dernier du paquet d’origine. S’il est positionné à 1, il indique que le paquet reçu est un fragment du paquet d’origine mais pas le dernier fragment. Un paquet qui n’a pas été fragmenté aura donc toujours ce bit à 0.
  • le champ Fragment Offset : indique la position du premier octet de données du paquet reçu dans la partie donnée du paquet d’origine. Le premier fragment à donc toujours la valeur 0 (position du premier octet), de même que tous paquets non fragmentés.

Cela vous paraît un peu nébuleux ? Pas clair ? La démonstration par l’exemple sera sans doute plus efficace !

Comment ça marche ?

ATTENTION !

L’offset est en réalité calculé en mot de 20 octets et non pas à l’octet prêt ! Pour des raisons de simplification j’ai ci-dessous considéré que l’on pouvait tronçonner par paquet de 1000 octets et que l’offset serait de 0, 1000, 2000, etc. alors que l’offset serait de 0, 50, 100, etc. La logique ci-dessous est donc correcte mais fausse dans ses valeurs d’offset. A vous de corriger pour vous entraîner !

Supposons que deux stations, A et B, émettent des paquets vers un serveur S. Les paquets transitent à travers un réseau dans lequel il est nécessaire de fragmenter les paquets d’origine qui sont trop volumineux pour passer sur un des supports du réseau. Imaginons que les paquets de départs ont une taille de 4024 octets (4000 octets de données et 24 octets d’entête IP). Dans le réseau une MTU d’un support est limitée à 1024 octets !

La station A émet deux paquets à la suite pour S et la station B n’en émet qu’un ! Enfin, pour faire simple, après l’endroit de fragmentation dans le réseau, le séquencement des paquets n’est pas respecté suite à une reconfiguration automatique du routage. Cela a eu pour effet d’envoyer les premiers paquets sur une route chargée alors que les paquets suivants ont emprunté une route non chargée. En conséquence les paquets arrivent dans le désordre au serveur !

Question : Combien de fragment vont être généré par paquet de 4 000 octets émis ?

Réponse : Chaque fragment ne peut dépasser 1024 octets dont 24 octets d’en-tête, il véhiculera donc 1 000 octets utiles. Comme le paquet d’origine fait 4024 octets dont 24 octets d’entête, il a 4 000 octets utiles. Il faut donc 4000/1000 fragments soit 4 fragments par paquet de 4024 octets. Comme il y a trois paquets émis au total par A et B, le serveur recevra 12 paquets !

Emission de A :

A envoie son premier paquet PA1 vers S. Ce paquet fait 4024 octets, à l’adresse IP source @IPA et l’adresse destination @IPS du serveur. Le paquet n’est pas fragmenté, c’est le paquet originel donc MF(PA1) = 0 et Offset(PA1) = 0. Un numéro d’identification est fixé ID(PA1) = 1000. La fragmentation est autorisée donc DF(PA1) = 0.

Puis immédiatement à la suite A envoie son deuxième paquet PA2 vers S. Ce paquet fait 4024 octets, à l’adresse IP source @IPA et l’adresse destination @IPS du serveur. Le paquet n’est pas fragmenté, c’est le paquet originel donc MF(PA2) = 0 et Offset(PA2) = 0. Le numéro d’identification est incrémenté car c’est le deuxième paquet à destination de S, il est fixé à ID(PA2) = 1001. La fragmentation est autorisée donc DF(PA2) = 0.

Emission de B :

Juste après que A est envoyé son premier paquet, et avant que A n’envoie son deuxième paquet, B émet son propre paquet. Elle émet PB1 vers S. Ce paquet fait 4024 octets, à l’adresse IP source @IPB et l’adresse destination @IPS du serveur. Le paquet n’est pas fragmenté, c’est le paquet originel donc MF(PB1) = 0 et Offset(PB1) = 0. Un numéro d’identification est fixé ID(PB1) = 1000 (Je fais exprès de prendre le même que A, bien que les chances que cela se produise sont très faibles, pour vous montrer que c’est pas grave !). La fragmentation est autorisée donc DF(PB1) = 0.

Dans le réseau une passerelle reçoit les paquets dans l’ordre PA1, PB1, PA2, elle doit les fragmenter :

Fragmentation de PA1 :

    • La passerelle tronçonne la partie Data du paquet reçu en 4 paquets de 1000 octets (dingue ça ! Ca tombre juste ! Trop fort !).
    • Puis elle envoie le premier fragment F1PA1 avec adresse source @IPA et adresse destination @IPS. Le bit DF(F1PA1) = 0, il est toujours recopié à sa valeur d’origine. Le bit MF(F1PA1) = 1, car le premier fragment n’est pas le dernier (sans blague ?) du paquet d’origine. Elle recopie la valeur de l’ID du paquet d’origine soit ID(F1PA1) = 1000. Puis elle positionne à 0 l’offset car c’est bien la position du premier octet de données du fragment dans le paquet d’origine, Offset(F1PA1) = 0.
    • La passerelle émet ensuite le deuxième fragment F2PA1 avec les mêmes caractéristiques que le premier fragment F1PA1, sauf l’Offset(F2PA1) égal à l’Offset(F1PA1) + nombre d’octets utiles véhiculés par F1PA1. Soit Offset(F2PA1) = Offset(F1PA1) + 1000 = 0 + 1000 = 1000.
    • La passerelle émet le troisième fragment sur les même caractéristiques que les deux premiers avec seulement l’Offset(F3PA1) qui différe. Offset(F3PA1) = 2000 (Offset(F2PA1) + 1000).
    • Enfin elle émet le dernier fragment F4PA1 du paquet PA1. Celui est également identique aux précédents hormis : l’Offset(F4PA1) = 3000 (Offset(F3PA1) + 1000) et le bit MF(F4PA1) = 0. En effet F4PA1 est le dernier fragment du paquet d’origine, le bit MF est donc positionné à 0.

Fragmentation de PA2, le principe est le même que pour PA1 :

    • F1PA2 : IPsource = @IPA – IPdest. = @IPS – DF = 0 – MF = 1 – ID = 1001 – Offset = 0
    • F2PA2 : IPsource = @IPA – IPdest. = @IPS – DF = 0 – MF = 1 – ID = 1001 – Offset = 1000
    • F3PA2 : IPsource = @IPA – IPdest. = @IPS – DF = 0 – MF = 1 – ID = 1001 – Offset = 2000
    • F4PA2 : IPsource = @IPA – IPdest. = @IPS – DF = 0 – MF = 0 – ID = 1001 – Offset = 3000

Fragmentation de PB1, c’est le même mécanisme ! Je vous laisse faire ?

Il y a donc 12 fragments émis par la passerelle vers le serveur S. Sur le chemin, entre la passerelle et le serveur, une reconfiguration dynamique du routage a lieu après le passage de F1PA1 à F2PA2. Les fragments F3PA2 a F3PB1 sont émis sur une route différente, plus rapide. Le serveur reçoit donc dans l’ordre : F3PA2, F4PA2, F1PB1 à F4PB1 puis F1PA1 à F2PA2. Le quarté dans le désordre !

Réassemblage des paquets par le serveur :

Toute machine IP maintien des buffers mémoire dans lesquels elle stocke les paquets en attente de réassemblage. La zone mémoire allouée a une taille définie par la taille du paquet. Cette taille varie en fonction des fragments qui arrivent au fil de l’eau. Le début de la zone est marqué par le premier fragment, la fin de zone par le dernier fragment. Il y a une zone mémoire par couple ID-@SourceIP.

IMPORTANT : La méthode de gestion de l’allocation mémoire présentée ici est une supposition. Il n’existe, à ma connaissance, pas de description normalisée de ces opérations. En conséquence cette méthode peut différer d’une implémentation IP à une autre. Quelle qu’elle soit précisément, le principe est bien de stocker les fragments en tampon, jusqu’à reconstitution compléte du paquet originel.

Logique appliquée :

Lorsque le serveur reçoit un paquet, il examine l’adresse source (on suppose que l’adresse destination a déjà été validée), l’ID, l’offset et le bit MF :

  • si MF = 0 et Offset = 0 : ce n’est pas un fragment, c’est un paquet originel. Le serveur place ce paquet sur la file d’attente du protocole supérieur véhiculé par le paquet. Ce protocole est indiqué dans le champ Protocole de l’entête IP.
  • si MF = 0 et Offset <> 0, le paquet est le dernier fragment d’un paquet originel. Le serveur examine le couple ID-@SourceIP du fragment :
    • s’il a déjà en buffer une zone mémoire pour ce couple, il place le paquet en fin de file de buffer.
    • s’il n’a pas de couple ID-@IPsource identique en buffer, il crée une zone mémoire en buffer et place le paquet en fin de file.
  • si MF = 1 et Offset = 0, le paquet est le premier fragment d’un paquet originel. Le serveur examine le couple ID-@SourceIP :
    • s’il a déjà en buffer une zone mémoire pour ce couple, il place le paquet en début de file de buffer.
    • s’il n’a pas de couple ID-@IPsource identique en buffer, il crée une zone mémoire en buffer et place le paquet en début de file.
  • si MF = 1 et Offset <> 0, le paquet est un des fragments d’un paquet originel. Le serveur examine le couple ID-@SourceIP du fragment :
    • s’il a déjà en buffer une zone mémoire pour ce couple, il place le paquet à l’offset indiqué dans le buffer, en décalant éventuellement la zone mémoire des fragments suivants déjà en place.
    • s’il n’a pas de couple ID-@IPsource identique en buffer, il crée une zone mémoire en buffer. Cette zone a la taille de la valeur d’offset + la taille du fragment.

Le serveur considère la file d’attente complète quand il a placé le premier et le dernier fragment ainsi que tous les fragments intermédiaires (vérification de la valeur d’offset + longueur de chaque fragment). Il remonte alors la partie Data au protocole identifié par le champ Protocole de l’entête IP du paquet originel reconstitué.

Séquencement de reconstitution des paquets de A et B :

  • Réception de F3PA2 : MF = 1 – ID = 1001 – IPsource = IPA – Offset = 2000 :
    • Zone mémoire 1001-IPA inexistante -> Création d’une zone de 2000 + 1000 + 24 octets (entête IP) = 3024 octets.
    • Recopie de l’entête IP de F3PA2 sur les 24 premiers octets en plaçant DF, MF et Offset à 0. Les autres champs gardent leur valeur.
    • Placement des données de F3PA2 à l’offset 2000.
  • Réception de F4PA2 : MF = 0 – ID = 1001 – IPsource = IPA – Offset = 3000 :
    • Zone mémoire 1001-IPA existante -> Extension de la zone mémoire de 1000 octets à partir de l’offset 3000.
    • Placement des données de F4PA2 à l’offset 3000.
  • Réception de F1PB1 : MF = 1 – ID = 1000 – IPsource = IPB – Offset = 0 :
    • Zone mémoire 1000-IPB inexistante -> Création d’une zone de 1000 + 24 octets (entête IP) = 1024 octets.
    • Recopie de l’entête IP de F1PB1 sur les 24 premiers octets en plaçant DF, MF et Offset à 0. Les autres champs gardent leur valeur.
    • Placement des données de F1PB1 à l’offset 0.
  • Réception de F2PB1, F3PB1 : Je vous laisse faire !
  • Réception de F4PB1 : MF = 0 – ID = 1000 – IPsource = IPB – Offset = 3000 :
    • Zone mémoire 1000-IPB existante -> Extension de la zone mémoire de 1000 octets à partir de l’offset 3000.
    • Placement des données de F4PB1 à l’offset 3000.
    • Le paquet est complétement reconstitué -> File d’attente du protocole de couche supérieure.
  • Réception de F1PA1 à F4PA1 : Je vous laisse faire, vous savez comment cela se passe maintenant !
  • Réception de F1PA2 : MF = 1 – ID = 1001 – IPsource = IPA – Offset = 0 :
    • Zone mémoire 1001-IPA existante -> Placement des données de F1PA2 à l’offset 0. La zone mémoire avait été dimensionné correstement par l’arrivée de F3PA2. Il n’est pas nécessaire de l’étendre.
  • Réception de F2PA2 : Vous êtes grand maintenant … Je vous laisse faire !

Voilà ! Tous les paquets ont été reconstitués par le serveur ! Vous avez pu remarquer que c’était du travail n’est-ce-pas ? Pendant que le serveur gére ces files il ne fait pas vraiment ce pour quoi il est payé (pas cher, c’est vrai !).

REMARQUE : Nous ne traitons pas dans ce cours des interactions de ce mécanisme avec la couche TCP, mais pour information, sachez qu’en fait l’en-tête TCP (ou UDP) comportant par exemple les numéros de ports sera véhiculée dans le dernier paquet (MF=0) avec les éventuelles données résiduelles.

Trois remarques sur la fragmentation

Si on peut l’éviter, tant mieux !

Il est évident qu’il était impératif d’inclure un mécanisme de fragmentation dans le protocole IP, notamment en raison du fait qu’il peut être véhiculé dans différents protocoles de couche 2, ne présentant pas toujours les mêmes MTU. Cependant si on peut éviter de fragmenter c’est préférable. En effet :

  • les passerelles assurant la fragmentation doivent gérer les modifications d’entête (DF, MF, ID, Offset, etc.) ce qui mobilise du temps CPU qu’elles ne passent pas à commuter !
  • les stations destinataires sont obligés de gérer le réassemblage des paquets ce qui mobilise du temps CPU et de la mémoire.
  • si vous perdez un fragment (voir le cas du TTL ci-dessous par exemple), tout le paquet IP originel est perdu parce qu’il n’aura pas pu être reconstitué complétement. Par contre les ressources réseaux et machines auront été utilisées pour acheminer les autres fragments à bon port.
  • enfin, et là je vous demande me croire sur parole, on peut démontrer que dans le cas de l’emploi d’une couche 4 TCP, la fragmentation IP diminue nettement le rendement du protocole (sous-emploi du fenêtrage). Au point, que certaines implémentations de TCP procéde à un test avant l’émission de leurs segments vers le destinataire. TCP recherche la MTU minimum de la route et adapte la taille de ses messages en conséquence.

Toutes ses raisons expliquent que l’on utilise très rarement, pour ne pas dire jamais, la taille maximum du paquet IP. La majorité des stacks IP proposent des tailles standards comprises en 128 et 512, voir 1024 octets. La fragmentation est ainsi plus rarement employée et les buffers des stations sont moins sollicités.

L’influence du TTL

Au chapitre 3, dans la description de l’entête IP, nous avons présenté le champ TTL (Time To Live). Ce champ, défini sur un octet, permet d’indiquer une durée de vie au datagramme émis.

En effet, le mode non connecté, sans contrôle du séquencement, ni reprise sur erreur du protocole IP, induit qu’un paquet peut être supprimé sans avertir qui que ce soit. Les principes de routage dynamique peuvent également conduire à générer des boucles (momentanément, rassurez-vous !) dans le réseau. Pour éviter qu’un paquet tourne indéfiniment dans le réseau ou soit conservé en file d’attente indéfiniment, on lui donne une durée de vie par le champ TTL.

A l’émission le TTL est généralement fixé à sa valeur maximum, soit 255.

Chaque fois que le paquet va traverser une passerelle, celle-ci décrémente le TTL de 1. Donc en théorie un paquet IP ne pourra jamais traverser plus de 255 routeurs ! C’est déjà bien suffisant ! Mais s’il était nécessaire de dépasser cette limite on pourrait utiliser une astuce nommée : tunneling (mais ne nous éloignons pas du sujet ! Je peux pas tout vous dire ! Il faut laisser un peu de travail à d’autres !).

Lorsqu’une passerelle passe le TTL à 0, elle détruit le paquet et éventuellement envoie un paquet ICMP Time Exceded à l’émetteur du paquet pour l’informer de sa destruction.

Lorsqu’une passerelle fragmente un paquet, tous les fragments partent avec la valeur du TTL d’arrivée (paquet originel) moins 1 !

Que se passe-t-il si une station de destination reçoit 3 fragments sur 4 ? Si le dernier fragment n’arrive jamais ? La station conserve-t-elle indéfiniment les 3 fragments reçus en zone mémoire tampon ? Vous imaginez bien que non !! Si cela se produit trop fréquemment, elle risque de saturer ses buffers !

C’est pourquoi la station va continuer de décrémenter le TTL de l’entête qu’elle a stocké en début de zone mémoire. Cette entête est celle du premier fragment reçu, donc le plus ancien en mémoire. Toutes les secondes elle décrémente ce TTL. S’il atteint la valeur 0 avant que l’ensemble du paquet originel ait été reconstitué, l’ensemble de la file mémoire est effacée !

La station pourra également retourner un ICMP Time Exceded à l’émetteur pour l’informer de la destruction de son paquet !

Bien sûr, si le dernier fragment arrive après la destruction de sa file (à la bourre le fragment !), il sera stocké, comme précédemment dans une nouvelle file, en attente des autres fragments, qui n’arriveront jamais puisqu’ils ont été détruit ! Mais à expiration de son TTL, il sera également détruit !

REMARQUE : Le principe de décrémentation du TTL toutes les secondes est également appliquée dans les files d’attentes des passerelles. Tant qu’un paquet IP reste en mémoire (surcharge du lien de sortie, surcharge CPU, ou autres), son TTL est décrémenté. Cependant si vous avez souvent des paquets qui restent bloqués plus d’une seconde dans votre routeur, je vous conseille de revoir le dimensionnement de votre réseau ! Une seconde de transfert dans une passerelle est un délai intolérable ! Les moyennes acceptées sont plutôt de 2 milli-secondes !

Pourquoi est-ce toujours la station de destination qui réassemble ?

Tout au long de ce chapitre nous avons constamment évoqué les opérations de réassemblage du paquet originel sur la station de destination du paquet. On aurait pu penser que le réassemblage aurait été effectué par un équipement plus proche de la passerelle qui a réalisé la fragmentation, par exemple son voisin direct ! Pourquoi n’est-ce jamais le cas ?

Il y a deux bonnes raisons à cela :

  • la première vraie, bonne raison, est que vous ne pouvez pas garantir qu’une autre passerelle du réseau verra passer tous les fragments d’un paquet ! Dans notre exemple précédent, supposons qu’une passerelle placée sur la route empruntée par F1PA1 à F2PA2, après la passerelle ayant réalisée la fragmentation, tente de reconstituer les paquets car sa MTU de sortie permet d’accueillir des paquets plus gros :
    • Elle pourra reconstituer le paquet PA1, puisqu’elle voit passer F1PA1 à F4PA1.
    • Mais elle ne pourra pas reconstituer PA2 puisqu’elle ne voit passer que F1PA2 et F2PA2, les autres fragments empruntant une autre route !
    • De plus comment peut-elle connaître la taille du paquet originel, pour être en mesure d’affirmer que son lien de sortie à une MTU suffisante au transfert du paquet originel sans le fragmenter ? Elle devrait attendre tous les fragments, pour connaître la taille du paquet global, et finalement se rendre compte qu’elle va devoir le fragmenter !
  • la deuxième raison est que même si une MTU de sortie peut prendre en charge des plus gros paquets, la passerelle ne connaît pas la taille des MTU des autres supports qui constituent le reste de la route ! Elle risque de passer du temps, de consommer des ressources pour réassembler un paquet, qui sera peut-être de nouveau fragmenté par la prochaine passerelle !! Pas vraiment rentable tout ça !

Conclusion du chapitre

Nous en resterons là, pour le chapitre de la fragmentation. Il y a encore sans doute beaucoup à dire, mais nous avons évoqué, je pense, l’essentiel !

Nous avons jusqu’ici décrit les mécanismes majeurs du protocole IP :

  • l’adressage
  • le routage de base
  • l’interaction avec le niveau 2 des LAN
  • la fragmentation

Dans aucun des chapitres nous n’avons évoqué de contrôle d’erreur (hormis le checksum sur l’entête) ou de reprise sur erreur. Nous savons également qu’IP fonctionne en mode non connecté. En fait IP est un protocole de niveau 3 dit non fiable ou aussi appelé « best effort ». Il fait du mieux qu’il peut, mais il peut peu !

Nous avons évoqué les pertes de paquets mais pas de récupération ! Enfin souvent lorsque des erreurs survenaient nous évoquions ICMP mais pas IP !

Le chapitre suivant, vous présente donc succinctement ICMP et certaines de ces fonctions.

Page Précédente | Page Suivante