Groupe de travail Réseau	S. Deering, éditeur	
Request for Comments : 1256	Xerox PARC	
Traduction Claude Brière de L’Isle	septembre 1991	

Messages ICMP de découverte de routeur

Statut de ce mémoire
La présente RFC spécifie un protocole en cours de normalisation de l’IAB pour la commubnauté de l’Internet, et appelle à des discussions et suggestions pour son améloration. Prière de se référer à l’édition en cours des "Normes officielles de protocole de l’IAB" pour connaître l’état de normalisation et le statut de ce protocole. Le présent document a été produit par le groupe de travail Découverte de routeur de l’IETF. La distribution du présent mémoire n’est soumise à aucune restriction.

Résumé
Le présent document spécifie une extension au protocole de message de contrôle de l’Internet (ICMP, Internet Control Message Protocol) pour permettre aux hôtes rattachés à des réseaux de diffusion ou de diffusion groupée de découvrir les adresses IP des routeurs de leur voisinage.

Table des Matières
1.	Terminologie
2.	Vue d’ensemble du protocole
3.	Formats de message
4.	Spécification du routeur
4.1	Variables de configuration de routeur
4.2	Validation de message par les routeurs
4.3	Comportement de routeur
5.	Spécification de l’hôte
5.1	Variables de configuration d’hôte
5.2	Validation du message par les hôtes
5.3	Comportement de l’hôte
6.	Constantes du protocole
7.	Considérations pour la sécurité

1.	Terminologie

Les termes suivants ont une signification précise dans le présent document :

Système	appareil qui met en œuvre le protocole Internet, IP [RFC0791].

Routeur	système qui transmet les datagrammes IP, comme spécifié dans la [RFC1009]. Cela n’inclut pas les systèmes qui, bien que capables de transmission sur IP, ont cette capacité désactivée. Pas plus que cela n’inclut les systèmes qui ne font la transmission IP qu’autant que nécessaire pour obéïr aux options Route de source IP.

Hôte	tout système qui n’est pas un routeur.

Diffusion groupée	sauf qualification contraire, signifie le service de diffusion groupée IP [RFC1112] ou la diffusion IP [RFC0919].

Liaison	facilité ou support de communication sur lequel les systèmes peuvent communiquer à la couche liaison, c’est-à-dire, à la couche de protocole immédiatement en-dessous de IP. Le terme de "réseau physique " (bien qu’imprécis) a parfois été utilisé pour cela. Des exemples de liaison sont ceux des LAN (éventuellement pontés avec d’autres LAN), des réseaux de large zone à transmission différée, des canaux par satellite, et des liaisons en point à point.

Liaison de diffusion groupée	Liaison sur laquelle le service de diffusion groupée IP ou de diffusion IP est pris en charge. Cela inclut des supports de diffusion comme des LAN et des canaux par satellite, des liaisons seules en point à point, et certains réseau à transmission différée tels que les réseaux SMDS [RFC1209].

Interface	point de rattachement d’un système à une liaison. Il est possible (bien que peu courant) qu’un système ait plus d’une interface pour la même liaison. Les interfaces sont identifiées de façon univoque par leur adresse IP d’envoi individuel ; une même interface peut avoir plus d’une de ces adresses.

Interface de diffusion groupée	interface à une liaison de diffusion groupée, c’est-à-dire, une interface avec une liaison sur laquelle le service de diffusion groupée IP ou de diffusion IP est pris en charge.

Sous-réseau	soit un seul sous-réseau d’un réseau IP organisé en sous-réseaux [RFC0950] soit un seul réseau IP non organisé en sous-réseaux, c’est-à-dire, l’entité identifiée par une adresse IP logiquement associée à son gabarit de sous-réseau alloué. Plus d’un sous-réseau peut exister sur la même liaison.

Voisinage	avoir une adresse IP qui appartient au même sous-réseau.

2.	Vue d’ensemble du protocole

Avant qu’un hôte puisse envoyer des datagrammes IP au delà des sous-réseaux qui lui sont directement rattachés, il doit découvrir l’adresse d’au moins un routeur opérationnel sur ce sous-réseau. Normalement, cela se fait en lisant une liste d’une ou plusieurs adresses de routeur à partir d’un fichier de configuration (éventuellement distant au moment du démarrage. Sur les liaisons en diffusion groupée, certains hôtes découvrent aussi les adresses de routeur en écoutant le trafic de protocole d’acheminement. Ces deux méthodes ont toutes deux de sérieux inconvénients : les fichiers de configuration doivent être entretenus manuellement – ce qui représente une charge administrative significative – et ils ne sont pas capables de retracer les changements dynamiques de disponibilité des routeurs ; l’espionnage sur le trafic d’acheminement exige que les hôtes reconnaissent les protocoles d’acheminement particuliers utilisés, qui varient de sous-réseau à sous-réseau et qui sont succeptibles de changer à tout moment. Le présent document spécifie une autre méthode de découverte de routeur qui utilise une paire de messages ICMP [RFC0792], à utiliser sur les liaisons de diffusion groupée.  Elle élimine le besoin de configuration manuelle des adresses de routeur et est indépendante de tout protocole d’acheminement spécifique.

Les messages ICMP de découverte de routeur sont appélés "Annonce de routeur " et "Sollicitation de routeur". Chaque routeur fait périodiquement une diffusion groupée d’annonce de routeur à partir de chacune de ses interfaces de diffusion groupée, annonçant la ou les adresses IP de cette interface. Les hôtes découvrent les adresses des routeurs de leur voisinage en écoutant simplement les annonces. Lorsque démarre un hôte rattaché à une liaison de diffusion groupée, il peut faire une diffusion groupée de sollicitation de routeur pour demander des annonces immédiates, plutôt que d’attendre l’arrivée de la prochaine annonce périodique ; si (et seulement si) aucune annonce ne se présente, l’hôte peut retransmettre la sollicitation un petit nombre de fois, mais doit ensuite cesser d’envoyer d’autres sollicitations. Tous les routeurs qui démarrent ultérieurement, ou qui n’ont pas été découverts à cause de la perte d’un paquet ou d’une partition temporaire de la liaison, sont finalement découverts par la réception de leurs annonces périodiques (non sollicitées). (Les liaisons qui subissent de forts taux de perte de paquet ou des partitions fréquentes sont traitées en augmentant le rythme des annonces, plutôt qu’en augmentant le nombre de sollicitations qu’il est permis aux hôtes d’envoyer.)

Les messages de découverte de routeur ne constituent pas un protocole d’acheminement : ils permettent aux hôtes de découvrir l’existence des routeurs du voisinage, mais pas quel routeur est le meilleur pour atteindre une destination particulière. Si un hôte choisit un mauvais routeur de premier bond pour une destination particulière, il devrait recevoir une redirection ICMP de la part de ce routeur, qui en identifie un meilleur.

Une annonce de routeur comporte un "niveau de préférence" pour chaque adresse de routeur annoncée. Lorsque un hôte doit choisir une adresse de routeur par défaut (c’est-à-dire, lorsque, pour une destination particulière, l’hôte n’a pas été redirigé ou configuré pour utiliser une adresse de routeur spécifique) il est supposé choisir à partir des adresses de routeur qui ont le plus fort niveau de préférence (voir au paragraphe 3.3.1 de la [RFC1122]). Un administrateur de réseau peut configurer les niveaux de préférence d’adresse de routeur pour encourager ou décourager l’usage de certains routeurs comme routeurs par défaut.

Une annonce de routeur comporte aussi un champ "Durée de vie", qui spécifie la durée maximum pendant laquelle les adresses annoncées seront considérées comme des adresses de routeur valides par les hôtes, en l’absence d’autres annonces. Ceci est utilisé pour s’assurer que les hôtes ne finissent pas par oublier les routeurs défaillants, qui deviennent indisponibles, ou arrêtent d’agir comme routeurs.

Le taux d’annonces par défaut est d’une fois toutes les 7 à 10 minutes, et la durée de vie par défaut est de 30 minutes. Cela signifie qu’en utilisant les valeurs par défaut, les annonces ne sont pas un mécanisme suffisant pour la détection des "trous noirs", c’est-à-dire, la détection de défaillance du premier bond sur un chemin actif – dans l’idéal, les trous noirs devraient être détectés suffisamment rapidement pour passer sur un autre routeur avant l’arrivée à expiration de toute connexion de transport ou session de couche supérieure. On suppose que les hôtes ont déjà des mécanismes pour détecter les trous noirs, comme l’exige la [RFC1122]. Les hôtes ne peuvent pas dépendre des annonces de routeur pour cela, car elles peuvent être indisponibles ou désactivées administrativement sur une liaison particulière ou à partir d’un routeur particulier. Donc, le taux d’annonce et les valeurs de durée de vie par défaut ont été choisies simplement pour rendre négligeable la charge imposée aux liaisons et aux hôtes par les annonces périodiques en diffusion groupée, même lorsque beaucoup de routeurs sont présents. Cependant, un administrateur de réseau qui souhaite employer les annonces comme mécanisme supplémentaire de détection de trous noirs a toute liberté pour configurer de plus petites valeurs.

3.	Formats de message

Message ICMP d’annonce de routeur

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |      Somme de contrôle        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Numéro adresse|Taille d’entrée|     Durée de vie              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Adresse[1] de routeur                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Niveau de préférence[1]                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Adresse[2] de routeur                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Niveau de préférence[2]                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               .                               |
|                               .                               |
|                               .                               |

Champs IP:
Adresse de source :	Adresse IP qui appartient à l’interface d’où ce message est envoyé.
Adresse de destination:	Adresse de l’annonce configurée ou adresse IP d’un hôte du voisinage.
Durée de vie :	1 si l’adresse de destination est une adresse IP de diffusion groupée ; au moins 1 autrement.

Champs ICMP :
Type  : 	9
Code : 	0
Somme de contrôle : Complément à un sur 16 bits de la somme des compléments à un du message ICMP, débutant par le type ICMP. Pour le calcul de la somme de contrôle, le champ Somme de contrôle est mis à 0.
Numéro adresse :	Numéro des adresses de routeur annoncées dans ce message.
Taille d’entrée :	Nombre de mots de 32 bits d’information pour chaque adresse de routeur (2, dans la version du protocole décrite ici).
Durée de vie : 	Nombre maximum de secondes pendant lequel les adresses du routeur peuvent être considérées valides.
Adresse[i] de routeur (i = 1…Numéro adresse) :
Adresse IP du routeur d'envoi sur l’interface d’où ce message est envoyé.
Niveau de préférence [i] (i = 1…Numéro adresse) : 
La préférence de chaque adresse [i] de routeur comme adresse de routeur par défaut, par rapport aux autres adresses de routeur sur le même sous-réseau. Une valeur signée de complément à deux ; les valeurs croissantes signifient une préférence croissante.

Message ICMP de sollicitation  de routeur

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |     Somme de contrôle         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Réservé                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champs IP :
Adresse de source :	Adresse IP qui appartient à l’interface d’où ce message est envoyé, ou 0.
Adresse de destination :	Adresse de sollicitation configurée.
Durée de vie :	1 si l’adresse de destination est une adresse IP de diffusion groupée ; au moins 1 autrement.

Champs ICMP :
Type : 	10
Code : 	0
Somme de contrôle :	Complément à un sur 16 bits de la somme des compléments à un du message ICMP, débutant par le type ICMP. Pour le calcul de la somme de contrôle, le champ Somme de contrôle est mis à 0.
Réservé :	Envoyé à 0 ; ignoré à réception.

4.	Spécification du routeur
4.1	Variables de configuration de routeur

Un routeur qui met en œuvre les messages ICMP de découverte de routeur doit accepter que les variables suivantes soient configurées par la gestion de système ; les valeurs par défaut sont spécifiées de façon à rendre inutile de configurer une de ces variables dans de nombreux cas.

Pour chaque interface de diffusion groupée:

AdvertisementAddress (adresse d’annonce)
C’est l’adresse IP de destination à utiliser pour les annonces de routeur de diffusion groupée envoyées de l’interface. Les seules valeurs permises sont l’adresse de diffusion groupée Tous systèmes, 224.0.0.1, ou l’adresse de diffusion limitée, 255.255.255.255. (L’adresse Tous systèmes est préférée chaque fois que possible, c’est-à-dire, sur toute liaison où tous les hôtes qui écoutent prennent en charge la diffusion groupée IP.)
Défaut : 224.0.0.1 si le routeur prend en charge la diffusion groupée IP sur l’interface, autrement 255.255.255.255

MaxAdvertisementInterval (intervalle maximum d’annonces)
Durée maximum permise entre l’envoi d’annonces de routeur de diffusion groupée de l’interface, en secondes. Ne doit pas être inférieure à 4 secondes et pas supérieure à 1800 secondes.
Défaut : 600 secondes

MinAdvertisementInterval (intervalle minimum d’annonces)
Durée minimum admis entre l’envoi d’annonces non sollicitées de routeur de diffusion groupée de l’interface, en secondes. Ne doit pas être inférieure à 3 secondes et pas supérieure à MaxAdvertisementInterval.
Défaut : 0,75 * MaxAdvertisementInterval

AdvertisementLifetime (durée de vie d’annonce)
C’est la valeur à placer dans le champ Durée de vie des annonces de routeur envoyées de l’interface, en secondes. Ne doit pas être inférieure à MaxAdvertisementInterval et pas supérieure à 9000 secondes.
Défaut : 3 * MaxAdvertisementInterval

Pour chacune des adresses IP du routeur sur ses interfaces de diffusion groupée :

Advertise (annoncer)
Fanion qui indique si l’adresse est ou non à annoncer.
Défaut : VRAI

PreferenceLevel (niveau de préférence)
Niveau de préférence de l’adresse en tant qu’adresse de routeur par défaut, par rapport aux autres adresses de routeur sur le même sous-réseau. Entier de 32 bits, signé, en complément à deux, les valeurs plus fortes signifiant une préférence plus forte. La valeur minimum (hex 80000000) est utilisée pour indique que l’adresse, bien qu’elle soit annoncée, n’est pas à utiliser par les hôtes du voisinage comme adresse de routeur par défaut.
Défaut : 0

Le cas dans lequel il est utile de configurer une adresse avec un niveau de préférence de hex 80000000 (plutôt que de simplement régler son fanion Advertise à FAUX) est celui d’annonces qui sont utilisées pour la détection de "trous noirs", comme mentionné à la Section 2. En particulier, un routeur qui n’est à utiliser que pour atteindre des destinations IP spécifiques pourrait annoncer son adresse avec un niveau de préférence de hex 80000000 (de sorte que les hôtes du voisinage ne vont pas l’utiliser comme routeur par défaut pour atteindre des destinations IP arbitraires) et une durée de vie différente de zéro (de sorte que les hôtes du voisinage qui ont été redirigés ou configurés pour l’utiliser puissent détecter sa défaillance en périmant la réception de ses annonces).

Il a été suggéré que, lorsque le niveau de préférence d’une adresse n’a pas été explicitement configuré, un routeur pourrait le régler selon la métrique du "chemin par défaut" du routeur (si il en a une), plutôt que de revenir par défaut à zéro comme suggéré ci-dessus. Donc, un routeur avec une meilleure métrique pour son chemin par défaut annoncerait un niveau de préférence plus élevé pour son adresse. (Noter que les métriques d’acheminement qui sont codées de telle sorte que "le plus faible soit le meilleur" devrait être inversées pour pouvoir être utilisées comme niveaux de préférence dans les messages d’annonce de routeur.) Une telle stratégie pourrait réduire la quantité de trafic ICMP de redirection sur certaines liaisons en rendant plus vraisemblable que le routeur de premier choix d’un hôte pour atteindre une destination arbitraire soit aussi le meilleur choix. Par ailleurs, le trafic de Redirection est rarement une charge significative pour une liaison, et il y a des cas où une telle stratégie pourrait résulter en plus de trafic de Redirection, et pas moins (par exemple, sur des liaisons où les destinations les plus fréquemment choisies sont le mieux atteintes via des routeurs autres que celui qui a le meilleur chemin par défaut). Le présent document ne fait pas de recommandation concernant ce problème, et les mises en œuvre ont toute liberté pour essayer une telle stratégie, pour autant qu’elles prennent aussi en charge la configuration statique des niveaux de préférence spécifiés ci-dessus.

4.2	Validation de message par les routeurs

Un routeur doit éliminer en silence tout message de sollicitation de routeur reçu qui ne satisfait pas aux vérifications de validité suivantes :

-	L’adresse IP de source est 0 ou l’adresse d’un voisin (c’est-à-dire, une adresse qui correspond à une des propres adresses du routeur sur l’interface d’arrivée, sous le gabarit de sous-réseau associé à cette adresse.)

-	La somme de contrôle ICMP est valide.

-	Le code ICMP est 0.

-	La longueur ICMP (déduite de la longueur IP) est d’au moins 8 octets.

Le contenu du champ ICMP Réservé, et tous les octets au-delà des huit premiers, sont ignorés. De futurs changements rétro compatibles du protocole pourront spécifier le contenu du champ Réservé ou d’octets supplémentaires à la fin du message ; les changements non rétro compatibles peuvent utiliser des valeurs de code différentes.

Une sollicitation qui réussit les contrôles de validité est appelée une "sollicitation valide".

Un routeur peut éliminer en silence tout message d’annonce de routeur reçu. Toute autre action à réception de tels messages par un routeur (par exemple, au titre d’un processus de "découverte d’homologues") sort du domaine d’application du présent document.

4.3	Comportement de routeur 

Le routeur se joint au groupe de diffusion groupée IP Tous routeurs (224.0.0.2) sur toutes les interfaces sur lesquelles il prend en charge la diffusion groupée IP.

Le terme "interface d’annonce" se réfère à toute interface de diffusion groupée qui fonctionne et est activée qui a au moins une adresse IP dont les fanions configurés Annoncer sont à VRAI. À partir de chaque interface d’annonce, le routeur transmet des annonces de routeur de diffusion groupée périodiques, qui contiennent les valeurs suivantes :

-	Dans le champ Adresse de destination de l’en-tête IP : le AdvertisementAddress configuré de l’interface.

-	Dans le champ Durée de vie : le AdvertisementLifetime configuré de l’interface.

-	Dans les champs Adresse[i] de routeur et niveau[i] de préférence : toutes les adresses de l’interface dont les fanions Advertise sont à VRAI, ainsi que leurs valeurs correspondantes de PreferenceLevel. (Dans le cas improbable où toutes les adresses ne tiendraient pas dans une seule annonce, compte tenu de la contrainte de la MTU de la liaison, plusieurs annonces sont envoyées, chacune sauf la dernière contenant autant d’adresses qu’il peut y tenir.)

Les annonces ne sont pas strictement périodiques : l’intervalle entre les transmissions successives est rendu aléatoire pour réduire la probabilité de synchronisation avec les annonces d’autres routeurs sur la même liaison. Cela se fait en maintenant un temporisateur d’intervalle de transmission pour chaque interface d’annonce. Chaque fois qu’une annonce en diffusion groupée est envoyée d’une interface, le temporisateur de cette interface est remis à une valeur aléatoire à distribution uniforme comprise entre les MinAdvertisementInterval et le MaxAdvertisementInterval configurés de l’interface ; l’arrivée à expiration du temporisateur cause l’envoi de la prochaine annonce à partir de l’interface, et une nouvelle valeur aléatoire est à choisir. (Il est recommandé que les routeurs incluent une valeur unique, comme une de leurs adresses IP ou de couche liaison, dans le germe utilisé pour initialiser leur générateur de nombres pseudo aléatoires. Bien que la gamme de nombres aléatoires soit configurée en unités de secondes, les valeur réelles choisies au hasard ne devraient pas être en unités de secondes entières, mais plutôt en unités de la plus petite résolution disponible pour le temporisateur.

Pour les quelques premières annonces envoyées d’une interface (jusqu’à MAX_INITIAL_ADVERTISEMENTS), si l’intervalle choisi au hasard est supérieur à MAX_INITIAL_ADVERT_INTERVAL, le temporisateur devrait être réglé à la place à MAX_INITIAL_ADVERT_INTERVAL. Utiliser ce plus petit intervalle pour les annonces initiales augmente la probabilité de découverte rapide d’un routeur lorsqu’il commence à devenir disponible, en présence de possibles pertes de paquets.

En plus des annonces périodiques non sollicitées, un routeur envoie des annonces en réponse à des sollicitations valides reçues sur une de ses interfaces d’annonce. Un routeur peut choisir d’envoyer la réponse en envoi individuel directement à l’adresse de l’hôte solliciteur (si elle n’est pas à zéro), ou de l’envoyer en diffusion groupée à l’adresse d’annonce configurée de l’interface ; dans ce cas, le temporisateur d’intervalle de l’interface est remis à un nouvelle valeur aléatoire, comme avec les annonces non sollicitées. Une réponse en envoi individuel peut être retardée, et une réponse en diffusion groupée doit être retardée, pour un petit intervalle aléatoire qui n’est pas supérieur à MAX_RESPONSE_DELAY, afin de prévenir la synchronisation avec les réponses des autres routeurs, et de permettre qu’il soit répondu à plusieurs sollicitations très rapprochées avec une seule annonce en diffusion groupée.

Si un routeur reçoit une sollicitation envoyée à une adresse IP de diffusion sur une interface dont l’adresse d’annonce configurée est une adresse IP de diffusion groupée, le routeur peut envoyer sa réponse à l’adresse de diffusion au lieu de l’adresse IP configurée de diffusion groupée. Un tel événement indique une incohérence de configuration qui devrait être enregistrée dans le journal du système en vue d’une possible action corrective de la part de l’administrateur du réseau.

On notera qu’une interface peut devenir une interface d’annonce à d’autres moments que le démarrage du système, par suite de la récupération d’une défaillance d’une interface ou par des actions de la gestion de système telles que:
-	activer l’interface, si elle avait eté désactivée administrativement et si elle a une ou plusieurs adresses dont le fanion Advertise est VRAI, ou
-	activer la capacité de transmisssion IP (c’est-à-dire, changer le système de l’état d’hôte en celui de routeur) lorsque l’interface a une ou plusieurs adresses dont le fanion Advertise est VRAI, ou
-	régler le fanion Advertise d’une ou plusieurs des adresses de l’interface à VRAI (ou ajouter une nouvelle adresse avec un fanion Advertise VRAI) lorsque précédemment l’interface n’avait pas d’adresse dont le fanion Advertise soit à VRAI.

Dans ces cas, le routeur doit commencer la transmission d’annonces périodiques sur la nouvelle interface d’annonce, limitant les quelques premières annonces à des intervallse non supérieurs à MAX_INITIAL_ADVERT_INTERVAL.
Dans le cas où un hôte devient un routeur, le système doit aussi se joindre au groupe IP de diffusion groupée Tous routeurs sur toutes les interfaces sur lesquelles le routeur prend en charge la diffusion groupée IP (qu’elles soient ou non des interfaces d’annonce).

Une interface peut aussi cesser d’être une interface d’annonce, par des actions de gestion de système telles que :
-	désactiver administrativement l’interface,
-	fermer le système, ou désactiver la capacité de transmission IP (c’est-à-dire, changer le système de routeur en hôte), ou
-	régler les fanions Advertise de toutes les adresses de l’interface à FAUX.

Dans de tels cas, il est recommandé (mais pas exigé) que le routeur transmette une annonce finale en diffusion groupée sur l’interface, identique à sa transmission précédente mais avec un champ Durée de vie de zéro. Dans le cas d’un routeur qui devient un hôte, le système doit aussi quitter le groupe de diffusion groupée IP Tous routeurs sur toutes les interfaces sur lesquelles le routeur prend en charge la diffusion groupée IP (qu’elles aient été ou non des interfaces d’annonce).

Lorsque le fanion Advertise d’une ou plusieurs adresse d’interface est réglée à FAUX par la gestion du système, mais qu’il reste d’autres adresses sur cette interface dont le fanion Advertise est à VRAI, il est recommandé que le routeur envoie une seule annonce en diffusion groupée contenant seulement les adresses dont le fanion Advertise était mis à FAUX, avec un champ Durée de vie à zéro.

5.	Spécification de l’hôte
5.1	Variables de configuration d’hôte

Un hôte qui met en œuvre les messages ICMP de découverte de routeur doit permettre que les variables suivantes soient configurées par la gestion du système ; les valeurs par défaut sont spécifiées de façon à rendre inutile de configurer ces variables dans de nombreux cas.

Pour chaque interface de diffusion groupée :

PerformRouteurDiscovery (effectuer la découverte de routeur)
C’est un fanion qui indique si l’hôte va effectuer une découverte ICMP de routeur sur l’interface.
Défaut : VRAI

SolicitationAddress (adresse de sollicitation)
Adresse IP de destination à utiliser pour l’envoi de sollicitations de routeur à partir de l’interface. Les seules valeurs permises sont l’adresse de diffusion groupée Tous routeurs, 224.0.0.2, ou l’adresse de diffusion limitée, 255.255.255.255. (L’adresse Tous routeurs est préférée chaque fois que possible, c’est-à-dire, sur toute liaison où tous les routeurs annonceurs acceptent la diffusion groupée IP.)
Défaut : 224.0.0.2 si l’hôte prend en charge la diffusion groupée IP sur l’interface, autrement 255.255.255.255

Le paragraphe 3.3.1.6 de la [RFC1122] "Exigences pour les hôtes – Couches de communication", spécifie que chaque mise en œuvre d’hôte doit prendre en charge une liste configurable d’adresses de routeurs par défaut. L’objet des messages ICMP de découverte de routeur est d’éliminer le besoin de configurer cette liste dans les hôtes rattachés aux liaisons de diffusion groupée. Sur les liaisons non en diffusion groupée, et sur les liaisons en diffusion groupée pour lesquelles la découverrte de routeur ICMP n’est pas (pas encore) prise en charge par les routeurs ou est désactivée administrativement, il va continuer d’être nécessaire de configurer la liste des routeurs par défaut dans chaque hôte. Chaque entrée dans la liste contient (au moins) les variables configurables suivantes :

RouteurAddress (adresse du routeur)
Adresse IP d’un routeur par défaut.
Défaut : (aucune)

PreferenceLevel (niveau de préférence)
Le niveau de préférence de l’adresse de routeur comme adresse de routeur par défaut, par rapport aux autres adresses de routeur sur le même sous-réseau. La RFC sur les exigences pour les hôtes ne spécifie pas comment cette valeur doit être codée ; pour permettre que le niveau de préférence soit convoyé dans une annonce de routeur ou configuré par la gestion du système, il est spécifié ici qu’il est codé comme un entier signé de 32 bits en complément à deux, les valeurs de préférence étant croissantes. La valeur minimum (hex 80000000) est réservée pour signifier que l’adresse n’est pas à utiliser comme adresse de routeur par défaut, c’est-à-dire qu’elle n’est à utiliser que pour des destinations IP spécifiques, dont l’hôte a été informé par des redirections ICMP ou par configuration.
Défaut : 0

5.2	Validation du message par les hôtes

Un hôte doit éliminer en silence tout message d’annonce de routeur reçu qui ne satisfait pas aux vérifications de validité suivantes :
-	La somme de contrôle ICMP est valide.
-	Le code ICMP est 0.
-	Le numéro d’adresse ICMP est supérieur ou égal à 1.
-	La taille d’entrée d’adresse ICMP est supérieure ou égale à 2.
-	La longueur ICMP (déduite de la longueur IP) est supérieure ou égale à 8 + (Numéro d’adresse * Taille d’entrée d’adresse * 4) octets.

Le contenu de tout mot additionnel d’information d’adresse (c’est-à-dire, autre que les champs Adresse de routeur et Niveau de préférence) et le contenu de tous octets au-delà des 8 + (Numéro d’adresse * Taille d’entrée d’adresse * 4) premiers octets, est ignoré. De futurs changements rétro compatibles au protocole pourront spécifier des mots d’information d’adresse supplémentaires, ou des octets additionnels à la fin du message ; les changements non rétro compatibles peuvent utiliser des valeurs de code différentes.

Une annonce qui réussit les vérifications de validité est appelée une "annonce valide".

Un hôte doit éliminer en silence tout message de sollicitation de routeur reçu.

5.3	Comportement de l’hôte

Sur toute interface sur laquelle l’hôte accepte la diffusion groupée IP, il sera un membre du groupe de diffusion groupée IP Tous systèmes (224.0.0.1). Cela se fait automatiquement, comme spécifié dans la [RFC1112] ; aucune action explicite n’est requise de la part de la mise en œuvre de protocole de découverte de routeur.

Un hôte n’envoie jamais de message d’annonce de routeur.

Un hôte élimine en silence tout message d’annonce de routeur qui arrive sur une interface pour laquelle le fanion configuré PerformRouteurDiscovery de l’hôte est FAUX, et il n’envoie jamais de sollicitation de routeur sur une telle interface.

Un hôte ne peut pas traiter une annonce tant qu’il n’a pas déterminé sa ou ses propres adresses IP et le ou les gabarits de sous-réseau pour l’interface sur laquelle est reçue l’annonce. (Sur certaines liaisons, un hôte peut être capable d’utiliser une combinaison de BOOTP [RFC0951], RARP [RFC0903], ou de messages ICMP Gabarit d’adresse [RFC0950] pour découvrir ses propres adresse et gabarit.)  En attendant d’apprendre l’adresse et le gabari d’une interface, un hôte peut sauvegarder toutes les annonces valides reçues sur cette interface pour les traiter ultérieurement ; cela permet que la découverte de routeur et la découverte d’adresse/gabarit soient traitées en parallèle.

Pour traiter une annonce, un hôte examine la liste d’adresses de routeurs qu’elle contient. Il ignore toutes les adresses qui ne sont pas du voisinage, c’est-à-dire, les adresses qui ne correspondent pas à une des propres adresses de l’hôte sur l’interface d’arrivée, sous le gabarit de sous-réseau associé à cette adresse. Pour chaque adresse du voisinage, l’hôte fait ce qui suit :
-	Si l’adresse n’est pas déjà présente dans la liste des routeurs par défaut de l’hôte, une nouvelle entrée est ajoutée à la liste, contenant l’adresse ainsi que le niveau de préférence qui l’accompagne et une temporisation initialisée à la valeur de durée de vie de l’annonce.
-	Si l’adresse est déjà présente dans la liste des routeurs par défaut de l’hôte par suite d’une annonce précédemment reçue, son niveau de préférence est mis à jour et son temporisateur est remis aux valeurs reçues dans la nouvelle annonce.
-	Si l’adresse est déjà présente dans la liste des routeurs par défaut de l’hôte par suite de la configuration par le système, aucun changement n’est fait à son niveau de préférence; il n’y a pas de temporisateur associé à une adresse configurée. (Noter que toute adresse de routeur acquise du sous-champ "Gateway" du champ Extensions de fabricant d’un paquet BOOTP [RFC1084] est considérée comme une adresse configurée ; elles ont allouées le niveau de préférence de zéro par défaut, et elles n’ont pas de temporisateur associé. Noter de plus que toute adresse trouvée dans le champ "giaddr" d’un paquet BOOTP [RFC0951] identifie un transmetteur BOOTP qui n’est pas nécessairement un routeur IP ; une telle adresse ne devrait pas être installée dans la liste de routeurs par défaut de l’hôte.)

Chaque fois que le temporisateur arrive à expiration dans toute entrée créée par suite de la réception d’une annonce, cette entrée est éliminée.

Pour limiter la quantité de mémoire nécessaire pour la liste des routeurs par défaut, un hôte peut choisir de ne pas mémoriser du tout les adresses de routeur découvertes via les annonces. S’il en est ainsi, l’hôte devrait éliminer les adresses qui ont de plus faibles niveaux de préférence en faveur de celles qui ont les niveaux les plus élevés. Il est souhaitable de conserver plus d’une adresse de routeur par défaut dans la liste, afin que si le choix actuel de routeur par défaut se trouve réduit à néant, l’hôte puisse immédiatement choisir un autre routeur par défaut, sans avoir à attendre qu’arrive la prochaine annonce.

Une adresse de routeur annoncée avec le niveau de préférence de hex 80000000 n’est pas à utiliser par l’hôte comme adresse de routeur par défaut ; une telle adresse peut être omise de la liste des routeurs par défaut, sauf si son temporisateur est utilisé comme mécanisme de détection de "trou noir", comme exposé au paragraphe 4.1.

On doit comprendre que les niveaux de préférence appris des annonces n’affectent aucune des entrées d’acheminement en antémémoire de l’hôte. Par exemple, si l’hôte a été redirigé pour utiliser une adresse particulière de routeur pour atteindre une destination IP spécifique, il continue d’utiliser cette adresse de routeur pour cette destination, même si il découvre une autre adresse de routeur avec un niveau de préférence plus élevé. Les niveaux de préférence n’influencent le choix du routeur que pour une destination IP pour laquelle il n’y a pas de chemin configuré ou en antémémoire, ou dont le chemin en antémémoire pointe sur un routeur qui se révèle ultérieurement être mort ou injoignable.

Un hôte peut (mais n’est pas obligé) de transmettre jusqu’à MAX_SOLICITATIONS messages de sollicitation de routeur à partir d’une de ses interfaces de diffusion groupée après un des événements suivants :
-	L’interface est initialisée au moment du démarrage du système.
-	L’interface est réinitialisée après une défaillance temporaire d’interface ou après avoir été temporairement désactivée par la gestion du système.
-	Le système passe du statut de routeur à celui d’hôte, en ayant la capacité de transmission IP désactivée par la gestion du système.
-	Le fanion PerformRouteurDiscovery pour l’interface est changé de FAUX à VRAI par la gestion du système.

L’adresse IP de destination des sollicitations est la SolicitationAddress configurée pour l’interface. L’adresse IP de source peut contenir zéro si l’hôte n’a pas encore déterminé une adresse pour l’interface ; autrement, elle contient une des adresses de l’interface.

Si un hôte ne choisit pas d’envoyer une sollicitation après un des événements ci-dessus, il devrait retarder cette transmission d’une durée aléatoire entre 0 et MAX_SOLICITATION_DELAY. Cela sert à alléger l’encombrement lorsque de nombreux hôtes démarrent sur une liaison au même moment, comme cela peut arriver après une récupération suite à une coupure d’alimentation. (Il est recommandé que les hôtes incluent une valeur unique, comme celle de leurs adresses IP ou de couche liaison, dans le germe utilisé pour initialiser leur générateur de nombres pseudo aléatoires. Bien que la gamme d’aléation soit spécifiée en unités de secondes, la valeur réelle choisie au hasard ne devrait pas être en unités de secondes entières, mais plutôt en unités de la plus forte résolution disponible du temporisateur.)

Un hôte peut aussi choisir de retarder encore plus ses sollicitations, par suite d’un des événements si-dessus, jusqu’à la première fois qu’il a besoin d’utiliser un routeur par défaut.

À réception d’une annonce valide contenant au moins une adresse de voisinage dont le niveau de préférence est autre que hex 80000000, suite à un des événements ci-dessus, l’hôte doit renoncer à l’envoi de sollicitations sur cette interface (même si aucune n’a encore été envoyée) jusqu’à la prochaine fois que survient un des événéments ci-dessus. Un petit nombre de retransmissions d’une sollicitation, qui sont permises si aucune de ces annonces n’est reçue, devrait être envoyé à l’intervalle de SOLICITATION_INTERVAL secondes, sans délai aléatoire.

6.	Constantes du protocole

Constantes de routeur :

MAX_INITIAL_ADVERT_INTERVAL	16 secondes	
MAX_INITIAL_ADVERTISEMENTS	3 transmissions	
MAX_RESPONSE_DELAY	2 secondes	

Constantes d’hôte :

MAX_SOLICITATION_DELAY	1 seconde	
SOLICITATION_INTERVAL 	3 secondes	
MAX_SOLICITATIONS	3 transmissions	

Les constantes de protocole supplémentaires sont définies avec les formats de message de la Section 3, et avec les variables de configuration de routeur et d’hôte des paragraphes 4.1 et 5.1.

Toutes les constantes du protocole sont susceptibles de changement dans les futures révisions du protocole.

7.	Considérations pour la sécurité

Cette extension de ICMP rend possible à tout système rattaché à une liaison de se faire passer pour un routeur par défaut auprès des hôtes rattachés à cette liaison. Tout trafic envoyé à un tel imposteur est vulnérable à l’espionnage, au déni de service de transmission, et à la modification par insertion, suppression, ou altération de paquets. On devrait noter que, sur la plupart des liaisons de diffusion groupée ou de diffusion sur lesquelles ce protocole est supposé fonctionner, l’espionnage est déjà possible par tout système rattaché à la liaison, et le protocole de résolution d’adresse (ARP, Address Resolution Protocol) utilisé sur ces liaisons offre une opportunité similaire de déni de service et de modification de flux de messages. Pour les environnements où ces menaces sont jugées inacceptables, il y a des variables de configuration pour désactiver la découverte dynamique du routeur par les hôtes.

Le format de message d’annonce de routeur est défini de telle sorte qu’il soit permis d’ajouter des informations supplémentaires au message d’une façon rétro compatible. Une utlisation possible de cette capacité est d’ajouter aux annonces des signatures numériques ou autres formes d’informations d’authentification, pour permettre aux hôtes de vérifier leur authenticité. Ceci fera l’objet d’études complémentaires.

Références
[RFC1122]	R. Braden, "Exigences pour les hôtes Internet – couches de communication", STD 3, octobre 1989.
[RFC1009]	R. Braden et J. Postel, "Exigences pour les routeurs de l'Internet", juin 1987. (Obsolète, voir RFC 1812)
[RFC0951]	B. Croft et J. Gilmore, "Protocole BOOTSTRAP (BOOTP)", septembre 1985.
[RFC1112]	S. Deering, "Extensions d'hôte pour diffusion groupée sur IP", STD 5, août 1989.
[RFC0903]	R. Finlayson, T. Mann, J. Mogul et M. Theimer, "Protocole de résolution inverse d'adresse", STD 38, juin 1984.
[RFC0919]	J. Mogul, "Diffusion des datagrammes Internet", octobre 1984.
[RFC0950]	J. Mogul et J. Postel, "Procédure standard de sous-réseautage Internet", (STD 5) août 1985.
[RFC1209]	D. Piscitello et J. Lawrence, "Transmission de datagrammes IP sur le service SMDS", STD 52, mars 1991.
[RFC0791]	J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet", STD 5, septembre 1981.
[RFC0792]	J. Postel, "Protocole du message de contrôle Internet – Spécification du protocole du programme Internet DARPA", STD 5, septembre 1981.
[RFC1084]	J. Reynolds, "Extensions Information de fabricant BOOTP", décembre 1988.

Adresse de l’éditeur

Stephen E. Deering
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA  94304
Téléphone : (415) 494-4839
Mél : deering@xerox.com

Ou envoyer les commentaires à gw-discovery@gregorio.stanford.edu.