8. Comportement des Fonctionnalités Substituables

Normalement, dans un réseau à sauts multiples 6LoWPAN, les messages RA sont utilisés pour diffuser les préfixes et les informations de contexte à tous les 6LR dans une topologie route-over. Si tous les routeurs sont configurés pour utiliser un mécanisme de substitution pour une telle distribution d'informations, toute utilisation restante des mécanismes 6LoWPAN-ND est régie par la spécification de substitution.

Il y a aussi l'option pour un 6LR d'effectuer une DAD à sauts multiples (pour les adresses IPv6 non dérivées d'un EUI-64) contre un 6LBR dans une topologie route-over en utilisant les messages DAR et DAC. Ceci est substituable car il pourrait y avoir d'autres moyens d'attribuer une adresse unique, tels que DHCPv6 [RFC3315], ou d'utiliser d'autres mécanismes futurs pour la DAD à sauts multiples. Encore une fois, dans ce cas, toute utilisation restante des mécanismes 6LoWPAN-ND est régie par la spécification de substitution.

Pour être clair : Les implémentations DOIVENT prendre en charge les fonctionnalités décrites dans les Sections 8.1 et 8.2, à moins que l'implémentation ne prenne en charge une alternative ("substitut") provenant d'une autre spécification.

8.1. Distribution de Préfixe et de Contexte à Sauts Multiples

La distribution à sauts multiples repose sur les messages RS et les messages RA envoyés entre les routeurs, et l'utilisation du numéro de version ABRO pour contrôler la propagation des informations (préfixes et informations de contexte) qui sont envoyées dans les RA.

Ce mécanisme de distribution à sauts multiples peut gérer des informations arbitraires provenant d'un nombre arbitraire de 6LBR. Cependant, la sémantique des informations de contexte exige que tous les 6LN utilisent les mêmes informations, qu'ils envoient, transmettent ou reçoivent des paquets compressés. Ainsi, le gestionnaire des 6LBR doit s'assurer d'une manière ou d'une autre que les informations de contexte sont synchronisées entre les 6LBR. Cela peut être géré de différentes manières. Une façon possible de s'en assurer est de traiter les informations de contexte et de préfixe comme provenant d'une source logique ou virtuelle, ce qui signifie essentiellement qu'il semble que les informations soient distribuées à partir d'une source unique.

Si un ensemble de 6LBR se comporte comme un seul (en utilisant des mécanismes hors de la portée de ce document) de sorte que les préfixes et les contextes et le numéro de version ABRO seront les mêmes pour tous les 6LBR, alors ces 6LBR peuvent choisir une seule adresse IP à utiliser dans l'ABRO.

8.1.1. 6LBR Envoyant des Annonces de Routeur

Les 6LBR prenant en charge la distribution de préfixe et de contexte à sauts multiples DOIVENT inclure une ABRO dans chacun de leurs RA. Le champ Numéro de Version ABRO est utilisé pour maintenir les informations de préfixe et de contexte cohérentes dans tout le LoWPAN, ainsi que les directives de la Section 7.2. Chaque fois qu'une information dans l'ensemble des PIO ou 6CO change, la version ABRO est augmentée de un.

Cela nécessite que le 6LBR maintienne les PIO, 6CO et le Numéro de Version ABRO dans un stockage stable, car un ancien numéro de version sera silencieusement ignoré par les 6LR.

8.1.2. Routeurs Envoyant des Sollicitations de Routeur

Dans un 6LoWPAN, à moins d'être substitué, la distribution à sauts multiples se fait à l'aide de messages RA. Ainsi, lors de l'initialisation de l'interface, un routeur (6LR) DOIT envoyer des messages RS en suivant les règles spécifiées pour les hôtes dans [RFC4861]. Cela amènera à son tour les routeurs à répondre avec des messages RA qui peuvent ensuite être utilisés pour semer initialement les informations de préfixe et de contexte.

8.1.3. Routeurs Traitant les Annonces de Routeur

Si la distribution à sauts multiples n'est pas effectuée à l'aide de messages RA, alors les routeurs suivent [RFC4861], qui stipule qu'ils effectuent simplement quelques contrôles de cohérence ; dans ce cas, rien dans la Section 8.1 ne s'applique. Sinon, les routeurs vérifieront et enregistreront les informations de préfixe et de contexte des RA reçus, et utiliseront ces informations comme suit.

Si un RA reçu ne contient pas d'ABRO, alors le RA DOIT être silencieusement ignoré.

Le routeur utilise le champ Adresse 6LBR dans l'ABRO pour vérifier s'il a déjà reçu des informations du 6LBR. S'il ne trouve aucune information de ce type, alors il enregistre simplement l'adresse du 6LBR, la Version, la Durée de Vie Valide, et les informations de préfixes et de contexte associées. Si le 6LBR est déjà connu, alors le champ Numéro de Version DOIT être comparé au numéro de version enregistré pour ce 6LBR. Si le numéro de version reçu dans le paquet est inférieur au numéro de version stocké, alors les informations dans le RA sont silencieusement ignorées. Sinon, les informations enregistrées et le numéro de version sont mis à jour.

8.1.4. Stockage des Informations

Le routeur conserve l'état pour chaque 6LBR qu'il voit avec une ABRO. Cela inclut le numéro de version, la Durée de Vie Valide, et l'ensemble complet des PIO et 6CO. Les préfixes expirent en fonction de la Durée de Vie Valide dans la PIO. Le Préfixe de Contexte expire en fonction de la Durée de Vie Valide dans la 6CO.

Tant que les informations de préfixes et de contexte sont stockées dans le routeur, leurs durées de vie valides et préférées sont décrémentées à mesure que le temps passe. Cela garantit que lorsque le routeur annonce à son tour ces informations dans les RA qu'il envoie, l'« heure d'expiration » ne se déplace pas accidentellement plus loin dans le futur. Par exemple, si une 6CO avec une Durée de Vie Valide de 10 minutes est reçue au temps T, et que le routeur l'inclut dans un RA qu'il envoie au temps T+5 minutes, la Durée de Vie Valide dans la 6CO qu'il envoie ne sera que de 5 minutes.

8.1.5. Envoi d'Annonces de Routeur

Lorsque la distribution à sauts multiples est effectuée à l'aide de messages RA, les routeurs DOIVENT s'assurer que l'ABRO reste toujours avec les informations de préfixes et de contexte reçues avec cette ABRO. Ainsi, si le routeur a reçu le préfixe P1 avec une ABRO indiquant qu'il provient d'un 6LBR, et le préfixe P2 d'un autre 6LBR, alors le routeur NE DOIT PAS inclure les deux préfixes dans le même message RA. Le préfixe P1 DOIT être dans un RA qui inclut une ABRO du premier 6LBR, etc. Notez que plusieurs 6LBR peuvent annoncer les mêmes informations de préfixe et de contexte, mais elles doivent toujours être associées aux 6LBR qui les ont annoncées.

Les routeurs envoient périodiquement des RA comme dans [RFC4861]. C'est au bénéfice des autres routeurs recevant les informations de préfixes et de contexte. Les routeurs répondent également aux RS en envoyant des messages RA en monodiffusion. Dans les deux cas, la contrainte ci-dessus de garder l'ABRO avec « ses » informations de préfixes et de contexte s'applique.

Lorsqu'un routeur reçoit de nouvelles informations d'un 6LBR, c'est-à-dire soit qu'il entend parler d'un nouveau 6LBR (une nouvelle adresse 6LBR dans l'ABRO) soit que le numéro de version ABRO d'un 6LBR existant a augmenté, alors il est utile d'envoyer quelques mises à jour déclenchées. La recommandation est de se comporter de la même manière que lorsqu'une interface est devenue une interface d'annonce comme décrit dans [RFC4861], c'est-à-dire envoyer jusqu'à trois messages RA. Cela garantit une propagation rapide des nouvelles informations à tous les 6LR.

8.2. Détection d'Adresse Dupliquée à Sauts Multiples

L'ARO peut être utilisée, en plus d'enregistrer une adresse dans un 6LR, pour faire vérifier par le 6LR que l'adresse n'est pas utilisée par un autre hôte connu du 6LR. Cependant, cela n'est pas suffisant dans une topologie route-over (ou dans un LoWPAN avec plusieurs 6LBR), car un hôte attaché à un autre 6LR pourrait utiliser la même adresse. Il pourrait y avoir différentes manières pour les 6LR de coordonner une telle détection d'adresse dupliquée à l'avenir, ou les adresses pourraient être attribuées à l'aide d'un serveur DHCPv6 qui vérifie l'unicité dans le cadre de l'attribution.

Cette spécification offre une technique simple et substituable pour que les 6LR et 6LBR effectuent la DAD qui réutilise les informations de l'ARO dans les messages DAR et DAC. Cette technique n'est pas nécessaire lorsque l'ID d'Interface dans l'adresse est basé sur un EUI-64, car ceux-ci sont supposés être globalement uniques. La technique suppose que soit les 6LR s'enregistrent auprès de tous les 6LBR, soit le réseau utilise un mécanisme hors de portée pour garder les tables DAD dans les 6LBR synchronisées.

Le mécanisme de DAD à sauts multiples est utilisé de manière synchrone la première fois qu'une adresse est enregistrée auprès d'un 6LR particulier. C'est-à-dire que l'ARO n'est pas renvoyée à l'hôte tant que la DAD à sauts multiples n'a pas été complétée contre les 6LBR. Pour les enregistrements existants dans le 6LR, la DAD à sauts multiples doit être répétée contre les 6LBR pour s'assurer que l'entrée pour l'adresse dans les 6LBR n'expire pas, mais cela peut être fait de manière asynchrone avec la réponse aux hôtes. Une méthode pour y parvenir est de suivre combien il reste de la durée de vie que le 6LR a enregistrée auprès des 6LBR et de se réenregistrer auprès du 6LBR lorsque cette durée de vie est sur le point de s'épuiser.

Pour la DAD à sauts multiples synchrone, le 6LR effectue quelques vérifications supplémentaires pour s'assurer qu'il a une NCE qu'il peut utiliser pour répondre à l'hôte lorsqu'il reçoit une réponse d'un 6LBR. Cela consiste à vérifier une NCE existante (Tentative ou Enregistrée) pour l'Adresse Enregistrée avec un EUI-64 différent. Si une telle NCE Enregistrée existe, alors le 6LR DEVRAIT répondre que l'adresse est un duplicata. Si une telle NCE Tentative existe, alors le 6LR DEVRAIT ignorer silencieusement l'ARO, comptant ainsi sur l'hôte pour retransmettre l'ARO. Ceci est nécessaire pour gérer le cas où plusieurs hôtes essaient d'enregistrer la même adresse IPv6 en même temps. Si aucune NCE n'existe, alors le 6LR DOIT créer une NCE Tentative avec l'EUI-64 et la SLLAO. Cette entrée sera utilisée pour envoyer la réponse à l'hôte lorsque le 6LBR répond positivement.

Lorsqu'un 6LR reçoit un NS contenant une ARO avec une Durée de Vie d'Enregistrement non nulle et qu'il n'a pas de NCE Enregistrée existante, alors avec ce mécanisme, le 6LR invoquera la DAD à sauts multiples synchrone.

Le 6LR enverra un message DAR en monodiffusion à un ou plusieurs 6LBR, où le DAR contient l'adresse de l'hôte dans le champ Adresse Enregistrée. Le DAR sera transmis par les 6LR jusqu'à ce qu'il atteigne le 6LBR ; par conséquent, son champ Limite de Sauts IPv6 ne sera pas 255 lorsqu'il sera reçu par le 6LBR. Le 6LBR répondra avec un message DAC, qui aura une limite de sauts inférieure à 255 lorsqu'il atteindra le 6LR.

Lorsque le 6LR reçoit le DAC du 6LBR, il recherchera une NCE correspondante (même adresse IP et EUI-64) (Tentative ou Enregistrée). Si aucune entrée de ce type n'est trouvée, alors le DAC est silencieusement ignoré. Si une entrée est trouvée et que le DAC avait Statut=0, alors le 6LR marquera la NCE Tentative comme Enregistrée. Dans tous les cas, lorsqu'une entrée est trouvée, alors le 6LR répondra à l'hôte avec un NA, copiant les champs Statut et EUI-64 du DAC vers une ARO dans le NA. Au cas où le statut est une erreur, alors l'adresse IP de destination du NA est dérivée du champ EUI-64 du DAC.

Une NCE Tentative DEVRAIT expirer TENTATIVE_NCE_LIFETIME secondes après sa création afin de permettre à un autre hôte de tenter d'enregistrer l'adresse IPv6.

8.2.1. Validation des Messages pour DAR et DAC

Un nœud DOIT rejeter silencieusement tout message DAR et DAC reçu pour lequel au moins l'une des vérifications de validité suivantes n'est pas satisfaite :

• Si le message inclut un En-tête d'Authentification IP, le message s'authentifie correctement.
• La Somme de Contrôle ICMP est valide.
• Le Code ICMP est 0.
• La Longueur ICMP (dérivée de la longueur IP) est de 32 octets ou plus.
• L'Adresse Enregistrée n'est pas une adresse de multidiffusion.
• Toutes les options incluses ont une longueur supérieure à zéro.
• L'adresse source IP n'est pas l'adresse non spécifiée, ni une adresse de multidiffusion.

Le contenu du champ Réservé et de toute option non reconnue DOIT être ignoré. Les changements futurs rétrocompatibles au protocole peuvent spécifier le contenu du champ Réservé ou ajouter de nouvelles options ; les changements non rétrocompatibles peuvent utiliser des valeurs de Code différentes.

Notez qu'en raison de la transmission des messages DAR et DAC entre le 6LR et le 6LBR, il n'y a pas de vérification de limite de sauts à la réception pour ces types de messages ICMPv6.

8.2.2. Structures de Données Conceptuelles

Un 6LBR implémentant la DAD à sauts multiples doit maintenir un état séparé du Cache des Voisins. Nous appelons cette structure de données conceptuelle la table DAD. Elle est indexée par l'adresse IPv6 -- l'Adresse Enregistrée dans le DAR -- et contient l'EUI-64 et la Durée de Vie d'Enregistrement de l'hôte qui utilise cette adresse.

8.2.3. 6LR Envoyant une Demande d'Adresse Dupliquée

Lorsqu'un 6LR qui implémente la DAD à sauts multiples reçoit un NS d'un hôte, et sous réserve des vérifications ci-dessus, le 6LR forme et envoie un DAR à au moins un 6LBR. Le DAR contient les informations suivantes :

• Dans l'adresse source IPv6, une adresse globale du 6LR.
• Dans l'adresse de destination IPv6, l'adresse du 6LBR.
• Dans la limite de sauts IPv6, MULTIHOP_HOPLIMIT.
• Le champ Statut DOIT être mis à zéro.
• L'EUI-64 et la Durée de Vie d'Enregistrement sont copiés de l'ARO reçue de l'hôte.
• L'Adresse Enregistrée est définie sur l'adresse IPv6 de l'hôte, c'est-à-dire l'expéditeur du NS déclencheur.

Lorsqu'un 6LR reçoit un NS d'un hôte avec une Durée de Vie d'Enregistrement nulle, alors, en plus de supprimer la NCE pour l'hôte comme spécifié à la Section 6, un DAR est envoyé aux 6LBR comme ci-dessus.

Un routeur NE DOIT PAS modifier le Cache des Voisins suite à la réception d'un DAR.

8.2.4. 6LBR Recevant une Demande d'Adresse Dupliquée

Lorsqu'un 6LBR qui implémente la DAD à sauts multiples substituable reçoit un DAR d'un 6LR, il effectue la validation de message spécifiée à la Section 8.2.1. Si le DAR est valide, le 6LBR procède à la recherche de l'Adresse d'Enregistrement dans la table DAD. Si une entrée est trouvée et que l'EUI-64 enregistré est différent de l'EUI-64 dans le DAR, alors il retourne un NA DAC avec le Statut mis à 1 ('Adresse Dupliquée'). Sinon, il retourne un DAC avec le Statut mis à zéro et met à jour la durée de vie.

Si aucune entrée n'est trouvée dans la table DAD et que la Durée de Vie d'Enregistrement est non nulle, alors une entrée est créée et l'EUI-64 et l'Adresse Enregistrée du DAR sont stockés dans cette entrée.

Si une entrée est trouvée dans la table DAD, que l'EUI-64 correspond, et que la Durée de Vie d'Enregistrement est nulle, alors l'entrée est supprimée de la table.

Dans les deux cas ci-dessus, le 6LBR forme un DAC avec les informations copiées du DAR et le champ Statut est mis à zéro. Le DAC est renvoyé au 6LR, c'est-à-dire à la source du DAR. La limite de sauts IPv6 est mise à MULTIHOP_HOPLIMIT.

8.2.5. Traitement d'une Confirmation d'Adresse Dupliquée

Lorsqu'un 6LR implémentant la DAD à sauts multiples reçoit un message DAC, alors il valide d'abord le message selon la Section 8.2.1. Pour un DAC valide, s'il n'y a pas de NCE Tentative correspondant à l'Adresse Enregistrée et à l'EUI-64, alors le DAC est silencieusement ignoré. Sinon, les informations dans le DAC et dans la NCE Tentative sont utilisées pour former un NA à envoyer à l'hôte. Le code de Statut est copié du DAC vers l'ARO qui est envoyée à l'hôte. Dans le cas où le DAC indique une erreur (le Statut est non nul), le NA est retourné à l'hôte comme décrit à la Section 6.5.2, et la NCE Tentative pour l'Adresse Enregistrée est supprimée. Sinon, elle est transformée en une NCE Enregistrée.

Un routeur NE DOIT PAS modifier le Cache des Voisins suite à la réception d'un DAC, à moins qu'il n'y ait une NCE Tentative correspondant à l'adresse IPv6 et à l'EUI-64.

8.2.6. Récupération après Pannes

S'il n'y a pas de réponse d'un 6LBR après RETRANS_TIMER [RFC4861], alors le 6LR retransmettrait le DAR au 6LBR jusqu'à MAX_UNICAST_SOLICIT [RFC4861] fois. Après cela, le 6LR DEVRAIT répondre à l'hôte avec un Statut ARO de zéro.