3. Aperçu du protocole (Protocol Overview)

Ces optimisations de Neighbor Discovery sont applicables aux configurations mesh-under et route-over. Dans une configuration mesh-under, seuls des 6LoWPAN Border Routers et des hôtes existent ; il n’y a pas de routeurs 6LoWPAN dans les topologies mesh-under.

La partie la plus importante des optimisations est l’interaction hôte-routeur évoluée qui permet des nœuds en sommeil et évite l’utilisation de messages Neighbor Discovery en multicast, sauf lorsqu’un hôte trouve un ensemble initial de routeurs par défaut, et lorsqu’il recommence cette détermination lorsque cet ensemble de routeurs est devenu injoignable.

Le protocole fournit aussi la compression d’en-têtes [RFC6282] en transportant des informations de compression d’en-têtes dans une nouvelle option des messages Router Advertisement.

En outre, il existe des mécanismes distincts pouvant être utilisés entre 6LR et 6LBR pour effectuer une Duplicate Address Detection multi-sauts et pour distribuer les informations de préfixe et de contexte de compression depuis les 6LBR vers tous les 6LR, lesquels utilisent ensuite des mécanismes Neighbor Discovery normaux pour transmettre ces informations aux hôtes.

Le protocole est conçu de sorte que l’interaction hôte-routeur ne soit pas affectée par la configuration du 6LoWPAN ; l’interaction hôte-routeur est la même en configuration mesh-under et route-over.

3.1. Extensions à RFC 4861 (Extensions to RFC 4861)

Le présent document spécifie les optimisations et extensions suivantes à IPv6 Neighbor Discovery [RFC4861] :

Rafraîchissement initié par l’hôte des informations de Router Advertisement. Cela supprime le besoin d’annonces de routeur périodiques ou non sollicitées des routeurs vers les hôtes.
Aucune Duplicate Address Detection (DAD) n’est effectuée si des adresses IPv6 basées sur EUI-64 sont utilisées (ces adresses étant supposées globalement uniques).
La DAD est optionnelle si DHCPv6 est utilisé pour attribuer des adresses.
Un nouveau mécanisme d’enregistrement d’adresse utilisant une nouvelle Address Registration Option entre hôtes et routeurs. Cela supprime le besoin pour les routeurs d’utiliser des Neighbor Solicitations en multicast pour trouver les hôtes et prend en charge les hôtes en sommeil. Cela permet aussi d’utiliser le(s) même(s) préfixe(s) d’adresses IPv6 sur un 6LoWPAN route-over. Il fournit l’interface hôte-routeur pour la Duplicate Address Detection.
Une nouvelle option de Router Advertisement, la 6LoWPAN Context Option, pour les informations de contexte utilisées par 6LoWPAN header compression.
Un nouveau mécanisme pour effectuer la Duplicate Address Detection sur un 6LoWPAN route-over en utilisant les nouveaux messages Duplicate Address Request et Duplicate Address Confirmation.
De nouveaux mécanismes pour distribuer les préfixes et les informations de contexte sur un réseau route-over qui utilisent une nouvelle Authoritative Border Router Option pour contrôler le flooding des changements de configuration.
Quelques nouvelles constantes de protocole par défaut sont introduites, et certaines constantes de protocole Neighbor Discovery existantes sont ajustées.

3.2. Attribution d’adresses (Address Assignment)

Les hôtes dans un 6LoWPAN configurent leurs adresses IPv6 comme spécifié dans [RFC4861] et [RFC4862] sur la base des informations reçues dans les messages Router Advertisement. L’utilisation du drapeau M (managed address configuration) dans cette optimisation est toutefois plus restrictive que dans [RFC4861]. Lorsque le drapeau M est positionné, on suppose qu’un hôte utilise DHCPv6 pour attribuer toute adresse non EUI-64. Lorsque le drapeau M n’est pas positionné, les nœuds du LoWPAN prennent en charge la Duplicate Address Detection ; ainsi, un hôte peut alors utiliser en toute sécurité le mécanisme d’enregistrement d’adresse pour vérifier l’unicité des adresses non EUI-64.

Les 6LR MAY utiliser les mêmes mécanismes pour configurer leurs adresses IPv6.

Les 6LBR sont responsables de la gestion du/des préfixe(s) attribué(s) au 6LoWPAN, en utilisant une configuration manuelle, DHCPv6 Prefix Delegation [RFC3633], ou d’autres mécanismes. Dans un LoWPAN isolé, un préfixe Unique Local Address (ULA) [RFC4193] SHOULD être généré par le 6LBR.

3.3. Interaction hôte-routeur (Host-to-Router Interaction)

Un hôte envoie des messages Router Solicitation au démarrage et aussi lorsque la Neighbor Unreachability Detection (NUD) de l’un de ses routeurs par défaut échoue.

Les hôtes reçoivent des messages Router Advertisement contenant typiquement l’Authoritative Border Router Option (ABRO) et pouvant éventuellement contenir une ou plusieurs 6LoWPAN Context Options (6COs) en plus des Prefix Information Options (PIOs) existantes comme décrit dans [RFC4861].

Lorsqu’un hôte a configuré une adresse IPv6 non link-local, il enregistre cette adresse auprès d’un ou plusieurs de ses routeurs par défaut en utilisant l’Address Registration Option (ARO) dans un message NS. L’hôte choisit une durée de vie de l’enregistrement et répète l’ARO périodiquement (avant l’expiration de la durée de vie) pour maintenir l’enregistrement. La durée de vie doit être choisie de manière à maintenir l’enregistrement même lorsque l’hôte est en sommeil. De même, les nœuds mobiles qui changent souvent de point d’attachement devraient utiliser une durée de vie adéquatement courte. Voir la Section 5.5 pour les détails d’enregistrement et la Section 9 pour les constantes de protocole.

L’enregistrement échoue lorsqu’un ARO est renvoyé à l’hôte avec un Status non nul. Une raison peut être que le routeur détermine que l’adresse IPv6 est déjà utilisée par un autre hôte, c’est-à-dire utilisée par un hôte avec un EUI-64 différent. Cela peut être utilisé pour prendre en charge des adresses non basées sur EUI-64, telles que des adresses IPv6 temporaires [RFC4941] ou des adresses basées sur un Interface ID qui est une adresse courte IEEE 802.15.4 16 bits. L’échec peut aussi se produire si la Neighbor Cache de ce routeur est pleine.

Le ré-enregistrement d’une adresse peut être combiné avec la Neighbor Unreachability Detection (NUD) du routeur, puisque les deux utilisent des messages Neighbor Solicitation en unicast. Cela rend les choses efficaces lorsqu’un hôte se réveille pour envoyer un paquet et doit à la fois effectuer la NUD pour vérifier que le routeur est toujours joignable et rafraîchir son enregistrement auprès du routeur.

La réponse à un enregistrement d’adresse peut ne pas être immédiate, puisque dans les configurations route-over le 6LR peut effectuer une Duplicate Address Detection contre le 6LBR. Un hôte retransmet l’Address Registration Option jusqu’à ce qu’elle soit acquittée par la réception d’une Address Registration Option.

Dans le cadre des optimisations, la résolution d’adresse n’est pas effectuée en diffusant des messages Neighbor Solicitation en multicast comme dans [RFC4861]. À la place, les routeurs maintiennent des Neighbor Cache Entries pour toutes les adresses IPv6 enregistrées. Si l’adresse n’est pas dans la Neighbor Cache du routeur, alors l’adresse n’existe pas, est attribuée à un hôte attaché à un autre routeur dans le 6LoWPAN, ou est externe au 6LoWPAN. Dans une configuration route-over, le protocole de routage est utilisé pour router de tels paquets vers la destination.

3.4. Interaction routeur-routeur (Router-to-Router Interaction)

La nouvelle interaction routeur-routeur n’est prévue que pour la configuration route-over où des 6LR sont présents. Voir aussi la Section 1.4.

Les 6LR MUST se comporter comme un hôte lors du démarrage du système et de la configuration des préfixes en envoyant des messages Router Solicitation et en autoconfigurant leurs adresses IPv6, contrairement aux routeurs dans [RFC4861].

Lorsque la diffusion multi-sauts des préfixes et du contexte est utilisée, les 6LR stockent l’ABRO, les 6CO et les informations de préfixe reçues (directement ou indirectement) des 6LBR et redistribuent ces informations dans le Router Advertisement qu’ils envoient à d’autres 6LR ou qu’ils envoient aux hôtes en réponse à un Router Solicitation. Il y a un champ Version Number dans l’ABRO (voir la Section 4.3), qui est utilisé pour limiter le flooding des informations mises à jour entre les 6LR.

Un 6LR peut effectuer une Duplicate Address Detection contre un ou plusieurs 6LBR en utilisant les nouveaux messages Duplicate Address Request (DAR) et Duplicate Address Confirmation (DAC), qui transportent l’information de l’Address Registration Option. Les messages DAR et DAC seront relayés entre le 6LR et les 6LBR ; ainsi, la règle [RFC4861] de vérification hop limit=255 ne s’applique pas aux messages DAR et DAC. Ces messages DAD multi-sauts MUST NOT modifier des Neighbor Cache Entries sur les routeurs, puisque nous ne disposons pas des bénéfices de sécurité fournis par la vérification hop limit=255.

3.5. Gestion de la Neighbor Cache (Neighbor Cache Management)

L’utilisation d’enregistrements explicites avec des durées de vie, ainsi que le souhait de ne pas diffuser en multicast des messages Neighbor Solicitation pour les hôtes, implique que nous gérions les Neighbor Cache Entries (NCEs) légèrement différemment de [RFC4861]. Cela aboutit à trois types différents de NCE, et les types spécifient comment ces entrées peuvent être supprimées :

Garbage-collectible (collectable par nettoyage) : Entrées soumises aux règles normales de [RFC4861] qui autorisent un nettoyage lorsqu’on manque de mémoire.
Registered (enregistré) : Entrées ayant une durée de vie explicitement enregistrée et conservées jusqu’à l’expiration de cette durée de vie ou jusqu’à désenregistrement explicite.
Tentative (provisoire) : Entrées temporaires avec une courte durée de vie, qui sont typiquement converties en entrées Registered.

Noter que le type du NCE est orthogonal aux états spécifiés dans [RFC4861].

Lorsqu’un hôte interagit avec un routeur en envoyant des Router Solicitations, cela aboutit à un NCE Tentative. Une fois qu’un routeur a réussi à faire enregistrer un nœud auprès de lui, le résultat est un NCE Registered. Lorsque les routeurs envoient des RA aux hôtes, et lorsque les routeurs reçoivent des messages RA ou reçoivent des messages NS en multicast d’autres routeurs, le résultat est des NCE Garbage-collectible. Il ne peut y avoir qu’un seul type de NCE à la fois pour une adresse IP.

Les Neighbor Cache Entries sur les routeurs peuvent en outre être ajoutées ou supprimées par un protocole de routage utilisé dans le 6LoWPAN. Cela est utile si le protocole de routage transporte les adresses de couche lien des routeurs voisins. Selon les détails de ces protocoles de routage, de tels NCE pourraient être soit Registered soit Garbage-collectible.