7. Résolution d'adresse et détection d'inaccessibilité des voisins (Address Resolution and Neighbor Unreachability Detection)

Cette section décrit la résolution d'adresse et la détection d'inaccessibilité des voisins. La résolution d'adresse est le processus par lequel un nœud détermine l'adresse de couche liaison d'un voisin en ne disposant que de son adresse IP. La détection d'inaccessibilité des voisins (Neighbor Unreachability Detection, NUD) est le processus de suivi de l'état d'accessibilité du chemin vers un voisin.

7.1. Résolution d'adresse (Address Resolution)

La résolution d'adresse n'est effectuée que sur les adresses déterminées comme étant on-link. Elle n'est jamais effectuée sur les adresses multicast.

Lorsqu'un nœud a un paquet IPv6 à envoyer, il examine d'abord le cache de destination pour déterminer l'adresse du prochain saut pour la destination. Si le cache de destination ne contient pas d'entrée pour la destination, le nœud utilise l'algorithme de détermination du prochain saut (voir Section 5.2) pour déterminer l'adresse du prochain saut.

Une fois l'adresse IP du prochain saut connue, l'expéditeur examine le cache de voisins pour obtenir des informations de couche liaison sur le prochain saut. Si aucune entrée n'existe, l'expéditeur en crée une, définit son état à INCOMPLETE, initie la résolution d'adresse et met en file d'attente le paquet de données en attendant l'achèvement de la résolution d'adresse.

Pour les paquets multicast, le prochain saut est toujours l'adresse de destination (multicast) et est considéré comme on-link. La procédure de détermination de l'adresse de couche liaison correspondant à une adresse IP multicast est décrite dans un document séparé qui couvre le fonctionnement d'IP sur un type de liaison particulier (par exemple, [IPv6-ETHER]).

Pour les paquets unicast, la résolution d'adresse est effectuée comme suit. L'expéditeur crée une entrée de cache de voisins pour l'adresse du prochain saut (si elle n'existe pas déjà), définit son état à INCOMPLETE et initie la résolution d'adresse en envoyant un message Neighbor Solicitation à l'adresse multicast solicited-node correspondant à l'adresse cible. La sollicitation est envoyée depuis une adresse assignée à l'interface à partir de laquelle la sollicitation est envoyée.

L'adresse cible du Neighbor Solicitation est définie à l'adresse du prochain saut. Si l'expéditeur a une adresse assignée à l'interface à partir de laquelle le Neighbor Solicitation est envoyé, l'option Source Link-Layer Address DEVRAIT (SHOULD) être incluse. Si l'expéditeur n'a pas d'adresse assignée à l'interface à partir de laquelle la sollicitation est envoyée (par exemple, pendant l'initialisation), l'expéditeur NE DOIT PAS (MUST NOT) inclure l'option Source Link-Layer Address.

En attendant l'achèvement de la résolution d'adresse, l'expéditeur DOIT (MUST), pour chaque voisin, conserver une petite file d'attente de paquets en attente de l'achèvement de la résolution d'adresse. La file d'attente DOIT (MUST) contenir au moins un paquet et PEUT (MAY) en contenir davantage. Cependant, le nombre de paquets en file d'attente par voisin DEVRAIT (SHOULD) être limité à un petit nombre. Une fois la résolution d'adresse terminée, le nœud transmet tous les paquets en file d'attente.

En attendant l'achèvement de la résolution d'adresse, l'expéditeur continue d'envoyer des Neighbor Solicitations. Les Neighbor Solicitations pour la résolution d'adresse sont envoyés toutes les RetransTimer millisecondes jusqu'à ce qu'un Neighbor Advertisement soit reçu ou jusqu'à ce que le nombre maximum de Neighbor Solicitations (MAX_MULTICAST_SOLICIT) ait été envoyé. Si aucun Neighbor Advertisement n'est reçu après MAX_MULTICAST_SOLICIT sollicitations, la résolution d'adresse a échoué. L'expéditeur DOIT (MUST) libérer toute copie en cache du paquet et DEVRAIT (SHOULD) retourner des indications ICMP destination inaccessible avec le code 3 (Address Unreachable) pour chaque paquet en file d'attente en attente de résolution d'adresse.

7.2. Détection d'inaccessibilité des voisins (Neighbor Unreachability Detection)

7.2.1. Confirmation d'accessibilité (Reachability Confirmation)

Un voisin est considéré comme accessible si le nœud a récemment reçu une confirmation que les paquets envoyés récemment au voisin ont été reçus par sa couche IP. Une confirmation positive peut être recueillie de deux manières : des indices des protocoles de couche supérieure indiquant qu'une connexion fait des "progrès en avant", ou la réception d'un message Neighbor Advertisement qui est une réponse à un message Neighbor Solicitation.

Une connexion fait des "progrès en avant" si les paquets reçus d'un pair distant ne peuvent arriver que si les paquets récents envoyés à ce pair l'atteignent réellement. Dans TCP, par exemple, la réception d'un acquittement (nouveau) indique que les données précédemment envoyées ont atteint le pair. De même, l'arrivée de nouvelles données (non dupliquées) indique que les acquittements antérieurs atteignent le pair distant. Si les paquets atteignent le pair, ils doivent également atteindre la couche IP du pair, ce qui est l'exigence pour la détection d'inaccessibilité des voisins.

Pour les destinations off-link, les progrès en avant impliquent que le routeur de premier saut est accessible. Lorsqu'une telle confirmation existe, une implémentation PEUT (MAY) mettre à jour l'entrée du cache de voisins pour le routeur de premier saut et définir son état d'accessibilité à REACHABLE. Si une implémentation ne suit pas les progrès en avant, elle DEVRAIT (SHOULD) supposer que des progrès en avant sont réalisés lorsque les paquets continuent d'être reçus d'un pair distant.

La détection d'inaccessibilité des voisins fonctionne en parallèle avec les applications qui envoient des paquets. L'envoi d'un paquet à un voisin ne confirme pas son accessibilité ; la réception de l'acquittement correspondant le fait. Une implémentation NE DOIT PAS (MUST NOT) conclure qu'un voisin est accessible simplement parce qu'il est activement utilisé.

Lorsqu'un nœud doit effectuer une résolution d'adresse sur une adresse voisine mais possède déjà une entrée de cache de voisins pour l'adresse dans l'état STALE, le nœud met à jour l'état à DELAY plutôt qu'à INCOMPLETE et envoie un Neighbor Solicitation pour confirmer l'accessibilité. Le nœud attend ensuite DELAY_FIRST_PROBE_TIME secondes. Si aucune confirmation d'accessibilité n'est reçue dans ce délai, l'état de l'entrée est changé en PROBE et la détection d'inaccessibilité des voisins commence.

7.2.2. États des entrées du cache de voisins (Neighbor Cache Entry States)

Une entrée de cache de voisins pour un voisin auquel du trafic est envoyé peut être dans l'un des cinq états possibles :

INCOMPLETE (incomplet) - La résolution d'adresse est actuellement effectuée sur l'entrée. Plus précisément, un Neighbor Solicitation a été envoyé à l'adresse multicast solicited-node de la cible, mais le Neighbor Advertisement correspondant n'a pas encore été reçu.

REACHABLE (accessible) - Une confirmation positive a été reçue au cours des dernières ReachableTime millisecondes que le chemin en avant vers le voisin fonctionnait correctement. En état REACHABLE, aucune action spéciale n'est effectuée lors de l'envoi de paquets.

STALE (périmé) - Plus de ReachableTime millisecondes se sont écoulées depuis la dernière confirmation positive reçue que le chemin en avant fonctionnait correctement. En état stale, aucune action n'est effectuée jusqu'à ce qu'un paquet soit envoyé.

L'état STALE est entré lors de la réception d'un message Neighbor Discovery non sollicité qui met à jour l'adresse de couche liaison en cache. La réception d'un tel message ne confirme pas l'accessibilité, et l'entrée dans l'état STALE garantit que les échecs de chemin sont détectés rapidement. Cependant, l'accessibilité n'est pas réellement vérifiée tant que l'entrée n'est pas utilisée.

DELAY (délai) - Plus de ReachableTime millisecondes se sont écoulées depuis la dernière confirmation positive reçue que le chemin en avant fonctionnait correctement, et un paquet a été envoyé au cours des dernières DELAY_FIRST_PROBE_TIME secondes. Si aucune confirmation d'accessibilité n'est reçue dans les DELAY_FIRST_PROBE_TIME secondes suivant l'entrée dans l'état DELAY, envoyer un Neighbor Solicitation unicast et changer l'état en PROBE.

L'état DELAY est une optimisation qui donne aux protocoles de couche supérieure un temps supplémentaire pour fournir une confirmation d'accessibilité dans les cas où ReachableTime millisecondes se sont écoulées depuis la dernière confirmation en raison d'un manque de trafic récent. Sans cette optimisation, l'ouverture d'une connexion TCP après une accalmie de trafic déclencherait des sondes même si la poignée de main à trois voies ultérieure fournirait une confirmation d'accessibilité presque immédiatement.

PROBE (sonde) - Une confirmation d'accessibilité est activement recherchée en retransmettant des Neighbor Solicitations unicast toutes les RetransTimer millisecondes jusqu'à ce qu'une confirmation d'accessibilité soit reçue ou jusqu'à ce que le nombre maximum de sondes (MAX_UNICAST_SOLICIT) ait été envoyé. Si aucune réponse n'est reçue après l'envoi de MAX_UNICAST_SOLICIT sollicitations, les retransmissions cessent et l'entrée DEVRAIT (SHOULD) être supprimée. Le trafic ultérieur vers ce voisin recréera l'entrée et effectuera à nouveau la résolution d'adresse.

Notez que tous les Neighbor Solicitations sont limités en débit sur une base par voisin. Un nœud NE DOIT PAS (MUST NOT) envoyer de Neighbor Solicitations à la même cible plus fréquemment qu'une fois toutes les RetransTimer millisecondes.

7.2.3. Comportement du nœud (Node Behavior)

L'algorithme de détection d'inaccessibilité des voisins fonctionne différemment selon que l'entrée est utilisée pour transférer des paquets.

Lorsqu'une confirmation d'accessibilité est reçue (soit par conseil de couche supérieure, soit par un Neighbor Advertisement sollicité), l'état d'une entrée change en REACHABLE. La seule exception est que le conseil de couche supérieure n'a aucun effet sur les entrées dans l'état INCOMPLETE (par exemple, pour lesquelles aucune adresse de couche liaison n'est en cache).

Lorsqu'un nœud envoie un paquet à un voisin dont l'entrée est STALE, le nœud met à jour l'état de l'entrée à DELAY et définit un temporisateur pour expirer dans DELAY_FIRST_PROBE_TIME secondes. Si l'entrée est toujours dans l'état DELAY lorsque le temporisateur expire, l'état de l'entrée change en PROBE et un Neighbor Solicitation unicast est envoyé. Le Neighbor Solicitation est envoyé en utilisant l'adresse de couche liaison en cache. Les sollicitations ultérieures (le cas échéant) sont envoyées en utilisant la même adresse de couche liaison en cache. Les Neighbor Solicitations sont retransmis toutes les RetransTimer millisecondes jusqu'à ce qu'une confirmation d'accessibilité soit reçue ou jusqu'à ce que MAX_UNICAST_SOLICIT sollicitations aient été envoyées.

Si un Neighbor Advertisement est reçu en réponse à un Neighbor Solicitation unicast et que le drapeau Solicited du Neighbor Advertisement est défini, l'état de l'entrée change en REACHABLE. Si le drapeau Solicited n'est pas défini, l'entrée reste dans l'état PROBE.

Si une confirmation d'accessibilité est reçue dans l'état PROBE, l'état de l'entrée change en REACHABLE. Si le nombre maximum de sondes a été envoyé sans recevoir de confirmation d'accessibilité, l'entrée DEVRAIT (SHOULD) être supprimée, et le trafic futur vers ce voisin nécessitera d'effectuer à nouveau la résolution d'adresse. Une implémentation PEUT (MAY) collecter les entrées périmées à tout moment. Cependant, les entrées dans l'état INCOMPLETE NE DEVRAIENT PAS (SHOULD NOT) être supprimées tant que la résolution d'adresse n'a pas échoué (c'est-à-dire, MAX_MULTICAST_SOLICIT Neighbor Solicitations ont été envoyés et aucune réponse n'a été reçue).

7.3. Protocole de détection d'inaccessibilité des voisins (Neighbor Unreachability Detection Protocol)

Cette section fournit un aperçu du fonctionnement de l'algorithme de détection d'inaccessibilité des voisins.

7.3.1. Événements de confirmation d'accessibilité (Reachability Confirmation Events)

Les événements suivants entraînent la reconfirmation d'une adresse de couche liaison en cache comme REACHABLE :

1. Réception d'un Neighbor Advertisement sollicité pour une entrée dans n'importe quel état sauf INCOMPLETE.

2. Réception d'une confirmation d'accessibilité de couche supérieure (par exemple, acquittement TCP positif) pour une entrée dans n'importe quel état sauf INCOMPLETE.

3. Pour une entrée dans l'état STALE, DELAY ou PROBE, envoi d'un Neighbor Solicitation et réception d'un Neighbor Advertisement sollicité.

7.3.2. Transitions d'état (State Transitions)

Les transitions d'état se produisent comme suit :

INCOMPLETE -> REACHABLE : Lorsqu'un Neighbor Advertisement valide est reçu qui contient l'option Target Link-Layer Address.

INCOMPLETE -> (supprimé) : Lorsque la résolution d'adresse échoue (c'est-à-dire, MAX_MULTICAST_SOLICIT Neighbor Solicitations envoyés sans réponse).

REACHABLE -> STALE : Lorsque ReachableTime millisecondes s'écoulent sans recevoir de confirmation d'accessibilité.

STALE -> DELAY : Lorsqu'un paquet est envoyé à un voisin dans l'état STALE.

STALE -> REACHABLE : Lorsqu'une confirmation d'accessibilité est reçue.

DELAY -> PROBE : Lorsque DELAY_FIRST_PROBE_TIME secondes s'écoulent sans recevoir de confirmation d'accessibilité.

DELAY -> REACHABLE : Lorsqu'une confirmation d'accessibilité est reçue.

PROBE -> REACHABLE : Lorsqu'une confirmation d'accessibilité est reçue.

PROBE -> (supprimé) : Lorsque MAX_UNICAST_SOLICIT sondes sont envoyées sans recevoir de confirmation d'accessibilité.

7.3.3. Envoi de Neighbor Solicitations (Sending Neighbor Solicitations)

Lors de l'envoi d'un message Neighbor Solicitation dans le but de la détection d'inaccessibilité des voisins, les règles suivantes s'appliquent :

• L'adresse cible du Neighbor Solicitation DOIT (MUST) être définie à l'adresse IP du voisin dont l'accessibilité est confirmée.

• Le Neighbor Solicitation DOIT (MUST) être envoyé comme paquet unicast en utilisant l'adresse de couche liaison en cache.

• L'adresse source du Neighbor Solicitation DOIT (MUST) être une adresse assignée à l'interface à partir de laquelle le Neighbor Solicitation est envoyé.

• Le Neighbor Solicitation DEVRAIT (SHOULD) inclure l'option Source Link-Layer Address.

7.3.4. Réception de Neighbor Solicitations (Receiving Neighbor Solicitations)

Lorsqu'un Neighbor Solicitation est reçu, le destinataire vérifie s'il est la cible de la sollicitation. Si c'est le cas, le destinataire DEVRAIT (SHOULD) créer ou mettre à jour l'entrée du cache de voisins pour l'expéditeur. Si une entrée de cache de voisins pour l'expéditeur existe déjà, le destinataire met à jour l'adresse de couche liaison de l'entrée (si différente) et définit l'état de l'entrée comme suit :

• Si l'entrée est dans n'importe quel état et que le drapeau Override dans un Neighbor Advertisement reçu est défini, l'adresse de couche liaison de l'entrée est mise à jour.

• Si l'entrée est dans l'état INCOMPLETE, l'adresse de couche liaison de l'entrée est définie à la valeur dans l'option Source Link-Layer Address (si présente) et l'état est défini à STALE.

• Si l'entrée est dans n'importe quel état autre que INCOMPLETE, et que l'adresse Source Link-Layer Address reçue diffère de l'adresse de couche liaison en cache, et que le drapeau Override est défini, l'adresse de couche liaison en cache est remplacée par l'adresse reçue, et l'état de l'entrée reste inchangé.

7.4. Envoi de Neighbor Advertisements (Sending Neighbor Advertisements)

Un nœud envoie des Neighbor Advertisements en réponse aux Neighbor Solicitations et envoie également des Neighbor Advertisements non sollicités lorsque son adresse de couche liaison change.

7.4.1. Réponse aux Neighbor Solicitations (Responding to Neighbor Solicitations)

Lorsqu'un Neighbor Solicitation est reçu, le nœud cible DEVRAIT (SHOULD) répondre avec un Neighbor Advertisement. Le Neighbor Advertisement est envoyé à l'adresse source du Neighbor Solicitation si ce n'est pas l'adresse non spécifiée ; sinon, le Neighbor Advertisement est envoyé à l'adresse multicast all-nodes.

L'adresse cible du Neighbor Advertisement est copiée de l'adresse cible du Neighbor Solicitation. Le drapeau Solicited est défini à un si le Neighbor Advertisement est envoyé en réponse à un Neighbor Solicitation ; sinon, il est défini à zéro.

Si l'option Target Link-Layer Address est incluse dans le Neighbor Solicitation et que l'adresse de couche liaison diffère de l'adresse de couche liaison du nœud récepteur, le drapeau Override est défini à un ; sinon, il est défini selon les circonstances.

7.4.2. Neighbor Advertisements non sollicités (Unsolicited Neighbor Advertisements)

Un nœud peut envoyer des Neighbor Advertisements non sollicités pour annoncer des changements à son adresse de couche liaison. Lorsqu'un nœud détecte que son adresse de couche liaison a changé (par exemple, après le remplacement à chaud d'une interface Ethernet), il DEVRAIT (SHOULD) multicaster quelques Neighbor Advertisements à l'adresse multicast all-nodes pour mettre rapidement à jour les entrées du cache de voisins des voisins.

Pour les Neighbor Advertisements non sollicités, le drapeau Override DEVRAIT (SHOULD) être défini à un pour garantir que les voisins mettent à jour leurs adresses de couche liaison en cache. Le drapeau Solicited DOIT (MUST) être défini à zéro dans les Neighbor Advertisements non sollicités.

---