5. Comportement de l’hôte (Host Behavior)

Les hôtes dans un LoWPAN utilisent l’ARO dans les messages NS qu’ils envoient comme moyen de maintenir le Neighbor Cache dans les routeurs, supprimant ainsi le besoin de NS multicast pour effectuer la résolution d’adresse. Contrairement à [RFC4861], les hôtes initient la mise à jour des informations qu’ils reçoivent dans les RA en envoyant des RS avant l’expiration de ces informations. Enfin, lorsque la NUD indique qu’un ou tous les routeurs par défaut sont devenus injoignables, l’hôte utilise des RS pour trouver un nouvel ensemble de routeurs par défaut.

5.1. Actions interdites (Forbidden Actions)

Un hôte MUST NOT envoyer un message NS en multicast.

5.2. Initialisation de l’interface (Interface Initialization)

Lorsque l’interface sur un hôte est initialisée, elle suit la spécification de [RFC4861]. Une adresse link-local est formée sur la base de l’identifiant EUI-64 [EUI64] assigné à l’interface selon [RFC4944] ou le document IP-over-foo approprié pour le lien, puis l’hôte envoie des messages RS comme décrit dans [RFC4861], Section 6.3.7.

Il n’est pas nécessaire de rejoindre l’adresse multicast solicited-node, puisque personne ne multicast de NS dans ce type de réseau. Un hôte MUST rejoindre l’adresse multicast all-nodes.

5.3. Envoi d’un Router Solicitation (Sending a Router Solicitation)

Le RS est formaté comme spécifié dans [RFC4861] et envoyé à l’adresse multicast IPv6 all-routers (voir [RFC4861], Section 6.3.7 pour les détails). Un SLLAO MUST être inclus pour permettre des RA en unicast en réponse. Une adresse source unspecified MUST NOT être utilisée dans les messages RS.

Si la couche lien supporte un moyen d’envoyer des paquets vers une sorte d’adresse anycast de couche lien all-routers, alors cela MAY être utilisé pour acheminer ces paquets vers un routeur.

Puisque les hôtes ne dépendent pas des RA multicast pour découvrir les routeurs, les hôtes doivent retransmettre intelligemment des RS chaque fois que la liste des routeurs par défaut est vide, qu’un de ses routeurs par défaut devient injoignable, ou que la durée de vie des préfixes et des contextes dans le RA précédent est sur le point d’expirer. Le taux de retransmissions RECOMMENDED consiste à envoyer initialement jusqu’à 3 (MAX_RTR_SOLICITATIONS) messages RS séparés par au moins 10 secondes (RTR_SOLICITATION_INTERVAL) comme spécifié dans [RFC4861], puis à passer à des retransmissions plus lentes. Après les retransmissions initiales, l’hôte SHOULD effectuer un backoff exponentiel binaire tronqué (truncated binary exponential backoff) [ETHERNET] du temporisateur de retransmission pour chaque retransmission suivante, en tronquant l’augmentation du temporisateur de retransmission à 60 secondes (MAX_RTR_SOLICITATION_INTERVAL). Dans tous les cas, les retransmissions de RS sont terminées lorsqu’un RA est reçu. Voir la Section 9 pour les constantes de protocole.

5.4. Traitement d’un Router Advertisement (Processing a Router Advertisement)

Le traitement des RA est comme dans [RFC4861], avec l’ajout du traitement de la 6CO et du déclenchement de l’enregistrement d’adresse lorsqu’une nouvelle adresse a été configurée. En outre, le SLLAO MUST être inclus dans le RA. Contrairement à [RFC4861], la valeur maximale du champ Router Lifetime du RA MAY aller jusqu’à 0xFFFF (environ 18 heures).

Si l’hôte reçoit par erreur un PIO avec le drapeau L (on-link) positionné, alors ce PIO MUST être ignoré.

5.4.1. Address Configuration (Configuration d’adresse)

La configuration d’adresse suit [RFC4862]. Pour une adresse non dérivée d’un EUI-64, le drapeau M du RA détermine comment l’adresse peut être configurée. Si le drapeau M est positionné dans le RA, alors DHCPv6 MUST être utilisé pour attribuer l’adresse. Si le drapeau M n’est pas positionné, alors l’adresse peut être configurée par tout autre moyen (et la détection de doublon est effectuée dans le cadre du processus d’enregistrement).

Une fois qu’une adresse a été configurée, elle sera enregistrée en envoyant en unicast un NS avec une ARO vers un ou plusieurs routeurs.

5.4.2. Storing Contexts (Stockage des contextes)

L’hôte maintient une structure de données conceptuelle pour les informations de contexte qu’il reçoit des routeurs. Cette structure est appelée la table de contexte (context table). Elle inclut le CID, le préfixe (depuis le champ Context Prefix dans la 6CO), le bit Compression, et le Valid Lifetime. Une entrée de table de contexte dont le bit Compression est à zéro est utilisée pour la décompression lors de la réception de paquets mais MUST NOT être utilisée pour la compression lors de l’envoi de paquets.

Lorsqu’une 6CO est reçue dans un RA, elle est utilisée pour ajouter ou mettre à jour l’information dans la table de contexte. Si le champ CID dans la 6CO correspond à une entrée existante de la table de contexte, alors cette entrée est mise à jour avec l’information de la 6CO. Si le champ Valid Lifetime dans la 6CO est à zéro, alors l’entrée est supprimée immédiatement.

S’il n’y a pas d’entrée correspondante dans la table de contexte et si le champ Valid Lifetime est non nul, alors un nouveau contexte est ajouté à la table de contexte. La 6CO est utilisée pour mettre à jour l’entrée créée.

Lorsque le 6LBR change l’information de contexte, un hôte peut ne pas le remarquer immédiatement. Et dans le pire cas, un hôte peut avoir une information de contexte obsolète. Pour cette raison, les 6LBR utilisent les recommandations de la Section 7.2 pour gérer soigneusement le cycle de vie du contexte. Les nœuds devraient faire attention à l’utilisation de la compression d’en-têtes dans les messages RA qui incluent des 6CO.

5.4.3. Maintaining Prefix and Context Information (Maintien des informations de préfixe et de contexte)

Les informations de préfixe expirent comme spécifié dans [RFC4861]. Lorsque le Valid Lifetime pour une entrée de table de contexte expire, l’entrée est placée en mode réception seule (receive-only), ce qui est l’équivalent de recevoir une 6CO pour ce contexte avec C=0. L’entrée est conservée en mode réception seule pendant une période égale à deux fois le Router Lifetime par défaut, après quoi l’entrée est supprimée.

Un hôte devrait examiner les différentes durées de vie afin de déterminer quand il devrait ensuite initier l’envoi d’un RS pour demander des mises à jour d’information. Les durées de vie pertinentes sont le Router Lifetime par défaut, le Valid Lifetime dans les PIO, et le Valid Lifetime dans la 6CO. L’hôte SHOULD envoyer en unicast un ou plusieurs RS au routeur bien avant l’expiration de la plus courte de ces durées de vie (sur l’ensemble des préfixes et des contextes), puis passer à des messages RS multicast s’il n’y a pas de réponse aux unicast. Le comportement de retransmission des RS est spécifié dans la Section 5.3.

5.5. Enregistrement et Neighbor Unreachability Detection (Registration and Neighbor Unreachability Detection)

Les hôtes envoient des messages NS en unicast pour enregistrer leurs adresses IPv6, et aussi pour effectuer la NUD afin de vérifier que leurs routeurs par défaut sont encore joignables. L’enregistrement est effectué par l’hôte en incluant une ARO dans le NS qu’il envoie. Même si l’hôte n’a pas de données à envoyer, mais s’attend à ce que d’autres tentent d’envoyer des paquets vers l’hôte, l’hôte doit maintenir ses NCE dans les routeurs. Cela est fait en envoyant des messages NS avec une ARO au routeur bien avant l’expiration du Registration Lifetime. Les messages NS sont retransmis jusqu’à MAX_UNICAST_SOLICIT fois en utilisant un délai minimal de RETRANS_TIMER jusqu’à ce que l’hôte reçoive un message NA avec une ARO.

Les hôtes qui reçoivent des messages RA de plusieurs routeurs par défaut SHOULD tenter de s’enregistrer auprès de plus d’un d’entre eux afin d’augmenter la robustesse du réseau.

Noter que les sondes NUD peuvent être supprimées par des confirmations de joignabilité provenant de protocoles de transport ou d’applications comme spécifié dans [RFC4861].

Lorsqu’un hôte sait qu’il n’utilisera plus un routeur auprès duquel il est enregistré, il SHOULD se désenregistrer auprès du routeur en envoyant un NS avec une ARO contenant une durée de vie de 0. Pour gérer le cas où un hôte perd involontairement la connectivité avec le routeur par défaut, l’hôte SHOULD utiliser un Registration Lifetime suffisamment faible.

5.5.1. Sending a Neighbor Solicitation (Envoi d’un Neighbor Solicitation)

L’hôte déclenche l’envoi de messages NS contenant une ARO lorsqu’une nouvelle adresse est configurée, lorsqu’il découvre un nouveau routeur par défaut, ou bien avant l’expiration du Registration Lifetime. Un tel NS MUST inclure un SLLAO, puisque le routeur doit enregistrer l’adresse de couche lien de l’hôte. Une adresse source unspecified MUST NOT être utilisée dans les messages NS.

5.5.2. Processing a Neighbor Advertisement (Traitement d’un Neighbor Advertisement)

Un hôte traite les messages NA comme spécifié dans [RFC4861], avec une logique additionnelle décrite dans cette section pour le traitement de l’ARO.

En plus de la validation normale d’un NA et de ses options, l’ARO (si présente) est vérifiée comme suit. Si le champ Length n’est pas égal à deux, l’option est ignorée silencieusement. Si le champ EUI-64 ne correspond pas à l’EUI-64 de l’interface, l’option est ignorée silencieusement.

Si le champ Status est zéro, alors l’enregistrement d’adresse a réussi. L’hôte sauvegarde le Registration Lifetime de l’ARO pour l’utiliser afin de déclencher un nouveau NS bien avant l’expiration de la durée de vie. Si le champ Status n’est pas égal à zéro, l’enregistrement d’adresse a échoué.

5.5.3. Recovering from Failures (Récupération après échecs)

La procédure pour maintenir l’information de joignabilité à propos d’un voisin est la même que dans [RFC4861], Section 7.3, à l’exception que la résolution d’adresse n’est pas effectuée.

La procédure d’enregistrement d’adresse peut échouer pour deux raisons : aucune réponse aux NS n’est reçue (échec NUD), ou une ARO avec un Status d’échec (Status > 0) est reçue. En cas d’échec NUD, l’entrée pour ce routeur sera supprimée ; ainsi, l’enregistrement d’adresse n’a plus d’importance. Lorsqu’une ARO avec un champ Status non nul est reçue, cela indique que l’enregistrement pour cette adresse a échoué. Un Status d’échec de un indique qu’une adresse dupliquée a été détectée, et la procédure décrite dans [RFC4862], Section 5.4.5 est suivie. L’hôte MUST NOT utiliser l’adresse qu’il a tenté d’enregistrer. Si l’hôte a des enregistrements valides avec d’autres routeurs, ceux-ci MUST être supprimés en s’enregistrant auprès de chacun avec une durée de vie ARO à zéro.

Un code Status de deux indique que le Neighbor Cache de ce routeur est plein. Dans ce cas, l’hôte SHOULD retirer ce routeur de sa liste de routeurs par défaut et tenter de s’enregistrer auprès d’un autre routeur. Si la liste de routeurs par défaut de l’hôte est vide, il doit revenir à l’envoi de RS comme spécifié dans la Section 5.3.

D’autres codes d’échec peuvent être définis dans de futurs documents.

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

L’adresse IP du prochain saut pour une destination est déterminée comme suit. Les destinations vers le préfixe link-local (fe80::) sont toujours envoyées sur le lien vers cette destination. Il est supposé que les adresses link-local sont formées comme spécifié dans la Section 5.2 à partir de l’EUI-64, et que la résolution d’adresse n’est pas effectuée. Les paquets sont envoyés vers des destinations link-local en inversant la procédure de l’Appendix A de [RFC4291].

Les adresses multicast sont considérées comme on-link et sont résolues comme spécifié dans [RFC4944] ou dans le document IP-over-foo approprié. Noter que [RFC4944] ne définit que la manière de représenter une adresse de destination multicast dans l’en-tête LoWPAN. Le support de portées multicast plus larges que link-local nécessite un algorithme de routage multicast approprié.

Tous les autres préfixes sont supposés être off-link [RFC5889]. Les adresses anycast sont toujours considérées comme off-link. Elles sont donc envoyées à l’un des routeurs dans la liste de routeurs par défaut.

Un nœud LoWPAN n’a pas besoin de maintenir un minimum d’un tampon par voisin comme spécifié dans [RFC4861], puisque les paquets ne sont jamais mis en file d’attente en attendant la résolution d’adresse.

5.7. Résolution d’adresse (Address Resolution)

Le mécanisme d’enregistrement d’adresse et le SLLAO dans les messages RA fournissent un état préalable suffisant dans les routeurs et les hôtes pour résoudre une adresse IPv6 en son adresse de couche lien associée. Comme tous les préfixes sauf le préfixe link-local et les adresses multicast sont toujours supposés être off-link, la résolution d’adresse entre voisins basée sur multicast n’est pas nécessaire.

Les adresses de couche lien des voisins sont stockées dans des NCE [RFC4861]. Afin d’obtenir la compression LoWPAN, la plupart des adresses globales sont formées en utilisant une adresse de couche lien. Ainsi, un hôte peut réduire l’utilisation mémoire en optimisant ce cas et en ne stockant l’information d’adresse de couche lien que si elle diffère de l’adresse de couche lien correspondant à l’Interface ID de l’adresse IPv6 (c’est-à-dire diffère en plus que l’inversion du bit on-link/global).

5.8. Sleeping (Sommeil)

Il est souvent avantageux pour des hôtes alimentés par batterie dans des LoWPAN de maintenir un faible duty cycle. Les optimisations décrites dans ce document permettent aux hôtes de dormir, comme décrit plus loin dans cette section. Les routeurs peuvent vouloir mettre en cache le trafic destiné à un hôte qui dort, mais une telle fonctionnalité est hors du périmètre de ce document.

5.8.1. Picking an Appropriate Registration Lifetime (Choisir un Registration Lifetime approprié)

Comme tous les messages ND sont initiés par les hôtes, cela permet à un hôte de dormir ou d’être autrement injoignable entre les échanges de messages NS/NA. L’ARO attachée aux messages NS indique à un routeur de garder la NCE pour cette adresse valide pendant la période du champ Registration Lifetime. Un hôte devrait choisir un temps de sommeil approprié à ses caractéristiques énergétiques et fixer un Registration Lifetime supérieur au temps de sommeil pour s’assurer que l’enregistrement est renouvelé avec succès (en considérant, par exemple, la dérive d’horloge et le temps supplémentaire pour de potentielles retransmissions du réenregistrement). La configuration externe d’un hôte devrait aussi considérer la stabilité du réseau (à quelle vitesse la topologie change) lors du choix de son temps de sommeil (et donc du Registration Lifetime). Un réseau dynamique requiert un temps de sommeil plus court afin que les routeurs ne gardent pas des NCE invalides pour des nœuds plus longtemps que nécessaire.

5.8.2. Behavior on Wakeup (Comportement au réveil)

Lorsqu’un hôte se réveille d’une période de sommeil, il SHOULD rafraîchir ses enregistrements d’adresse actuels qui expireront avant le prochain réveil. Cela se fait en envoyant des messages NS avec une ARO comme décrit dans la Section 5.5.1. L’hôte peut aussi avoir besoin de rafraîchir ses informations de préfixe et de contexte en envoyant un nouveau RS en unicast (le Router Lifetime maximal est d’environ 18 heures, tandis que le Registration Lifetime maximal est d’environ 45,5 jours). Si après le réveil l’hôte (en utilisant la NUD) détermine que certains ou tous les routeurs par défaut précédents sont devenus injoignables, alors l’hôte enverra des RS en multicast pour découvrir de nouveaux routeur(s) par défaut et redémarrer le processus d’enregistrement d’adresse.