P. MariagerJ. Petersen (RTX A/S)Z. Shelby (ARM)M. Van de Logt (Gigaset Communications GmbH)D. Barthel (Orange Labs)May20172017-05-03
Tout le monde connait DECT, la technique
utilisée, depuis vingt ans, entre votre téléphone sans fil à la maison, et sa
base. DECT ne sert pas que pour la voix, il peut aussi être
utilisé pour transmettre des données, par exemple de capteurs
situés dans une « maison intelligente ». DECT a une variante
« basse consommation », DECT ULE (pour Ultra Low
Energy) qui est spécialement conçue pour des objets
connectés ayant peu de réserves d'énergie. Elle vise donc la
domotique, s'appuyant sur la vaste
distribution de DECT, la disponibilité de composants bon marché et
très diffusés, de
fréquences dédiées, etc. Il ne restait donc plus qu'à faire passer
IPv6 sur DECT ULE. C'est ce que normalise
ce RFC, qui réutilise les techniques
6LoWPAN ().
DECT est normalisé par
l'ETSI sous le numéro 300.175 (et la norme
est en
ligne). ULE s'appuie sur DECT pour le cas particulier des
engins sans guère de réserves énergétiques. Il est normalisé dans
les documents ETSI 102.939-1
et 102.939-2. Dans
la terminologie DECT, le FP (Fixed Part) est la
base, le PP (Portable Part) le téléphone sans
fil (ou bien, dans le cas d'ULE, le capteur ou l'actionneur ). Le FP peut être
connecté à l'Internet (et c'est évidemment là
qu'IPv6 est important).
Un réseau DECT ULE typique serait une maison où des capteurs
(les PP)
mesureraient des informations et les transmettraient au FP qui,
étant doté de capacités de calcul et de réserves d'énergie
suffisantes, les traiterait, en ferait des jolis graphiques,
aurait une interface Web, etc. Le RFC cite
un autre exemple où une personne âgée serait munie d'un pendentif
qui enverrait des signaux de temps en temps (consommant peu
d'énergie) mais permettrait d'établir une liaison vocale avec le
FP (et, de là, avec les services médicaux) en cas d'urgence.
Et IPv6 ? Il permettrait d'avoir une
communication avec tous les équipements
IP. IPv6 fonctionne déjà sur une autre
technologie similaire, IEEE 802.15.4, avec le système
6LoWPAN (,
et ). Comme DECT ULE ressemble à 802.15.4 (mais est un
protocole différent, attention), ce RFC
décrit comment faire passer de l'IPv6, en s'inspirant de ce qui
marchait déjà pour 802.15.4.
La section 2 du RFC rappelle ce qu'il faut savoir de DECT et
d'ULE. ULE permet le transport de la voix et des données mais ce
RFC ne se préoccupe que des données. Le protocole utilise les
bandes de fréquence entre 1880 et 1920
MHz, à 1,152 Mbauds. La topologie théorique est celle d'un réseau
cellulaire mais, en pratique, DECT est la plupart du temps organisé
en étoile, un FP (la base) au « centre » et des PP (téléphones et
capteurs) qui lui sont rattachés. Toute session peut commencer à
l'initiative du FP ou d'un PP mais attention : avec ULE, bien des
PP seront des engins aux batteries limitées, qui dormiront pendant
l'essentiel du temps. Au minimum, il y aura une sérieuse latence
s'il faut les réveiller.
Comme, dans le cas typique, le FP est bien moins contraint que
le PP (connecté au courant électrique, processeur plus puissant),
ce sera le FP qui jouera le rôle de 6LBR
(6LoWPAN Border Router,
voir ), et le PP celui de 6LN
(6LoWPAN Node, même RFC). Contrairement à
802.15.4, DECT ULE ne permet que des liens directs, pour aller au
delà, il faut un routeur (le FP). Tous les PP connectés à un FP
forment donc un seul lien, leurs adresses seront dans le même
préfixe IPv6.
Comment attribuer cette adresse ? Alors, là, faites attention,
c'est un point délicat et important. Chaque PP a un IPEI
(International Portable Equipment Identity) de
40 bits, qui
est l'identifiant DECT. Les FP ont un RFPI (Radio Fixed
Part Identity, également 40 bits). Les messages envoyés entre PP et FP ne
portent pas l'IPEI mais le TPUI (Temporary Portable User
Identity, 20 bits). Pas mal de mises en œuvre de DECT
attribuent répétitivement le même TPUI à une machine, même si ce
n'est pas obligatoire. Il peut donc être un identifiant stable, en
pratique, comme le sont IPEI et RFPI.
L'adresse IPv6 est composée du préfixe du réseau et d'un
identifiant d'interface, qu'on peut construire à partir de
l'adresse MAC (les équipements DECT peuvent
aussi avoir une adresse MAC, en sus des identificateurs déjà cités). Adresse MAC, IPEI, RFPI ou TPUI,
tout ce qui est stable pose des problèmes de protection de la
vie privée (), et n'est pas recommandé comme identifiant
d'interface par défaut.
Un petit mot aussi sur la MTU : les
paquets DECT ne sont que 38 octets, bien trop petit pour IP. Certes, DECT fournit un
mécanisme de fragmentation et de réassemblage, qui fournit une MTU
« virtuelle » qui est,
par défaut,
de 500 octets. La MTU minimum exigée par IPv6 étant de 1 280
octets (, section 5), il faudra donc
reconfigurer le lien DECT pour passer à une MTU de 1 280. Ainsi,
les paquets n'auront jamais besoin d'être fragmentés par
IP. Évidemment, plus le paquet est gros, plus le coût énergétique
de transmission est élevé, au détriment de la durée de vie de la batterie.
Place maintenant à la spécification elle-même, en section 3 du
RFC. La base (alias FP, alias 6LBR) et l'objet (alias PP, alias
6LN) vont devoir se trouver et établir une session DECT
classique. On aura alors une couche 2
fonctionnelle. Ensuite, on lancera IPv6, qui fournira la
couche 3. La consommation de
ressources, notamment d'énergie, étant absolument cruciale ici, il
faudra s'appuyer sur les technologies IPv6 permettant de faire des
économies, notamment (IPv6 sur un
autre type de réseau contraint, IEEE 802.15.4), (optimisation des mécanismes de neighbor discovery pour les
6LoWPAN) et
(compression des paquets et notamment des
en-têtes).
Comme indiqué plus haut, les PP ne peuvent parler qu'au FP, pas
directement de l'un à l'autre. Si tous les PP d'un même FP (d'une
même base) forment un sous-réseau IPv6 (choix le plus simple), le
modèle sera celui d'un NBMA. Lorsqu'un PP
écrira à un autre PP, cela sera forcément relayé par le FP.
Les adresses IPv6 des PP seront formées à partir du préfixe
(commun à tous les PP d'un même FP) et d'un identifiant
d'interface. Pour les adresses locales au lien, cet identifiant
d'interface dérivera des identifiants DECT, les IPEI et RFPI,
complétés avec des zéros pour atteindre la taille requise. Le bit
« unique mondialement » sera à zéro puisque ces identifiants ne
seront pas uniques dans le monde (ils ont juste besoin d'être
uniques localement, ce fut un des points les plus chauds lors de
l'écriture de ce RFC).
Pour les adresses globales des PP, pas
question d'utiliser des identificateurs trop révélateurs (), il faut utiliser une technique qui
préserve la vie privée comme les CGA (), les adresses temporaires du ou les adresses stables mais opaques du
.
Le FP, la base, a une connexion avec l'Internet, ou en tout cas avec
d'autres réseaux IP, et routera donc les paquets, s'ils viennent
d'un PP et sont destinés à une adresse extérieure au sous-réseau
(idem avec les paquets venus de l'extérieur et destinés au
sous-réseau.) Au fait, comment est-ce que la base, qui est un
routeur IPv6, obtient, elle, le préfixe
qu'elle va annoncer ? Il n'y a pas de méthode obligatoire mais
cela peut être, par exemple, la délégation de préfixe du , ou bien le .
Question mises en œuvre, il semble que
RTX et Gigaset en
aient déjà, et que peut-être l'alliance ULE
va produire une version en logiciel libre.