Aller au contenu principal

RFC 4944 - Transmission de paquets IPv6 sur les réseaux IEEE 802.15.4

  • Statut: Proposed Standard
  • Publié: September 2007
  • Stream: IETF
  • Errata: Pas d'errata

Résumé (Abstract)​

Ce document décrit le format de trame (Frame Format) pour la transmission de paquets IPv6 sur les réseaux IEEE 802.15.4, ainsi que la formation d'adresses locales de lien IPv6 (Link-Local Addresses) et d'adresses autoconfigurées sans état (Stateless Autoconfiguration) sur ces réseaux. Les spécifications supplémentaires incluent un schéma de compression d'en-tête (Header Compression) simple utilisant un contexte partagé, ainsi que des dispositions pour la livraison de paquets dans les réseaux maillés (Mesh Networks) IEEE 802.15.4.

Table des matières (Contents)​

Annexes (Appendices)​

Ressources connexes​

1. Introduction​

La norme IEEE 802.15.4 [ieee802.15.4] est destinée aux réseaux personnels à faible consommation d'énergie (Low-Power Personal Area Networks). Ce document définit le format de trame pour la transmission de paquets IPv6 [RFC2460] sur des réseaux IEEE 802.15.4, ainsi que les méthodes pour former des adresses locales de lien (Link-Local Addresses) et des adresses autoconfigurées sans état (Statelessly Autoconfigured Addresses) au-dessus des réseaux IEEE 802.15.4. Étant donné qu'IPv6 nécessite la prise en charge de tailles de paquets bien supérieures à la taille maximale de trame IEEE 802.15.4, une couche d'adaptation (Adaptation Layer) est définie. Ce document définit également les mécanismes de compression d'en-tête (Header Compression) nécessaires pour rendre IPv6 pratique sur les réseaux IEEE 802.15.4, ainsi que les dispositions requises pour la livraison de paquets dans les maillages (Meshes) IEEE 802.15.4. Cependant, la spécification complète du routage en réseau maillé (utilisant des protocoles spécifiques, l'interaction avec la découverte de voisins, etc.) dépasse le cadre de ce document.

1.1. Notation des exigences (Requirements Notation)​

Les mots-clés « MUST » (DOIT), « MUST NOT » (NE DOIT PAS), « REQUIRED » (requis), « SHALL » (devra), « SHALL NOT » (ne devra pas), « SHOULD » (DEVRAIT), « SHOULD NOT » (ne devrait pas), « RECOMMENDED » (recommandé), « MAY » (PEUT) et « OPTIONAL » (optionnel) dans ce document doivent être interprétés comme décrit dans [RFC2119].

1.2. Termes utilisés (Terms Used)​

AES : Advanced Encryption Scheme (schéma de chiffrement avancé)

CSMA/CA : Carrier Sense Multiple Access / Collision Avoidance (accès multiple avec écoute de porteuse / évitement de collision)

FFD : Full Function Device (dispositif à fonctionnalité complète)

GTS : Guaranteed Time Service (service à créneaux garantis)

MTU : Maximum Transmission Unit (unité de transmission maximale)

MAC : Media Access Control (contrôle d'accès au support)

PAN : Personal Area Network (réseau personnel)

RFD : Reduced Function Device (dispositif à fonctionnalité réduite)

2. Mode IEEE 802.15.4 pour IP (IEEE 802.15.4 Mode for IP)​

IEEE 802.15.4 définit quatre types de trames : les trames balise (Beacon Frames), les trames de commande MAC (MAC Command Frames), les trames d'acquittement (Acknowledgement Frames) et les trames de données (Data Frames). Les paquets IPv6 DOIVENT être transportés sur des trames de données. Les trames de données peuvent optionnellement demander à être acquittées (Acknowledged). Conformément à [RFC3819], il est RECOMMANDÉ de transporter les paquets IPv6 dans des trames demandant un acquittement, afin de faciliter la récupération au niveau de la couche liaison (Link-Layer Recovery).

Les réseaux IEEE 802.15.4 peuvent être sans balise (Nonbeacon-Enabled) ou avec balise (Beacon-Enabled) [ieee802.15.4]. Ce dernier est un mode optionnel dans lequel les dispositifs se synchronisent via les balises d'un coordinateur (Coordinator). Cela permet l'utilisation de supertrame (Superframes), à l'intérieur desquelles un service à créneaux garantis sans contention (Guaranteed Time Service, GTS) peut être réalisé. Ce document N'EXIGE PAS que le réseau IEEE fonctionne en mode avec balise. Dans les réseaux sans balise, les trames de données (y compris celles transportant des paquets IPv6) sont envoyées via la méthode d'accès au canal CSMA/CA non à créneaux basée sur la contention (Contention-Based Channel Access Method of Unslotted CSMA/CA).

Dans les réseaux sans balise, les balises ne sont pas utilisées pour la synchronisation. Cependant, elles restent utiles pour la découverte de dispositifs au niveau de la couche liaison (Link-Layer Device Discovery), afin de faciliter les événements d'association (Association) et de désassociation (Disassociation). Ce document RECOMMANDE de configurer les balises pour faciliter ces fonctions. Il est en outre recommandé de rendre ces événements disponibles au niveau de la couche IPv6, afin de faciliter la détection de l'attachement réseau (Network Attachment), un problème à l'étude à l'IETF au moment de la rédaction de ce document.

Cette spécification autorise les trames dans lesquelles l'adresse source ou de destination (ou les deux) peut être omise (Elided). Les mécanismes définis dans ce document EXIGENT que les adresses source et de destination soient présentes dans l'en-tête de trame IEEE 802.15.4 (Frame Header). Les champs d'identifiant PAN source ou de destination peuvent également être inclus.

3. Modes d'adressage (Addressing Modes)​

IEEE 802.15.4 définit plusieurs modes d'adressage (Addressing Modes) : il permet l'utilisation d'adresses étendues IEEE 64 bits (64-bit Extended Addresses), ou (après un événement d'association) d'adresses 16 bits uniques au sein d'un PAN [ieee802.15.4]. Ce document prend en charge à la fois les adresses étendues 64 bits et les adresses courtes 16 bits (Short Addresses).

Pour une utilisation dans un réseau 6LoWPAN, ce document impose des contraintes supplémentaires sur le format des adresses courtes 16 bits (en plus de celles imposées par IEEE 802.15.4), comme spécifié à la section 12. Étant donné que les adresses courtes sont par nature transitoires (Transient), une attention particulière est requise : comme elles sont attribuées lors des événements d'association par la fonction de coordinateur PAN (PAN Coordinator Function), leur validité et leur unicité sont limitées à la durée de vie de cette association. Cela peut être raccourci par l'expiration de l'association ou toute défaillance du coordinateur PAN. En raison des problèmes de scalabilité liés à cette attribution centralisée et au point de défaillance unique (Single Point of Failure) au niveau du coordinateur PAN, les déployeurs devraient soigneusement peser les avantages et les inconvénients de l'extension de tels réseaux basés sur des adresses courtes (et mettre en œuvre les mécanismes nécessaires). Bien sûr, les adresses étendues IEEE 64 bits ne souffrent peut-être pas de ces défauts, mais partagent néanmoins les autres problèmes de scalabilité liés au routage, à la découverte, à la configuration, etc.

Ce document suppose qu'un PAN est mappé à un lien IPv6 (IPv6 Link) spécifique. Cela est conforme à la recommandation selon laquelle les réseaux partagés devraient prendre en charge la diffusion de sous-réseau de couche liaison [RFC3819]. Strictement parlant, ce qui existe dans IPv6 est la multidiffusion (Multicast) et non la diffusion (Broadcast). Cependant, IEEE 802.15.4 lui-même ne prend pas en charge la multidiffusion. Par conséquent, les paquets de multidiffusion de la couche IPv6 DOIVENT être transportés comme des trames de diffusion de couche liaison dans les réseaux IEEE 802.15.4. Cela DOIT être fait de telle manière que les trames de diffusion ne soient remarquées que par les dispositifs au sein du PAN spécifique du lien en question. Conformément à la section 7.5.6.2 de [ieee802.15.4], cela est réalisé comme suit :

  1. L'identifiant PAN de destination (Destination PAN Identifier) DOIT être inclus dans la trame, et il DOIT correspondre à l'identifiant PAN du lien en question.

  2. L'adresse de destination courte (Short Destination Address) DOIT être incluse dans la trame, et elle DOIT correspondre à l'adresse de diffusion (0xffff).

De plus, la prise en charge du mappage d'adresses de multidiffusion IPv6 conformément à la section 9 DOIT être utilisée uniquement dans les configurations en réseau maillé (Mesh Configuration). La spécification complète de cette fonctionnalité dépasse le cadre de ce document.

Comme d'habitude, les hôtes apprennent les préfixes IPv6 via les annonces de routeur (Router Advertisements), comme décrit dans [RFC4861].

4. Unité de transmission maximale (Maximum Transmission Unit)​

La taille MTU des paquets IPv6 sur IEEE 802.15.4 est de 1280 octets. Cependant, un paquet IPv6 complet ne peut pas tenir dans une seule trame IEEE 802.15.4. Les unités de données de protocole (Protocol Data Units) 802.15.4 ont des tailles différentes selon la quantité de surcharge présente [ieee802.15.4]. En partant de la taille maximale de paquet de la couche physique de 127 octets (aMaxPHYPacketSize) et d'une surcharge de trame maximale de 25 (aMaxFrameOverhead), la taille maximale de trame finale de la couche de contrôle d'accès au support (Media Access Control Layer) est de 102 octets. La sécurité au niveau de la couche liaison (Link-Layer Security) impose une surcharge supplémentaire, dans le pire des cas (21 octets de surcharge pour AES-CCM-128, et 9 et 13 respectivement pour AES-CCM-32 et AES-CCM-64), ne laissant que 81 octets disponibles. Cela est manifestement bien inférieur à la taille minimale de paquet IPv6 de 1280 octets, et conformément à la section 5 de la spécification IPv6 [RFC2460], une couche d'adaptation de fragmentation et de réassemblage (Fragmentation and Reassembly Adaptation Layer) DOIT être fournie par les couches inférieures à la couche IP. Une telle couche est définie à la section 5 ci-dessous.

De plus, étant donné que la longueur de l'en-tête IPv6 est de 40 octets, cela ne laisse que 41 octets pour les protocoles de couche supérieure (comme UDP). Ce dernier utilise 8 octets dans son en-tête, ce qui ne laisse que 33 octets pour les données applicatives (Application Data). De plus, comme mentionné ci-dessus, une couche de fragmentation et de réassemblage est nécessaire, ce qui utilisera davantage d'octets.

Les considérations ci-dessus conduisent aux deux observations suivantes :

  1. Une couche d'adaptation DOIT être fournie pour satisfaire l'exigence de MTU minimum IPv6. Cependant, il est prévu que (a) la plupart des applications IEEE 802.15.4 n'utiliseront pas des paquets aussi grands, et que (b) des charges utiles applicatives plus petites (Application Payloads) combinées à une compression d'en-tête (Header Compression) appropriée produiront des paquets adaptés à une seule trame IEEE 802.15.4. La justification de cette couche d'adaptation n'est pas seulement la conformité IPv6, car certains échanges applicatifs (par exemple, la configuration ou l'approvisionnement (Provisioning)) produisent des tailles de paquets qui nécessiteront vraisemblablement une fragmentation limitée.

  2. Même si les calculs d'espace ci-dessus montrent le pire des cas, ils indiquent que la compression d'en-tête est presque inévitable. Étant donné que nous prévoyons que la plupart (sinon la totalité) des applications IP over IEEE 802.15.4 utiliseront la compression d'en-tête, celle-ci est définie à la section 10 ci-dessous.

5. Couche d'adaptation LoWPAN et format de trame (LoWPAN Adaptation Layer and Frame Format)​

Les formats d'encapsulation (Encapsulation Formats, ci-après dénommés « encapsulation LoWPAN ») définis dans cette section constituent la charge utile des unités de données de protocole (Protocol Data Unit, PDU) MAC IEEE 802.15.4. La charge utile LoWPAN (par exemple, un paquet IPv6) suit immédiatement cet en-tête d'encapsulation.

Tous les datagrammes encapsulés LoWPAN (Datagrams) transmis via IEEE 802.15.4 sont précédés d'une pile d'en-têtes d'encapsulation (Encapsulation Header Stack). Chaque en-tête de la pile contient un type d'en-tête (Header Type), suivi de zéro ou plusieurs champs d'en-tête. Dans l'en-tête IPv6, la pile contiendra dans l'ordre suivant : adressage (Addressing), options saut par saut (Hop-by-Hop Options), routage (Routing), fragmentation (Fragmentation), options de destination (Destination Options), et enfin la charge utile [RFC2460] ; dans l'en-tête LoWPAN, une séquence d'en-têtes similaire est : adressage réseau maillé (L2), options saut par saut (incluant la diffusion/multidiffusion L2), fragmentation, et enfin la charge utile.

Exemple typique de pile d'en-têtes :

Datagramme IPv6 encapsulé LoWPAN :

+---------------+-------------+---------+
| IPv6 Dispatch | IPv6 Header | Payload |
+---------------+-------------+---------+

Cas nécessitant un adressage en réseau maillé et une fragmentation :

+-------+-------+-------+-------+---------+---------+---------+
| M Typ | M Hdr | F Typ | F Hdr | HC1 Dsp | HC1 Hdr | Payload |
+-------+-------+-------+-------+---------+---------+---------+

Lorsque plusieurs en-têtes LoWPAN sont utilisés dans le même paquet, ils DOIVENT apparaître dans l'ordre suivant : en-tête d'adressage réseau maillé, en-tête de diffusion, en-tête de fragmentation.

5.1. Type de dispatch et en-tête (Dispatch Type and Header)​

Le type de dispatch est défini par les deux premiers bits « 01 », suivis d'un sélecteur de 6 bits identifiant le type d'en-tête suivant.

Schémas de bits des valeurs de dispatch :

  • 00 xxxxxx - NALP : n'est pas une trame LoWPAN
  • 01 000001 - IPv6 : adresse IPv6 non compressée
  • 01 000010 - LOWPAN_HC1 : IPv6 compressé HC1
  • 01 010000 - LOWPAN_BC0 : diffusion BC0
  • 01 111111 - ESC : octet de dispatch supplémentaire
  • 10 xxxxxx - MESH : en-tête réseau maillé
  • 11 000xxx - FRAG1 : en-tête du premier fragment
  • 11 100xxx - FRAGN : en-tête des fragments suivants

5.2. Type et en-tête d'adressage réseau maillé (Mesh Addressing Type and Header)​

Le type réseau maillé est défini par les deux premiers bits « 10 » :

|1 0|V|F|HopsLft| adresse de l'émetteur, adresse finale

Définition des champs :

  • V : 1 bit, 0 indique que l'adresse de l'émetteur est sur 64 bits, 1 indique une adresse courte 16 bits
  • F : 1 bit, 0 indique que l'adresse de destination finale est sur 64 bits, 1 indique une adresse courte 16 bits
  • Hops Left : 4 bits, décrémenté à chaque transfert, le paquet est rejeté lorsqu'il atteint 0. La valeur 0xF indique qu'un champ d'extension de 8 bits suit
  • Originator Address : adresse de couche liaison de l'émetteur
  • Final Destination Address : adresse de couche liaison de la destination finale

5.3. Type et en-tête de fragmentation (Fragmentation Type and Header)​

Si le datagramme ne tient pas dans une seule trame 802.15.4, il DEVRA être décomposé en fragments de liaison. Tous les fragments sauf le dernier DOIVENT être des multiples de 8 octets.

En-tête du premier fragment (FRAG1) :

|1 1 0 0 0| datagram_size | datagram_tag |

En-tête des fragments suivants (FRAGN) :

|1 1 1 0 0| datagram_size | datagram_tag |
|datagram_offset|

Définition des champs :

  • datagram_size : 11 bits, encode la taille totale du paquet IP (avant la fragmentation au niveau de la couche liaison). Pour IPv6, la valeur est Payload Length + 40
  • datagram_tag : 16 bits, tous les fragments du même datagramme ont le même tag, l'émetteur incrémente cette valeur pour les datagrammes consécutifs
  • datagram_offset : 8 bits, décalage du fragment en unités de 8 octets, présent uniquement dans les fragments suivants

Règles de réassemblage :

Le récepteur utilise les informations suivantes pour identifier les fragments appartenant au même datagramme :

  1. L'adresse source 802.15.4 de l'émetteur (ou l'adresse de l'émetteur du réseau maillé)
  2. L'adresse 802.15.4 de destination (ou l'adresse de destination finale du réseau maillé)
  3. datagram_size
  4. datagram_tag

Le délai de réassemblage DOIT être fixé à 60 secondes au maximum. Lors de la détection d'un événement de désassociation, tous les fragments partiellement réassemblés DOIVENT être rejetés.

6. Autoconfiguration d'adresse sans état (Stateless Address Autoconfiguration)​

Cette section définit comment obtenir un identifiant d'interface IPv6 (Interface Identifier).

L'identifiant d'interface [RFC4291] pour une interface IEEE 802.15.4 peut être basé sur l'identifiant EUI-64 [EUI64] attribué au dispositif IEEE 802.15.4. Dans ce cas, l'identifiant d'interface est formé à partir de l'EUI-64 conformément à la spécification « IPv6 over Ethernet » [RFC2464].

Tous les dispositifs 802.15.4 ont une adresse IEEE EUI-64, mais les adresses courtes 16 bits (sections 3 et 12) sont également possibles. Dans ces cas, une « pseudo-adresse 48 bits » (Pseudo 48-bit Address) est formée de la manière suivante. Premièrement, les 32 bits les plus à gauche sont formés en concaténant seize bits zéro à l'identifiant PAN 16 bits (ou, si l'identifiant PAN n'est pas connu, seize bits zéro peuvent être utilisés). Cela produit le champ de 32 bits suivant :

16_bit_PAN:16_zero_bits

Ensuite, ces 32 bits sont concaténés avec l'adresse courte 16 bits. Cela produit l'adresse 48 bits suivante :

32_bits_as_specified_previously:16_bit_short_address

L'identifiant d'interface est formé à partir de cette adresse 48 bits conformément à la spécification « IPv6 over Ethernet » [RFC2464]. Cependant, dans l'identifiant d'interface résultant, le bit « Universal/Local » (U/L) DEVRA être mis à zéro, pour refléter le fait qu'il ne s'agit pas d'une valeur globalement unique. Pour l'un ou l'autre format d'adresse, l'adresse tout-zéro NE DOIT PAS être utilisée.

Des adresses MAC différentes, définies manuellement ou par logiciel, PEUVENT être utilisées pour dériver l'identifiant d'interface. Si une telle adresse MAC est utilisée, sa propriété d'unicité globale devrait être reflétée dans la valeur du bit U/L.

Le préfixe d'adresse IPv6 pour l'autoconfiguration sans état [RFC4862] utilisé pour les interfaces IEEE 802.15.4 DOIT avoir une longueur de 64 bits.

9. Mappage d'adresses multicast (Multicast Address Mapping)​

Les fonctionnalités de cette section DOIVENT être utilisées uniquement dans les réseaux LoWPAN avec réseau maillé activé. Les paquets IPv6 avec une adresse de destination multicast (DST), composée de seize octets DST[1] à DST[16], sont transmis à l'adresse multicast 16 bits 802.15.4 suivante :

                   0                   1
                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |1 0 0|DST[15]* |   DST[16]     |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8 : Format de mappage d'adresse multicast

Ici, DST[15]* désigne les 5 derniers bits de l'octet DST[15], c'est-à-dire les bits 3 à 7 dans DST[15]. Le schéma initial de 3 bits « 100 » suit le format d'adresse 16 bits pour les adresses multicast (section 12).

Cela permet la prise en charge de la multidiffusion au sein d'un réseau 6LoWPAN, mais la spécification complète d'une telle prise en charge dépasse le cadre de ce document. Des exemples de mécanismes incluent : l'inondation (Flooding), l'inondation contrôlée (Controlled Flooding), l'unicast vers le coordinateur PAN, etc. Il est prévu que cela sera spécifié par différents mécanismes de routage en réseau maillé.

10. Compression d'en-tête (Header Compression)​

Il existe de nombreux travaux de standardisation publiés et en cours sur la compression d'en-tête. Cependant, la compression d'en-tête pour IPv6 over IEEE 802.15.4 présente des contraintes différentes, résumées ci-dessous :

  • Les travaux existants supposent de nombreux flux (Flows) entre deux dispositifs quelconques. Ici, nous supposons un style de compression d'en-tête très simple et à faible contexte (Low-Context). Bien que cela soit indépendant du travail sur les flux (il peut y en avoir plusieurs), il n'utilise aucun contexte spécifique à un flux particulier. Par conséquent, il ne peut pas atteindre le niveau de compression qu'un schéma construisant des contextes séparés pour chaque flux à compresser pourrait atteindre.

  • Étant donné la taille de paquet très limitée, il est hautement souhaitable d'intégrer la compression des couches 2 et 3, ce qui n'a traditionnellement pas été fait (bien que cela soit en train de changer grâce au groupe de travail ROHC (RObust Header Compression, compression d'en-tête robuste)).

  • Il est prévu que les dispositifs IEEE 802.15.4 seront déployés dans des réseaux multi-sauts (Multi-Hop Networks). Cependant, la compression d'en-tête dans un réseau maillé diffère du scénario habituel de liaison point à point, dans lequel le compresseur et le décompresseur communiquent directement et exclusivement l'un avec l'autre. Dans les réseaux IEEE 802.15.4, il est hautement souhaitable que les dispositifs puissent envoyer des paquets avec en-tête compressé via n'importe lequel de leurs voisins, avec le moins possible de construction de contexte préalable.

Tout nouveau format de paquet requis pour la compression d'en-tête réutilise le format de paquet de base défini à la section 5 en utilisant différentes valeurs de dispatch (Dispatch Values).

La compression d'en-tête peut entraîner un alignement qui ne tombe pas sur des limites d'octets. Étant donné que le matériel ne peut généralement pas transmettre des données en unités inférieures à l'octet, un rembourrage (Padding) doit être utilisé. Le rembourrage est effectué comme suit : premièrement, toute la série continue d'en-têtes compressés est arrangée (ce document ne définit que des schémas de compression d'en-tête IPv6 et UDP, mais d'autres schémas peuvent être définis ailleurs). Ensuite, des bits zéro sont ajoutés selon les besoins pour s'aligner sur une limite d'octet. Cela compense tout désalignement potentiel causé par la compression d'en-tête, de sorte que les champs suivants (par exemple, les en-têtes non compressés ou la charge utile de données) commencent à une limite d'octet et se poursuivent normalement.

10.1. Encodage des champs d'en-tête IPv6 (Encoding of IPv6 Header Fields)​

En rejoignant le même réseau 6LoWPAN, les dispositifs partagent un certain état. Cela permet de compresser les en-têtes sans avoir à construire explicitement un état de contexte de compression. Par conséquent, la compression d'en-tête 6LoWPAN ne conserve aucun état de flux ; au lieu de cela, elle s'appuie sur des informations liées à l'ensemble du lien. Les valeurs d'en-tête IPv6 suivantes sont prévues comme étant courantes sur les réseaux 6LoWPAN, et l'en-tête HC1 est donc construit pour les compresser efficacement dès le départ :

  • Version est IPv6
  • Les adresses source et de destination IPv6 sont toutes deux locales au lien (Link Local)
  • L'identifiant d'interface IPv6 (les 64 bits inférieurs) de l'adresse source ou de destination peut être déduit des adresses source et de destination de la couche 2 (bien sûr, cela n'est possible que pour les identifiants d'interface dérivés des adresses MAC 802.15.4 sous-jacentes)
  • La longueur du paquet peut être déduite de la couche 2 (le champ « Frame Length » dans le PPDU IEEE 802.15.4) ou du champ « datagram_size » dans l'en-tête de fragmentation (s'il est présent)
  • Traffic Class et Flow Label sont tous deux nuls
  • Next Header est UDP, ICMP ou TCP

Le seul champ de l'en-tête IPv6 qui doit toujours être transporté intégralement est Hop Limit (limite de sauts, 8 bits). Selon le degré de correspondance du paquet avec ce cas courant, différents champs peuvent ne pas être compressibles et doivent donc être transportés « en ligne » (In-Line) (section 10.3.1). Cet en-tête IPv6 courant (tel que décrit ci-dessus) peut être compressé à 2 octets (1 octet pour l'encodage HC1, 1 octet pour Hop Limit), au lieu de 40 octets.

Un tel paquet peut être compressé via le format LOWPAN_HC1 en utilisant la valeur de dispatch de LOWPAN_HC1, suivie du champ « encodage HC1 » de l'en-tête LOWPAN_HC1 (8 bits) pour encoder les différentes combinaisons présentées ci-dessous.

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | HC1 encoding  |     Non-Compressed fields follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9 : LOWPAN_HC1 (encodage d'en-tête compressé courant)

Les champs d'adresse encodés par « l'encodage HC1 » sont interprétés comme suit :

  • PI : Prefix carried in-line (préfixe transporté en ligne)
  • PC : Prefix compressed (préfixe compressé, préfixe local au lien supposé)
  • II : Interface identifier carried in-line (identifiant d'interface transporté en ligne)
  • IC : Interface identifier elided (identifiant d'interface omis, peut être dérivé de l'adresse de couche liaison correspondante)

Encodage HC1 (du bit 0 au bit 7) :

Adresse source IPv6 (bits 0 et 1) :

  • 00 : PI, II
  • 01 : PI, IC
  • 10 : PC, II
  • 11 : PC, IC

Adresse de destination IPv6 (bits 2 et 3) :

  • 00 : PI, II
  • 01 : PI, IC
  • 10 : PC, II
  • 11 : PC, IC

Traffic Class et Flow Label (bit 4) :

  • 0 : non compressé ; envoyer le Traffic Class complet sur 8 bits et le Flow Label sur 20 bits
  • 1 : Traffic Class et Flow Label sont nuls

Next Header (bits 5 et 6) :

  • 00 : non compressé ; envoyer les 8 bits complets
  • 01 : UDP
  • 10 : ICMP
  • 11 : TCP

Encodage HC2 (bit 7) :

  • 0 : pas d'autres bits de compression d'en-tête
  • 1 : l'encodage HC1 est immédiatement suivi de bits de compression d'en-tête supplémentaires selon le format d'encodage HC2. Les bits 5 et 6 déterminent quels encodages HC2 possibles s'appliquent (par exemple, encodages UDP, ICMP ou TCP).

10.2. Encodage des champs d'en-tête UDP (Encoding of UDP Header Fields)​

Les bits 5 et 6 de LOWPAN_HC1 permettent de compresser le champ Next Header dans l'en-tête IPv6 (pour UDP, TCP et ICMP). Il est également possible de compresser davantage chacun de ces en-têtes de protocole. Cette section explique comment compresser l'en-tête UDP lui-même. L'encodage HC2 dans cette section est l'encodage HC_UDP, qui ne s'applique que lorsque les bits 5 et 6 de HC1 indiquent que le protocole suivant l'en-tête IPv6 est UDP.

L'encodage HC_UDP permet de compresser les champs suivants de l'en-tête UDP : port source (Source Port), port de destination (Destination Port) et longueur (Length). Le champ de somme de contrôle (Checksum) de l'en-tête UDP n'est pas compressé et est donc transporté intégralement. Le schéma défini ci-dessous permet de compresser l'en-tête UDP à 4 octets, au lieu des 8 octets d'origine.

Le seul champ d'en-tête UDP dont la valeur peut être déduite d'informations disponibles ailleurs est Length. Les autres champs doivent être transportés en ligne, intégralement ou de manière partiellement compressée (section 10.3.2).

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |HC_UDP encoding|     Fields carried in-line follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10 : HC_UDP (encodage d'en-tête UDP compressé courant)

« Encodage HC_UDP » pour UDP (du bit 0 au bit 7) :

Port source UDP (bit 0) :

  • 0 : non compressé, transporté en ligne
  • 1 : compressé à 4 bits. Le port source 16 bits réel est obtenu par calcul : P + valeur short_port. La valeur de P est le nombre 61616 (0xF0B0). short_port est représenté comme une valeur de 4 bits, transportée en ligne

Port de destination UDP (bit 1) :

  • 0 : non compressé, transporté en ligne
  • 1 : compressé à 4 bits. Le port de destination 16 bits réel est obtenu par calcul : P + valeur short_port. La valeur de P est le nombre 61616 (0xF0B0). short_port est représenté comme une valeur de 4 bits, transportée en ligne

Length (bit 2) :

  • 0 : non compressé, transporté en ligne
  • 1 : compressé, la longueur est calculée à partir des informations de longueur de l'en-tête IPv6. La valeur du champ de longueur UDP est égale à la Payload Length de l'en-tête IPv6, moins la longueur de tout en-tête d'extension présent entre l'en-tête IPv6 et l'en-tête UDP

Réservé (bits 3 à 7)

10.3. Champs non compressés (Non-Compressed Fields)​

10.3.1. Champs IPv6 non compressés (Non-Compressed IPv6 Fields)​

Ce schéma permet de compresser l'en-tête IPv6 à différents degrés. Par conséquent, seuls les champs non compressés doivent être envoyés, et non l'intégralité de l'en-tête IPv6 (standard). Les en-têtes suivants (spécifiés par le champ Next Header dans l'en-tête IPv6 d'origine) suivent immédiatement les champs IPv6 non compressés.

Le champ IPv6 non compressé qui DOIT toujours être présent est Hop Limit (8 bits). Ce champ DOIT toujours suivre les champs d'encodage (par exemple, « l'encodage HC1 » comme illustré à la figure 9, pouvant inclure d'autres champs d'encodage futurs). Les autres champs non compressés DOIVENT suivre Hop Limit dans l'ordre impliqué par « l'encodage HC1 », exactement dans le même ordre que celui indiqué ci-dessus (section 10.1) : préfixe d'adresse source (64 bits) et/ou identifiant d'interface (64 bits), préfixe d'adresse de destination (64 bits) et/ou identifiant d'interface (64 bits), Traffic Class (8 bits), Flow Label (20 bits) et Next Header (8 bits). L'en-tête suivant réel (par exemple, UDP, TCP, ICMP, etc.) suit les champs non compressés.

10.3.2. Champs UDP non compressés et partiellement compressés (Non-Compressed and Partially Compressed UDP Fields)​

Ce schéma permet de compresser l'en-tête UDP à différents degrés. Par conséquent, seuls les champs non compressés ou partiellement compressés doivent être envoyés, et non l'intégralité de l'en-tête UDP (standard).

Les champs en ligne non compressés ou partiellement compressés de l'en-tête UDP DOIVENT toujours suivre l'en-tête IPv6 et tous ses champs en ligne associés. Tout champ en ligne d'en-tête UDP présent DOIT apparaître dans le même ordre que les champs correspondants dans l'en-tête UDP normal [RFC0768], par exemple, port source, port de destination, longueur et somme de contrôle. Si le port source ou de destination utilise la notation « short_port » (comme indiqué dans l'en-tête UDP compressé), le numéro de port en ligne prend 4 bits au lieu de 16 bits.

Bien qu'il soit prévu que les réseaux 802.15.4 utiliseront généralement le routage en réseau maillé (Mesh Routing), la spécification IEEE 802.15.4-2003 [ieee802.15.4] ne définit pas une telle capacité. Dans ce contexte, les dispositifs à fonctionnalité complète (Full Function Devices, FFDs) exécutent des protocoles de routage ad hoc ou en réseau maillé pour remplir leurs tables de routage (hors du cadre de ce document). Dans ce scénario de réseau maillé, deux dispositifs n'ont pas besoin d'être directement accessibles pour communiquer. Parmi ces dispositifs, l'émetteur est appelé « émetteur d'origine » (Originator) et le récepteur est appelé « destination finale » (Final Destination). Le dispositif émetteur d'origine peut utiliser d'autres dispositifs intermédiaires comme relais (Forwarders) vers la destination finale. Pour réaliser cette livraison de trames en utilisant l'unicast, les adresses de couche liaison de l'émetteur d'origine et de la destination finale doivent être incluses en plus des adresses source et de destination saut par saut.

Cette section définit comment réaliser la livraison de trames de couche 2 dans un réseau maillé, étant donné l'adresse de couche liaison de la « destination finale » cible.

La livraison en réseau maillé est réalisée en incluant un en-tête d'adressage réseau maillé (Mesh Addressing Header) avant tout autre en-tête dans l'encapsulation LoWPAN (section 5), y compris les en-têtes non fragmentés et fragmentés ; l'en-tête IPv6 complet ; ou l'en-tête IPv6 compressé selon la section 10 ou défini ailleurs.

Si un nœud souhaite utiliser le relais réseau maillé par défaut pour livrer un paquet (c'est-à-dire parce qu'il n'a pas d'accessibilité directe vers la destination), il DOIT inclure un en-tête d'adressage réseau maillé dans lequel l'adresse de couche liaison de l'émetteur d'origine est définie comme la sienne, et l'adresse de couche liaison de la destination finale est définie comme la destination finale du paquet. Il définit l'adresse source dans l'en-tête 802.15.4 comme sa propre adresse de couche liaison, et place l'adresse de couche liaison du relais dans le champ d'adresse de destination de l'en-tête 802.15.4. Enfin, il transmet le paquet.

De même, si un nœud reçoit une trame avec un en-tête d'adressage réseau maillé, il DOIT examiner le champ « Final Destination » de l'en-tête d'adressage réseau maillé pour déterminer la vraie destination. Si le nœud lui-même est la destination finale, il consomme le paquet selon la livraison normale. S'il n'est pas la destination finale, le dispositif décrémente le champ « Hops Left » et, si le résultat est zéro, rejette le paquet. Sinon, le nœud interroge sa table de routage de couche liaison, détermine quel devrait être le prochain saut vers la destination finale, et place cette adresse dans le champ d'adresse de destination de l'en-tête 802.15.4. Enfin, le nœud change l'adresse source dans l'en-tête 802.15.4 en sa propre adresse de couche liaison et transmet le paquet.

Bien qu'un nœud DOIVE participer à un protocole de routage en réseau maillé pour être un relais, il n'existe pas d'exigence similaire pour utiliser uniquement le transfert en réseau maillé. Seuls les « dispositifs à fonctionnalité complète » (FFDs) sont prévus pour participer comme routeurs dans le réseau maillé. Les « dispositifs à fonctionnalité réduite » (Reduced Function Devices, RFDs) se limitent à découvrir les FFDs et à les utiliser pour tout transfert, d'une manière similaire à celle dont les hôtes IP utilisent généralement un routeur par défaut pour transférer tout leur trafic hors lien. Pour un RFD utilisant la livraison en réseau maillé, le « relais » est toujours un FFD approprié.

11.1. Diffusion LoWPAN (LoWPAN Broadcast)​

Les capacités de routage en réseau maillé supplémentaires sont encodées à l'aide d'un en-tête de routage (Routing Header) placé immédiatement après l'en-tête réseau maillé. En particulier, l'en-tête de diffusion est composé du dispatch LOWPAN_BC0 suivi d'un champ de numéro de séquence (Sequence Number). Le numéro de séquence est utilisé pour détecter les paquets dupliqués (et, espérons-le, les supprimer).

                       1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0|1|LOWPAN_BC0 |Sequence Number|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 11 : En-tête de diffusion

Définition des champs :

Sequence Number (numéro de séquence) : Ce champ de 8 bits DEVRA être incrémenté chaque fois que l'émetteur d'origine envoie un nouveau paquet de diffusion ou de multidiffusion en réseau maillé. La spécification complète de la façon de traiter ce champ dépasse le cadre de ce document.

Les implications supplémentaires de cette diffusion au niveau de la couche réseau maillé, par exemple si elle correspond à un mécanisme d'inondation contrôlée ou son rôle dans la découverte de topologie, dépassent le cadre de ce document.

Les capacités de routage en réseau maillé supplémentaires, telles que la spécification d'un protocole de routage en réseau maillé, le routage à la source, etc., peuvent être exprimées en définissant des en-têtes de routage supplémentaires placés avant les en-têtes de fragmentation ou d'adressage dans la pile d'en-têtes. La spécification complète de telles capacités de routage en réseau maillé dépasse le cadre de ce document.

12. Considérations IANA (IANA Considerations)​

Ce document crée deux nouveaux registres IANA, décrits ci-dessous. Les futures attributions dans ces registres seront coordonnées via l'IANA selon la politique « Specification Required » (spécification requise) [RFC2434]. Il est prévu que cette politique permettra à d'autres organisations (non-IETF) d'obtenir plus facilement des attributions.

Registre du champ de type de dispatch (Dispatch Type Field Registry)​

Ce document crée un nouveau registre IANA pour le champ de type de dispatch (Dispatch Type Field) présenté dans les définitions d'en-tête de la section 5. Ce document définit des valeurs pour IPv6, la compression d'en-tête LOWPAN_HC1, la diffusion BC0 et deux modes d'échappement (NALP pour « n'est pas une trame LoWPAN », ESC pour permettre des octets de dispatch supplémentaires). Ce document définit ce champ comme ayant une longueur de 8 bits. Les valeurs 00xxxxxx sont réservées et non utilisées, permettant un total de 192 valeurs différentes, ce qui devrait être suffisant. Si des formats de compression d'en-tête autres que HC1 sont définis, ou si des formats HC2 supplémentaires pour TCP et ICMP sont définis, il est prévu qu'ils utiliseront les valeurs de dispatch réservées après LOWPAN_HC1. Si des formats de livraison en réseau maillé supplémentaires sont définis, ils utiliseront les valeurs réservées après LOWPAN_BC0.

Registre des adresses courtes 16 bits (16-bit Short Address Registry)​

Ce document crée un nouveau registre IANA pour le champ d'adresse courte 16 bits utilisé dans les paquets 6LoWPAN.

                   0                   1
                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |     16-bit short Address      |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 12 : Format d'adresse courte 16 bits

Ce registre DOIT inclure l'adresse 0xffff (l'adresse de diffusion 16 bits acceptée par tous les dispositifs écoutant le canal) et 0xfffe, telles que définies dans [ieee802.15.4]. De plus, au sein d'un réseau 6LoWPAN, les adresses courtes 16 bits DOIVENT respecter ce format (en référençant les champs de bits de 0 à 7), où « x » est un espace réservé pour les valeurs de bits non spécifiées :

Plage 1, 0xxxxxxxxxxxxxxx : Si l'adresse 16 bits est une adresse unicast (Unicast Address), le premier bit (bit 0) DEVRA être zéro. Cela laisse 15 bits pour l'adresse réelle.

Plage 2, 100xxxxxxxxxxxxx : Si l'adresse 16 bits est une adresse multicast (Multicast Address) (voir section 9), les bits 0, 1 et 2 DEVRONT suivre ce schéma. Cela laisse 13 bits pour l'adresse multicast réelle.

Plage 3, 101xxxxxxxxxxxxx : Ce schéma pour les bits 0, 1 et 2 est réservé. Toute attribution future devrait suivre la politique ci-dessus.

Plage 4, 110xxxxxxxxxxxxx : Ce schéma pour les bits 0, 1 et 2 est réservé. Toute attribution future devrait suivre la politique ci-dessus.

Plage 5, 111xxxxxxxxxxxxx : Ce schéma pour les bits 0, 1 et 2 est réservé. Toute attribution future devrait suivre la politique ci-dessus.

13. Considérations de sécurité (Security Considerations)​

La méthode de dérivation des identifiants d'interface (Interface Identifiers) à partir des adresses MAC EUI-64 vise à maintenir l'unicité globale dans la mesure du possible. Cependant, aucune protection n'existe contre les doublons causés par accident ou par falsification.

La découverte de voisins (Neighbor Discovery) dans les liaisons IEEE 802.15.4 peut être vulnérable aux menaces détaillées dans [RFC3756]. Le routage en réseau maillé est prévu comme étant courant dans les réseaux IEEE 802.15.4. Cela implique des menaces supplémentaires dues au routage ad hoc selon [KW03]. IEEE 802.15.4 fournit certaines capacités pour la sécurité au niveau de la couche liaison. Si possible et pratique, il est fortement recommandé aux utilisateurs d'utiliser de telles dispositions. Cela atténuera les menaces mentionnées ci-dessus.

Il est prévu qu'une proportion significative des dispositifs IEEE 802.15.4 communiquera toujours au sein de leur PAN (c'est-à-dire, dans leur lien en termes IPv6). En réponse aux considérations de coût et de consommation d'énergie, et en accord avec le modèle des « dispositifs à fonctionnalité réduite » (Reduced Function Devices, RFDs) IEEE 802.15.4, ces dispositifs implémenteront généralement l'ensemble minimal de fonctionnalités nécessaires. Par conséquent, la sécurité de tels dispositifs peut dépendre dans une large mesure des mécanismes définis par IEEE 802.15.4 au niveau de la couche liaison. Cependant, ces derniers ne définissent que les modes AES (Advanced Encryption Standard, standard de chiffrement avancé) pour l'authentification ou le chiffrement des trames IEEE 802.15.4, et en particulier ne spécifient pas la gestion des clés (qui peut être orientée groupe). D'autres problèmes à résoudre dans les déploiements réels concernent la configuration et la gestion de la sécurité. Bien que la situation complète dépasse le cadre de ce document, de telles considérations doivent être prises en compte lors du déploiement de réseaux IEEE 802.15.4. Bien sûr, il est également prévu que certains dispositifs IEEE 802.15.4 (les « dispositifs à fonctionnalité complète » ou « FFDs ») implémenteront des fonctions de coordination ou d'intégration. Ceux-ci peuvent communiquer périodiquement avec des pairs IPv6 hors lien (en plus des échanges intra-lien plus courants). De tels dispositifs IPv6 devraient utiliser des mécanismes courants (par exemple, IPsec, TLS, etc.) pour protéger leurs communications de bout en bout.

14. Remerciements (Acknowledgements)​

Nous remercions les auteurs des RFC 2464 et RFC 2734, car certaines parties de ce document ont été rédigées en suivant leur modèle. Nous remercions Geoff Mulligan pour ses discussions utiles qui ont contribué à façonner ce document. Les suggestions d'Erik Nordmark ont joué un rôle déterminant dans la section sur la compression d'en-tête. Nous remercions également Shoichi Sakane, Samita Chakrabarti, Vipul Gupta, Carsten Bormann, Ki-Hyung Kim, Mario Mao, Phil Levis, Magnus Westerlund et Jari Arkko.