Cours d'introduction à TCP/IP

Les octets issus de la couche de transport et encapsulés à l'aide d'un entête IP avant d'être propagés vers la couche réseau (Ethernet par exemple), sont collectivement nommés « datagramme IP », datagramme Internet ou datagramme tout court. Ces datagrammes ont une taille maximale liée aux caractéristiques de propagation du support physique, c'est le « Maximum Transfer Unit » ou MTU.

Quelques caractéristiques en vrac du protocole IP :

• IP est le support de travail des protocoles de la couche de transport, UDP, TCP et SCTP ;
• IP ne donne aucune garantie quant au bon acheminement des données qu'il envoie. Il n'entretient aucun dialogue avec une autre couche IP distante, on dit aussi qu'il délivre les datagrammes « au mieux » ;
• chaque datagramme est géré indépendamment des autres datagrammes même au sein du transfert des octets d'un même fichier. Cela signifie que les datagrammes peuvent être mélangés, dupliqués, perdus ou altérés !
• Ces problèmes ne sont pas détectés par IP et donc il ne peut en informer la couche de transport ;
• les octets sont lus et transmis au réseau en respectant le « Network Byte Order » ou NBO (cf. paragraphe 1.2), quelle que soit l'architecture CPU de l'hôte ;
• l'entête IP minimal fait cinq mots de quatre octets, soit 20 octets. S'il y a des options, la taille maximale peut atteindre 60 octets.

Sur la figure V.01 les bits les plus significatifs de chaque mot de quatre octets sont à gauche (31...). Ils sont d'ailleurs transmis sur le réseau dans cet ordre(37), c'est un standard, c'est le « Network Byte Order ».

Toutes les architectures de CPU ne sont pas bâties sur le même modèle :

Les termes « Big endian » et « Little endian » indiquent quelle est la terminaison (« end ») de deux octets que l'on écrit en premier, le poids fort (« big »), c'est aussi le sens de l'écriture humaine, ou le poids faible (« little »).

VERS

• Quatre bits qui spécifient la version du protocole IP. L'objet de ce champ est la vérification que l'émetteur et le destinataire des datagrammes sont bien en phases avec la même version. Actuellement c'est la version 4 qui est principalement utilisée sur l'Internet, bien que quelques implémentations de la version 6 existent et soient déjà en expérimentation(38).

HLEN

• Quatre bits qui donnent la longueur de l'entête en mots de quatre octets. La taille standard de cet entête fait cinq mots, la taille maximale fait : (2³ + 2² + 2¹ + 2⁰) x 4 = 60 octets(39).

TOTAL LENGTH

• Donne la taille du datagramme, entête plus données. S'il y fragmentation (voir plus loin) il s'agit également de la taille du fragment (chaque datagramme est indépendant des autres).
• La taille des données est donc à calculer par soustraction de la taille de l'entête.
• 16 bits autorisent la valeur 65535... La limitation vient le plus souvent du support physique (MTU) qui impose une taille plus petite, sauf sur les liaisons de type « hyperchannel ».

TYPE OF SERVICE vs DSCP/ECN

• Historiquement dans la RFC 791 ce champ est nommé TYPE OF SERVICE et joue potentiellement deux rôles selon les bits examinés (préséance et type de service). Pratiquement, la préséance ne sert plus et la RFC 1349 définit quatre bits utiles sur les huit (3 à 6). Ceux-ci indiquent au routeur l'attitude à avoir vis-à-vis du datagramme.
• Par exemple, des datagrammes d'un transfert de fichier (ftp) peuvent avoir à laisser passer un datagramme repéré comme contenant des caractères frappés au clavier (session Telnet).

• L'usage de ces bits est mutuellement exclusif.
• Les nouveaux besoins de routage ont conduit l'IETF à revoir la définition de ce champ dans la RFC 3168. Celle-ci partage les huit bits en deux parties, les premiers bits définissent le DSCP ou « Differentiated Services CodePoints » qui est une version beaucoup plus fine des quatre bits ci-dessus. Les deux derniers bits définissent l'ECN ou « Explicit Congestion Notification » qui est un mécanisme permettant de prévenir les congestions, contrairement au mécanisme plus ancien basé sur les messages ICMP de type « source quench » qui tente de régler le flux en cas de congestion.
• Il faut noter que les protocoles de routage qui tiennent compte de l'état des liaisons (OSPF,IS-IS...) sont susceptibles d'utiliser ce champ.
• Enfin la RFC 3168 indique que ces deux écritures du champ ne sont pas compatibles entre elles...

IDENTIFICATION, FLAGS et FRAGMENT OFFSET

• Ces mots sont prévus pour contrôler la fragmentation des datagrammes. Les données sont fragmentées, car les datagrammes peuvent avoir à traverser des réseaux avec des MTU plus petits que celui du premier support physique employé.
• Consulter la section suivante Fragmentation IP.

TTL

• « Time To Live » 8 bits, 255 secondes maximum de temps de vie pour un datagramme sur le Net.
• Prévu à l'origine pour décompter un temps, ce champ n'est qu'un compteur décrémenté d'une unité à chaque passage dans un routeur.
• Couramment la valeur de départ est 32 ou même 64. Son objet est d'éviter la présence de paquets fantômes circulant indéfiniment...
• Si un routeur passe le compteur à zéro avant délivrance du datagramme, un message d'erreur - ICMP (consultez le paragraphe 4) - est renvoyé à l'émetteur avec l'indication du routeur. Le paquet en lui-même est perdu.

PROTOCOL

• Huit bits pour identifier le format et le contenu des données, un peu comme le champ « type » d'une trame Ethernet. Il permet à IP d'adresser les données extraites à l'une ou l'autre des couches de transport.
• Dans le cadre de ce cours, nous utiliserons essentiellement ICMP(1), IGMP(2), IP-ENCAP(4), TCP(6), UDP(17), ESP(50), AH(51), et OSPF(89).
• La table de correspondance entre le symbole et le numéro du protocole est présente sur tout système d'exploitation digne de ce nom, dans le fichier /etc/protocols.

HEADER CHECKSUM

• 16 bits pour s'assurer de l'intégrité de l'entête. Lors du calcul de ce « checksum » ce champ est à 0.
• À la réception de chaque paquet, la couche calcule cette valeur, si elle ne correspond pas à celle trouvée dans l'entête le datagramme est oublié (« discard ») sans message d'erreur.

SOURCE ADDRESS

• Adresse IP de l'émetteur, à l'origine du datagramme.

DESTINATION ADDRESS

• Adresse IP du destinataire du datagramme.

IP OPTIONS

• 24 bits pour préciser des options de comportement des couches IP traversées et destinatrices. Les options les plus courantes concernent :
  • • des problèmes de sécurité,
    • des enregistrements de routes,
    • des enregistrements d'heure,
    • des spécifications de route à suivre,
    • ...
• Historiquement ces options ont été prévues dès le début, mais leur implémentation n'a pas été terminée et la plupart des routeurs filtrants bloquent les datagrammes IP comportant des options.

PADDING

• Remplissage pour aligner sur 32 bits...

En conclusion partielle que peut-on dire du travail de la couche IP ?

• Il consiste à router les datagrammes en les acheminant « au mieux », on verra plus loin de quelle manière. C'est son travail principal.
• Il peut avoir à fragmenter les données de taille supérieure au MTU du support physique à employer.

La couche de liaison (Couche 2 « Link ») impose une taille limite, le « Maximum Transfer Unit ». Par exemple cette valeur est de 1500 pour une trame Ethernet, elle peut être de 256 avec SLIP (« Serial Line IP ») sur liaison série (RS232...).

Dans ces conditions, si la couche IP doit transmettre un bloc de données de taille supérieure au MTU à employer, il y a fragmentation !

Par exemple, un bloc de 1481 octets sur Ethernet sera décomposé en un datagramme de 1480 ( 1480 + 20 = 1500) et un datagramme de 1 octet !

Il existe une exception à cette opération, due à la présence active du bit « Don't Fragment bit » du champ FLAGS de l'entête IP. La présence à 1 de ce bit interdit la fragmentation dudit datagramme par la couche IP qui en aurait besoin. C'est une situation de blocage, la couche émettrice est tenue au courant par un message ICMP (cf. paragraphe 4) « Fragmentation needed but don't fragment bit set » et bien sûr le datagramme n'est pas transmis plus loin.

5-1-4-1. Fragmentation▲

• Quand un datagramme est fragmenté, il n'est réassemblé que par la couche IP destinatrice finale. Cela implique trois remarques :
  • la taille des datagrammes reçus par le destinataire final est directement dépendante du plus petit MTU rencontré ;
  • les fragments deviennent des datagrammes à part entière ;
  • rien ne s'oppose à ce qu'un fragment soit à nouveau fragmenté.
• Cette opération est absolument transparente pour les couches de transport qui utilisent IP.
• Quand un datagramme est fragmenté, chaque fragment comporte la même valeur de champ IDENTIFICATION que le datagramme initial.

S'il y a encore des fragments, un des bits du champ FLAGS est positionné à 1 pour indiquer « More fragment » !

Ce champ a une longueur de trois bits.

FRAGMENT OFFSET contient l'offset du fragment, relativement au datagramme initial.

Cet offset est codé sur 13 bits.

Pour tous les fragments :

• les données doivent faire un multiple de huit octets, sauf pour le dernier fragment, évidemment ;
• le champ TOTAL LENGTH change ;
• chaque fragment est un datagramme indépendant, susceptible d'être à son tour fragmenté.

Pour le dernier fragment :

• FLAGS est remis à zéro ;
• les données ont une taille quelconque.

5-1-4-2. Réassemblage▲

• Tous les datagrammes issus d'une fragmentation deviennent des datagrammes IP comme (presque) les autres.
• Ils arrivent à destination, peuvent être dans le désordre, dupliqués. IP doit faire le tri.
• Il y a suffisamment d'information dans l'entête pour réassembler les fragments épars.
• Mais si un fragment manque, la totalité du datagramme est perdu car aucun mécanisme de contrôle n'est implémenté pour cela dans IP.

C'est la raison principale pour laquelle il faut absolument éviter de fragmenter un datagramme IP !

La figure IV.05 résume l'opération de fragmentation d'un datagramme IP.

Â	H1	H2	H3	H4	H5	Â
IDENTIFICATION	I	I	I	I	I	Â
FLAG	MF	MF	MF	MF	0	Â
OFFSET	0	N	2 x N	3 x N	4 x N	Â
TOTAL LENGTH	H+N	H+N	H+N	H+N	H+M	Â
HEADER CHECKSUM	C 1	C 2	C 3	C 4	C 5	Â

Notez les variations de certains champs de l'entête :

• IDENTIFICATION est le même pour tous.
• FLAG est 0 pour le dernier datagramme.
• OFFSET croît de la taille du fragment, ici N.
• TOTAL LENGTH est généralement différent pour le dernier fragment, sauf cas particulier.
• HEADER CHECKSUM change à chaque fois, car l'OFFSET change (rappel : il ne tient pas compte des données).

Sur la figure IV.06 la station Ethernet A (I_A, P_A) a besoin de connaître l'adresse physique de la station Ethernet B (I_B, P_B). Pour ce faire, elle envoie un datagramme de format spécial (cf. paragraphe suivant), dédié à ARP, qui lui permet de poser la question (« Arp question ») à l'ensemble des machines actives. L'adresse de la machine qui doit répondre étant l'objet de la question, son adresse (champ destinataire) est donc remplacée par une adresse de « broadcast » (48 bits à 1).

Toutes les machines du LAN écoutent cet échange et peuvent mettre à jour leur table de conversion (adresse IP - adresse Ethernet) pour la machine A.

Remarque : quand une station Ethernet ne répond plus (cf. ICMP) il y a suppression de l'association adresse IP - adresse MAC.

Le « broadcast », coûteux en bande passante, est ainsi utilisé au maximum de ses possibilités. Sur la figure V.07 la réponse de B est du type « unicast ».

Si la station B ne répond pas, la station continuera à poser la question à intervalles réguliers pendant un temps infini...

Il n'est pas besoin d'utiliser ARP préalablement à chaque échange, car heureusement le résultat est mémorisé.

En règle générale la durée de vie d'une adresse en mémoire est de l'ordre de 20 minutes et chaque utilisation remet à jour ce compteur.

La commande arp -a sous Unix permet d'avoir le contenu de la table de la machine sur laquelle on se trouve, par exemple :

$ arp -a
soupirs.chezmoi.fr  (192.168.192.10) at 8:0:9:85:76:9c
espoirs.chezmoi.fr  (192.168.192.11) at 8:0:9:85:76:bd
plethore.chezmoi.fr (192.168.192.12) at 8:0:9:a:f9:aa
byzance.chezmoi.fr  (192.168.192.13) at 8:0:9:a:f9:bc
ramidus.chezmoi.fr  (192.168.192.14) at 0:4f:49:1:28:22 permanent
desiree.chezmoi.fr  (192.168.192.33) at 8:0:9:70:44:52
pythie.chezmoi.fr   (192.168.192.34) at 0:20:af:2f:8f:f1
ramidus.chezmoi.fr  (192.168.192.35) at 0:4f:49:1:36:50 permanent
gateway.chezmoi.fr  (192.168.192.36) at 0:60:8c:81:d5:1b

Enfin, et c'est un point très important, du fait de l'utilisation de « broadcast » physique, les messages ARP ne franchissent pas les routeurs. Il existe cependant un cas particulier : le proxy ARP, que nous évoquerons succinctement à la fin de ce paragraphe.

Le datagramme ci-dessus est encapsulé dans une trame physique du type 0x0806(41).

HARDWARE TYPE : pour spécifier le type d'adresse physique dans les champs SENDER HA et TARGET HA, c'est 1 pour Ethernet.

PROTOCOL TYPE : pour spécifier le type d'adresse logique dans les champs SENDER ADR et TARGET ADR, c'est 0x0800 (même valeur que dans la trame Ethernet) pour des adresses IP.

HLEN 1 : pour spécifier la longueur de l'adresse physique (six octets pour Ethernet).

HLEN 2 : pour spécifier la longueur de l'adresse logique (quatre octets pour IP).

OPERATION : ce champ précise le type de l'opération, il est nécessaire, car la trame est la même pour toutes les opérations des deux protocoles qui l'utilisent.

SENDER HA : adresse physique de l'émetteur.

SENDER ADR : adresse logique de l'émetteur.

TARGET HA : adresse physique du destinataire.

TARGET ADR : adresse logique du destinataire.

Le proxy ARP permet l'extension du LAN à des hôtes qui ne lui sont pas directement physiquement reliés, mais qui s'y rattachent par exemple au travers d'une passerelle.

Un exemple très courant est celui d'un hôte qui accède à un réseau via un dialup (rtc, numéris...). Le NetID de son adresse IP peut alors être le même que celui du réseau rejoint, comme s'il y était physiquement raccordé. Ce subterfuge est rendu possible après configuration adéquate de la passerelle de raccordement.

Dans le système que nous avons décrit, chaque passerelle et chaque hôte opère de manière autonome, route et délivre les datagrammes qui arrivent sans coordination avec l'émetteur.

Le système fonctionne parfaitement si toutes les machines sont en ordre de marche et si toutes les tables de routage sont à jour. Malheureusement c'est une situation idéale...

Il peut y avoir des ruptures de lignes de communication, des machines peuvent être à l'arrêt, en pannes, déconnectées du réseau ou incapables de router les paquets parce qu'en surcharge.

Des paquets IP peuvent alors ne pas être délivrés à leur destinataire et le protocole IP lui-même ne contient rien qui puisse permettre de détecter cet échec de transmission.

C'est pourquoi est ajouté systématiquement un mécanisme de gestion des erreurs connu sous le doux nom de ICMP. Il fait partie de la couche IP(42) et porte le numéro de protocole 1.

Ainsi, quand un message d'erreur arrive pour un paquet émis, c'est la couche IP elle-même qui gère le problème, la plupart des cas sans en informer les couches supérieures (certaines applications utilisent ICMP(43)).

Initialement prévu pour permettre aux passerelles d'informer les hôtes sur des erreurs de transmission, ICMP n'est pas restreint aux échanges passerelles-hôtes, des échanges entre hôtes sont tout à fait possibles.

Le même mécanisme est valable pour les deux types d'échanges.

Chaque message ICMP traverse le réseau dans la partie DATA d'un datagramme IP :

La conséquence directe est que les messages ICMP sont routés comme les autres paquets IP à travers le réseau. Il y a toutefois une exception : il peut arriver qu'un paquet d'erreur rencontre lui-même un problème de transmission, dans ce cas on ne génère pas d'erreur sur l'erreur !

La figure IV.10 décrit le format du message ICMP :

Il est important de bien voir que puisque les messages ICMP sont encapsulés dans un datagramme IP, ICMP n'est pas considéré comme un protocole de niveau plus élevé.

La raison de l'utilisation d'IP pour délivrer de telles informations est que les messages peuvent avoir à traverser plusieurs réseaux avant d'arriver à leur destination finale. Il n'était donc pas possible de rester au niveau physique du réseau (à l'inverse de ARP ou RARP).

Chaque message ICMP a un type particulier qui caractérise le problème qu'il signale. Un entête de 32 bits est composé comme suit :

TYPE : contient le code d'erreur.

CODE : complète l'information du champ précédent.

CHECKSUM : est utilisé avec le même mécanisme de vérification que pour les datagrammes IP, mais ici il ne porte que sur le message ICMP (rappel : le checksum de l'entête IP ne porte que sur son entête et non sur les données véhiculées).

En addition, les messages ICMP donnent toujours l'entête IP et les 64 premiers bits (les deux premiers mots de quatre octets) du datagramme qui est à l'origine du problème, pour permettre au destinataire du message d'identifier quel paquet est à l'origine du problème.

Ce paragraphe examine quelques-uns des principaux types de messages ICMP, ceux qui sont le plus utilisés. Il existe onze valeurs de TYPE différentes.

« Echo Request (8), Echo reply (0) »

• Une machine envoie un message ICMP « echo request » pour tester si son destinataire est accessible. N'importe quelle machine qui reçoit une telle requête doit formuler un message ICMP « echo reply » en retour(44).
• Ce mécanisme est extrêmement utile, la plupart des implémentations le proposent sous forme d'un utilitaire (ping sous Unix).

« Destination Unreachable (3) »

• Quand une passerelle ne peut pas délivrer un datagramme IP, elle envoie un message ICMP « destination unreachable » à l'émetteur.
• Dans ce cas le champ CODE complète le message d'erreur avec :
  • 0 : « Network unreachable » ;
  • 1 : « Host unreachable » ;
  • 2 : « Protocol unreachable » ;
  • 3 : « Port unreachable » ;
  • 4 : « Fragmentation needed and DF set » ;
  • 5 : « Source route failed ».

« Source Quench (4) »

• Quand un datagramme IP arrive trop vite pour une passerelle ou un hôte, il est rejeté.
• Un paquet arrive « trop vite » quand la machine qui doit le lire est congestionnée, trop de trafic à suivre...
• Dans ce cas la machine en question envoie un paquet ICMP « source quench » qui est interprété de la façon suivante :
  • • l'émetteur ralenti le rythme d'envoi de ses paquets jusqu'à ce qu'il cesse de recevoir ce message d'erreur. La vitesse est donc ajustée par une sorte d'apprentissage rustique. Puis graduellement il augmente le débit, aussi longtemps que le message « source quench » ne revient pas.
  • Ce type de paquet ICMP a donc tendance à vouloir réguler le flux des datagrammes au niveau IP alors que c'est une fonctionnalité de la couche de transport (TCP).
  • C'est donc une sérieuse entorse à la règle d'indépendance des couches.

« Redirect (5) »

• Les tables de routage (voir le paragraphe 6) des stations restent assez statiques durant de longues périodes. Le système d'exploitation les lit au démarrage sur le système de fichiers et l'administrateur en change de temps en temps les éléments.
• Si entre deux modifications une destination change d'emplacement, la donnée initiale dans la table de routage peut s'avérer incorrecte.
• Les passerelles connaissent de bien meilleures routes que les hôtes eux-mêmes, ainsi quand une passerelle détecte une erreur de routage, elle fait deux choses :
  • • elle envoie à l'émetteur du paquet un message ICMP « redirect » ;
    • elle redirige le paquet vers la bonne destination.
• Cette redirection ne règle pas les problèmes de routage, car elle est limitée aux interactions entre passerelles et hôtes directement connectés.
• La propagation des routes au travers des réseaux multiples est un autre problème.
• Le champ CODE du message ICMP peut avoir les valeurs suivantes :
  • 0 : « Redirect datagram for the Net » ;
  • 1 : « Redirect datagram for the host » ;
  • 2 : ...

« Router solicitation (10) vs Router advertisement (9) »

• Il s'agit d'obtenir ou d'annoncer des routes, nous verrons cela plus en détail dans le paragraphe 6.4.

« Time exceeded (11) »

• Chaque datagramme contient un champ TTL dit « TIME TO LIVE » appelé aussi « hop count ».
• Afin de prévenir le cas où un paquet circulerait à l'infini d'une passerelle à une autre, chaque passerelle décrémente ce compteur, rejette le paquet quand le compteur arrive à zéro et envoie un message ICMP à l'émetteur pour le tenir au courant.

IGMP est un protocole de communication entre les routeurs susceptibles de transmettre des datagrammes multicast et des hôtes qui veulent s'enregistrer dans tel ou tel groupe. IGMP est encapsulé dans IP(46) avec le protocole numéro 2. Comme le montre la figure IV.12, sa taille est fixe (contrairement à ICMP) : seulement deux mots de quatre octets.

• Version : version 1.
• Type : ce champ prend deux valeurs, 1 pour dire qu'il s'agit d'une question (query d'un routeur), 2 pour dire qu'il s'agit de la réponse d'un hôte.
• Inutilisé : ...
• Checksum : le checksum est calculé comme celui d'ICMP.
• Adresse : c'est l'adresse multicast (classe D) à laquelle appartient l'hôte qui répond.

La RFC 1112 précise que les routeurs multicast envoient des messages de questionnement (Type=Queries) pour reconnaître quels sont les éventuels hôtes appartenant à quel groupe. Ces questions sont envoyées à tous les hôtes des LAN directement raccordés à l'aide de l'adresse multicast du groupe 224.0.0.1(47) encapsulé dans un datagramme IP ayant un champ TTL=1. Tous les hôtes susceptibles de joindre un groupe multicast écoutent ce groupe par hypothèse.

Les hôtes, dont les interfaces ont été correctement configurées, répondent à une question par autant de réponses que de groupes auxquels ils appartiennent sur l'interface réseau qui a reçu la question. Afin d'éviter une « tempête de réponses », chaque hôte met en œuvre la stratégie suivante :

• Un hôte ne répond pas immédiatement à la question reçue. Pour chaque groupe auquel il appartient, il attend un délai compris entre 0 et 10 secondes, calculé aléatoirement à partir de l'adresse IP unicast de l'interface qui a reçu la question, avant de renvoyer sa réponse. La figure
  IV.13 montre un tel échange, remarquez au passage la valeur des adresses.
• La réponse envoyée est écoutée par tous les membres du groupe appartenant au même LAN. Tous ceux qui s'apprêtaient à envoyer une telle réponse au serveur en interrompent le processus pour éviter une redite. Le routeur ne reçoit ainsi qu'une seule réponse pour chaque groupe, et pour chaque LAN, ce qui lui suffit pour justifier le routage demandé.

Il y a deux exceptions à la stratégie ci-dessus. La première est que si une question est reçue alors que le compte à rebours pour répondre à une réponse est en cours, il n'est pas interrompu.

La deuxième est qu'il n'y a jamais de délai appliqué pour l'envoi de datagramme portant l'adresse du groupe de base 224.0.0.1.

Pour rafraîchir leur connaissance des besoins de routage, les routeurs envoient leurs questions avec une fréquence très faible de l'ordre de la minute, afin de préserver au maximum la bande passante du réseau. Si aucune réponse ne leur parvient pour tel ou tel groupe demandé précédemment, le routage s'interrompt.

Quand un hôte rejoint un groupe, il envoie immédiatement une réponse (type=report) pour le groupe (les) qui l'intéresse, plutôt que d'attendre une question du routeur. Au cas où cette réponse se perdrait, il est recommandé d'effectuer une réémission dans un court délai.

Remarques :

• Sur un LAN sans routeur pour le multicast, le seul trafic IGMP est celui des hôtes demandant à rejoindre tel ou tel groupe.
• Il n'y a pas de report pour quitter un groupe.
• La plage d'adresses multicast entre 224.0.0.0 et 224.0.0.225 est dédiée aux applications utilisant une valeur de 1 pour le champ TTL (administration et services au niveau du LAN). Les routeurs ne doivent pas transmettre de tels datagrammes.
• Il n'y a pas de message ICMP sur les datagrammes ayant une adresse de destination du type multicast.

En conséquence les applications qui utilisent le multicast (avec une adresse supérieure à 224.0.0.225) pour découvrir des services, doivent avoir une stratégie pour augmenter la valeur du champ TTL en cas de non-réponse.

Précisions en cours...

Sous Unix toutes les opérations de routage se font grâce à une table, dite « table de routage », qui se trouve dans le noyau lui-même. La figure V.14 résume la situation :

Cette table est très fréquemment utilisée par IP sur un serveur, plusieurs centaines de fois par secondes.

Comment est-elle créée ?

Au démarrage avec la commande « route », invoquée dans les scripts de lancement du système, et en fonctionnement :

• au coup par coup avec la commande « route », à partir du shell (administrateur système uniquement) ;
• dynamiquement avec les démons de routage « routed » ou « gated » (la fréquence de mise à jour est typiquement de l'ordre de 30 s) ;
• par des messages « ICMP redirect ».

La commande netstat -rn permet de la visualiser au niveau de l'interface utilisateur (« Application layer ») :

    $ netstat -rn
    Routing tables

    Internet:
    Destination          Gateway            Flags
    default              192.168.192.36     UGS
    127.0.0.1            127.0.0.1          UH
    192.168.192/27       link#1             UC
    192.168.192.10       8:0:9:85:76:9c     UHLW
    192.168.192.11       8:0:9:85:76:bd     UHLW
    192.168.192.12       8:0:9:88:8e:31     UHLW
    192.168.192.13       8:0:9:a:f9:bc      UHLW
    192.168.192.14       0:4f:49:1:28:22    UHLW
    192.168.192.15       link#1             UHLW
    192.168.192.32/27    link#2             UC
    192.168.192.33       8:0:9:70:44:52     UHLW
    192.168.192.34       0:20:af:2f:8f:f1   UHLW
    192.168.192.35       0:4f:49:1:36:50    UHLW
    192.168.192.36       link#2             UHLW

On peut mémoriser cette table comme étant essentiellement composée d'une colonne origine, d'une colonne destination.

De plus, chaque route qui désigne une passerelle (ici la route par défaut) doit s'accompagner d'un nombre de sauts (« hop »), ou encore métrique, qui permet le choix d'une route plutôt qu'une autre en fonction de cette valeur. Chaque franchissement d'un routeur compte pour un saut. Dans la table ci-dessus, la métrique de la route par défaut est 1.

Remarque : la sortie de la commande netstat -rn ci-dessus a été simplifiée(49).

Les drapeaux (« flags ») les plus courants :

La figure IV.15 précise l'architecture du réseau autour de la machine sur laquelle a été exécuté le netstat.

Comme nous avons pu le deviner au paragraphe précédent, les routes statiques sont celles créées au démarrage de la machine ou ajoutées manuellement par l'administrateur système, en cours de fonctionnement.

Le nombre de machines possibles à atteindre potentiellement sur l'Internet est beaucoup trop élevé pour que chaque machine puisse espérer en conserver l'adresse, qui plus est, même si cela était concevable, cette information ne serait jamais à jour donc inutilisable.

Plutôt que d'envisager la situation précédente, on préfère restreindre l'étendue du « monde connu » et utiliser la « stratégie de proche en proche » précédemment citée.

Si une machine ne peut pas router un datagramme, elle connaît (ou est supposée connaître) l'adresse d'une passerelle supposée être mieux informée pour transmettre ce datagramme.

Dans l'exemple de sortie de la commande netstat du paragraphe 6.1, on peut reconnaître que l'administrateur système n'a configuré qu'une seule route « manuellement »(50), toutes les autres lignes ont été déduites par la couche IP elle-même.

La figure V.16 met en situation plusieurs réseaux et les passerelles qui les relient. Voici une version très simplifiée des tables de routage statiques où sont présentes les machines A, B, R1 et R2 :

Machine A : default : 192.168.192.251

Machine B : default : 10.1.1.1

Routeur R1 : 10 : 172.16.10.3

Routeur R2 : 192.168.192 : 172.16.10.1

5-6-2-1. Algorithme de routage▲

Si la topologie d'un réseau offre la possibilité de plusieurs routes pour atteindre une même destination, s'il est vaste et complexe, sujet à des changements fréquents de configuration... Le routage dynamique est alors un bon moyen d'entretenir les tables de routage et de manière automatique.

Il existe de nombreux protocoles de routage dynamique dont certains sont aussi anciens que l'Internet. Néanmoins tous ne conviennent pas à tous les types de problème, il en existe une hiérarchie.

Schématiquement on peut imaginer l'Internet comme une hiérarchie de routeurs. Les routeurs principaux (« core gateways ») de cette architecture utilisent entre eux des protocoles comme GGP (« Gateway to Gateway Protocol »), l'ensemble de ces routeurs forment ce que l'on nomme l'« Internet Core ».

En bordure de ces routeurs principaux se situent les routeurs qui marquent la frontière avec ce que l'on nomme les « Autonomous systems », c'est-à-dire des systèmes de routeurs et de réseaux qui possèdent leurs mécanismes propres de propagation des routes. Le protocole utilisé par ces routeurs limitrophes est souvent EGP (« Exterior Gateway Protocol ») ou BGP (« Border Gateway Protocol »).

Au sein d'un système autonome on utilise un IGP (« Interior Gateway Protocol »), c'est-à-dire un « protocole de gateways intérieurs ». Les protocoles les plus couramment employés sont RIP (« Routing Information Protocol ») qui est simple à comprendre et à utiliser, ou encore OSPF (« Open Shortest Path First ») plus récent, plus capable, mais aussi beaucoup plus complexe à comprendre dans son mode de fonctionnement, ou encore IS-IS de la couche ISO de l'OSI.

5-6-3-1. RIP - « Routing Information Protocol »▲

RIP est apparu avec la version BSD d'Unix, il est documenté dans la RFC 1058 (1988 - Version 1 du protocole) et la RFC 1388 (1993 - Version 2 du protocole). Ce protocole est basé sur des travaux plus anciens menés par la firme Xerox.

RIP utilise le concept de « vecteur de distances », qui s'appuie sur un algorithme de calcul du chemin le plus court dans un graphe. Le graphe est celui des routeurs, la longueur du chemin est établie en nombre de sauts (« hop »), ou métrique, entre la source et la destination, c'est-à-dire en comptant toutes les liaisons. Cette distance est exprimée comme un nombre entier variant entre 1 et 15 ; la valeur 16 est considérée comme l'infini et indique une mise à l'écart de la route.

Chaque routeur émet dans un datagramme portant une adresse IP de broadcast, à fréquence fixe (environ 30 secondes), le contenu de sa table de routage et écoute celle des autres routeurs pour compléter sa propre table. Ainsi se propagent les tables de routes d'un bout à l'autre du réseau. Pour éviter une « tempête de mises à jour », le délai de 30 secondes est augmenté d'une valeur aléatoire comprise entre 1 et 5 secondes.

Si une route n'est pas annoncée au moins une fois en trois minutes, la distance devient « infinie », et la route sera retirée un peu plus tard de la table (elle est propagée avec cette métrique).

L'adresse IP utilisée est une adresse de multipoint (« multicast ») comme nous verrons au paragraphe 6.4

Depuis la définition de RIPv2 les routes peuvent être accompagnées du masque de sous-réseau qui les caractérise. Ainsi on peut avoir la situation suivante :

Après propagation des routes, la table de routage du routeur R1 pourrait bien ressembler à :

Source	Destination	Coût
192.168.192.224	R1	1
192.168.10.0	R1	1
192.168.11.0	R2	2
192.168.192.64	R3	3

Avec une route par défaut qui est le routeur R2. La constitution de cette table n'est possible qu'avec RIPv2 étant donné l'existence des deux sous-réseaux de la classe C 192.168.192.

Le fonctionnement de ce protocole est détaillé plus loin.

5-6-3-2. OSPF - « Open Shortest Path First »▲

Au démarrage d'une station, plutôt que de configurer manuellement les routes statiques, surtout si elles sont susceptibles de changer et que le nombre de stations est grand, il peut être intéressant de faire de la « découverte automatique de routeurs » (RFC 1256).

À intervalles réguliers les routeurs diffusent des messages ICMP de type 9 (« router advertisement ») d'annonces de routes. Ces messages ont l'adresse multicast 224.0.0.1, qui est à destination de tous les hôtes du LAN.

Toutes les stations capables de comprendre le multicast (et convenablement configurées pour ce faire) écoutent ces messages et mettent à jour leur table.

Les stations qui démarrent peuvent solliciter les routeurs si l'attente est trop longue (environ sept minutes) avec un autre message ICMP, de type 10 (« router sollicitation ») et avec l'adresse multicast 224.0.0.2 (à destination de tous les routeurs de ce LAN). La réponse du ou des routeurs est du type « unicast », sauf si le routeur s'apprêtait à émettre une annonce.

À chaque route est associé un niveau de préférence et une durée de validité, définis par l'administrateur du réseau. Une validité nulle indique un routeur qui s'arrête et donc une route qui doit être supprimée.

Si entre deux annonces une route change, le mécanisme de « ICMP redirect », examiné au paragraphe suivant, corrige l'erreur de route.

La découverte de routeur n'est pas un protocole de routage, son objectif est bien moins ambitieux : obtenir une route par défaut.

Il est intéressant de noter que sur les machines FreeBSD, c'est le démon de routage routed qui effectue ce travail à la demande(52).

La table de routage peut être modifiée dynamiquement par un message ICMP (IV).

La situation est celle de la figure IV.21.

• La station veut envoyer un datagramme et sa table de routage lui commande d'utiliser la route qui passe par le routeur R1.
• Le routeur R1 reçoit le datagramme, scrute sa table de routage et s'aperçoit qu'il faut désormais passer par R2. Pour ce faire :
  • il reroute le datagramme vers R2, ce qui évite qu'il soit émis deux fois sur le LAN ;
  • il envoie un message « ICMP redirect » (type 5) à la station, lui indiquant la nouvelle route vers R2 ;
  • il reroute le datagramme vers R2, ce qui évite qu'il soit émis deux fois sur le LAN ;
  • il envoie un message « ICMP redirect » (type 5) à la station, lui indiquant la nouvelle route vers R2.

Ce travail s'effectue pour chaque datagramme reçu de la station.

• Dès que la station reçoit le message « ICMP redirect » elle met à jour sa table de routage. La nouvelle route est employée pour les datagrammes qui suivent (vers la même direction).

La route modifiée est visible avec la commande netstat -r, elle figure avec le drapeau 'M' (modification dynamique).

Pour des raisons évidentes de sécurité, cette possibilité n'est valable que sur un même LAN.

Toutes les implémentations d'IP supportent une interface de type « loopback ». L'objet de cette interface est de pouvoir utiliser les outils du réseau en local, sans passer par une interface réseau réelle (associée à une carte physique).

La figure IV.22 ci-dessus, montre que la couche IP peut utiliser, selon le routage, l'interface standard du réseau, où l'interface de loopback.

Le routage est ici bien sûr basé sur l'adresse IP associée à chacune des interfaces. Cette association est effectuée sur une machine Unix à l'aide de la commande ifconfig, qui établit une correspondance entre un pilote de périphérique (repéré par son fichier spécial) et une adresse IP.

Dans le cas du pilote de loopback, l'adresse est standardisée à n'importe quelle adresse valide du réseau 127.

La valeur courante est 127.0.0.1, d'où l'explication de la ligne ci-dessous déjà rencontrée dans le cadre de la table de routage :

   Routing tables
    Internet:
    Destination        Gateway            Flags  Netif
    ...
    127.0.0.1          127.0.0.1          UH      lo0
    ...

Dans toutes les machines Unix modernes, cette configuration est déjà prévue d'emblée dans les scripts de démarrage.

Concrètement, tout dialogue entre outils clients et serveurs sur une même machine est possible et même souhaitable sur cette interface pour améliorer les performances et parfois la sécurité(53).

L'exemple d'usage le plus marquant est sans doute celui du serveur de noms qui tient compte explicitement de cette interface dans sa configuration.