Aller au contenu principal

6. Découverte de routeur et de préfixe (Router and Prefix Discovery)

Cette section décrit la découverte de routeur et de préfixe. La découverte de routeur est le processus par lequel les hôtes localisent les routeurs qui résident sur une liaison attachée. La découverte de préfixe est le processus par lequel les hôtes découvrent l'ensemble des préfixes d'adresse qui définissent quelles destinations sont on-link pour une liaison attachée.

Les hôtes utilisent les préfixes on-link annoncés pour construire et maintenir une liste qui est utilisée pour décider quand la destination d'un paquet est on-link ou au-delà d'un routeur. Par défaut, les hôtes apprennent tous les préfixes on-link à partir des Router Advertisements. Cependant, les routeurs peuvent être configurés pour omettre certains ou tous les préfixes des Router Advertisements. Dans de tels cas, les hôtes supposent que les destinations sont off-link et envoient le trafic aux routeurs. Un routeur peut alors émettre des redirections selon les besoins.

6.1. Validation des messages (Message Validation)​

6.1.1. Validation des messages Router Solicitation​

Les hôtes DOIVENT (MUST) silencieusement rejeter tous les messages Router Solicitation reçus.

Un routeur DOIT (MUST) silencieusement rejeter tous les messages Router Solicitation reçus qui ne satisfont pas toutes les vérifications de validité suivantes :

  • L'adresse source IP est une adresse link-local. Les routeurs NE DOIVENT PAS (MUST NOT) envoyer de Router Advertisements aux adresses multicast (autres que l'adresse multicast all-nodes) si l'adresse source de la sollicitation est l'adresse non spécifiée. Cette restriction vise à empêcher les attaques par déni de service de nœuds malveillants.

  • Le champ IP Hop Limit a une valeur de 255, c'est-à-dire que le paquet n'aurait pas pu être transféré par un routeur.

  • Le checksum ICMP est valide.

  • Le code ICMP est 0.

  • La longueur ICMP (dérivée de la longueur IP) est de 8 octets ou plus.

  • Toutes les options incluses ont une longueur supérieure à zéro.

Si une Router Solicitation valide selon les vérifications ci-dessus est reçue sur une interface, et que l'interface est une interface publicitaire, le routeur peut répondre soit avec un Router Advertisement multicast, soit avec un Router Advertisement unicast destiné à l'adresse du nœud sollicitant, comme décrit ci-dessous. Le routeur devrait répondre avec un Router Advertisement unicast si la Router Solicitation a été envoyée depuis une adresse unicast, et avec un Router Advertisement multicast si la Router Solicitation a été envoyée depuis l'adresse non spécifiée.

6.1.2. Validation des messages Router Advertisement​

Un nœud DOIT (MUST) silencieusement rejeter tous les messages Router Advertisement reçus qui ne satisfont pas toutes les vérifications de validité suivantes :

  • L'adresse source IP est une adresse link-local. Les routeurs doivent utiliser leur adresse link-local comme source pour les messages Router Advertisement et Redirect afin que les hôtes puissent identifier de manière unique les routeurs.

  • Le champ IP Hop Limit a une valeur de 255, c'est-à-dire que le paquet n'aurait pas pu être transféré par un routeur.

  • Le checksum ICMP est valide.

  • Le code ICMP est 0.

  • La longueur ICMP (dérivée de la longueur IP) est de 16 octets ou plus.

  • Toutes les options incluses ont une longueur supérieure à zéro.

Le contenu du champ Reserved et de toutes les options non reconnues DOIT (MUST) être ignoré. Les modifications futures et rétrocompatibles du protocole peuvent spécifier le contenu du champ Reserved ou ajouter de nouvelles options ; les modifications non rétrocompatibles peuvent utiliser des valeurs de code différentes.

Le contenu de toutes les options définies qui ne sont pas spécifiées pour être utilisées avec les messages Router Advertisement DOIT (MUST) être ignoré et le paquet traité normalement. Les seules options définies qui peuvent apparaître sont les options Source Link-Layer Address, MTU et Prefix Information.

Un Router Advertisement qui passe les vérifications de validité est appelé un "Router Advertisement valide".

6.2. Spécification du routeur (Router Specification)​

6.2.1. Variables de configuration du routeur (Router Configuration Variables)​

Un routeur DOIT (MUST) permettre la configuration par la gestion système des variables conceptuelles suivantes pour chaque interface publicitaire :

MaxRtrAdvInterval - Le temps maximum autorisé entre l'envoi de Router Advertisements multicast non sollicités depuis l'interface, en secondes. DOIT (MUST) être au moins 4 secondes et au plus 1800 secondes.

Défaut : 600 secondes

MinRtrAdvInterval - Le temps minimum autorisé entre l'envoi de Router Advertisements multicast non sollicités depuis l'interface, en secondes. DOIT (MUST) être au moins 3 secondes et au plus 0.75 * MaxRtrAdvInterval.

Défaut : 0.33 * MaxRtrAdvInterval

AdvManagedFlag - La valeur à placer dans le drapeau "Managed address configuration" dans le Router Advertisement. Voir [ADDRCONF].

Défaut : FALSE

AdvOtherConfigFlag - La valeur à placer dans le drapeau "Other configuration" dans le Router Advertisement. Voir [ADDRCONF].

Défaut : FALSE

AdvLinkMTU - La valeur à placer dans les options MTU envoyées par le routeur. Une valeur de zéro indique qu'aucune option MTU n'est envoyée.

Défaut : 0

AdvReachableTime - La valeur à placer dans le champ Reachable Time dans les messages Router Advertisement envoyés par le routeur. La valeur zéro signifie non spécifié (par ce routeur). NE DOIT PAS (MUST) être supérieure à 3 600 000 millisecondes (1 heure).

Défaut : 0

AdvRetransTimer - La valeur à placer dans le champ Retrans Timer dans les messages Router Advertisement envoyés par le routeur. La valeur zéro signifie non spécifié (par ce routeur).

Défaut : 0

AdvCurHopLimit - La valeur à placer dans le champ Cur Hop Limit dans les messages Router Advertisement envoyés par le routeur. La valeur devrait être définie au diamètre actuel d'Internet. La valeur zéro signifie non spécifié (par ce routeur).

Défaut : La valeur spécifiée dans les "Assigned Numbers" [ASSIGNED] qui était en vigueur au moment de l'implémentation.

AdvDefaultLifetime - La valeur à placer dans le champ Router Lifetime des Router Advertisements envoyés depuis l'interface, en secondes. DOIT (MUST) être soit zéro, soit entre MaxRtrAdvInterval et 9000 secondes. Une valeur de zéro indique que le routeur ne doit pas être utilisé comme routeur par défaut. Ces limites peuvent être remplacées par des documents spécifiques qui décrivent comment IPv6 fonctionne sur différentes couches liaison. Par exemple, sur une liaison point-à-point, les pairs peuvent avoir suffisamment d'informations sur le nombre et l'état des dispositifs à l'autre extrémité pour que les annonces ne soient pas nécessaires.

Défaut : 3 * MaxRtrAdvInterval

AdvPrefixList - Une liste de préfixes à placer dans les options Prefix Information dans les messages Router Advertisement envoyés depuis l'interface.

Défaut : tous les préfixes que le routeur annonce via les protocoles de routage comme étant on-link pour l'interface à partir de laquelle l'annonce est envoyée.

Pour chaque préfixe annoncé dans les options Prefix Information, le routeur DOIT (MUST) également permettre les variables de configuration suivantes :

AdvValidLifetime - La valeur à placer dans la Valid Lifetime dans l'option Prefix Information, en secondes. La valeur désignée de tous les 1 (0xffffffff) représente l'infini.

Défaut : 2 592 000 secondes (30 jours), fixe (c'est-à-dire, reste identique dans les annonces consécutives).

AdvOnLinkFlag - La valeur à placer dans le champ du drapeau on-link ("L-bit") dans l'option Prefix Information.

Défaut : TRUE

AdvPreferredLifetime - La valeur à placer dans la Preferred Lifetime dans l'option Prefix Information, en secondes. La valeur désignée de tous les 1 (0xffffffff) représente l'infini.

Défaut : 604 800 secondes (7 jours), fixe (c'est-à-dire, reste identique dans les annonces consécutives).

AdvAutonomousFlag - La valeur à placer dans le champ Autonomous Flag dans l'option Prefix Information.

Défaut : TRUE

6.2.2. Devenir une interface publicitaire (Becoming An Advertising Interface)​

Le terme "interface publicitaire" fait référence à toute interface sur laquelle un routeur envoie des Router Advertisements périodiques. Un routeur DOIT (MUST) permettre à un administrateur système de faire d'une interface une interface publicitaire.

Une interface peut devenir une interface publicitaire à tout moment. Lorsque cela se produit, le routeur :

  • Initialise l'interface comme décrit dans [ADDRCONF].

  • Programme son premier Router Advertisement à envoyer depuis l'interface. Le temps de transmission est choisi de telle sorte que l'annonce soit envoyée à un moment uniformément distribué entre 0 et MAX_INITIAL_RTR_ADVERT_INTERVAL.

6.2.3. Contenu du message Router Advertisement (Router Advertisement Message Content)​

Un routeur envoie des Router Advertisements périodiques ainsi que sollicités depuis ses interfaces publicitaires. Les Router Advertisements sortants sont remplis avec les valeurs suivantes cohérentes avec le format de message donné dans la Section 4.2 :

  • Dans le champ Router Lifetime : le AdvDefaultLifetime configuré de l'interface.

  • Dans les drapeaux M et O : respectivement le AdvManagedFlag et AdvOtherConfigFlag configurés de l'interface.

  • Dans le champ Cur Hop Limit : le CurHopLimit configuré de l'interface.

  • Dans le champ Reachable Time : le AdvReachableTime configuré de l'interface.

  • Dans le champ Retrans Timer : le AdvRetransTimer configuré de l'interface.

  • Dans les options :

    • Option Source Link-Layer Address : adresse de couche liaison de l'interface. Cette option DEVRAIT (SHOULD) être incluse, mais PEUT (MAY) être omise sur les liaisons qui n'ont pas d'adresses.

    • Option MTU : la valeur AdvLinkMTU configurée de l'interface si la valeur est non nulle. Si AdvLinkMTU est zéro, l'option MTU n'est pas envoyée.

    • Options Prefix Information : une option Prefix Information pour chaque préfixe listé dans AdvPrefixList. Chaque option Prefix Information inclut les champs suivants :

      • Dans le drapeau "on-link" : AdvOnLinkFlag
      • Dans le champ Valid Lifetime : AdvValidLifetime
      • Dans le drapeau "autonomous address-configuration" : AdvAutonomousFlag
      • Dans le champ Preferred Lifetime : AdvPreferredLifetime
      • Dans le Prefix : le préfixe annoncé

Un routeur PEUT (MAY) inclure des options autres que celles spécifiées ci-dessus.

6.2.4. Envoi de Router Advertisements non sollicités (Sending Unsolicited Router Advertisements)​

Un routeur envoie des Router Advertisements non sollicités pour annoncer sa présence et pour annoncer divers paramètres de liaison et Internet. Pour chaque interface publicitaire, le routeur envoie des Router Advertisements multicast périodiques à l'adresse multicast all-nodes.

Le taux auquel les Router Advertisements sont envoyés est contrôlé par les variables de configuration du routeur : MaxRtrAdvInterval et MinRtrAdvInterval. Lorsqu'une interface devient une interface publicitaire, le routeur initialise un temporisateur sur l'interface qui expire après l'envoi de la première annonce. Le temporisateur est défini pour expirer à un moment uniformément distribué entre 0 et MAX_INITIAL_RTR_ADVERT_INTERVAL.

Après la première annonce, les Router Advertisements suivants sont envoyés lorsque le temporisateur expire. Le temporisateur est réinitialisé à une valeur uniformément distribuée entre MinRtrAdvInterval et MaxRtrAdvInterval chaque fois que le temporisateur expire.

6.2.5. Cesser d'être une interface publicitaire (Ceasing To Be An Advertising Interface)​

Une interface peut cesser d'être une interface publicitaire à tout moment. Par exemple, un routeur qui s'arrête ou une interface qui est désactivée peut cesser d'être une interface publicitaire. Dans de tels cas, le routeur DEVRAIT (SHOULD) transmettre un ou plusieurs (mais pas plus de MAX_FINAL_RTR_ADVERTISEMENTS) Router Advertisements multicast finaux sur l'interface avec un champ Router Lifetime de zéro. Dans le cas d'un routeur qui s'arrête, l'interface DEVRAIT (SHOULD) être déclarée cesser d'être une interface publicitaire puis les Router Advertisements finaux devraient être envoyés. Dans le cas où le routeur est conscient qu'une interface sera probablement indisponible pendant un certain temps (par exemple, en raison d'une perte d'alimentation imminente), le routeur PEUT (MAY) transmettre les Router Advertisements finaux à un taux plus rapide (c'est-à-dire, plus fréquemment qu'une fois par MinRtrAdvInterval).

6.2.6. Traitement des Router Solicitations (Processing Router Solicitations)​

Un hôte DOIT (MUST) silencieusement rejeter tous les messages Router Solicitation reçus.

En plus d'envoyer des annonces périodiques et non sollicitées, un routeur envoie des Router Advertisements en réponse aux Router Solicitations valides reçues sur une interface publicitaire. Un routeur PEUT (MAY) choisir d'unicaster la réponse directement à l'adresse de l'hôte sollicitant (si l'adresse source de la sollicitation n'est pas l'adresse non spécifiée), mais le cas habituel sera de multicaster la réponse au groupe all-nodes. Dans ce dernier cas, le temporisateur d'intervalle de l'interface est réinitialisé à une nouvelle valeur aléatoire, comme si une annonce non sollicitée avait été envoyée (voir Section 6.2.4).

Dans tous les cas, les Router Advertisements envoyés en réponse à une Router Solicitation DOIVENT (MUST) être retardés d'un temps aléatoire entre 0 et MAX_RA_DELAY_TIME secondes. (Si une seule annonce est envoyée en réponse à plusieurs sollicitations, le délai est relatif à la première sollicitation.) De plus, les Router Advertisements consécutifs envoyés à l'adresse multicast all-nodes DOIVENT (MUST) être limités en taux à pas plus d'une annonce toutes les MIN_DELAY_BETWEEN_RAS secondes.

Un routeur PEUT (MAY) choisir d'ignorer les Router Solicitations si la configuration du routeur indique que les Router Advertisements ne doivent pas être envoyés sur l'interface.

6.2.7. Cohérence des Router Advertisements (Router Advertisement Consistency)​

Pour minimiser la probabilité de mauvaise configuration, les routeurs DEVRAIENT (SHOULD) être cohérents dans les valeurs qu'ils annoncent. C'est-à-dire, les routeurs sur la même liaison DEVRAIENT (SHOULD) annoncer les mêmes valeurs pour AdvCurHopLimit, AdvManagedFlag, AdvOtherConfigFlag, AdvLinkMTU, AdvReachableTime et AdvRetransTimer. Une telle cohérence n'est cependant pas requise, et si les routeurs annoncent des valeurs différentes, le système devrait toujours fonctionner, bien que peut-être pas aussi bien qu'il le pourrait.

Si les routeurs sur une liaison annoncent des valeurs différentes pour AdvCurHopLimit, les hôtes utiliseront la valeur annoncée qu'ils ont apprise le plus récemment. Si AdvCurHopLimit change, certains hôtes peuvent utiliser une valeur, tandis que d'autres peuvent utiliser une valeur différente jusqu'à ce que tous les hôtes aient reçu un Router Advertisement qui annonce la nouvelle valeur.

Si les routeurs annoncent des valeurs différentes pour AdvReachableTime ou AdvRetransTimer, les hôtes calculeront leurs propres valeurs comme décrit dans la Section 6.3.2.

Si les routeurs annoncent des valeurs différentes pour AdvDefaultLifetime, les hôtes préféreront le routeur annonçant la valeur la plus grande.

6.3. Spécification de l'hôte (Host Specification)​

6.3.1. Variables de configuration de l'hôte (Host Configuration Variables)​

Un hôte DEVRAIT (SHOULD) permettre la configuration par la gestion système de la variable suivante pour chaque interface :

DupAddrDetectTransmits - Le nombre de messages Neighbor Solicitation consécutifs envoyés lors de la réalisation de la Duplicate Address Detection sur une adresse tentative. Une valeur de zéro indique que la Duplicate Address Detection n'est pas effectuée sur les adresses tentatives. Une valeur de un indique une transmission unique sans retransmissions de suivi.

Défaut : 1, mais peut être remplacé par une valeur spécifique au type de liaison dans le document qui couvre le fonctionnement d'IP sur un type de liaison particulier.

6.3.2. Variables d'hôte (Host Variables)​

Un hôte maintient les variables suivantes sur une base par interface :

RouterList - Une liste de routeurs par défaut, comme défini dans la Section 5.

PrefixList - Une liste de préfixes, comme défini dans la Section 5.

LinkMTU - La valeur MTU pour la liaison. Initialisée à partir de la valeur linkmtu que la couche liaison fournit.

CurHopLimit - La valeur par défaut qui devrait être placée dans le champ Hop Count de l'en-tête IP pour les paquets IP sortants. Initialisée à la valeur spécifiée par le document "IPv6 Assigned Numbers" [ASSIGNED].

BaseReachableTime - Une valeur de base utilisée pour calculer la valeur aléatoire ReachableTime. Initialisée à REACHABLE_TIME.

ReachableTime - Le temps pendant lequel un voisin est considéré accessible après réception d'une confirmation d'accessibilité. ReachableTime est utilisé par l'algorithme de détection d'inaccessibilité des voisins (voir Section 7.3). Il est appris des Router Advertisements ou est défini à une valeur par défaut. C'est une valeur aléatoire uniformément distribuée entre MIN_RANDOM_FACTOR et MAX_RANDOM_FACTOR fois BaseReachableTime. Une nouvelle valeur aléatoire devrait être calculée lorsque BaseReachableTime change (en raison de Router Advertisements) ou au moins toutes les quelques heures même si aucun Router Advertisement n'est reçu.

RetransTimer - Le temps entre les retransmissions de messages Neighbor Solicitation à un voisin lors de la résolution de l'adresse ou lors de la sonde de l'accessibilité d'un voisin. Également utilisé pendant la Duplicate Address Detection (voir [ADDRCONF]). RetransTimer est appris des Router Advertisements ou est défini à une valeur par défaut.

6.3.3. Initialisation de l'interface (Interface Initialization)​

L'hôte rejoint l'adresse multicast all-nodes sur toutes les interfaces capables de multicast.

6.3.4. Traitement des Router Advertisements reçus (Processing Received Router Advertisements)​

À la réception d'un Router Advertisement valide, un hôte extrait l'adresse source du paquet et fait ce qui suit :

  • Si l'adresse n'est pas déjà présente dans la liste de routeurs par défaut de l'hôte, et que la Router Lifetime de l'annonce est non nulle, créer une nouvelle entrée dans la liste et initialiser sa valeur de temporisateur d'invalidation à partir du champ Router Lifetime de l'annonce.

  • Si l'adresse est déjà présente dans la liste de routeurs par défaut de l'hôte en raison d'une annonce précédemment reçue, réinitialiser son temporisateur d'invalidation à la valeur Router Lifetime dans l'annonce nouvellement reçue.

  • Si l'adresse est déjà présente dans la liste de routeurs par défaut de l'hôte et que la valeur Router Lifetime reçue est zéro, faire immédiatement expirer l'entrée comme spécifié dans la Section 6.3.5.

Un champ Router Advertisement (par exemple, Cur Hop Limit, Reachable Time et Retrans Timer) peut contenir une valeur indiquant qu'il n'est pas spécifié. Dans de tels cas, le paramètre devrait être ignoré et l'hôte devrait continuer à utiliser la valeur qu'il utilise déjà.

Si la valeur Cur Hop Limit reçue est non nulle, l'hôte DEVRAIT (SHOULD) définir sa variable CurHopLimit à la valeur reçue.

Si la valeur Reachable Time reçue est non nulle, l'hôte DEVRAIT (SHOULD) définir sa variable BaseReachableTime à la valeur reçue. Si la nouvelle valeur diffère de la valeur précédente, l'hôte DEVRAIT (SHOULD) recalculer une nouvelle valeur aléatoire ReachableTime.

Si la valeur Retrans Timer reçue est non nulle, l'hôte DEVRAIT (SHOULD) définir sa variable RetransTimer à la valeur reçue.

Si l'option MTU est présente, les hôtes DEVRAIENT (SHOULD) copier la valeur de l'option dans LinkMTU tant que la valeur est supérieure ou égale au MTU de liaison minimum [IPv6] et ne dépasse pas la valeur LinkMTU par défaut spécifiée dans le document spécifique au type de liaison (par exemple, [IPv6-ETHER]).

Les options Prefix Information qui ont le drapeau "on-link" (L) défini indiquent un préfixe identifiant une plage d'adresses qui devraient être considérées on-link. Notez, cependant, qu'une option Prefix Information avec le drapeau on-link défini à zéro ne transmet aucune information concernant la détermination on-link et NE DOIT PAS (MUST NOT) être interprétée comme signifiant que les adresses couvertes par le préfixe sont off-link. La seule façon de désactiver un préfixe précédemment annoncé est d'annoncer ce préfixe avec la Valid Lifetime définie à zéro (voir Section 6.3.5).

Pour chaque option Prefix Information avec le drapeau on-link défini, un hôte fait ce qui suit :

  • Si le préfixe n'est pas déjà présent dans la liste de préfixes, et que le champ Valid Lifetime de l'option Prefix Information est non nul, créer une nouvelle entrée pour le préfixe et initialiser son temporisateur d'invalidation à la valeur Valid Lifetime dans l'option Prefix Information.

  • Si le préfixe est déjà présent dans la liste de préfixes de l'hôte en raison d'une annonce précédemment reçue, réinitialiser son temporisateur d'invalidation à la valeur Valid Lifetime dans l'option Prefix Information. Si la nouvelle valeur Lifetime est zéro, faire immédiatement expirer le préfixe (voir Section 6.3.5).

  • Si le champ Valid Lifetime de l'option Prefix Information est zéro, et que le préfixe n'est pas présent dans la liste de préfixes de l'hôte, ignorer silencieusement l'option.

Le drapeau de configuration d'adresse autonome (A-flag) indique si le préfixe peut être utilisé pour l'autoconfiguration d'adresse sans état ou non. Le traitement du A-flag est spécifié dans [ADDRCONF].

6.3.5. Expiration des préfixes et routeurs par défaut (Timing out Prefixes and Default Routers)​

Lorsque la Valid Lifetime d'un préfixe expire, le préfixe est retiré de la liste de préfixes. Un préfixe est invalidé lorsque sa Valid Lifetime expire.

Chaque fois que le temporisateur d'invalidation expire pour une entrée dans la liste de routeurs par défaut, cette entrée est rejetée. Lors de la suppression d'un routeur de la liste de routeurs par défaut, le nœud DOIT (MUST) mettre à jour le cache de destination de telle sorte que toutes les entrées utilisant le routeur effectuent à nouveau la détermination du prochain saut plutôt que de continuer à envoyer du trafic au routeur (supprimé).

6.3.6. Sélection du routeur par défaut (Default Router Selection)​

L'algorithme de sélection d'un routeur par défaut dépend de la politique de l'hôte. Cet algorithme pourrait faire partie d'une solution de mobilité.

Les règles ci-dessous représentent l'algorithme de sélection du routeur par défaut qui DEVRAIT (SHOULD) être utilisé en l'absence d'un meilleur algorithme.

  • Les routeurs qui sont accessibles ou probablement accessibles (c'est-à-dire, dans n'importe quel état autre que INCOMPLETE) DEVRAIENT (SHOULD) être préférés aux routeurs dont l'accessibilité est inconnue ou suspecte (c'est-à-dire, dans l'état INCOMPLETE). Une implémentation peut choisir de toujours retourner le même routeur ou de parcourir la liste de routeurs en round-robin tant qu'elle retourne toujours un routeur accessible lorsqu'un est disponible.

  • Lorsqu'aucun routeur de la liste n'est connu pour être accessible ou probablement accessible, les routeurs DEVRAIENT (SHOULD) être sélectionnés en round-robin, de sorte que les demandes ultérieures pour un routeur par défaut ne retournent pas le même routeur jusqu'à ce que tous les autres routeurs aient été sélectionnés.

Parcourir la liste de routeurs dans ce cas garantit que tous les routeurs disponibles sont activement testés pour l'accessibilité alors qu'aucun n'est connu pour être accessible.

6.3.7. Envoi de Router Solicitations (Sending Router Solicitations)​

Lorsqu'une interface est activée, un hôte peut envoyer jusqu'à MAX_RTR_SOLICITATIONS messages Router Solicitation. Cependant, les interfaces sur lesquelles les Router Advertisements non sollicités ne sont pas attendus (par exemple, les liaisons hôte uniquement, ou les liaisons où un hôte a été configuré avec un routeur par défaut) n'ont pas besoin d'envoyer de Router Solicitations.

Un hôte envoie des Router Solicitations à l'adresse multicast all-routers.

L'hôte DEVRAIT (SHOULD) transmettre jusqu'à MAX_RTR_SOLICITATIONS messages Router Solicitation, chacun séparé par au moins RTR_SOLICITATION_INTERVAL secondes. Cependant, pour éviter la congestion du réseau, le délai avant la première transmission DEVRAIT (SHOULD) être une valeur aléatoire uniformément distribuée entre 0 et MAX_RTR_SOLICITATION_DELAY. Ce délai garantit que les Router Solicitations de différents hôtes ne sont pas synchronisées.

Après avoir transmis MAX_RTR_SOLICITATIONS sollicitations, l'hôte recevra des Router Advertisements, ou aura conclu qu'il n'y a pas de routeurs sur la liaison. Une fois que l'hôte a envoyé MAX_RTR_SOLICITATIONS sollicitations, il DEVRAIT (SHOULD) continuer à recevoir et traiter les Router Advertisements qui peuvent arriver après qu'il ait cessé d'envoyer des Router Solicitations.

Dernière mise à jour le