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 ensemble 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 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 : 5-1-2. Network Byte Order▲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 : figure IV.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 »). 5-1-3. Description de l'entête▲VERS
HLEN
TOTAL LENGTH
TYPE OF SERVICE vs DSCP/ECN
IDENTIFICATION, FLAGS et FRAGMENT OFFSET
TTL
PROTOCOL
HEADER CHECKSUM
SOURCE ADDRESS
DESTINATION ADDRESS
IP OPTIONS
PADDING
En conclusion partielle que peut-on dire du travail de la couche IP ?
5-1-4. Fragmentation IP - MTU▲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. figure IV.03 - Fragmentation IP5-1-4-1. Fragmentation▲
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. figure IV.04 - Fragment à transmettrePour tous les fragments :
Pour le dernier fragment :
5-1-4-2. Réassemblage▲
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. figure IV.05 - Résumé de la fragmentation
Notez les variations de certains champs de l'entête :
5-2. Protocole ARP▲ARP est l'acronyme de « Address Resolution Protocol », il est défini dans la RFC 826.
On suppose qu'une machine connaît 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.
5-2-1. Fonctionnement▲figure IV.06 - Question ARPSur la figure IV.06 la station Ethernet A (IA, PA) a besoin de connaître 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. 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 ». figure IV.07 - Réponse ARPSi 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 :
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. 5-2-2. Format du datagramme▲figure IV.08 - Datagramme ARPLe 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. 5-2-3. Proxy ARP▲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. 5-3. Protocole RARP▲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).
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. 5-4. Protocole ICMP▲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 une 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 événement 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 montre que le niveau Application peut également avoir un accès direct à ce protocole. 5-4-1. Le système de messages d'erreur▲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. 5-4-2. Format des messages ICMP▲Chaque message ICMP traverse le réseau dans la partie DATA d'un datagramme IP : figure IV.09 - Message ICMPLa 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 : figure IV.10 - Format d'un message ICMPIl 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. 5-4-3. Quelques types de messages ICMP▲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) »
« Destination Unreachable (3) »
« Source Quench (4) »
« Redirect (5) »
« Router solicitation (10) vs Router advertisement (9) »
« Time exceeded (11) »
5-5. Protocole IGMP▲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 multicast sont à destination d'un groupe d'utilisateurs dont l'émetteur ne connaît 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éseau(45), 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 LAN directement accessibles pour ne pas encombrer les bandes passantes associées avec des flux d'octets que personne n'utilise plus ! 5-5-1. Description de l'entête▲figure IV.12 - Entête IGMPIGMP 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.
5-5-2. Fonctionnement du protocole▲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 :
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 :
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. 5-5-3. Fonctionnement du Mbone▲Précisions en cours... 5-6. Routage IP▲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 faire(48). Dans ce paragraphe nous examinons le problème du routage de manière synthétique, nous aborderons plus en détail les aspects techniques du routage dynamique au chapitre 7. 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'une interface à une 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 au travers de multiples réseaux physiques, donc au travers de multiples passerelles. On divise le routage en deux grandes familles : Le routage direct
Le routage indirect
Parce que 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 certains cas (CIDR) le masque de sous-réseau est aussi employé. Munie de ce numéro de réseau, la couche IP examine les informations contenues dans sa table de routage. 5-6-1. 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 : figure IV.14 - Table de routageCette 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 :
La commande netstat -rn permet de la visualiser au niveau de l'interface utilisateur (« Application layer ») :
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. figure IV.15 - Situation réseau lors du netstat5-6-2. Routage statique▲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 figure IV.16 - Exemple de nuage avec routage statique5-6-2-1. Algorithme de routage▲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 IN : est un numéro de réseau auquel M est directement reliée :
Sinon Si ID apparaît comme une machine à laquelle une route spéciale est attribuée :
Sinon Si IN apparaît dans la table de routage :
Sinon s'il existe une route par défaut :
Sinon :
5-6-3. Routage dynamique▲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 »). figure IV.17 - Exemple pour routage dynamiqueAu 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 : figure IV.18 - Topologie pour routage dynamiqueAprès propagation des routes, la table de routage du routeur R1 pourrait bien ressembler à :
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 »▲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, parce que 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 chemins multiples, OSPF, bien que beaucoup plus complexe que RIP, a toutes les qualités pour le remplacer, même sur les tout petits réseaux. OSPF doit son nom à l'algorithme d'Edsger W. Dijkstra(51) de recherche du chemin le plus court 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é plus loin. 5-6-4. Découverte de routeur et propagation de routes▲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). 5-6-5. Message ICMP « redirect »▲La table de routage peut être modifiée dynamiquement par un message ICMP (IV). La situation est celle de la figure IV.21. figure IV.21 - ICMP « redirect »
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. 5-6-6. Interface de « loopback »▲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). figure IV.22 - Interface de « loopback »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 :
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. 5-7. Finalement, comment ça marche ?▲Dans ce paragraphe nous reprenons la figure III.06 et nous y apportons comme cela é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 ! figure IV.23 - Illustration du routage direct et indirectCe tableau résume l'adressage physique et logique de la situation :
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 ? Étape 1
Étape 2
Étape 3
Étape 4
Étape 5
Étape 6
Remarque : si A envoie un deuxième datagramme, les caches ARP ont les adresses MAC utiles et donc les étapes 1, 2, 4 et 5 deviennent inutiles... 5-8. Conclusion sur IP▲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 :
5-9. Bibliographie▲Pour en savoir plus :
Le lecteur ayant un accès aux sources d'une pile IP pourra aller consulter directement la structure de l'entête, par exemple le fichier /usr/src/sys/netinet/ip.h sur une machine FreeBSD. Nous examinerons les caractéristiques de la version 6 d'IP à la fin de ce cycle de cours. Ou encore plus simple (24 - 1) x 4. Cf. chapitre I « Réseaux locaux ». Voir ou revoir la figure II.02 du chapitre d'introduction à IP. Voir ou revoir la figure II.02 du chapitre d'introduction à IP. Même figure qu'au point précédent. Pour des raisons de sécurité, certaines machines peuvent ne pas répondre. La première expérience à grande échelle du multicast fut sans doute la conférence de l'IETF en mars 1992. Le papier ftp://venera.isi.edu/ietf-audiocast-article.ps relate cette expérience. Voir ou revoir la figure II.02 du chapitre I d'introduction à IP. « tous les hôtes du LAN ». On peut consulter par exemple http://www.freebsd.org/$\sim$picobsd/, où le site du projet Zebra de GNU http://www.zebra.org/ Des colonnes Refs, Use et Netif. Ce n'est pas tout à fait exact, nous verrons pourquoi au paragraphe concernant l'interface de « loopback » (6.6). http://www.cs.utexas.edu/users/EWD/ À condition d'activer avec router enable=YES dans le fichier /etc/rc.conf. Nous verrons ultérieurement (cf. chapitre VIII) que le filtrage IP sur le 127/8 est aussi aisé que sur n'importe quel autre réseau Copyright © 2009 François Laissus. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts. Quelle est la valeur du champ protocole afin d'indiquer TCP ?Le protocole TCP est indiqué par la valeur 06H dans le champ protocole de l'en tête IP.
Quel est le protocole TCP ?Présenté simplement, le protocole TCP/IP est un standard de communication entre deux processus. Il détermine et fixe les règles inhérentes à l'émission et à la réception de données sur un réseau. L'association des deux protocoles permet d'apporter des garanties de fiabilité dans le transfert des données.
Quels sont les deux champs inclus dans l'EnLe champ PSH est codé sur 1 bit et indique au récepteur de délivrer les données à l'application et de ne pas attendre le remplissage des tampons. Le champ RST est codé sur 1 bit et demande la réinitialisation de la connexion. Le champ SYN est codé sur 1 bit et indique la synchronisation des numéros de séquence.
Quelle est la taille minimum de l'entêté TCP ?C'est-à-dire, si l'entête est de 20 octets (longueur minimale de l'entête TCP) alors ce champ aura comme valeur 5 (car 4 x 5 = 20) et si l'entête est de 60 octets (longueur maximale de l'entête TCP), alors ce champ aura comme valeur 15 (car 4 x 15 = 60).
|