next up previous contents index
Next: VI Protocole UDP Up: A Introduction à la Previous: IV Anatomie d'une adresse   Contents   Index

Subsections


V Protocole IP


1 Datagramme IP

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.

1.1 Structure de l'en-tête

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
\includegraphics{fig.ipv4.01.ps}

Quelques caractéristiques en vrac du protocole IP :


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 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 :

\includegraphics{fig.ipv4.02.ps} 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 '').

1.3 Description de l'en-tête

VERS
4 bits qui spécifient la version du protocol 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é sur l'Internet, bien que quelques implémentations de la version 6 existent et soient déjà en expérimentationV2.

HLEN
4bits qui donnent la longueur de l'en-tête en mots de 4 octets. La taille standard de cette en-tête fait 5 mots, la taille maximale fait : (23 + 22 + 21 + 20) x 4 = 60 octetsV3

TOTAL LENGTH
Donne la taille du datagramme, en-tê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'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 ''.

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 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 [*]) 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
8 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'en-tête. Lors du calcul de ce `` checksum '' ce champ est à 0.

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.

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 :

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 ?

  1. Il consiste à router les datagrammes en les acheminant `` au mieux '', on verra plus loin de quelle manière. C'est son travail principal.

  2. Il peut avoir à fragmenter les données de taille supérieure au MTU du support physique à employer.


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'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.

\includegraphics{fig.ipv4.03.ps}
figure V.03 -- Fragmentation IP

1.4.1 Fragmentation

1.4.2 Réassemblage

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

\includegraphics{fig.ipv4.05.ps}
cm figure V.05 -- Résumé de la fragmentation

  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 :

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


2 Protocole ARP

ARP est l'acronyme de `` Address Resolution Protocol '', il est définie dans la RFC 826.


2.1 Fonctionnement

\includegraphics{fig.ipv4.06.ps}
cm figure V.06 -- Question ARP

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.

\includegraphics{fig.ipv4.07.ps}
cm figure V.07 -- Réponse ARP

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.


2.2 Format du datagramme

\includegraphics{fig.ipv4.08.ps}
cm figure V.08 -- Datagramme ARP

Le datagramme ci-dessus est encapsulé dans une trame physique du type 0x0806V5.

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 (6 octets pour Ethernet).

HLEN 2
pour spécifier la longueur de l'adresse logique (4 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.

  Question Réponse
ARP 1 2
RARP 3 4

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


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.


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.


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 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.

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 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.


4.2 Format des messages ICMP

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

\includegraphics{fig.ipv4.09.ps}
cm figure V.09 -- Message ICMP

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 :

\includegraphics{fig.ipv4.10.ps}
cm figure V.10 -- Format d'un 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 :

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'en-tête IP ne porte que sur son en-tête et non sur les données véhiculées).

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.

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) ''

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).

\includegraphics{fig.ipv4.11.ps}
cm figure V.11 -- `` Echo request '' vs `` Echo reply ''

`` 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 :

  1. Elle envoie à l'émetteur du paquet un message ICMP `` redirect ''
  2. 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 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 :

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 '' 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.


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 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 !

5.1 Description de l'en-tête

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.

\includegraphics{fig.ipv4.12.ps}
cm figure V.12 -- En-tête IGMP

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.


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 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 \oeuvre la stratégie suivante :

  1. Un hôte ne répond pas immédiatement à la question reçue. Pour chaque groupe auquel il appartient, il attend un délais 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
    Romanchapter.13
    montre un tel échange, remarquez au passage la valeur des adresses.

  2. La réponse envoyée est écoutée par tous les membres du groupe appartenant au même LAN. Tout 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é.

\includegraphics{fig.ipv4.13.ps}
cm figure V.13 -- Fonctionnement IGMP

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 :

  1. Sur un LAN sans routeur pour le multicast, le seul trafic IGMP est celui des hôtes demandant à rejoindre tel ou tel groupe.

  2. Il n'y a pas de report pour quitter un groupe.

  3. 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.

  4. 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.


5.3 Fonctionnement du Mbone

Précisions en cours...


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 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 :

Le routage direct

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 routage indirect

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 :


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 :

cm

\includegraphics{fig.ipv4.14.ps}
cm figure V.14 -- Table de routage

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.

\includegraphics{fig.ipv4.15.ps}
cm figure V.15 -- Situation réseau lors du netstat


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'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 :

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

\includegraphics{fig.ipv4.16.ps}
cm figure V.16 -- Exemple de nuage avec routage statique


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
apparait comme une machine à laquelle une route spéciale est attribuée, router le datagramme en fonction.

Sinon Si IN
apparait dans la table de routage, router le datagramme en fonction.

Sinon S'il existe une route par défaut
router le datagramme vers la passerelle ainsi désignée.

Sinon
Déclarer une erreur de routage (ICMP).


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 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 '').

\includegraphics{fig.ipv4.17.ps}
cm figure V.17 -- Exemple pour routage dynamique

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.


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 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 :

\includegraphics{fig.ipv4.18.ps}
cm figure V.18 -- Topologie pour routage dynamique

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 [*]

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, 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 [*]

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 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


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 V.21.

\includegraphics{fig.ipv4.21.ps}
cm figure V.21 -- ICMP `` redirect ''

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

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 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 [*]).

\includegraphics{fig.ipv4.22.ps} 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.

7 Finalement, comment ça marche ?

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 !

\includegraphics{fig.ipv4.23.ps} 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 :

  1. Les caches `` arp '' des machines A, B et R sont vides
  2. La machine A a connaissance d'une route vers le réseau 192.168.20 passant par 192.168.10.249 et réciproquement la machine B voit le réseau 192.168.10.0 via le 192.168.20.249
  3. La machine A a connaissance de l'adresse IP de la machine B

La machine A envoie un datagramme à la machine B, que se passe t-il sur le réseau ?

Étape 1
La machine A applique l'algorithme de routage (page [*]) 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 !

Étape 2
R répond à la `` question ARP '' par une `` réponse ARP '' (OPERATION contient 2) et un champ complèté :

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

Étape 3
A est en mesure d'envoyer son datagramme à B en passant par R. Il s'agit de routage indirect puisque l'adresse de B n'est pas sur le même LAN. Les adresses physiques et logiques se répartissent maintenant comme ceci :

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 !

Étape 4
R a reçu le datagramme depuis A et à destination de B. Celle-ci est sur un LAN dans lequel R se trouve également, un routage direct est donc le moyen de transférrer le datagramme. Pour la même raison qu'à l'étape 1 R n'a pas l'adresse MAC de B et doit utiliser ARP pour obtenir cette adresse. Voici les éléments de cette `` question ARP '' :

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

Étape 5
Et la `` réponse ARP '' :
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

Étape 6

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...

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 :

  1. Son en-tête comporte deux problèmes, la somme de contrôle (checksum) doit être calculée à chaque traitement de datagramme, chaque routeur doit analyser le contenu du champ option.

  2. Sa configuration nécessite au moins trois informations que sont l'adresse, le masque de sous réseau et la route par défaut.

  3. Son absence de sécurité est insupportable. Issu d'un monde fermé où la sécurité n'était pas un problème, le datagramme de base n'offre aucun service de confidentialité, d'intégrité et d'authentification.

  4. Son absence de qualité de service ne répond pas aux exigences des protocoles applicatifs modernes (téléphonie, vidéo, jeux interactifs en réseau, ...). Le champ TOS n'est pas suffisant et surtout est interprété de manière inconsistante par les équipements.


9 Bibliographie

Pour en savoir plus :

RFC 791
`` Internet Protocol. '' J. Postel. Sep-01-1981. (Format: TXT=97779 bytes) (Obsoletes RFC0760) (Status: STANDARD)

RFC 826
`` Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware. '' D.C. Plummer. Nov-01-1982. (Format: TXT=22026 bytes) (Status: STANDARD)

RFC 903
`` Reverse Address Resolution Protocol. '' R. Finlayson, T. Mann, J.C. Mogul, M. Theimer. Jun-01-1984. (Format: TXT=9345 bytes) (Status: STANDARD)

RFC 950
`` Internet Standard Subnetting Procedure. '' J.C. Mogul, J. Postel. Aug-01-1985. (Format: TXT=37985 bytes) (Updates RFC0792) (Status: STANDARD)

RFC 1112
`` Host extensions for IP multicasting. '' S.E. Deering. Aug-01-1989. (Format: TXT=39904 bytes) (Obsoletes RFC0988, RFC1054) (Updated by RFC2236) (Also STD0005) (Status: STANDARD)

RFC 1256
`` ICMP Router Discovery Messages. S. Deering. '' Sep-01-1991. (Format: TXT=43059 bytes) (Also RFC0792) (Status: PROPOSED STANDARD)


next up previous contents index
Next: VI Protocole UDP Up: A Introduction à la Previous: IV Anatomie d'une adresse   Contents   Index
Fran├žois Laissus 2009-02-27