Aller au contenu principal

Introduction

Le protocole Internet (Internet Protocol, IP) [1] est utilisé pour le service de datagramme hôte-à-hôte dans un système de réseaux interconnectés appelé catenet [2]. Les dispositifs de connexion réseau sont appelés passerelles (gateways). Ces passerelles communiquent entre elles à des fins de contrôle via un protocole passerelle-à-passerelle (Gateway to Gateway Protocol, GGP) [3,4]. Parfois, une passerelle ou un hôte de destination doit communiquer avec un hôte source, par exemple pour signaler une erreur dans le traitement du datagramme. À cette fin, le protocole de messages de contrôle Internet (Internet Control Message Protocol, ICMP) est utilisé. ICMP utilise le support de base d'IP comme s'il s'agissait d'un protocole de niveau supérieur, cependant ICMP fait en réalité partie intégrante d'IP et doit être implémenté par chaque module IP.

Les messages ICMP sont envoyés dans plusieurs situations : par exemple, lorsqu'un datagramme ne peut pas atteindre sa destination, lorsque la passerelle n'a pas la capacité de mémoire tampon pour transférer un datagramme, et lorsque la passerelle peut diriger l'hôte pour envoyer le trafic sur un itinéraire plus court.

Le protocole Internet n'est pas conçu pour être absolument fiable. L'objectif de ces messages de contrôle est de fournir un retour d'information sur les problèmes dans l'environnement de communication, et non de rendre IP fiable. Il n'y a toujours aucune garantie qu'un datagramme sera livré ou qu'un message de contrôle sera retourné. Certains datagrammes peuvent encore être non livrés sans aucun rapport de leur perte. Les protocoles de niveau supérieur qui utilisent IP doivent implémenter leurs propres procédures de fiabilité si une communication fiable est requise.

Les messages ICMP signalent généralement des erreurs dans le traitement des datagrammes. Pour éviter la récursion infinie de messages sur les messages, etc., aucun message ICMP n'est envoyé concernant les messages ICMP. De plus, les messages ICMP ne sont envoyés que concernant les erreurs dans le traitement du fragment zéro des datagrammes fragmentés. (Le fragment zéro a un décalage de fragment égal à zéro).

Principes de conception clés​

1. Partie de la couche IP​

Couche Application
    ↓
Couche Transport (TCP/UDP)
    ↓
Couche Réseau (IP + ICMP) ← ICMP fait partie intégrante d'IP
    ↓
Couche Liaison de données

ICMP n'est pas un protocole de niveau supérieur qui utilise IP ; c'est plutôt une partie intégrante de la couche IP elle-même.

2. Signalement d'erreurs, pas de fiabilité​

Ce que fait ICMP :

  • ✅ Signale les problèmes dans le traitement des datagrammes
  • ✅ Fournit un retour d'information sur les conditions réseau
  • ✅ Aide au diagnostic réseau

Ce que ICMP ne fait pas :

  • ❌ Garantir la livraison des messages
  • ❌ Rendre IP fiable
  • ❌ Fournir une fiabilité de bout en bout
  • ❌ Implémenter le contrôle de flux

3. Pas de récursion infinie​

Règle : Les messages ICMP ne sont jamais envoyés concernant les messages ICMP.

Datagramme avec erreur
    ↓
Message d'erreur ICMP envoyé ✅
    ↓
Message ICMP avec erreur
    ↓
AUCUN message d'erreur ICMP envoyé ❌ (Empêche la boucle infinie)

Exemple :

1. Paquet TCP → Datagramme IP → Erreur se produit
   → ICMP Destination Unreachable envoyé ✅

2. ICMP Destination Unreachable → Erreur se produit
   → AUCUN message ICMP envoyé ❌

Cela empêche les cascades de messages d'erreur

4. Règle du fragment zéro​

Les messages d'erreur ICMP ne sont envoyés que pour le premier fragment (décalage de fragment = 0) d'un datagramme fragmenté.

Datagramme original (fragmenté) :
┌─────────────┬─────────────┬─────────────┐
│ Fragment 0  │ Fragment 1  │ Fragment 2  │
│ offset=0    │ offset=500  │ offset=1000 │
└─────────────┴─────────────┴─────────────┘
      ↓              ↓              ↓
   Erreur         Erreur         Erreur
      ↓              ↓              ↓
ICMP envoyé ✅  Pas d'ICMP ❌  Pas d'ICMP ❌

Justification :

  • Évite de générer plusieurs messages d'erreur pour le même datagramme original
  • Garantit que le signalement d'erreurs est gérable
  • Seul le premier fragment contient des informations complètes sur le protocole de couche supérieure

Scénarios courants pour les messages ICMP​

Scénario 1 : Destination inaccessible​

Hôte A → Routeur → [Réseau B en panne]
         ↓
    ICMP Type 3 : Destination Unreachable
         ↓
       L'hôte A reçoit la notification d'erreur

Scénario 2 : Redirection​

Hôte A → Passerelle 1 → Passerelle 2 → Destination
         ↓
    ICMP Type 5 : Redirect
    « Utilisez Passerelle 2 directement pour cette destination »
         ↓
       L'hôte A met à jour la table de routage

Scénario 3 : Temps dépassé​

Paquet avec TTL=1
    ↓
Le routeur décrémente TTL à 0
    ↓
ICMP Type 11 : Time Exceeded
    ↓
L'hôte source reçoit la notification

Scénario 4 : Limitation de source (Contrôle de congestion)​

Mémoire tampon de passerelle pleine
    ↓
ICMP Type 4 : Source Quench
    ↓
L'hôte source ralentit le taux de transmission

Note : Source Quench est maintenant déprécié (RFC 6633) en raison de son inefficacité et du potentiel d'abus.

Relation avec d'autres protocoles​

ICMP et IP​

Datagramme IP :
┌─────────────┬──────────────────┐
│  En-tête IP │   Charge utile IP │
│ Protocol=1  │   Message ICMP    │
└─────────────┴──────────────────┘

En-tête IP :
- Champ Protocol = 1 (indique ICMP)
- Source Address = expéditeur ICMP
- Destination Address = destinataire ICMP

ICMP et GGP​

Protocole passerelle-à-passerelle (Gateway to Gateway Protocol, GGP) :

  • Les passerelles utilisent GGP pour la communication de contrôle entre elles
  • ICMP est utilisé pour la communication passerelle-vers-hôte
  • Des objectifs différents, des protocoles complémentaires

ICMP et les protocoles de couche supérieure​

Application (par ex., utilitaire ping)
    ↓ Construit le message ICMP
Couche IP avec module ICMP
    ↓ Envoie ICMP dans un datagramme IP
Interface réseau

Exemples de signalement d'erreurs​

Exemple 1 : Hôte inaccessible​

Étape 1 : L'hôte A envoie un paquet à l'hôte B (10.0.2.100)
┌─────────────────────────────┐
│ Src : 10.0.1.10             │
│ Dst : 10.0.2.100            │
│ Data : « Hello »            │
└─────────────────────────────┘

Étape 2 : Le routeur R1 détermine que l'hôte B est inaccessible
Table de routage du routeur R1 : Pas de route vers 10.0.2.0/24

Étape 3 : Le routeur R1 envoie ICMP Destination Unreachable
┌─────────────────────────────┐
│ ICMP Type : 3               │
│ Code : 1 (Host Unreachable) │
│ Contient : En-tête IP + 64  │
│            bits du           │
│            datagramme        │
│            original          │
└─────────────────────────────┘

Étape 4 : L'hôte A reçoit ICMP et signale l'erreur à l'application

Exemple 2 : Fragmentation nécessaire mais DF défini​

Étape 1 : L'hôte A envoie un grand paquet avec le flag Don't Fragment (DF)
┌─────────────────────────────┐
│ Src : 192.168.1.10          │
│ Dst : 203.0.113.50          │
│ Flags : DF=1 (Don't Fragment)│
│ Length : 1500 bytes         │
└─────────────────────────────┘

Étape 2 : Le routeur R1 reçoit le paquet
- MTU de l'interface sortante = 1000 bytes
- Taille du paquet = 1500 bytes
- Le flag DF est défini → Ne peut pas fragmenter

Étape 3 : Le routeur R1 envoie ICMP Destination Unreachable
┌─────────────────────────────┐
│ ICMP Type : 3               │
│ Code : 4 (Fragmentation     │
│          needed but DF set) │
│ Next-Hop MTU : 1000         │
└─────────────────────────────┘

Étape 4 : L'hôte A reçoit ICMP
- Implémente Path MTU Discovery
- Réduit la taille du paquet à 1000 bytes
- Renvoie les données

C'est un mécanisme critique pour la découverte du MTU de chemin (Path MTU Discovery, PMTUD) [RFC 1191].

Règles de traitement​

Pour les expéditeurs ICMP​

  1. Déterminer si ICMP doit être envoyé :

    • Est-ce une condition d'erreur ?
    • Est-ce concernant un message ICMP ? (Si oui, ne pas envoyer)
    • Est-ce concernant le fragment zéro ? (Si ce n'est pas le fragment zéro, ne pas envoyer)

  2. Construire le message ICMP :

    • Définir Type et Code appropriés
    • Calculer le checksum
    • Inclure l'en-tête IP original + 64 bits des données originales

  3. Envoyer via IP :

    • Utiliser le protocole IP 1 (ICMP)
    • Définir les champs d'en-tête IP appropriés

Pour les récepteurs ICMP​

  1. Valider le message :

    • Vérifier le checksum
    • Vérifier les valeurs Type et Code

  2. Traiter selon le Type :

    • Messages d'erreur : Signaler au protocole de couche supérieure
    • Messages de requête : Générer une réponse
    • Messages d'information : Traiter en conséquence

  3. Passer au gestionnaire approprié :

    • Démultiplexer en fonction des informations du datagramme original
    • Notifier le protocole ou l'application affecté

Contexte historique : ICMP a été défini dans la RFC 792 (septembre 1981) comme partie de la suite de protocoles Internet originale. Il reste un composant fondamental de la mise en réseau IP, bien que certains types de messages aient été dépréciés et de nouveaux ajoutés au fil des ans.

Dernière mise à jour le