|
|
RFC
792 : Internet Control Message Protocol (ICMP)
Crédits : J. Postel,
ISI,
Traduction : V.G.
FREMAUX / Ingénieur Professeur / EISTI
Statut : Standard
Remplace: RFCs 777, 760
Remplace: IENs 109, 128
Note du traducteur :
Le texte suivant est
la traduction intégrale de la spécification ICMP, telle qu'éditée
par les auteurs originaux du protocole, sans ajouts, commentaires, ni omissions.
Ce document est un standard reconnu et approuvé par la communauté
Internet.
Table des matières
Introduction
Le Protocole Internet (IP) [1]
est utilisé pour la transmission de datagrammes de hôte à
hôte à l'intérieur d'un système de réseaux
interconnectés appelé Catenet [2]. Les appareils raccordant
les réseaux entre eux sont appelés des Routeurs. Ces routeurs
communiquent entre eux en utilisant le protocole Routeur à Routeur
(GGP) [3,4] afin d'échanger des informations de contrôle et
de gestion du réseau. Occasionnellement, un routeur ou un hôte
destinataire peut avoir à communiquer vers l'émetteur du
datagramme, par exemple, pour signaler une erreur de traitement du datagramme.
C'est dans cette perspective qu'a été mis en place le protocole
Internet Control Message Protocol (ICMP). Il s'appuie sur le support de
base fourni par IP comme s'il s'agissait d'un protocole d'une couche supérieure.
ICMP n'en reste pas moins une partie intégrante du protocole IP,
et doit de ce fait être implémenté dans chaque module
IP.
Les messages ICMP sont envoyés
dans diverses situations: par exemple, lorsqu'un datagramme ne peut pas
atteindre sa destination, lorsque le routeur manque de réserve de
mémoire pour retransmettre correctement le datagramme, ou lorsque
le routeur décode de viser l'hôte destinataire via une route
alternative pour optimiser le trafic.
Le protocole Internet n'est
pas, dans sa définition, absolument fiable. Le but de ces messages
de contrôle est de pouvoir signaler l'apparition d'un cas d'erreur
dans l'environnement IP, pas de rendre IP fiable. Aucune garantie que le
datagramme soit acheminé ni qu'un message de contrôle soit
retourné, de peut être donnée. Certains datagrammes
pourront se perdre dans le réseau sans qu'aucun message de contrôle
ne le signale. Les protocoles de niveau supérieur s'appuyant sur
une couche IP devront implémenter leurs propres mécanismes
de contrôle d'erreur et de retransmission si leur objet nécessite
un circuit de communication sécurisé.
Les messages ICMP reportent
principalement des erreurs concernant le traitement d'un datagramme dans
un module IP. Pour éviter de ne pas entrer dans un cercle vicieux
de réémission de message de contrôle en réponse
à un autre message de contrôle et ce sans fin, aucun message
ICMP ne sera réémis en réponse à un message
ICMP. De même les messages ICMP ne seront transmis qu'en réponse
à un traitement erroné du fragment zéro dans le cas
d'un datagramme fragmenté. (Le fragment zéro est celui dont
l'offset vaut zéro).
Formats de message
Les messages ICMP sont émis
en utilisant l'en-tête IP de base. Le premier octet de la section
de données du datagramme est le champ de type ICMP; Sa valeur détermine
le format du reste des données dans le datagramme ICMP. Tout champ
qualifié de "non utilisé" est réservé pour
application future et doit être laissé à zéro
lors de l'émission, les récepteurs ne DEVANT PAS utiliser
ces champs (sauf lorsqu'il s'agit de calculer le Checksum). Sauf mention
particulière contraire signalée dans chaque description de
message spécifique, les valeurs des champs d'en-tête Internet
auront la signification suivante:
| Version : |
4 |
| IHL : |
Longueur d'en-tête
Internet en mots de 32-bits. |
| Type de Service
: |
0 |
| Longueur Totale
: |
Longueur totale du datagramme
en octets. |
Identification
:
Bits Contrôles :
Fragment Offset : |
Utilisés par le mécanisme
de fragmentation, voir [1]. |
| Durée
de vie : |
Durée de vie du datagramme
en secondes; ce champ est diminué d'une unité par chaque
module IP traversé dans lesquels le datagramme est traité,
la valeur dans ce champ doit être au moins égale au nombre
maximum de routeurs que ce datagramme est sensé traverser jusqu'à
sa destination finale. |
| Protocole
: |
ICMP = 1 |
| Checksum : |
Le complément à
un sur 16 bits de la somme des compléments à un de l'en-tête
Internet pris par mots de 16 bits. Lors du calcul du Checksum, le champ
destiné à recevoir ce Checksum sera laissé à
zéro. Ce mécanisme de Checksum sera changé dans le
futur. |
| Adresse source
: |
L'adresse du routeur ou
hôte qui compose le message ICMP. Sauf mention contraire, celle-ci
peut être toute adresse de routeur. |
| Adresse destinataire
: |
L'adresse du routeur ou
hôte à qui le message doit être envoyé. |
Message "destinataire non accessible"
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| non ut
1000
ilisé |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Datagramme original En-tête Internet + 64 bits de données |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Champs IP:
| Adresse destinataire
: | L'adresse et réseau
source du datagramme original. |
Champs ICMP:
| Type : | 3 |
| Code : | 0 = réseau inaccessible;
1 = hôte inaccessible;
2 = protocole non disponible;
3 = port non accessible;
4 = fragmentation nécessaire
mais interdite;
5 = échec d'acheminement
source. |
| Checksum : | Le complément à
un sur 16 bits de la somme des compléments à un du message
ICMP. Lors du calcul du Checksum, le champ destiné à recevoir
ce Checksum sera laissé à zéro. Ce mécanisme
de Checksum sera changé dans le futur. |
Datagramme avec une en-tête Internet
+ 64 bits de donnéesL'en-tête Internet plus
les 64 premiers bits extraits du datagramme original. Ces données
seront utilisées par l'hôte pour reconnaître le programme
concerné par ce message. Si un protocole de niveau supérieur
utilise des "numéros de port", on admet que ce dernier apparaît
dans les 64 premiers bits de données du datagramme original.
DescriptionSi, compte tenu des information
contenues dans les tables de routage du routeur, le réseau indiqué
dans le champ adresse de destination de l'en-tête IP du datagramme
reçu est inaccessible ou inconnu, ex., la distance à ce réseau
est marquée comme infinie, le routeur pourra émettre un tel
message a destination de l'hôte d'origine du datagramme. De plus,
dans certains réseaux, le routeur peut être capable de déterminer
que l'hôte destinataire n'est pas accessible. Un tel routeur pourra,
sur réception d'un datagramme destiné à cet hôte,
émettre en retour un tel message ICMP, et détruire le datagramme.
Si, dans l'hôte destinataire,
le module IP ne peut délivrer le message à la couche supérieure
soit parce que le protocole indiqué n'est pas implémenté
soit parce que l'application ne répond pas, l'hôte destinataire
lui-même peut être amené à émettre un
tel message à destination de la source.
Un autre cas de figure
est celui où le datagramme doit être fragmenté pour
pouvoir être retransmis sur le segment suivant de réseau et
où celui-ci affiche un bit antifragmentation marqué interdisant
d'effectuer cette opération pour ce datagramme. Ce message ICMP
permet de signaler ce cas de figure.
Les codes 0, 1, 4, et 5 seront
reçus de la part de routeurs. Les codes 2 et 3 proviendront d'hôtes.
Message "Durée de vie écoulée" 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| non utilisé |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Datagramme original En-tête Internet + 64 bits de données |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Champs IP :
| Adresse destinataire
: | L'adresse et réseau
source du datagramme original. |
Champs ICMP :
| Type : | 11 |
| Code : | 0 = durée de vie
écoulée avant arrivée à destination;
1 = temps limite de réassemblage
du fragment dépassé. |
| Checksum : | Le complément à
un sur 16 bits de la somme des compléments à un du message
ICMP. Lors du calcul du Checksum, le champ destiné à recevoir
ce Checksum sera laissé à zéro. Ce mécanisme
de Checksum sera changé dans le futur. |
Datagramme avec une en-tête Internet
+ 64 bits de donnéesL'en-tête Internet plus
les 64 premiers bits extraits du datagramme original. Ces données
seront utilisées par l'hôte pour reconnaître le programme
concerné par ce message. Si un protocole de niveau supérieur
utilise 1000 des "numéros de port", on admet que ce dernier apparaît
dans les 64 premiers bits de données du datagramme original.
DescriptionLorsqu'un routeur traitant un
datagramme est amené à mettre à jour le champ Durée
de Vie de l'en-tête IP et que ce champ atteint une valeur zéro,
le datagramme doit être détruit. Le routeur peut alors prévenir
l'hôte source de cette destruction par ce message.
Si un hôte réassemblant
un datagramme fragmenté ne peut terminer cette opération
à cause de fragments manquants au bout de la temporisation de réassemblage,
il doit détruire le datagramme en cours de traitement et peut dans
ce cas en avertir la source en émettant ce message.
Si parmi les fragments reçu,
aucun ne porte le numéro 0, il n'est pas utile d'envoyer ce message.
Un message de code 0 pourra
provenir d'un routeur. Un message de code 1 peut être reçu
provenant d'un hôte.
Message d'erreur de paramètre 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pointeur | non utilisé |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Datagramme original En-tête Internet + 64 bits de données |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Champs IP :
| Adresse destinataire
: | L'adresse et réseau
source du datagramme original. |
Champs ICMP :
| Type : | 12 |
| Code : | 0 = l'erreur est indiquée
par le pointeur. |
| Checksum : | Le complément à
un sur 16 bits de la somme des compléments à un du message
ICMP. Lors du calcul du Checksum, le champ destiné à recevoir
ce Checksum sera laissé à z&eacut 1000 e;ro. Ce mécanisme
de Checksum sera changé dans le futur. |
| Pointer : | Si code = 0, identifie l'octet
où l'erreur a été détectée. |
Datagramme avec une en-tête Internet
+ 64 bits de donnéesL'en-tête Internet plus
les 64 premiers bits extraits du datagramme original. Ces données
seront utilisées par l'hôte pour reconnaître le programme
concerné par ce message. Si un protocole de niveau supérieur
utilise des "numéros de port", on admet que ce dernier apparaît
dans les 64 premiers bits de données du datagramme original.
DescriptionSi le routeur où l'hôte
traitant le datagramme rencontre un problème avec un paramètre
d'en-tête l'empêchant de finir son traitement, le datagramme
doit être détruit. Un exemple possible pour ce cas est la
présence d'arguments invalides dans une option. Le routeur ou l'hôte
détectant la faute peut alors en avertir la source par un tel message.
Cependant, un tel message ne peut être envoyé que si la faute
est de nature à empêcher le traitement du datagramme.
Le pointeur identifie l'octet
par sa position dans l'en-tête du datagramme original dans laquelle
l'erreur a été détectée (cela peut être
au milieu d'une option). Par exemple, une valeur de 1 indique un Type de
Service erroné, et (si l'en-tête comporte des options) 20
indique une erreur sur le code de type de la première option.
Un message de code 0 pourront
provenir d'un routeur ou d'un hôte.
Message de contrôle de flux 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| non utilisé |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Datagramme original En-tête Internet + 64 bits de données |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Champs IP :
| Adresse destinataire
: | L'adresse et réseau
1000 source du datagramme original. |
Champs ICMP :
| Type : | 4 |
| Code : | 0 |
| Checksum : | Le complément à
un sur 16 bits de la somme des compléments à un du message
ICMP. Lors du calcul du Checksum, le champ destiné à recevoir
ce Checksum sera laissé à zéro. Ce mécanisme
de Checksum sera changé dans le futur. |
Datagramme avec une en-tête Internet
+ 64 bits de donnéesL'en-tête Internet plus
les 64 premiers bits extraits du datagramme original. Ces données
seront utilisées par l'hôte pour reconnaître le programme
concerné par ce message. Si un protocole de niveau supérieur
utilise des "numéros de port", on admet que ce dernier apparaît
dans les 64 premiers bits de données du datagramme original.
DescriptionUn routeur peut être amené
à détruire un datagramme s'il manque de mémoire pour
tamponner les datagrammes à émettre sur le segment de réseau
suivant du chemin d'acheminement. Dans ce cas, il pourra émettre
ce message à destination de la source du datagramme détruit.
Un hôte destinataire peut aussi émettre ce message si le datagramme
arrive trop rapidement pour qu'il puisse être traité. Ce message
peut donc constituer une demande à la source de diminuer le débit
d'émission de données vers le destinataire. Le routeur devra
émettre autant de messages de ce type que de datagrammes détruits.
Sur réception de ce message, l'hôte source devra faire chuter
son débit d'émission vers cette destination tant que de tels
messages lui parviennent. L'hôte source pourra alors graduellement
augmenter son débit de sortie jusqu'à de nouveau recevoir
ce type de message.
Il sera plus judicieux de
faire émettre ce message lorsque les ressources du routeur ou de
l'hôte passent en dessous d'une valeur de sécurité,
plutôt que d'attendre de ne plus disposer de ressource du tout. Ceci
veut aussi dire que le datagramme ayant déclenché l'émission
de ce message aura de fortes chances d'arriver quand même à
destination.
Le message de code 0 pourront
provenir d'un hôte ou d'un routeur.
Message de redirection 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code |&nb
1000
sp; Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adresse Internet de routeur |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Datagramme original En-tête Internet + 64 bits de données |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Champs IP :
| Adresse destinataire
: | L'adresse et réseau
source du datagramme original. |
Champs ICMP :
| Type : | 5 |
| Code : | 0 = Redirection de datagramme
sur la base du réseau;
1 = Redirection de datagramme
sur la base de l'adresse d'hôte;
2 = Redirection de datagramme
sur la base du réseau et du Type de Service;
3 = Redirection de datagramme
sur la base de l'hôte et du Type de Service; |
| Checksum : | Le complément à
un sur 16 bits de la somme des compléments à un du message
ICMP. Lors du calcul du Checksum, le champ destiné à recevoir
ce Checksum sera laissé à zéro. Ce mécanisme
de Checksum sera changé dans le futur. |
| Adresse Internet
de routeur : | Adresse du routeur auquel
le trafic à destination du réseau spécifié
dans le champ de destination de l'en-tête IP du datagramme original
doit être envoyé. |
Datagramme avec une en-tête Internet
+ 64 bits de donnéesL'en-tête Internet plus
les 64 premiers bits extraits du datagramme original. Ces données
seront utilisées par l'hôte pour reconnaître le programme
concerné par ce message. Si un protocole de niveau supérieur
utilise des "numéros de port", on admet que ce dernier apparaît
dans les 64 premiers bits de données du datagramme original.
DescriptionUn routeur peut rediriger un
datagramme destiné à un hôte dans les situations suivantes.
Un routeur, G1, reçoit un datagramme Internet en provenance d'un
hôte situé sur le segment local de réseau où
il se trouve. Le routeur, G1, vérifie ses tables de routage et obtient
l'adresse du routeur suivant, G2, situé sur le chemin d'acheminement
de ce datagramme vers le réseau local destinataire, X. Si G2 et
l'hôte source se trouvent être sur le même segment de
réseau, un message de 1000 redirection est envoyé vers l'hôte
source. Il permet d'avertir la source que le trafic vers le réseau
X peut être directement adressé au routeur G2, diminuant ainsi
le chemin d'acheminement. Le routeur reportera le datagramme original vers
sa destination Internet.
Pour les datagrammes présentant
une option IP de routage précisant l'adresse du routeur dans le
champ de destination, aucun message de redirection ne sera émis
même si un chemin plus court vers la destination finale existe, autre
que celui indiqué par l'adresse suivante de la liste de routage.
Les messages de codes 0,
1, 2, et 3 pourront provenir d'un routeur.
Message d'écho et de "réponse
à écho"
|
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identificateur | Numéro de Séquence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+- |
Champs IP :
| Adresses : | L'adresse de la source dans
un message d'écho doit être le destinataire du message de
"réponse à écho". Pour constituer un message de réponse
à écho, il suffit d'inverser les adresses de source et de
destination, et de mettre code type à 0, puis enfin de recalculer
le Checksum. |
Champs ICMP :
| Type : | 8 = écho;
0 = réponse à
écho. |
| Code : | 0 |
| Checksum : | Le complément à
un sur 16 bits de la somme des compléments à un du message
ICMP. Lors du calcul du Checksum, le champ destiné à recevoir
ce Checksum sera laissé à zéro. Si la longueur totale
du message est un nombre impair d'octets, le calcul du Checksum se fera
en ajoutant un dernier octet à zéro de bourrage en fin de
message. Ce mécanisme de Checksum sera changé dans le futur. |
| 1000 | Identificateur
: | Si le code = 0, un identificateur
permettant d'associer l'écho et la réponse à l'écho,
peut être nul. |
| Numéro
de séquence : | Si le code = 0, un numéro
de séquence permettant d'associer l'écho et sa réponse.
Peut être nul. |
DescriptionLes données reçues
dans un message d'écho doivent être réémises
dans la réponse à l'écho. L'identificateur et le numéro
de séquence peuvent être utilisés par l'émetteur
du message d'écho afin d'associer facilement l'écho et sa
réponse. Par exemple, l'identificateur peut être utilisé
comme l'est un port pour TCP ou UDP, identifiant ainsi une session, et
le numéro de séquence incrémenté pour chaque
message d'écho envoyé. Le "miroir" respectera ces deux valeurs
pour renvoyer le retour.
Les messages de code 0 peuvent
provenir d'un routeur ou d'un hôte.
Marqueur temporel ou réponse à
marqueur temporel 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identificateur | Numéro de séquence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Etiquette temporelle origine |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Etiquette temporelle reçue |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Etiquette temporelle transmise |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Champs IP :
| Adresses : | L'adresse source dans
un marqueur temporel doit être la destination du message de réponse
à marqueur temporel. Pour constituer une telle réponse, on
intervertira simplement l'adresse source et l'adresse de destination, on
marquera le code de type à la valeur 14, et le Checksum sera recalculé. |
Champs ICMP :
| Type : | 13 = marqueur temporel;
14 = réponse à
marqueur temporel. |
| Code : | 0 |
| Checksum : | Le complément à
un sur 16 bits de la somme des compléments à un du message
ICMP. Lors du calcul du Checksum, le champ destiné à recevoir
ce Checksum sera laissé à zéro. Ce mécanisme
de Checksum sera changé dans le futur. |
| Identificateur
: | Si le code = 0, un identificateur
permettant d'associer le marqueur et sa réponse, peut être
nul. |
| Numéro
de séquence : | Si le code = 0, un numéro
de séquence permettant d'associer le marqueur et sa réponse.
Peut être nul. |
DescriptionLes données reçues
(une étiquette temporelle) dans le message sont recopiées
dans la réponse, additionnées d'une étiquette supplémentaire.
Une étiquette temporelle code une durée en millisecondes
sur 32 bits à partir de minuit GMT. Une utilisation de ces étiquettes
temporelles est décrite par Mills [5].
L'étiquette Origine
est l'heure à laquelle le message a été modifié
pour la dernière fois par la source avant de l'envoyer, L'étiquette
de Réception donne l'heure à laquelle la cible a reçu
le message, et l'étiquette de Transmission donne l'heure à
laquelle la cible réémet le message.
Si l'heure ne peut être
obtenue en millisecondes ou ne peut être calculée par rapport
à la référence 0 h 00 GMT, alors toute heure peut
être codée dans l'étiquette temporelle pourvu que le
bit de poids fort soit marqué pour indiquer la présence d'une
valeur non standard.
L'identificateur et le numéro
de séquence peuvent être utilisés par l'émetteur
du marqueur temporel afin d'associer facilement le marqueur et sa réponse.
Par exemple, l'identificateur peut être utilisé comme l'est
un port pour TCP ou UDP, identifiant ainsi une session, et le numéro
de séquence incrémenté pour chaque marqueur envoyé.
Le "miroir" respectera ces deux valeurs pour renvoyer le retour.
Les messages de code 0 peuvent
provenir d'un routeur ou d'un hôte.
1000
Messages Demande d'Information et Réponse 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identificateur | Numéro de séquence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Champs IP :
| Adresses : | L'adresse source dans un
message d'information doit être la destination du message de réponse
à demande d'information. Pour constituer une telle réponse,
on intervertira simplement l'adresse source et l'adresse de destination,
on marquera le code de type à la valeur 16, et le Checksum sera
recalculé. |
Champs ICMP :
| Type : | 15 = demande d'information;
16 = réponse. |
| Code : | 0 |
| Checksum : | Le complément à
un sur 16 bits de la somme des compléments à un du message
ICMP. Lors du calcul du Checksum, le champ destiné à recevoir
ce Checksum sera laissé à zéro. Ce mécanisme
de Checksum sera changé dans le futur. |
| Identificateur
: | Si le code = 0, un identificateur
permettant d'associer la demande et sa réponse, peut être
nul. |
| Numéro
de séquence : | Si le code = 0, un numéro
de séquence permettant d'associer la demande et sa réponse.
Peut être nul. |
DescriptionCe message peut être envoyé
vers une adresse constituée du numéro de réseau dans
le champ source de l'en-tête IP et un champ destinataire à
0 (ce qui signifie "ce" réseau). Le module IP qui répondra
pourra alors envoyer une réponse avec les adresses entièrement
renseignées. Par ce message, un hôte peut demander à
un routeur le numéro du réseau sur f24 lequel il est situé.
L'identificateur et le numéro
de séquence peuvent être utilisés par l'émetteur
du message de demande d'information afin d'associer facilement la demande
et sa réponse. Par exemple, l'identificateur peut être utilisé
comme l'est un port pour TCP ou UDP, identifiant ainsi une session, et
le numéro de séquence incrémenté pour chaque
message de demande d'information envoyé. Le "miroir" respectera
ces deux valeurs pour renvoyer le retour.
Les messages de code 0 peuvent
provenir d'un routeur ou d'un hôte.
Résumé des types de Message
| 0 | Réponse Echo |
| 3 | Destination non accessible |
| 4 | Contrôle de flux |
| 5 | Redirection |
| 8 | Echo |
| 11 | Durée de vie écoulée |
| 12 | Erreur de Paramètre |
| 13 | Marqueur temporelle |
| 14 | Réponse à
marqueur temporel |
| 15 | Demande d'information |
| 16 | Réponse à
demande d'information |
Références[1] Postel, J. (ed.), "Internet
Protocol - DARPA Internet Program Protocol Specification," RFC 791, USC/Information
Sciences Institute, September 1981.
[2] Cerf, V., "The Catenet
Model for Internetworking," IEN 48, Information Processing Techniques Office,
Defense Advanced Research Projects Agency, July 1978.
[3] Strazisar, V., "Gateway
Routing: An Implementation Specification", IEN 30, Bolt Beranek and Newman,
April 1979.
[4] Strazisar, V., "How to
Build a Gateway", IEN 109, Bolt Beranek and Newman, August 1979.
[5] Mills, D., "DCNET Internet
Clock Service," RFC 778, COMSAT Laboratories, April 1981.0
|
|