6. Comportement du routeur pour les 6LR et 6LBR (Router Behavior for 6LRs and 6LBRs)

Les 6LR et les 6LBR maintiennent la Neighbor Cache [RFC4861] en se basant sur les ARO qu’ils reçoivent dans les messages NA provenant des hôtes, sur les paquets ND provenant d’autres nœuds et, potentiellement, sur un protocole de routage utilisé dans le 6LoWPAN comme décrit à la Section 3.5.

Les routeurs SHOULD NOT procéder au garbage-collect des NCE enregistrées (Registered NCEs, voir Section 3.4), car ils doivent les conserver jusqu’à l’expiration de la Registration Lifetime. De même, si la NUD sur le routeur détermine que l’hôte est UNREACHABLE (selon la logique de [RFC4861]), la NCE SHOULD NOT être supprimée, mais plutôt conservée jusqu’à l’expiration de la Registration Lifetime. Un ARO renouvelé devrait marquer l’entrée de cache comme STALE. Ainsi, pour les routeurs 6LoWPAN, la Neighbor Cache ne se comporte pas comme un cache. Elle se comporte plutôt comme un registre de toutes les adresses d’hôtes attachées au routeur.

Les routeurs MAY implémenter l’extension Default Router Preference (Prf) [RFC4191] et l’utiliser pour indiquer à l’hôte si le routeur est un 6LBR ou un 6LR. Si cela est implémenté, alors les 6LR sans route vers un routeur frontière MUST définir Prf à (11) pour une préférence basse, les autres 6LR MUST définir Prf à (00) pour une préférence normale, et les 6LBR MUST définir Prf à (01) pour une préférence élevée.

6.1. Actions interdites (Forbidden Actions)

Même si un routeur dans une topologie route-over peut atteindre à la fois un hôte et une autre cible, du fait de la propagation radio il ne peut généralement pas savoir si l’hôte peut atteindre directement l’autre cible. Par conséquent, il ne peut pas supposer que Redirect fonctionnera réellement d’un hôte vers un autre. Par conséquent, il SHOULD NOT envoyer de messages Redirect. La seule exception potentielle à ce "SHOULD NOT" est lorsque le déploiement/l’implémentation dispose d’un moyen de savoir comment l’hôte peut atteindre la cible visée. Il est donc RECOMMENDED que l’implémentation, par défaut, n’envoie pas de messages Redirect, mais qu’elle puisse être configurable lorsque le déploiement l’exige. En revanche, pour les topologies mesh-under, les mêmes considérations à propos des Redirect s’appliquent que dans [RFC4861].

Un routeur MUST NOT définir le drapeau L (on-link) dans les PIO, car cela pourrait déclencher l’envoi de NS multicast par les hôtes.

6.2. Initialisation de l’interface (Interface Initialization)

Le comportement d’initialisation de l’interface routeur d’un 6LBR est le même que dans [RFC4861]. Cependant, dans un scénario de configuration dynamique (voir Section 8.1), un 6LR démarre en tant que non-routeur et attend de recevoir l’annonce permettant de configurer d’abord l’adresse de sa propre interface, avant de définir ses interfaces comme des interfaces annonçantes et de devenir un routeur.

6.3. Traitement d’une Router Solicitation (Processing a Router Solicitation)

Un routeur traite les messages RS comme spécifié dans [RFC4861]. Les différences concernent l’inclusion d’ABRO dans les messages RA et l’utilisation exclusive de RA en unicast. Si un 6LR a reçu un ABRO d’un 6LBR, alors il inclura cette option sans la modifier dans les messages RA qu’il envoie. Et si le 6LR a reçu des RA — qu’ils contiennent les mêmes informations de préfixe et de contexte ou des informations différentes — d’un autre 6LBR, alors il devra conserver séparément ces préfixes et ces informations de contexte afin que les RA envoyés par le 6LR maintiennent l’association entre l’ABRO et les informations de préfixe et de contexte. Le routeur peut déterminer quel 6LBR a originé les informations de préfixe et de contexte à partir du champ 6LBR Address dans l’ABRO. Lorsqu’un routeur possède des informations liées à plusieurs ABRO, un seul RS entraînera plusieurs RA, chacun contenant un ABRO différent.

Lorsque la ABRO Valid Lifetime associée à un 6LBR expire, toutes les informations liées à ce 6LBR MUST être supprimées. En tant que note d’implémentation, il est recommandé que des RA soient envoyés suffisamment plus fréquemment que la ABRO Valid Lifetime afin qu’un RA manqué ne conduise pas à supprimer toutes les informations liées à un 6LBR.

Un RS peut être reçu d’un hôte qui n’a pas encore enregistré son adresse auprès du routeur. Ainsi, le routeur MUST NOT modifier une NCE existante sur la base du SLLAO du RS. Toutefois, un routeur MAY créer une Tentative NCE sur la base du SLLAO. Une telle Tentative NCE SHOULD expirer après TENTATIVE_NCE_LIFETIME secondes, sauf si un enregistrement la convertit en Registered NCE.

Un 6LR ou un 6LBR MUST inclure un SLLAO dans les RA qu’il envoie ; cela est requis afin que les hôtes connaissent l’adresse de liaison du routeur. Contrairement à [RFC4861], la valeur maximale du champ Router Lifetime d’un RA MAY aller jusqu’à 0xFFFF (environ 18 heures).

Contrairement à [RFC4861] qui suggère des RA en multicast, cette spécification améliore l’échange en envoyant toujours des RA en unicast en réponse aux RS. Cela est possible, puisque le RS inclut toujours un SLLAO, utilisé par le routeur pour unicaster le RA.

6.4. Router Advertisements périodiques (Periodic Router Advertisements)

Un routeur n’a pas besoin d’envoyer des messages RA périodiques, puisque les hôtes solliciteront des informations mises à jour en envoyant des RS avant l’expiration des durées de vie.

Cependant, si les routeurs utilisent des RA pour distribuer des informations de préfixe et/ou de contexte à travers une topologie route-over, cela peut nécessiter des messages RA périodiques. De tels RA sont envoyés en utilisant les paramètres configurables MinRtrAdvInterval et MaxRtrAdvInterval conformément à [RFC4861].

6.5. Traitement d’une Neighbor Solicitation (Processing a Neighbor Solicitation)

Un routeur traite les messages NS comme spécifié dans [RFC4861], avec une logique supplémentaire décrite dans cette section pour la gestion de l’ARO.

En plus de la validation normale d’un NS et de ses options, l’ARO (si présent) est vérifié comme suit. Si le champ Length n’est pas égal à deux, ou si le champ Status n’est pas égal à zéro, alors le NS est silencieusement ignoré.

Si l’adresse source du NS est l’adresse unspecified, ou si aucun SLLAO n’est inclus, alors tout ARO inclus est ignoré ; c’est-à-dire que le NS est traité comme s’il ne contenait pas d’ARO.

6.5.1. Vérification des doublons (Checking for Duplicates)

Si le NS contient un ARO valide, alors le routeur inspecte sa Neighbor Cache sur l’interface d’arrivée pour voir s’il s’agit d’un doublon. Ce n’est pas un doublon si (1) il n’existe pas de NCE pour l’adresse IPv6 source du NS ou (2) il existe une telle NCE et l’EUI-64 est identique. Sinon, il s’agit d’une adresse dupliquée. Notez que si la multihop DAD (Section 8.2) est utilisée, alors les vérifications sont légèrement différentes afin de prendre en compte les Tentative NCE. Dans le cas où il s’agit d’une adresse dupliquée, le routeur répond avec un message NA en unicast avec le champ ARO Status défini à un (pour indiquer que l’adresse est un doublon) comme décrit à la Section 6.5.2. Dans ce cas, il n’y a aucune modification de la Neighbor Cache.

6.5.2. Retour des erreurs d’enregistrement d’adresse (Returning Address Registration Errors)

Les erreurs d’enregistrement d’adresse ne sont pas renvoyées à l’adresse source du NS en raison d’un risque possible de collision d’adresse L2. À la place, le NA est envoyé à l’adresse IPv6 link-local dont la partie Interface ID est dérivée du champ EUI-64 de l’ARO selon [RFC4944]. En particulier, cela signifie que le bit universal/local doit être inversé. Le NA est formaté avec une copie de l’ARO du NS, mais avec le champ Status défini pour indiquer l’erreur appropriée.

L’erreur est envoyée à l’adresse link-local avec l’Interface ID dérivé de l’EUI-64. Ainsi, si l’ARO provenait d’une adresse courte et concernait une adresse courte, la destination L2 du NA avec l’erreur ARO sera l’adresse unique 64 bits.

6.5.3. Mise à jour de la Neighbor Cache (Updating the Neighbor Cache)

Si l’ARO n’a pas conduit à la détection d’une adresse dupliquée comme ci-dessus, alors si la Registration Lifetime est non nulle, le routeur crée (si elle n’existait pas) ou met à jour (sinon) une NCE pour l’adresse IPv6 source du NS. Si la Neighbor Cache est pleine et qu’une nouvelle entrée doit être créée, alors le routeur répond avec un NA en unicast avec le champ ARO Status défini à deux (pour indiquer que la Neighbor Cache du routeur est pleine) comme décrit à la Section 6.5.2.

La Registration Lifetime et l’EUI-64 sont enregistrés dans la NCE. Un NA en unicast est ensuite envoyé en réponse au NS. Ce NA SHOULD inclure une copie de l’ARO, avec le champ Status défini à zéro. Un TLLAO (Target Link-Layer Address Option) [RFC4861] n’est pas requis dans le NA, puisque l’hôte connaît déjà l’adresse de liaison du routeur grâce aux RA.

Si l’ARO contient une Registration Lifetime nulle, alors toute NCE existante pour l’adresse IPv6 source du NS MUST être supprimée et un NA envoyé comme ci-dessus.

Si la Registration Lifetime d’une NCE expire, alors le routeur MUST supprimer l’entrée de cache.

L’ajout et la suppression de Registered NCE entraîneraient une notification au protocole de routage.

Note : Si la multihop DAD substituable (Section 8.2) est utilisée, alors la mise à jour de la Neighbor Cache est légèrement différente en raison des Tentative NCE.

6.5.4. Détermination du prochain saut (Next-Hop Determination)

Afin de délivrer un paquet destiné à un 6LN enregistré auprès d’un routeur, la détermination du prochain saut est légèrement différente pour les routeurs que pour les hôtes (voir Section 5.6). La table de routage est consultée pour déterminer l’adresse IP du prochain saut. Une Registered NCE détermine si l’adresse IP du prochain saut est on-link. Il est de la responsabilité du protocole de routage du routeur de maintenir l’information on-link concernant ses voisins enregistrés. Les Tentative NCE MUST NOT être utilisées pour déterminer le statut on-link des nœuds enregistrés.

6.5.5. Résolution d’adresse entre routeurs (Address Resolution between Routers)

Il doit exister un mécanisme permettant aux routeurs de découvrir les adresses de liaison les uns des autres. Si le protocole de routage utilisé entre les routeurs fournit cela, alors il n’est pas nécessaire que les routeurs utilisent l’ARO entre eux. Sinon, les routeurs SHOULD utiliser l’ARO. Lorsque les routeurs utilisent l’ARO pour s’enregistrer entre eux et que la multihop DAD (Section 8.2) est utilisée, il faut veiller à éviter un flot de messages portant des ARO envoyés au 6LBR, au fur et à mesure que chaque routeur entend un ARO de ses routeurs voisins. Les détails de ce scénario sont hors du champ de ce document.

Les routeurs MAY également utiliser des NS en multicast comme dans [RFC4861] pour résoudre les adresses de liaison entre eux. Ainsi, les routeurs MAY multicaster des NS pour d’autres routeurs, par exemple à la suite de la réception d’une mise à jour de protocole de routage. Les routeurs MUST répondre aux NS en multicast. Cela implique que les routeurs MUST rejoindre les adresses multicast solicited-node comme spécifié dans [RFC4861].