1. Introduction (Introduction)

Le document "IPv6-over-IEEE 802.15.4" [RFC4944] spécifie comment IPv6 est transporté sur un réseau IEEE 802.15.4 à l’aide d’une couche d’adaptation située entre la couche Media Access Control (MAC) et la couche réseau IP. Un lien dans un Low-power Wireless Personal Area Network (LoWPAN) est caractérisé comme étant à pertes, basse consommation, faible débit binaire, courte portée ; avec de nombreux nœuds économisant l’énergie grâce à de longues périodes de sommeil. Le multicast tel qu’utilisé dans IPv6 Neighbor Discovery (ND) [RFC4861] n’est pas souhaitable dans un tel réseau sans fil basse consommation et à pertes. De plus, les liens LoWPAN sont asymétriques et non transitifs par nature. Un LoWPAN est potentiellement composé d’un grand nombre de portées radio qui se chevauchent. Bien qu’une portée radio donnée dispose de capacités de diffusion (broadcast), l’agrégation de ces portées forme une structure complexe de type Non-Broadcast Multiple Access (NBMA) [RFC2491] qui ne dispose généralement pas de capacités multicast à l’échelle du LoWPAN. La portée link-local est, en réalité, définie par l’atteignabilité et la puissance radio. Ainsi, nous pouvons considérer un LoWPAN comme composé de liens ayant des propriétés de connectivité indéterminées (undetermined connectivity properties) comme dans [RFC5889], avec les hypothèses correspondantes de modèle d’adressage définies dans ce document.

La présente spécification introduit les optimisations suivantes à IPv6 Neighbor Discovery [RFC4861], spécifiquement destinées aux réseaux basse consommation et à pertes tels que les LoWPAN :

Interactions initiées par l’hôte pour permettre des hôtes en sommeil.
Élimination de la résolution d’adresse basée sur le multicast pour les hôtes.
Fonction d’enregistrement d’adresse de l’hôte utilisant une nouvelle option dans les messages Neighbor Solicitation (NS) et Neighbor Advertisement (NA) en unicast.
Une nouvelle option Neighbor Discovery pour distribuer le contexte de compression d’en-têtes 6LoWPAN aux hôtes.
Distribution multi-sauts des préfixes et du contexte de compression d’en-têtes 6LoWPAN.
Duplicate Address Detection (DAD) multi-sauts, qui utilise deux nouveaux types de messages ICMPv6.

Les deux éléments multi-sauts peuvent être substitués par un mécanisme de protocole de routage si cela est souhaité ; voir la Section 1.4.

Le document définit trois nouvelles options de message ICMPv6 : l’Address Registration Option (ARO), l’Authoritative Border Router Option (ABRO) et la 6LoWPAN Context Option (6CO). Il définit également deux nouveaux types de messages ICMPv6 : la Duplicate Address Request (DAR) et la Duplicate Address Confirmation (DAC).

1.1. Les limites de IPv6 Neighbor Discovery (The Shortcomings of IPv6 Neighbor Discovery)

IPv6 Neighbor Discovery [RFC4861] fournit plusieurs mécanismes importants utilisés pour la découverte de routeurs, la résolution d’adresse, la Duplicate Address Detection et les messages Redirect, ainsi que la découverte de préfixes et de paramètres.

Après la mise sous tension et l’initialisation du réseau dans des réseaux IPv6 Ethernet, un nœud rejoint l’adresse multicast solicited-node sur l’interface puis effectue la Duplicate Address Detection (DAD) pour l’adresse link-local acquise en envoyant un message multicast solicited-node sur le lien. Après cela, il envoie des messages multicast à l’adresse multicast all-routers pour solliciter des Router Advertisements (RAs). Si l’hôte reçoit un RA valide avec le drapeau A (autonomous address configuration), il autoconfigure l’adresse IPv6 avec le préfixe annoncé dans le message RA. En outre, les routeurs IPv6 envoient généralement des RAs périodiquement sur le réseau. Les RAs sont envoyés à l’adresse multicast all-nodes. Les nœuds envoient des messages Neighbor Solicitation/Neighbor Advertisement pour résoudre l’adresse IPv6 de la destination sur le lien. Les messages Neighbor Solicitation utilisés pour la résolution d’adresse sont en multicast. La procédure de Duplicate Address Detection et l’utilisation de messages Router Advertisement périodiques supposent que les nœuds sont sous tension et atteignables la plupart du temps.

Dans Neighbor Discovery, les routeurs trouvent les hôtes en supposant qu’un préfixe de sous-réseau correspond à un domaine de diffusion, puis ils diffusent en multicast des messages Neighbor Solicitation pour trouver l’hôte et son adresse de couche lien. En outre, l’utilisation du multicast pour la DAD suppose que tous les hôtes qui autoconfigurent des adresses IPv6 à partir du même préfixe peuvent être atteints à l’aide de messages multicast link-local.

Noter que le bit L (on-link) dans la Prefix Information Option (PIO) peut être mis à zéro dans Neighbor Discovery, ce qui fait que l’hôte n’utilise pas de messages multicast Neighbor Solicitation (NS) pour la résolution d’adresse d’autres hôtes, mais les routeurs utilisent toujours des messages multicast NS pour trouver les hôtes.

En raison de la nature à pertes des communications sans fil et d’un environnement radio changeant, l’ensemble des nœuds d’un lien IPv6 peut changer en raison de facteurs physiques externes. Ainsi, le lien est souvent instable, et les nœuds semblent se déplacer sans nécessairement se déplacer physiquement.

Un LoWPAN peut utiliser deux types d’adresses de couche lien : des adresses courtes 16 bits et des adresses uniques 64 bits telles que définies dans [RFC4944]. De plus, la taille de charge utile disponible au niveau lien est de l’ordre de moins de 100 octets ; ainsi, la compression d’en-têtes est très utile.

Compte tenu des caractéristiques ci-dessus d’un LoWPAN, et de la conception du protocole IPv6 Neighbor Discovery [RFC4861], certaines optimisations et extensions à Neighbor Discovery sont utiles pour le déploiement à grande échelle de IPv6 sur des réseaux basse consommation et à pertes (exemple : 6LoWPAN et autres réseaux basse consommation homogènes).

1.2. Applicabilité (Applicability)

Dans sa Section 1, [RFC4861] prévoit un document qui couvre l’exploitation d’IP sur un type de lien particulier et définit une exception à l’applicabilité générale de [RFC4861] non modifié. La présente spécification améliore l’usage de IPv6 Neighbor Discovery pour les LoWPAN afin d’économiser l’énergie et la puissance de traitement de tels nœuds. Ce document met ainsi à jour [RFC4944] pour spécifier l’utilisation des optimisations définies ici.

L’applicabilité de cette spécification est limitée aux LoWPAN où tous les nœuds du sous-réseau implémentent ces optimisations de manière homogène. Bien que l’on note que certaines de ces optimisations peuvent être utiles en dehors des 6LoWPAN, par exemple dans des réseaux IPv6 basse consommation et à pertes en général, et éventuellement même en combinaison avec [RFC4861], l’usage de telles combinaisons est hors du périmètre de ce document.

Dans ce document, nous spécifions un ensemble de comportements entre hôtes et routeurs dans des LoWPAN. Une implémentation conforme à ce document MUST implémenter ces comportements. Le document spécifie également un ensemble de comportements (diffusion multi-sauts de préfixes ou de contexte et, séparément, Duplicate Address Detection multi-sauts) nécessaires dans des configurations route-over. Une implémentation de cette spécification MUST supporter ces éléments, à moins qu’elle ne supporte une alternative ("substitute") provenant d’une autre spécification.

Les optimisations décrites dans ce document s’appliquent à différentes topologies. Elles sont particulièrement utiles pour les configurations route-over et mesh-under dans des topologies Mesh. Cependant, les configurations en topologie Star bénéficieront également des optimisations en raison de la réduction de la signalisation, de la gestion robuste des liens non transitifs et des informations de contexte de compression d’en-têtes.

1.3. Objectifs et hypothèses (Goals and Assumptions)

Le document a les objectifs et hypothèses principaux suivants.

Objectifs (Goals) :

Optimiser Neighbor Discovery avec un mécanisme minimal mais suffisant pour le fonctionnement dans des configurations mesh-under et route-over.
Minimiser la signalisation en évitant l’inondation multicast et en réduisant l’utilisation de messages multicast à portée lien.
Optimiser les interfaces entre les hôtes et leurs routeurs par défaut.
Fournir la prise en charge des hôtes en sommeil.
Diffuser aux hôtes, selon les besoins, les informations de contexte pour 6LoWPAN header compression [RFC6282].
Diffuser les informations de contexte et de préfixe depuis la frontière vers tous les routeurs dans un LoWPAN.
Fournir un mécanisme de Duplicate Address Detection multi-sauts adapté aux LoWPAN route-over.

Hypothèses (Assumptions) :

Les adresses 64-bit Extended Unique Identifier (EUI-64) [EUI64] sont globalement uniques, et le LoWPAN est homogène.
Tous les nœuds du réseau ont un EUI-64 Interface ID afin d’effectuer l’autoconfiguration d’adresse et de détecter les adresses dupliquées.
La technologie de couche lien est supposée être basse consommation et à pertes, présentant une connectivité indéterminée, telle que IEEE 802.15.4 [RFC4944]. Toutefois, le mécanisme d’enregistrement d’adresse pourrait être utile pour d’autres technologies de couche lien.
Un 6LoWPAN est configuré pour partager un ou plusieurs préfixes d’adresses IPv6 globales afin de permettre aux hôtes de se déplacer entre routeurs dans le LoWPAN sans changer leurs adresses IPv6.
Lors de l’utilisation du mécanisme DAD multi-sauts (Section 8.2), chaque 6LoWPAN Router (6LR) s’enregistre auprès de tous les 6LoWPAN Border Routers (6LBRs) disponibles dans le LoWPAN.
Si des adresses courtes IEEE 802.15.4 16 bits sont utilisées, alors une technique est utilisée pour assurer l’unicité de ces adresses de couche lien. Cela pourrait être fait en utilisant DHCPv6, la Duplicate Address Detection basée sur l’Address Registration Option (spécifiée en Section 8.2), ou d’autres techniques hors du périmètre de ce document.
Afin de préserver l’unicité des adresses (voir Section 5.4 de [RFC4862]) qui ne sont pas dérivées d’un EUI-64, elles doivent être soit attribuées, soit vérifiées pour détecter les doublons de la même manière dans tout le LoWPAN. Cela peut être fait en utilisant DHCPv6 pour l’attribution et/ou en utilisant le mécanisme de Duplicate Address Detection spécifié en Section 8.2 (ou tout autre protocole développé à cette fin).
Pour que 6LoWPAN header compression [RFC6282] fonctionne correctement, le contexte de compression doit correspondre pour tous les hôtes, 6LR et 6LBR qui peuvent envoyer, recevoir ou transférer un paquet donné. Si la Section 8.1 est utilisée pour distribuer les informations de contexte, cela implique que tous les 6LBR doivent coordonner les informations de contexte qu’ils distribuent au sein d’un même LoWPAN.
Cette spécification décrit le fonctionnement de ND au sein d’un seul LoWPAN. La participation d’un nœud à plusieurs LoWPAN simultanément peut être possible, mais est hors du périmètre de ce document.
Puisque le LoWPAN partage son/ses préfixe(s) à travers le réseau, la mobilité des nœuds au sein du LoWPAN est transparente. La mobilité inter-LoWPAN est hors du périmètre de ce document.

1.4. Fonctionnalités substituables (Substitutable Features)

Ce document définit l’optimisation des messages Neighbor Discovery pour l’interface hôte-routeur et introduit deux nouveaux mécanismes dans une topologie route-over.

Sauf spécification contraire (dans un document qui définit un protocole de routage utilisé dans un 6LoWPAN), ce document s’applique à des réseaux utilisant n’importe quel protocole de routage. Cependant, comme le protocole de routage peut fournir de bons mécanismes alternatifs, ce document définit certaines fonctionnalités comme "substitutable", ce qui signifie qu’elles peuvent être substituées par une spécification de protocole de routage qui fournit des mécanismes atteignant le même effet global.

Les fonctionnalités qui sont substituables (individuellement ou en groupe) :

Distribution multi-sauts des préfixes et du contexte de compression d’en-têtes 6LoWPAN
Duplicate Address Detection multi-sauts

Ainsi, la distribution multi-sauts des préfixes (l’ABRO) et la 6LoWPAN Context Option (6CO) pour la distribution des contextes de compression d’en-têtes vont de pair. Si une substitution est prévue pour l’une d’entre elles, alors les deux MUST être substituées.

Des lignes directrices pour l’implémentation et le déploiement des fonctionnalités sont fournies en Section 14.