3. PROTOCOLES DE COUCHE INTERNET (INTERNET LAYER PROTOCOLS)
3.1 INTRODUCTION
Le protocole Internet (Internet Protocol, IP) est le protocole central de la suite de protocoles Internet. Tous les protocoles de transport Internet utilisent IP pour transporter les données de l'hôte source à l'hôte destination. IP est un service d'interréseau sans connexion ou datagramme, et il comprend des dispositions pour l'adressage, la spécification du type de service, la fragmentation et le réassemblage, ainsi que les informations de sécurité.
La couche Internet comprend également le protocole de messages de contrôle Internet (Internet Control Message Protocol, ICMP), qui fournit des fonctions de contrôle et de rapport, et le protocole de gestion de groupe Internet (Internet Group Management Protocol, IGMP), qui est utilisé pour la multidiffusion.
Tous les hôtes Internet doivent implémenter IP et ICMP (MUST). Les hôtes qui supportent la multidiffusion IP doivent également implémenter IGMP (MUST).
3.2 PARCOURS DU PROTOCOLE (PROTOCOL WALK-THROUGH)
3.2.1 Protocole Internet -- IP (Internet Protocol)
Le protocole Internet est défini dans RFC 791 [IP:1]. Le format d'en-tête IP et la sémantique de chaque champ sont bien définis et documentés. Cependant, il existe plusieurs domaines qui nécessitent des clarifications ou des spécifications supplémentaires pour les implémentations d'hôte.
3.2.1.1 Numéro de version (Version Number)
Un hôte doit rejeter silencieusement tout datagramme IP dont le numéro de version n'est pas 4 (MUST) (le numéro de version actuel du protocole Internet).
3.2.1.2 Somme de contrôle (Checksum)
Un hôte doit vérifier la somme de contrôle d'en-tête IP sur chaque datagramme reçu et rejeter silencieusement chaque datagramme ayant une mauvaise somme de contrôle (MUST).
3.2.1.3 Adressage (Addressing)
Chaque datagramme IP comprend une adresse IP source et une adresse IP destination. Une adresse IP a deux composants : un numéro de réseau et un numéro d'hôte.
Le numéro de réseau identifie un réseau physique auquel l'hôte est attaché. Le numéro d'hôte identifie un hôte particulier sur ce réseau.
Un hôte doit supporter les adresses spéciales suivantes (MUST) :
- Diffusion limitée (Limited Broadcast) : 255.255.255.255
- Diffusion dirigée (Directed Broadcast) :
{tous les 1 dans la partie hôte} - Cet hôte sur ce réseau (This Host on This Network) : 0.0.0.0
- Hôte sur ce réseau (Host on This Network) :
{réseau, hôte} - Bouclage (Loopback) : 127.x.x.x
3.2.1.4 Fragmentation et réassemblage (Fragmentation and Reassembly)
Chaque module Internet doit pouvoir transférer un datagramme de 68 octets sans fragmentation (MUST). Un hôte doit pouvoir réassembler des datagrammes fragmentés d'au moins 576 octets (MUST).
3.2.1.5 Identification
Lors de l'envoi d'une copie identique d'un datagramme, le champ d'identification IP doit être le même que pour le datagramme original (MUST).
Lorsqu'un hôte fragmente un datagramme IP, il doit copier le champ d'identification de l'en-tête IP original dans tous les en-têtes de fragment (MUST).
3.2.1.6 Type de service (Type-of-Service)
L'octet de type de service (Type-of-Service, TOS) dans l'en-tête IP est utilisé pour indiquer la qualité de service désirée pour un datagramme particulier. La valeur TOS spécifie l'importance relative du débit, du délai, de la fiabilité et du coût.
Une application doit pouvoir spécifier une valeur TOS pour les paquets qu'elle envoie (MUST). La couche IP doit passer la valeur TOS inchangée à la couche de liaison (MUST).
3.2.1.7 Durée de vie (Time-to-Live)
Le champ durée de vie (Time-to-Live, TTL) est défini par l'expéditeur et décrémenté par chaque routeur qui transfère le datagramme. Lorsque le TTL atteint zéro, le datagramme est rejeté.
Un hôte ne doit pas envoyer de datagramme avec une valeur de durée de vie (TTL) de zéro (MUST NOT). Un hôte ne doit pas rejeter un datagramme simplement parce qu'il a été reçu avec TTL inférieur à 2 (MUST NOT).
3.2.1.8 Options
Plusieurs options IP sont définies :
- Enregistrement de route (Record Route) : Enregistre la route prise par un datagramme
- Horodatage (Timestamp) : Enregistre les horodatages aux routeurs le long du chemin
- Route source (Source Route) : Spécifie la route qu'un datagramme doit prendre
- Sécurité (Security) : Fournit des restrictions de sécurité et de manipulation
Un hôte doit pouvoir agir sur toutes les options IP qu'il reçoit (MUST). Certaines options nécessitent un traitement par chaque hôte qui les reçoit ; d'autres nécessitent un traitement uniquement par l'hôte destination.
3.2.2 Protocole de messages de contrôle Internet -- ICMP (Internet Control Message Protocol)
ICMP [INTERNET:8] est utilisé pour signaler les erreurs et autres informations sur le traitement des paquets IP à la source. Les messages ICMP sont envoyés dans des datagrammes IP.
Chaque hôte doit implémenter ICMP (MUST). Un message d'erreur ICMP ne doit pas être envoyé suite à la réception (MUST NOT) :
- D'un message d'erreur ICMP
- D'un datagramme destiné à une adresse de diffusion IP ou de multidiffusion IP
- D'un datagramme envoyé en diffusion de couche liaison
- D'un fragment non initial
- D'un datagramme dont l'adresse source est invalide
3.2.2.1 Destination inaccessible (Destination Unreachable)
Le message Destination inaccessible est envoyé lorsqu'un datagramme ne peut pas être livré à sa destination pour des raisons autres que la congestion.
Un hôte devrait générer des messages Destination inaccessible avec les codes suivants (SHOULD) :
- 2 (Protocole inaccessible) : Envoyé lorsque le protocole de transport désigné dans un datagramme n'est pas supporté
- 3 (Port inaccessible) : Envoyé lorsque le protocole de transport de destination est incapable de démultiplexer le datagramme
3.2.2.2 Redirection (Redirect)
Un message Redirect est envoyé par un routeur à un hôte pour l'informer d'une meilleure route vers une destination particulière.
Un hôte doit pouvoir agir sur les messages Redirect (MUST). Un hôte doit mettre à jour sa table de routage lors de la réception d'un Redirect (MUST).
3.2.2.3 Source Quench
Source Quench est un mécanisme de contrôle de congestion. Lorsqu'un hôte ou un routeur doit rejeter un datagramme en raison d'un débordement de tampon, il peut envoyer un message Source Quench à la source (MAY).
Un hôte qui reçoit un message Source Quench doit réduire la vitesse à laquelle il envoie des datagrammes à la destination spécifiée (MUST).
3.2.2.4 Temps dépassé (Time Exceeded)
Un message Time Exceeded est envoyé par un routeur lorsqu'un datagramme est rejeté parce que son champ Time-to-Live a atteint zéro.
Un message Time Exceeded est également envoyé par un hôte destination lorsque le réassemblage de fragment ne peut pas être complété dans un délai d'attente.
3.2.2.5 Problème de paramètre (Parameter Problem)
Un message Parameter Problem indique qu'un problème a été détecté lors du traitement d'un paramètre d'en-tête IP, et le datagramme a été rejeté.
3.2.2.6 Requête/Réponse Echo (Echo Request/Reply)
Chaque hôte doit implémenter une fonction de serveur ICMP Echo qui reçoit des requêtes Echo et envoie des réponses Echo correspondantes (MUST).
Une requête ICMP Echo destinée à une adresse de diffusion IP ou de multidiffusion IP peut être rejetée silencieusement (MAY).
3.2.2.7 Requête/Réponse d'information (Information Request/Reply)
Les messages Information Request et Reply sont obsolètes et ne devraient pas être implémentés (SHOULD NOT).
3.2.2.8 Horodatage et réponse d'horodatage (Timestamp and Timestamp Reply)
Les messages Timestamp et Timestamp Reply sont utilisés pour mesurer les temps aller-retour et synchroniser les horloges.
Un hôte peut implémenter ICMP Timestamp (MAY). S'il le fait, il doit suivre le format spécifié pour les horodatages (MUST).
3.2.2.9 Requête/Réponse de masque d'adresse (Address Mask Request/Reply)
Les messages Address Mask Request et Reply permettent à un hôte d'obtenir le masque de sous-réseau pour un réseau local.
Un hôte doit supporter les messages ICMP de masque de sous-réseau s'il supporte le sous-réseautage (MUST). S'il le fait, il doit répondre aux requêtes Address Mask (MUST) et devrait avoir une option de configuration pour envoyer des requêtes Address Mask pendant le démarrage (SHOULD).
3.2.3 Protocole de gestion de groupe Internet -- IGMP (Internet Group Management Protocol)
IGMP [INTERNET:4] est utilisé par les hôtes et les routeurs adjacents pour établir les appartenances aux groupes de multidiffusion.
Un hôte doit implémenter IGMP s'il supporte la multidiffusion IP (MUST). La conformité de niveau 2 (implémentation IGMP complète) est requise (REQUIRED).
3.3 PROBLÈMES SPÉCIFIQUES (SPECIFIC ISSUES)
3.3.1 Routage des datagrammes sortants (Routing Outbound Datagrams)
Pour décider si une destination est locale ou distante, un hôte IP vérifie si l'adresse de destination a le même préfixe réseau que l'une des propres adresses IP de l'hôte.
3.3.2 Réassemblage (Reassembly)
La fonction de réassemblage IP doit se conformer aux exigences suivantes (MUST) :
- Un hôte doit pouvoir réassembler des datagrammes fragmentés d'au moins 576 octets (MUST)
- Le délai de réassemblage doit être d'au moins 60 secondes mais ne doit pas dépasser 120 secondes (MUST)
3.3.3 Fragmentation
Un hôte doit supporter la fragmentation IP locale (MUST). Lors de la fragmentation d'un datagramme, un hôte doit copier certains champs d'en-tête IP dans chaque en-tête de fragment (MUST).
3.3.4 Multihoming local (Local Multihoming)
Un hôte multihomed a plusieurs adresses IP, qui peuvent être sur les mêmes réseaux ou sur des réseaux différents. Un hôte avec plusieurs adresses IP doit pouvoir envoyer et recevoir des datagrammes en utilisant n'importe laquelle de ses adresses IP (MUST).
3.3.5 Transfert de route source (Source Route Forwarding)
Un hôte doit supporter l'origine et le traitement des routes sources (MUST).
3.3.6 Diffusions (Broadcasts)
Un hôte doit supporter la réception et le traitement des datagrammes de diffusion (MUST). Lorsqu'un hôte reçoit un datagramme de diffusion, il doit passer une copie à chaque protocole de transport (MUST).
3.3.7 Multidiffusion IP (IP Multicasting)
Un hôte devrait supporter la multidiffusion IP (SHOULD). Les hôtes qui supportent la multidiffusion IP doivent se conformer aux exigences dans [INTERNET:4] (MUST).
3.3.8 Rapport d'erreurs (Error Reporting)
Les erreurs de couche IP devraient être signalées à la couche transport ou à l'application selon le cas (SHOULD).
3.4 INTERFACE COUCHE INTERNET/COUCHE TRANSPORT (INTERNET/TRANSPORT LAYER INTERFACE)
La couche Internet fournit des services aux protocoles de couche transport (TCP et UDP). L'interface comprend les opérations suivantes :
- Envoi (Send) : Accepter un paquet de la couche transport et l'envoyer
- Réception (Receive) : Accepter un paquet entrant et le livrer à la couche transport
- Rapport d'erreur (Report Error) : Signaler une erreur à la couche transport
3.5 RÉSUMÉ DES EXIGENCES DE LA COUCHE INTERNET (INTERNET LAYER REQUIREMENTS SUMMARY)
| Fonctionnalité | Section | Must | Should | May | Not |
|---|---|---|---|---|---|
| Vérifier la somme de contrôle IP, rejeter les mauvais datagrammes | 3.2.1.2 | x | |||
| Rejeter les datagrammes avec version != 4 | 3.2.1.1 | x | |||
| Réassembler les datagrammes d'au moins 576 octets | 3.2.1.4 | x | |||
| Support de l'adressage de sous-réseau | 3.3.4.2 | x | |||
| Implémenter ICMP | 3.2.2 | x | |||
| Envoyer ICMP Destination inaccessible | 3.2.2.1 | x | |||
| Implémenter le serveur ICMP Echo | 3.2.2.6 | x | |||
| Support de la multidiffusion IP | 3.3.7 | x | |||
| Détection de passerelle morte | 3.3.1.4 | x | |||
| Traiter l'option Record Route | 3.2.1.8 | x | |||
| Traiter l'option Source Route | 3.3.5 | x |