IP est l'acronyme de `` Internet Protocol '', il est défini dans la RFC 791 et a été conçu en 1980 pour remplacer NCP (`` Network Control Protocol ''), le protocole de l'Arpanet.
Presque trente ans après sa première implémentation, ses limitations se font de plus en plus pénalisantes pour les nouveaux usages sur les réseaux. Avant de le jeter aux orties, posons-nous la question de qui pouvait prévoir à cette époque où moins de mille ordinateurs étaient reliés ensembles, que trois décennies plus tard des dizaines de millions d'hôtes l'utiliseraient comme principal protocole de communication ?
Sa longévité est donc remarquable et il convient de l'analyser de près avant de pouvoir le critiquer de manière constructive.
Les octets issus de la couche de transport et encapsulés à l'aide d'un en-tê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.
figure V.01 -- Structure du datagramme IP
|
Quelques caractéristiques en vrac du protocole IP :
Ces problèmes ne sont pas détectés par IP et donc il ne peut en informer la couche de transport.
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 ordreV1, 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 :
figure V.02 -- `` Big endian '' vs `` Little endian ''
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 '').
La taille des données est donc à calculer par soustraction de la taille de l'en-tê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 ''.
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 4 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).
| 0x00 | - | Service normal | Transfert banal |
| 0x10 | bit 3,D | Minimiser le délai | Session telnet |
| 0x08 | bit 4,T | Maximiser le débit | Transfert ftp |
| 0x04 | bit 5,R | Maximiser la qualité | ICMP |
| 0x02 | bit 6,C | Minimiser le coût | `` news '' (nntp) |
L'usage de ces bits est mutuellement exclusif.
Les nouveaux besoins de routage on conduit l'IETF a 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 '' (voir page ![[*]](crossref.png)
)
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...
Consulter la section suivante Fragmentation IP.
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.
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.
A la réception de chaque paquet, la couche calcule cette valeur, si elle ne correspond pas à celle trouvée dans l'en-tête le datagramme est oublié (`` discard '') sans message d'erreur.
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.
En conclusion partielle que peut-on dire du travail de la couche IP ?
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'en-tê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 page )
`` Fragmentation needed but don't fragment bit set '' et
bien sûr le datagramme n'est pas transmis plus loin.
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 3 bits.
FRAGMENT OFFSET contient l'offset du fragment, relativement au datagramme initial.
Cet offset est codé sur 13 bits.
Pour tous les fragments :
Pour le dernier fragment :
C'est la raison principale pour laquelle il faut absolument éviter de fragmenter un datagramme IP !
La figure V.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 | C1 | C2 | C3 | C4 | C5 |
Notez les variations de certains champs de l'en-tête :
ARP est l'acronyme de `` Address Resolution Protocol '', il est définie dans la RFC 826.
elles connaissent
leurs adresses physiques respectives.
On suppose qu'une machine connait sa propre adresse physique par un moyen qui n'est pas décrit ici (ne fait pas partie du protocole).
Remarque importante : Cette information n'a pas de sens dans le cadre d'une liaison de type `` point à point '' avec un protocole tel que ppp.
Sur la figure V.06 la station Ethernet A (IA, PA) a besoin de connaitre l'adresse physique de la station Ethernet B (IB, PB), 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.
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 ''.
Remarque : quand une station Ethernet ne répond plus (cf ICMP) il y a suppression de l'association adresse IP - adresse MAC.
Si la station B ne répond pas, la station continuera à poser la question à intervals 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 '' physiques, les messages ARP ne franchissent pas les routeurs. Il existe cependant un cas particulier : le proxy ARP, que nous évoquerons succintement à la fin de ce paragraphe.
Le datagramme ci-dessus est encapsulé dans une trame physique du type 0x0806V5.
| Question | Réponse | |
| ARP | 1 | 2 |
| RARP | 3 | 4 |
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.
RARP est l'acronyme de `` Reverse Address Resolution Protocol '', il est défini dans la RFC 903 (BOOTP et DHCP en sont des alternatives avec plus de possibilités).
Le champ OPERATION contient alors le code de `` RARP question ''
Sur une machine Unix configurée en serveur RARP les correspondances entres adresses IP et adresses physiques sont enregistrées dans un fichier nommé généralement /etc/bootptab.
ICMP est l'acronyme de `` Internet Control Message Protocol '', il est historiquement défini dans la RFC 950.
Nous avons vu que le protocole IP ne vérifie pas si les paquets émis sont arrivés à leur destinataire dans de bonnes conditions.
Les paquets circulent d'une passerelle vers un autre jusqu'à en trouver une qui puisse les délivrer directement à un hôte. Si une passerelle ne peut router ou délivrer directement un paquet ou si un évenement anormal arrive sur le réseau comme un trafic trop important ou une machine indisponible, il faut pouvoir en informer l'hôte qui a émis le paquet. Celui-ci pourra alors réagir en fonction du type de problème rencontré.
ICMP est un mécanisme de contrôle des erreurs au niveau
IP, mais la figure II.02 du chapitre d'introduction
à IP (page ) montre que le niveau Application
peut également avoir un accès direct à ce protocole.
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 rupture 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 parcequ'en surcharge.
Des paquets IP peuvent alors ne pas être délivrés à leur destinataire et le protocol 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 IPV6 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 ICMPV7).
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 entres 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 au 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 !
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).
La figure V.10 décrit le format du message ICMP :
Chaque message ICMP a un type particulier qui caractérise le problème qu'il signale. Un en-tête de 32 bits est composé comme suit :
En addition, les messages ICMP donnent toujours l'en-tê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.
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 retourV8
Ce mécanisme est extrêmement utile, la plupart des implémentations le propose sous forme d'un utilitaire (ping sous Unix).
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 :
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.
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 :
Cette redirection ne règle pas les problèmes de routage car elle est limitée aux interactions entres passerelles et hôtes directement connectés.
La propagation des routes aux travers des réseaux multiples est un autre problème.
Le champ CODE du message ICMP peut avoir les valeurs suivantes :
Chaque datagramme contient un champ TTL dit `` TIME TO LIVE '' appellé aussi `` hop count ''.
Afin de prévenir le cas ou un paquet circulerait à l'infini d'une passerelle à une autre, chaque passerelle décrémente ce compteur et rejette le paquet quand le compteur arrive à zéro et envoie un message ICMP à l'émetteur pour le tenir au courant.
IGMP, l'acronyme de `` Internet Group Management Protocol '', est historiquement défini dans l'Annexe I de la RFC 1112.
Sa raison d'être est que les datagrammes ayant une adresse multicastV9 sont à destination d'un groupe d'utilisateurs dont l'émetteur ne connait ni le nombre ni l'emplacement. L'usage du multicast étant par construction dédié aux applications comme la radio ou la vidéo sur le réseauV10, donc consommatrices de bande passante, il est primordial que les routeurs aient un moyen de savoir s'il y a des utilisateurs de tel ou tel groupe sur les LANs directement accessibles pour ne pas encombrer les bandes passantes associées avec des flux d'octets que personne n'utilise plus !
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 IPV11 avec le
protocole numéro 2. Comme le montre la figure
Romanchapter.12, sa taille
est fixe (contrairement à ICMP) : seulement 2 mots de 4 octets.
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 LANs directement raccordés à l'aide de l'adresse multicast du groupe 224.0.0.1V12encapsulé 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 :
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édement, 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 :
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.
Ce paragraphe décrit de manière succincte le routage des datagrammes. Sur l'Internet, ou au sein de toute entité qui utilise IP, les datagrammes ne sont pas routés par des machines Unix, mais par des routeurs dont c'est la fonction par définition. Ils sont plus efficaces et plus perfectionnés pour cette tâche par construction, et surtout autorisent l'application d'une politique de routage (`` routing policy '') ce que la pile IP standard d'une machine Unix ne sait pas faire. Toutefois il est courant dans les `` petits réseaux '', ou quand le problème à résoudre reste simple, de faire appel à une machine Unix pour ce faireV13.
Dans ce paragraphe nous examinons le problème du routage
de manière synthétique, nous l'aborderons plus en détail
les aspects techniques du routage dynamique
au chapitre VII, page .
Le routage des datagrammes se fait au niveau de la couche IP, et c'est son travail le plus important. Toutes les machines multiprocessus sont théoriquement capables d'effectuer cette opération.
La différence entre un `` routeur '' et un `` hôte '' est que le premier est capable de transmettre un datagramme d'un interface à un autre et pas le deuxième.
Cette opération est délicate si les machines qui doivent dialoguer sont connectées à de multiples réseaux physiques.
D'un point de vue idéal établir une route pour des datagrammes devrait tenir compte d'éléments comme la charge du réseau, la taille des datagrammes, le type de service demandé, les délais de propagation, l'état des liaisons, le trajet le plus court... La pratique est plus rudimentaire !
Il s'agit de transporter des datagrammes aux travers de multiples réseaux physiques, donc aux travers de multiples passerelles.
cm
On divise le routage en deux grandes familles :
Il s'agit de délivrer un datagramme à une machine raccordée au même LAN.
L'émetteur trouve l'adresse physique du correspondant (ARP), encapsule le datagramme dans une trame et l'envoie.
Le destinataire n'est pas sur le même LAN comme précédement. Il est absolument nécessaire de franchir une passerelle connue d'avance ou d'employer un chemin par défaut.
En effet, toutes les machines à atteindre ne sont pas forcément sur le même réseau physique. C'est le cas le plus courant, par exemple sur l'Internet qui regroupe des centaines de milliers de réseaux différents.
Cette opération est beaucoup plus délicate que la précédente car il faut sélectionner une passerelle.
Parceque le routage est une opération fondamentalement orientée `` réseau '', le routage s'appuie sur cette partie de l'adresse IP du destinataire. La couche IP détermine celle-ci en examinant les bits de poids fort qui conditionnent la classe d'adresse et donc la segmentation `` network.host ''. Dans certain cas (CIDR) le masque de sous réseau est aussi employé.
Muni de ce numéro de réseau, la couche IP examine les informations contenues dans sa table de routage :
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 :
cm
Cette table est très fréquemment utilisée par IP : sur un serveur plusieurs centaines de fois par secondes.
cm Comment est-elle crée ? cm
Au démarrage avec la commande route, invoquée dans les scripts de lancement du système, et en fonctionnement :
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.V14
Les drapeaux (`` flags '') les plus courants :
| C c | La route est générée par la machine, à l'usage. |
| D | La route a été crée dynamiquement (démons de routage). |
| G | La route désigne une passerelle, sinon c'est une route directe. |
| H | La route est vers une machine, sinon elle est vers un réseau. |
| L | Désigne la conversion vers une adresse physique (cf ARP). |
| M | La route a été modifiée par un `` redirect ''. |
| S | La route a été ajoutée manuellement. |
| U | La route est active. |
| W | La route est le résultat d'un clônage. |
La figure V.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'administeur 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édement citée.
Si une machine ne peut pas router un datagramme, elle connait (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 ''V15, 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 présentes sont les machines A, B, R1 et R2 :
Cet algorithme simplifié résume les opérations de la couche IP pour choisir une destination, en fonction de sa table de routage. Cette opération est essentiellement basée sur le numéro de réseau, IN, extrait de l'adresse IP, ID. M désigne la machine sur laquelle s'effectue le 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 routages 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 entres-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.
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 distance '', 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êtes de mises à jours '', le délais 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é
page
Contrairement à RIP, OSPF n'utilise pas de vecteur de distances mais base ses décisions de routage sur le concept d'`` états des liaisons ''. Celui-ci permet un usage beaucoup plus fin des performances réelles des réseaux traversés, parceque cette métrique est changeante au cours du temps. Si on ajoute à cela une méthode de propagation très rapide des routes par inondation, sans boucle et la possibilité de chemin multiples, OSPF, bien que beaucoup plus complexe que RIP, a toutes les qualités pour le remplacer, même sur les tous petits réseaux.
OSPF doit son nom à l'algorithme d'Edsger W. DijkstraV16de recherche du chemin le plus court d'abord lors du parcours d'un graphe. Le `` Open '' vient du fait qu'il s'agit d'un protocole ouvert de l'IETF, dans la RFC 2328...
Le fonctionnement de ce protocole est détaillé
page
Au démarrage d'une station, plutôt que de configurer manuellement les routes statiques, surtout si elle 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).
À intervals 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 a 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 7 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 sur les machines FreeBSD c'est le démon de routage routed qui effectue ce travail à la demande V17
La table de routage peut être modifiée dynamiquement par un message ICMP (IV).
La situation est celle de la figure V.21.
Ce travail s'effectue pour chaque datagramme reçu de la station.
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 un interface réseau réel (associé à une carte physique).
La figure V.22 ci-contre, 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 (page
).
cm
figure V.22 -- Interface de `` loopback ''
|
La valeur courante est 127.0.0.1, d'où l'explication de la ligne
ci-dessous déjà rencontrée (page ) 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 cet interface pour améliorer les performances et parfois la sécuritéV18.
L'exemple d'usage le plus marquant est sans doute celui du serveur
de noms (voir page ) qui tient compte
explicitement de cet interface dans sa configuration.
Dans ce paragraphe nous reprenons la figure III.06page
) et nous y apportons comme était annoncé une
explication du fonctionnement qui tienne compte des protocoles
principaux examinés dans ce chapitre. Pour cela nous utilisons
deux réseaux privés de la RFC 1918 : 192.168.10.0 et 192.168.20.0 et
nous faisons l'hypothèse que la passerelle fonctionne comme une machine
Unix qui ferait du routage entre deux de ses interfaces !
cm
figure V.23 -- Illustration du routage direct et indirect
Ce tableau résume l'adressage physique et logique de la situation :
| Interface | Adresse MAC | Adresse IP |
| ifA | 08:00:20:20:cf:af |
192.168.10.109 |
| ifB | 00:01:e6:a1:07:64 |
192.168.20.69 |
| ifR1 | 00:06:5b:0f:5a:1f |
192.168.10.249 |
| ifR2 | 00:06:5b:0f:5a:20 |
192.168.20.249 |
Nous faisons en outre les hypothèses suivantes :
La machine A envoie un datagramme à la machine B, que se passe t-il sur le réseau ?
) et s'apperçoit que la partie
réseau de l'adresse de B n'est pas dans le même
LAN (192.168.10/24 et 192.168.20/20 diffèrent).
L'hypothèse 2 entraine qu'une route route existe pour atteindre
ce réseau, passant par R. L'adresse IP de R est dans
le même LAN, A peut donc atteindre R par un routage
direct. La conséquence de l'hypothèse 1 implique que pour
atteindre R directement il nous faut d'abord déterminer
son adresse physique. Le protocole ARP (page ) doit
être utilisé.
A envoie en conséquence une trame ARP
(page comportant les éléments suivants :
| SENDER HA | 08:00:20:20:cf:af |
| SENDER ADR | 192.168.10.109 |
| TARGET HA | ff:ff:ff:ff:ff:ff |
| TARGET ADR | 192.168.10.249 |
Avec un champ OPERATION qui contient la valeur 1, comme `` question ARP ''.
Remarquez qu'ici l'adresse IP destination est celle de R !
| SENDER HA | 00:06:5b:0f:5a:1f |
| SENDER ADR | 192.168.10.249 |
| TARGET HA | 08:00:20:20:cf:af |
| TARGET ADR | 192.168.10.109 |
| IP SOURCE | 192.168.10.109 |
| IP TARGET | 192.168.20.69 |
| MAC SOURCE | 08:00:20:20:cf:af |
| MAC TARGET | 00:06:5b:0f:5a:1f |
Remarquez qu'ici l'adresse IP destination est celle de B !
| SENDER HA | 00:06:5b:0f:5a:20 |
| SENDER ADR | 192.168.20.249 |
| TARGET HA | ff:ff:ff:ff:ff:ff |
| TARGET ADR | 192.168.20.69 |
| SENDER HA | 00:01:e6:a1:07:64 |
| SENDER ADR | 192.168.20.69 |
| TARGET HA | 00:06:5b:0f:5a:20 |
| TARGET ADR | 192.168.20.249 |
Enfin, dans cette dernière étape, R envoie le datagramme en provenance de A, à B :
| IP SOURCE | 192.168.10.109 |
| IP TARGET | 192.168.20.69 |
| MAC SOURCE | 00:06:5b:0f:5a:20 |
| MAC TARGET | 00:01:e6:a1:07:64 |
Remarque, comparons avec le datagramme de l'étape 3. Si les adresses IP n'ont pas changé, les adresses MAC, diffèrent complètement !
Remarque : Si A envoie un deuxième datagramme, les caches ARP ont les adresses MAC utiles et donc les étape 1, 2, 4 et 5 deviennent inutiles...
Après notre tour d'horizon sur IPv4 nous pouvons dire en conclusion que son espace d'adressage trop limité n'est pas la seule raison qui a motivé les travaux de recherche et développement d'IPv6 :
Pour en savoir plus :