Traceroute en utilisant une option IP

Statut du présent mémoire

Ce mémoire définit un protocole expérimental pour la communauté de l'Internet. Il appelle à des discussions et des suggestions pour son amélioration. Prière de se référer à l'édition en cours des "Normes officielles des protocoles de l'IAB" pour connaître l'état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n'est soumise à aucune restriction.

Résumé

Traceroute sert d'outil précieux de débogage de réseau. La façon dont il est actuellement mis en œuvre présente l'avantage d'être automatiquement pris en charge par tous les routeurs. Ses deux problèmes sont le nombre de paquets qu'il génère et le temps qu'il prend pour son fonctionnement.

Le présent document spécifie une nouvelle option IP et un nouveau type de message ICMP qui duplique la fonctionnalité de la méthode Traceroute existante tout en générant moins de paquets et en s'accomplissant en un temps plus court.

Table des matières

1.   Traceroute aujourd'hui

2.   Traceroute demain

2.1   Algorithme de base

2.2   Format de l'option IP Traceroute

2.3   Format de message ICMP de Traceroute

3.   Protocole

3.1   Compte des bonds

3.2   Fonctionnement du nœud de destination

3.3   Fonctionnement du routeur

4.   Références

5.   Considérations pour la sécurité

6.   Adresse de l'auteur

1.   Traceroute aujourd'hui

Le Traceroute existant fonctionne en envoyant un paquet avec une durée de vie (TTL, Time To Live) de 1. Le premier bond renvoie alors un message d'erreur ICMP [1] indiquant que le paquet n'a pas pu être transmis à cause de son TTL expiré. Le paquet est alors renvoyé avec un TTL de 2, et le second bond retourne le TTL expiré. Ce processus continue jusqu'à ce que la destination soit atteinte. L'objet de tout ceci est d'enregistrer la source de chacun des messages ICMP TTL expiré pour fournir la trace du chemin suivi par le paquet pour atteindre la destination.

L'avantage de cet algorithme, est que chaque routeur a déjà la capacité d'envoyer des messages TTL expiré. Aucun code particulier n'est requis. L'inconvénient est le nombre de paquets générés (2n, où n est le nombre de bonds), le temps que prend la duplication de tous les bonds plus proches avec chaque paquet successif, et le fait que le chemin puisse changer durant ce processus. Aussi, cet algorithme ne retrace pas le chemin de retour, qui peut différer du chemin de sortie.

2.   Traceroute demain

Le Traceroute proposé utiliserait un algorithme différent pour atteindre le même objectif, à savoir de tracer le chemin vers un hôte. Parce que le nouveau Traceroute utilise un message ICMP conçu pour cet objet, des informations supplémentaires, indisponibles à l'usager traceroute d'origine, peuvent devenir disponibles.

2.1   Algorithme de base

Une nouvelle option Traceroute IP sera définie. La présence de cette option dans un paquet Echo ICMP (ou tout autre), qu'on appelle ici le Paquet de sortie, amènera un routeur à envoyer le message ICMP Traceroute nouvellement défini à l'origine du paquet de sortie. De cette façon, le chemin du paquet de sortie sera enregistré par le générateur avec seulement n+1 (au lieu de 2n) paquets. Cet algorithme ne souffre pas d'un changement de chemin et permet que la réponse au paquet de sortie, qu'on appelle ici paquet de retour soit retracée (pourvu que la destination du paquet de sortie préserve l'option IP Traceroute dans le paquet de retour).

L'inconvénient de cette méthode est que la fonction Traceroute devra être entrée dans les routeurs. Pour contrer cet inconvénient, il y a cependant le fait que ce mécanisme peut être facilement porté dans une nouvelle version d'IP.

2.2   Format de l'option IP Traceroute

F (fragment)

1 (copier dans les fragments)

0 (ne pas copier dans les fragments)

C (classe)

2 (débogage & mesures)

Nombre

18 (F+C+Nombre = 82)

Numéro d'identifiant

Nombre arbitraire utilisé par le générateur du paquet de sortie pour identifier les messages Traceroute ICMP. Il N'EST PAS en rapport avec le numéro d'identifiant qui se trouve dans l'en-tête IP.

Adresse IP de l'origine

Adresse IP de l'origine du paquet de sortie. Elle est nécessaire pour que les routeurs sachent où envoyer le message Traceroute ICMP pour le paquet de retour. Il est aussi nécessaire pour les paquets de sortie qui ont une option Route de source.

Compte de bond en sortie (OHC, Outbound Hop Count)

Nombre de routeurs au travers desquels le paquet de sortie est passé. Ce champ n'est pas incrémenté par la destination du paquet de sortie.

Compte de bond du retour (RHC, Return Hop Count)

Nombre de routeurs au travers desquels le paquet de retour est passé. Ce champ n'est pas incrémenté par la destination du paquet de retour.

2.3   Format de message ICMP de Traceroute

Type : 30

Code

0 – Paquet de sortie bien transmis

1 – Pas de route pour le paquet de sortie ; paquet éliminé

Somme de contrôle

Complément à un sur 16 bits de la somme des compléments à un de tous les mots de 16 bits de l'en-tête. Pour calculer la somme de contrôle, le champ somme de contrôle devrait être à zéro.

Numéro d'identifiant

Numéro d'identifiant copié de l'option IP Traceroute du paquet qui a causé l'envoi de ce message Traceroute. Ce N'EST PAS en rapport avec le numéro d'identifiant de l'en-tête IP.

Compte des bonds de sortie

Compte des bonds de sortie copié de l'option IP Traceroute du paquet qui a causé l'envoi de ce message Traceroute.

Compte des bonds de retour

Compte des bonds de retour copié de l'option IP Traceroute du paquet qui a causé l'envoi de ce message Traceroute.

Vitesse de liaison de sortie

Vitesse, en octets par seconde, de la liaison sur laquelle le paquet de sortie/retour sera envoyé. Comme il ne faudra plus longtemps pour que la vitesse des réseaux dépasse 4,3 Gbit/s, et comme certaines machines ont du mal avec les champs qui dépassent 32 bits, l'octet par seconde a été choisi de préférence au bit par seconde. Si cette valeur ne peut être déterminée, le champ devrait être mis à zéro.

MTU de liaison sortante

La MTU, en octets, de la liaison sur laquelle le paquet de sortie/retour sera envoyé. La MTU se réfère à la portion de données du paquet (elle inclut l'en-tête IP et exclut l'en-tête/en-queue de liaison des données). Si cette valeur ne peut être déterminée, le champ devrait être mis à zéro.

3.   Protocole

Le paquet de sortie qui est utilisé pour porter l'option IP Traceroute ne devrait pas utiliser de Type de service (TOS) ou Préséance particuliers, sauf si le but est de retracer le chemin de paquets avec des valeurs de TOS ou Préséance particulières.

Le TTL du paquet de sortie devrait être réglé à la valeur par défaut spécifié dans "Numéros alloués" [2].

3.1   Compte des bonds

Les compte de bonds fournissent en dernier ressort les informations sur la longueur des chemins de sortie et de retour jusqu'à la destination. Il donnent aussi le moyen de déterminer si des messages ICMP Traceroute ont ou non été perdus. Par exemple, si un message Traceroute avec un OHC de 4 est suivi par un message avec un OHC de 6, le message avec un OHC de 5 a été perdu. C'est pourquoi le simple compte des messages Traceroute n'est pas suffisant pour déterminer la longueur du chemin.

L'origine su paquet de sortie devrait régler le OHC à zéro et le RHC à 0xFFFF. 0xFFFF est une valeur particulière qui indique aux routeurs que le paquet est un paquet de sortie plutôt qu'un paquet de retour (qui commence par un RHC de zéro).

Il est important de noter que le compte des bonds de Traceroute N'EST PAS en rapport avec le TTL d'IP. Un compte de bond ne devrait être incrémenté que quand un message ICMP Traceroute est envoyé.

3.2   Fonctionnement du nœud de destination

Lorsque un nœud reçoit un paquet de sortie avec une option IP Traceroute, le paquet de retour, s'il en est exigé ainsi (par exemple, demande/réponse d'écho ICMP), devrait aussi porter cette option. Les valeurs dans les champs Numéro d'identifiant, OHC, et Adresse d'origine devraient être copiées dans le paquet de retour. La valeur du champ RHC devrait être réglée à zéro.

La destination NE DEVRAIT PAS incrémenter de compte de bons ou envoyer de message ICMP Traceroute.

3.3   Fonctionnement du routeur

Lorsque un routeur transmet un paquet avec une option IP Traceroute, il devrait envoyer un message ICMP Traceroute à l'hôte qui se trouve dans le champ Adresse IP d'origine de l'option. Si la valeur du champ RHC est 0xFFFF, alors le paquet est un paquet de sortie et l'OHC devrait être incrémenté ; autrement, c'est le champ RHC qui devrait être incrémenté. Le message Traceroute devrait refléter le compte de bonds incrémenté. Le champ Vitesse de liaison de sortie devrait être réglé à la vitesse, en octets par seconde, de la liaison sur laquelle le paquet de sortie/retour sera envoyé (par exemple, 1 250 000 pour un Ethernet) ou zéro si la vitesse de la liaison de sortie ne peut être déterminée. Le champ MTU de liaison de sortie sera réglé à la MTU de la liaison sur laquelle le paquet de sortie/retour sera envoyé, ou zéro si la MTU ne peut être déterminée.

Le paquet de sortie/retour devrait être transmis comme si l'option Traceroute n'existait pas, c'est-à-dire qu'il devrait prendre le même chemin vers la destination qu'un paquet sans l'option.

Le message ICMP Traceroute devrait avoir les mêmes valeurs de TOS et de Préséance que le paquet de sortie/retour. Le TTL devrait être réglé à la valeur par défaut définie dans "Numéros alloués".

Le message ICMP Traceroute ne devrait pas porter l'option IP Traceroute.

Si le paquet de sortie ne peut être transmis, le message ICMP Traceroute devrait avoir une valeur de Code de 1. Si le paquet de retour ne peut pas être transmis parce qu'il n'y a pas de chemin, il n'est alors pas besoin d'envoyer un message Traceroute car il ne pourra pas non plus être transmis.

4.   Références

[1]   J. Postel, "Protocole du message de contrôle Internet – Spécification du protocole du programme Internet DARPA", STD 5, RFC 792, USC/Information Sciences Institute, septembre 1981.

[2]   J. Reynolds et J. Postel, "Numéros alloués", STD 2, RFC 1340, USC/Information Sciences Institute, juillet 1992. (Rendue obsolète par la RFC 1700, elle-même Historique)

5.   Considérations pour la sécurité

Les questions de sécurité ne sont pas abordées dans le présent mémoire.

6.   Adresse de l'auteur

Gary Scott Malkin

Xylogics, Inc.

53 Third Avenue

Burlington, MA 01803

téléphone : (617) 272-8140

mél : gmalkin@Xylogics.COM