7. Comportement du Routeur de Bordure
Un 6LBR gère l'envoi de RA et le traitement des NS provenant des hôtes comme spécifié ci-dessus à la Section 6. Un 6LBR DEVRAIT toujours inclure une ABRO dans les RA qu'il envoie, s'inscrivant lui-même comme l'adresse du 6LBR. Cela nécessite que le 6LBR maintienne le numéro de version dans un stockage stable et augmente le numéro de version lorsque certaines informations dans ses RA changent. Les informations dont le changement affecte la version se trouvent dans les PIO (les préfixes ou leurs durées de vie) et dans les 6CO (les préfixes, les CID ou les durées de vie).
De plus, un 6LBR est configuré d'une manière ou d'une autre avec le préfixe ou les préfixes qui sont attribués au LoWPAN et annonce ceux-ci dans les RA comme dans [RFC4861]. Dans le cas du route-over, ces préfixes peuvent être diffusés à tous les 6LR en utilisant la technique discutée à la Section 8.1. Cependant, il pourrait y avoir des mécanismes hors de la portée de ce document qui peuvent être utilisés comme substitut à la diffusion des préfixes dans la topologie route-over (voir Section 1.4).
Si le 6LoWPAN utilise la compression d'en-tête [RFC6282] avec contexte, alors le 6LBR doit gérer les CID et les annoncer dans les RA en incluant des 6CO dans ses RA afin que les hôtes directement attachés soient informés des CID. Ci-dessous, nous spécifions les éléments à prendre en compte lorsque le 6LBR doit ajouter, supprimer ou modifier les informations de contexte. Dans le cas du route-over, les informations de contexte sont diffusées à tous les 6LR en utilisant la technique discutée à la Section 8, à moins qu'une spécification différente ne fournisse un substitut à cette distribution à sauts multiples.
7.1. Détermination du Préfixe
Le préfixe ou les préfixes utilisés dans un LoWPAN peuvent être configurés manuellement ou peuvent être acquis en utilisant la Délégation de Préfixe DHCPv6 [RFC3633]. Pour un LoWPAN qui est isolé du réseau soit de manière permanente soit occasionnellement, le 6LBR peut attribuer un préfixe ULA en utilisant [RFC4193]. Le préfixe ULA doit être stocké dans un stockage stable afin que le même préfixe soit utilisé après une panne du 6LBR. Si le LoWPAN a plusieurs 6LBR, alors ils doivent être configurés avec le même ensemble de préfixes. L'ensemble des préfixes est inclus dans les messages RA comme spécifié dans [RFC4861].
7.2. Configuration et Gestion du Contexte
Si le 6LoWPAN utilise la compression d'en-tête [RFC6282] avec contexte, alors le 6LBR doit être configuré avec les informations de contexte et les CID associés. Si le LoWPAN a plusieurs 6LBR, alors ils DOIVENT être configurés avec les mêmes informations de contexte et CID. Comme indiqué dans [RFC6282], le maintien de la cohérence des informations de contexte est crucial pour garantir que les paquets seront décompressés correctement.
Les informations de contexte transportées dans les messages RA proviennent des 6LBR et doivent être diffusées à tous les routeurs et hôtes au sein du LoWPAN. Les RA incluent une 6CO pour chaque contexte.
Pour la diffusion des informations de contexte en utilisant la 6CO, un cycle de vie strict DEVRAIT être utilisé afin de garantir que les informations de contexte restent synchronisées dans tout le LoWPAN. Les nouvelles informations de contexte DEVRAIENT être introduites dans le LoWPAN avec C=0, pour s'assurer qu'elles sont connues de tous les nœuds qui peuvent avoir à effectuer une décompression d'en-tête basée sur ces informations de contexte. Ce n'est que lorsqu'il est raisonnable de supposer que ces informations ont été diffusées avec succès qu'une option avec C=1 DEVRAIT être envoyée, permettant l'utilisation réelle des informations de contexte pour la compression.
Inversement, pour éviter la situation où les nœuds envoient des paquets qui utilisent des valeurs précédentes de contextes -- ce qui entraînerait une ambiguïté lors de la réception d'un paquet qui utilise un contexte récemment modifié -- les anciennes valeurs d'un contexte DEVRAIENT être mises hors service pendant un certain temps avant que de nouvelles valeurs ne soient attribuées à ce contexte spécifique. C'est-à-dire, en préparation d'un changement d'informations de contexte, sa diffusion DEVRAIT continuer pendant au moins MIN_CONTEXT_CHANGE_DELAY avec C=0. Ce n'est que lorsqu'il est raisonnable de supposer que le fait que le contexte est maintenant invalide a été diffusé avec succès que le CID devrait être retiré de la diffusion ou réutilisé avec un champ Préfixe de Contexte différent. Dans ce dernier cas, la diffusion de la nouvelle valeur DEVRAIT à nouveau commencer avec C=0, comme ci-dessus.