L’EXPERTISE TECHNIQUE 10 000 ARTICLES

& SCIENTIFIQUE DE RÉFÉRENCE 1 000 FICHES PRATIQUES

EXTRAIT
ISSU DE L’OFFRE

Réseaux Télécommunications

6LoWPAN - IPv6 dans les réseaux personnels

sans fil à faible puissance

par Ana MINABURO, Laurent TOUTAIN

RÉSUMÉ

L'Internet des Objets change la vision que l'on peut avoir des protocoles, notamment en termes de contraintes énergétiques.
L'IETF (Internet Engineering Task Force), l'organisme qui standardise les protocoles de l'Internet, permet des services
interopérants entre les applications existantes sur Internet. Le protocole 6LoWPAN a été développé pour définir l'adaptation
d'IPv6 ainsi que la manière de transporter les datagrammes IP sur des liaisons IEEE802.15.4 et d'exécuter les fonctions de
configurations nécessaires pour former et maintenir un sous-réseau IPv6 (Internet Protocol version 6). Différentes
modifications aux protocoles d'IPv6 ont été faites pour adapter le réseau Internet aux caractéristiques des objets.

ABSTRACT

The Internet of Things has changed the constraints in use when defining a protocol, particularly as regards energy. The IETF
(Internet Engineering Task Force) is the corporation in charge of the Internet standardization. It offers interoperability services
among its current applications. The 6LoWPAN protocol has been developed to define the IPv6 adaptation and the way the IP
datagrams will be transported over the IEEE802.15.4 links. It also defines the configuration functions needed to create an IPv6
subnetwork. Different modifications to the IPv6 protocols have been made to adapt the Internet network to the characteristics
of Things.

En savoir plus Techniques de l’Ingénieur

sur nos conditions 33 (0)1 53 35 20 20

d’abonnement ? infos.clients@teching.com

Document téléchargé le : 01/03/2024 | © Techniques de l'Ingénieur | Tous droits réservés

6LoWPAN
IPv6 dans les réseaux personnels sans fil
à faible puissance
par Ana MINABURO
Consultant
et Laurent TOUTAIN
Maître de conférences, RSM, Telecom Bretagne, Rennes, France

1. De l’Internet des Objets à l’IETF ....................................................... TE 8 002 - 2

2. Protocole IEEE 802.15.4...................................................................... — 4
2.1 Couche physique ..................................................................................... — 4
2.2 Couche MAC............................................................................................. — 5
3. Protocole 6LoWPAN............................................................................. — 5
3.1 Fragmentation.......................................................................................... — 5
3.2 Compression des en-têtes....................................................................... — 7
3.2.1 Exemples de compression ............................................................. — 8
3.2.2 Dispatch mesh-under ..................................................................... — 10
3.2.3 Dispatch de niveau supérieur ........................................................ — 10
4. Neighbor Discovery — 10
5. Conclusion .............................................................................................. — 11
6. Glossaire .................................................................................................. — 12
7. Sigles ........................................................................................................ — 12
Pour en savoir plus ......................................................................................... Doc. TE 8 002

’Internet des Objets modifie profondément la vision habituelle des proto-

L coles, par le fait que les contraintes sont différentes des environnements
informatiques classiques. En particulier, les contraintes énergétiques sont
importantes, les objets auraient des sources d’alimentation non continues, soit
des batteries, soit une récupération de l’énergie ambiante (changement de
température, vibrations, énergie des ondes radio...). Heureusement, les proces-
seurs actuels sont relativement sobres en consommation d’énergie et la
transmission est le critère à optimiser. Il faut cependant maintenir les équipe-
ments inactifs le plus longtemps possible pour éviter d’émettre trop
régulièrement des données, l’écoute étant aussi coûteuse que l’émission, du
fait des opérations complexes de décodage des signaux. Il faudrait également
éviter qu’un équipement capte en permanence tout le trafic pour récupérer les
données qui lui sont destinées. On voit que ce dernier critère va à l’encontre de
protocoles basés sur les réseaux à diffusion comme le Wi-Fi. Une autre
conséquence liée à la préservation de l’énergie résulte de la faible puissance
des signaux émis, ce qui conduit soit à imposer un relayage des données si les
distances à parcourir sont grandes, soit à utiliser des codages sophistiqués
pour parcourir de longues distances, mais au détriment du débit.
Finalement, une autre différence provient de la faible puissance de calcul
comparé à celle d’un ordinateur, ainsi que les faibles ressources en mémoire qui
imposeront des contraintes fortes sur la taille du programme embarqué et sur
les contextes imposés pour dialoguer avec son environnement (tables de voisi-
nage...). Cela exigera une approche protocolaire beaucoup plus intégrée que ce
qu’offre le modèle de référence de l’ISO (International Organization for Standar-
dization), qui tend à séparer les fonctionnalités et à insister sur les interfaces
entre les couches. Ainsi, dans l’Internet des Objets, même si le modèle est
respecté dans sa philosophie, sa mise en œuvre obligera à des optimisations,

Copyright © – Techniques de l’Ingénieur – Tous droits réservés TE 8 002 – 1

6LOWPAN _________________________________________________________________________________________________________________________

comme le partage d’information entre les couches. La loi de Moore, sur l’évolu-
tion des puissances de calculs, est à interpréter autrement quand il s’agit de
l’Internet des Objets, car, vu la diffusion massive attendue dans les années à
venir, les critères de coût seront déterminants. Cette loi tendra donc vers une
réduction des coûts, plutôt qu’une augmentation drastique de la puissance.
Enfin, l’Internet des Objets devra prendre en compte des cycles de vie des objets
totalement différents des évolutions de l’informatique. La durée de vie d’un
compteur électrique (ou de gaz) est d’une vingtaine d’années, même si Internet
Protocol est resté stable sur des périodes similaires, les moyens de transmettre les
paquets ont beaucoup évolué. Deux cas de figures se présenteront donc :
– intégrer à l’Internet des Objets des équipements déjà existants n’ayant pas
de capacité de communication ou utilisant des méthodes propriétaires, incom-
patibles avec les protocoles de l’Internet ;
– déployer des systèmes et devoir garantir leur interopérabilité pour une
dizaine d’années.
Des objets connectés sont aujourd’hui disponibles et des compagnies propo-
sent déjà des produits permettant de compter la nourriture ingérée, le nombre
de cigarettes électroniques fumées, le suivi des paramètres d’un sportif... Ces
solutions sont généralement propriétaires et ne forment pas à proprement
parler un Internet des Objets, car l’interopérabilité n’est pas le critère domi-
nant. Si les protocoles transportant l’information sont relativement similaires
(Bluetooth ou Bluetooth low energy pour la communication entre l’objet et un
agrégateur (généralement un téléphone portable), puis HTTP (Hyper Text
Transfer Protocol) pour stocker les données dans des serveurs), la manière de
représenter ces données n’est pas normalisée rendant impossible la
combinaison de plusieurs applications pour offrir un service plus riche.
Si, pour pouvoir investir ce nouveau domaine de l’Internet des Objets, les
protocoles doivent être adaptés aux nouvelles contraintes, la sécurité doit être
également renforcée, car les objets ont une action dans le monde réel et un
mauvais fonctionnement peut entraîner de conséquences graves. Quant aux
architectures, elles doivent être les plus génériques possibles pour permettre
l’interconnexion et ne pas être liées à un usage particulier.
Le protocole 6LoWPAN a été développé pour définir l’adaptation d’IPv6, ainsi
que la manière de transporter les datagrammes IP sur des liaisons
IEEE 802.15.4 et d’exécuter les fonctions de configurations nécessaires pour
former et maintenir un sous-réseau IPv6 (Internet Protocol version 6).

1. De l’Internet des Objets
à l’IETF
L’IETF (Internet Engineering Task Force) [1], l’organisme qui
standardise les protocoles de l’Internet par le biais de groupes de
travail spécifiques, passe en revue les solutions existantes pour
permettre des services interopérants entre eux ou avec les
applications existantes sur Internet. Cela couvre un grand nombre
de protocoles principalement IP (Internet Protocol) et plus large-
ment HTTP (Hyper Text Transfer Protocol).
Au niveau 3, le groupe 6LoWPAN, puis le groupe 6lo (IPv6 over
Networks of Resource-constrained Nodes) s’intéressent au trans-
port d’IP sur les supports de transmission utilisé par les objets. La
version 4 d’IP ayant un espace d’adressage saturé, le choix s’est
naturellement tourné vers le protocole IPv6 qui, en plus d’un
espace d’adressage quasi-illimité, offre des possibilités d’auto-
configuration bien utiles, vu qu’il est relativement difficile de
configurer un objet qui ne dispose la plupart du temps ni d’un cla-
vier ni d’un écran.
Le premier groupe de travail se voulait généraliste, mais s’est
finalement focalisé sur le protocole IEEE 802.15.4 [2] qui permet
des transmissions à bas débit et à faible consommation électrique.
Ce standard est également à la base d’autres protocoles, comme la
norme IEEE P1901.2 [3] utilisée dans les réseaux électriques intelli-
gents (smart grid ) pour permettre aux compteurs électriques de
communiquer leurs consommations sur le réseau électrique.
Le second groupe étend ces travaux à d’autres environnements
que l’on retrouve dans l’informatique grand public comme Bluetooth
Low Energy. Les travaux ne portent pas uniquement sur l’adaptation
d’IPv6, mais également sur le protocole Neighbor Discovery [4] qui
permet aux équipements de s’insérer dans un réseau et de dialoguer
avec leurs voisins.
Le terme générique choisi par l’IETF est LoWPAN pour Low
Power Personal Area Network, réseau personnel à faible puis-
sance. En fait, cet acronyme s’applique à d’autres réseaux que les
réseaux personnels, puisque l’on peut les retrouver dans un
bâtiment, dans la ville pour la collecte de données de compteurs...
Le groupe ROLL (Routing Over Low power and Lossy
networks) [5] a revu le routage pour les réseaux ayant des caracté-
ristiques comme une faible consommation électrique et une forte
instabilité due aux faibles puissances de transmission. Un nouveau
protocole appelé RPL [6] (prononcer « ripeul », comme une vague-
lette en anglais) (IPv6 Routing Protocol for Low power and Lossy
networks) offre une architecture générique qui pourra être adaptée
à un environnement particulier.

TE 8 002 − 2 Copyright © – Techniques de l’Ingénieur – Tous droits réservés

_________________________________________________________________________________________________________________________ 6LOWPAN
Le groupe CORE (Constrained RESTful Environments) [7] s’inté-
resse aux applications contraintes en mémoire. Il a développé une
version simplifiée de HTTP demandant moins de ressources
mémoire et de traitement, mais assurant, par le biais de passe-
relles génériques et simples, une compatibilité avec HTTP. Il s’agit
de reprendre l’architecture REST (Representational State
Transfer) [8] et de l’étendre au monde des objets.
D’autres groupes traitent des aspects liés à la sécurité. Le groupe
ACE (Authentication and Authorization for Constrained
Environments) [9] traite de l’authentification et des autorisations
pour les systèmes contraints. Cela peut impliquer de déléguer ces
fonctions à des tiers de confiance qui ont plus de capacité de traite-
ment que les objets eux-mêmes, et d’adapter les protocoles existants
comme EAP (Extensible Authentication Protocol), PANA (Protocol for
carrying Authentication for Network Access), Oauth (Open authoriza-
tion). Le groupe DICE (DTLS In Constrained Environments) [10]
s’occupe de la mise en œuvre du protocole DTLS (Datagram Trans-
port Layer Security) qui permet de chiffrer les datagrammes UDP
(User Datagram Protocol) à l’instar des messages TCP (Transport
Control Protocol) avec TLS (Transport Layer Security).
Pour pouvoir intégrer toutes ces fonctionnalités dans les envi-
ronnements contraints, le groupe lwig (Integrated Working Imple-
mentation Group) [11] étudie les méthodes les plus efficaces pour
orchestrer ces protocoles et les mettre en œuvre.
Un point bien particulier des architectures définies par l’IETF, par
rapport à des systèmes propriétaires comme ZigBee, est que cha-
que couche garde ses propres identifiants. Au niveau 3, on retrou-
vera les adresses IP qui ne sont pas liées aux adresses de niveau 2.
Au niveau applicatif, quand l’architecture REST est utilisée, les
identifiants seront des URI (Uniform Resource Identifier). Cela per-
met une grande souplesse architecturale puisqu’il est possible de
changer de protocole de transmission sans modifier l’applicatif. Au
contraire, les adresses des applications ZigBee dérivent des adres-
ses IEEE 802.15.4, il est donc difficile de faire évoluer le système.
Cette agnoticité des niveaux supérieurs vis-à-vis des niveaux infé-
rieurs fait la force de l’Internet traditionnel. On retrouve cet avan-
tage dans les architectures pour l’Internet des Objets.
Les premiers travaux autour d’IPv6 datent du début des années
1990 quand la petite taille des champs adresses du protocole IPv4
conduisait à rendre la croissance du réseau plus délicate. D’un pre-
mier abord, IPv6 est une simplification et une amélioration du pro-
tocole existant, ainsi qu’une augmentation importante des champs
d’adressage, puisque leur taille a été quadruplée, multipliant par
296 le nombre d’adresses disponibles. IPv6 simplifie le traitement
dans les routeurs, renvoyant toute opération complexe à la bor-
dure du réseau dans les équipements terminaux. D’un point de
vue informatique, cette approche est logique puisqu’elle permet de
répartir la charge de travail sur un nombre important d’équipe-
ments, plutôt que de la concentrer dans les routeurs. Néanmoins,
pour les objets, cela peut se traduire par du code supplémentaire.
IPv6 a également été conçu avec Ethernet comme modèle de
réseau de transmission. Les protocoles annexes comme Neighbor
Discovery, quasiment indispensable pour insérer facilement un
équipement dans un réseau, feront donc appel intensivement au
trafic multicast. Or, s’il permet sur Ethernet de réduire le nombre
de messages échangés, il est beaucoup moins efficace dans
d’autres technologies. Ainsi en Wi-Fi, les trames multicast utilisent
le codage le plus robuste possible pour pouvoir joindre le plus
grand nombre de récepteurs, ce qui conduit à des temps de trans-
mission (donc d’occupation du canal), nettement supérieurs à la
transmission en point-à-point qui cherche à optimiser le codage. Il
est à noter que les travaux d’adaptation d’IPv6 pour l’Internet des
Objets trouvent aussi un impact dans l’Internet traditionnel pour
insérer un équipement dans un réseau.
■ Si l’on se focalise sur IPv6, du point de vue de l’Internet des
Objets, ce protocole présente certains désavantages :
– la taille de l’en-tête est importante par rapport aux données uti-
les transmises. Cela a un impact énergétique important, car la
Copyright © – Techniques de l’Ingénieur – Tous droits réservés
transmission est une part importante de la consommation d’un
objet. De plus, comme les supports de transmission ont générale-
ment des MTU (Maximum Transmission Unit) faibles (IEEE 802.15.4
impose des trames de 127 octets maximum incluant les en-têtes), il
faut avoir recours à la fragmentation, ce qui rend la transmission
moins efficace, car tout fragment perdu impose la retransmission
complète du paquet ;
– IPv6 impose une taille de MTU minimale de 1 280 octets. Cela
est lié au processus d’adaptation du MTU, à la capacité du chemin
entre la source et le destinataire. Si un paquet est trop grand, un
routeur intermédiaire peut demander à la source d’en réduire sa
taille. Or, l’identité des routeurs intermédiaire est inconnue de la
source. Pour limiter l’impact d’une attaque où un équipement impo-
serait de réduire fortement la taille des données émise, l’IETF a fixé
une limite de réduction à 1 280 octets. Cela convient pour à peu près
toutes les situations, incluant les encapsulations liées aux tunnels,
mais, comme vu précédemment, les protocoles utilisés pour
connecter les objets ont des tailles de paquet plus petites liées aux
performances des codes correcteurs d’erreur. L’IETF impose dans
ce cas une couche d’adaptation qui fera la fragmentation et le réas-
semblage, permettant à IPv6 d’avoir le MTU nécessaire.
Mais, la fragmentation est complexe à mettre en œuvre et doit
être évitée. Quand les échanges sont limités en taille, par exemple
l’interrogation d’un capteur peut simplement retourner une valeur
numérique sur quelques octets, la réduction de la taille de l’en-tête
permet d’envoyer plus de données utiles. Par contre, pour de gros
transferts, par exemple la récupération d’un fichier de log ou la
mise à jour du firmware d’un objet, la fragmentation peut être
effectuée :
• au niveau applicatif : par exemple CoAP (Constrained Appli-
cation Protocol) permet de découper en blocs des données.
Un mécanisme d’acquittement permet de retransmettre uni-
quement les blocs erronées ou perdus ;
• au niveau physique : par exemple le protocole IEEE P1901.2
de transmission sur courant porteur inclut des mécanismes
de fragmentation avec retransmission uniquement des frag-
ments perdus ;
– les protocoles annexes d’IPv6 comme Neighbor Discovery,
mais également la configuration avec DHCP (Dynamic Host Confi-
guration Protocol) et EAP (Extensible Authentication Protocol ),
ainsi que le routage, font beaucoup appel au multicast, soit pour,
en théorie, optimiser la bande passante en n’envoyant qu’une fois
l’information à plusieurs destinataires, soit pour dialoguer avec un
équipement dont on ne connaît pas l’identité, le groupe multicast
est donc associé à un service particulier. Or, la gestion du multi-
cast est coûteuse en bande passante et en énergie. Il faudra donc
limiter son usage à la découverte des services basiques.
■ Malgré tout, IPv6 a aussi de nombreux avantages :
– il permet cette architecture en sablier rendant le niveau 3 tota-
lement indépendant du niveau applicatif et du niveau 2. Il est ainsi
possible de développer des services sans se soucier du moyen de
transporter l’information. En uniformisant le réseau, c’est-à-dire en
cachant les spécificités de niveau 2, et en offrant un adressage
unique et structuré des équipements terminaux, il est possible de
construire un réseau de bout en bout. En contre partie, il faut pou-
voir jongler et faire le lien avec 2 ou 3 niveaux d’adressage, entre
les adresses MAC (ou plus généralement de niveau 2), les
adresses IP et parfois les identifiants de niveau 7 à savoir les URI ;
– le plan d’adressage de la version 4 est saturé, ce qui fait qu’il
n’est pas possible d’utiliser ce protocole pour un nouveau
domaine. Néanmoins, l’adressage IPv6 présente aussi d’autres
avantages liés à ses 128 bits de longueur. Une adresse IPv6 se
décompose généralement en deux parties de même longueur
(figure 1). Les 64 premiers bits contiennent le préfixe, c’est-à-dire
l’information nécessaire pour router le paquet jusqu’au réseau
final. Ce préfixe peut aussi contenir la valeur FE80::/64 qui dési-
gnera une adresse lien-local. Cette adresse ne pourra être utilisée
que sur ce réseau local et non routée à l’extérieur. Mais, elle sera
TE 8 002 – 3
6LOWPAN _________________________________________________________________________________________________________________________

48 bits 16 bits 64 bits

Préfixe globale SID ID de l’Interface

Préfixe publique donné Topologie locale, Adresse du lien

par le fournisseur de services donnée par
l’ingénieur système
Adresse du lien en utilisant l’@ MAC

MAC-48 …00 Vendeur Numéro de série

EUI-64 …00 Vendeur FFFE Numéro de série

IDD …10 Vendeur FFFE Numéro de série

Figure 1 – Adresse IPv6

très utile au démarrage de l’objet qui pourra se créer une identité Le protocole IEEE 802.15.4 [2] décrit la couche physique et la
pour dialoguer avec ses voisins dont les routeurs et autres relais couche MAC qui seront utilisés ensuite pour l‘IETF comme base
(comme DHCP) ; pour l’Internet des Objets.
– les 64 derniers bits désignent l’identifiant d’interface qui iden-
tifiera de manière unique la machine sur ce dernier réseau. Le fait
d’avoir un identifiant aussi long permet d’y inclure facilement
l’adresse MAC de la machine. Cette facilité, si elle est déconseillée 2.1 Couche physique
pour les équipements traditionnels, permettra dans le monde des
Objets dans certains cas de faciliter la compression des en-têtes et La couche physique est responsable de différentes fonctions :
la correspondance entre les adresses MAC et IP.
– activation ou désactivation de l’émetteur radio ;
– réception et transmission des données ;

2. Protocole IEEE 802.15.4 – sélection de la fréquence du canal ;

La popularité du protocole IEEE 802.15.4 le rend aussi important
que IPv6 pour l’Internet des Objets, du moins pour les applications
professionnelles. Pour l’électronique grand public, Bluetooth LE
(Low Energy ) semble s’imposer. Le protocole prend en compte les
caractéristiques des dispositifs embarqués : avec une consomma-
tion basse d’énergie, une faible mémoire et un faible traitement de
ressources. Ainsi, le protocole définit un faible débit de données,
une faible puissance et des transmissions à courte portée de fré-
quence radio pour les réseaux WPAN (Wireless Personal Area
Networks). Par contre, ce protocole présente différentes caractéristi-
ques similaires aux autres protocoles de niveau 2 comme : Ethernet
et Wi-Fi. Le protocole 802.15.4 offre un MTU réduit de 127 octets, ce
qui est très petit comparé aux 1 500 octets d’Ethernet. De plus,
802.15.4 ne fournit pas une diffusion broadcast complète où tous les
nœuds peuvent recevoir des messages des autres nœuds avec une
transmission physique unique. Les réseaux 802.15.4 sont plutôt
composés de domaines qui se chevauchent avec un voisinage radio
formé par les nœuds accessibles avec une transmission unique.
– détection de l’énergie dans un canal ;
– vérification que le canal est libre (CCA, Clear Channel
Assessment).
Le protocole IEEE 802.15.4 définit 15 modes physiques diffé-
rents de transmission afin de choisir la bande de fréquence et la
modulation qui seront utilisées lors de la transmission des
données.
Il y a des fréquences qui sont libres de licence et donc plus
utilisées : 868-868,6 MHz en Europe, 902-928 MHz en Amérique du
Nord et 2400-2483,5 MHz partout dans le monde. Quant à la modula-
tion, IEEE 802.15.4 exploite O-QPSK (Offset Quadrature Phase Shift
Keying) ou BPSK (Binary Phase Shift Keying) parce que ses techni-
ques de diffusion sont robustes et résistantes aux interférences.
La portée de communication varie entre 10 et 100 mètres, tout
dépend du mode PHY (physique) utilisé et le médium. Dans tous
les cas, la vitesse est limitée à 250 kbps.

TE 8 002 – 4 Copyright © – Techniques de l’Ingénieur – Tous droits réservés

 L’EXPERTISE TECHNIQUE
& SCIENTIFIQUE DE RÉFÉRENCE

Besoin de consulter les articles de l’offre :

“Réseaux Télécommunications” Abonnez-vous !

AU SOMMAIRE

 Tutoriaux sur les techniques et systèmes de transmission

numérique à haut débit : des technologies DSL aux fibres
optiques.

 Protocoles détaillés pour appréhender les technologies IP : IPv6,

transport TCP, multicast IP, protocoles de routage, technologies
MPLS.

 Les services mobiles et Les systèmes sans fil : qualité de service et

performances des réseaux IEEE 802 .11, évolution du système
UMTS, convergence des services voix et données vers la 5G.

 Mise en œuvre et gestion de l’administration des réseaux

informatiques : protocole SNMP, pare-feu, métrologie des réseaux.

DÉTAIL DE L’OFFRE ET SOMMAIRE COMPLET À RETROUVER SUR LE SITE

www.techniques-ingenieur.fr

De la conception au + de 10 000 articles

520 bases
prototypage, jusqu’à de référence
documentaires,
et 1 000 fiches
l’industrialisation, réparties
pratiques
Techniques de l’ingénieur dans 85 offres
opérationnelles
est l’outil de référence pour
sécuriser le développement 3 000 QUIZ
de vos projets industriels, 1280 auteurs 340 000
DANS + DE 1 000
contribuent utilisateurs
optimiser vos flux de ARTICLES
chaque année de techniques- INTERACTIFS
production et accélérer à enrichir ingenieur.fr
votre innovation produit. cette ressource chaque mois

NOS ÉQUIPES SONT Par téléphone Par email

À VOTRE DISPOSITION  33 (0)1 53 35 20 20  infos.clients@teching.com

www.techniques-ingenieur.fr