2. Mises à jour spécifiques de la RFC 4944

Ce document spécifie un format de compression d'en-tête qui est destiné à remplacer celui défini dans la Section 10 de la [RFC4944]. L'implémentation de la Section 10 de la [RFC4944] est désormais NON RECOMMANDÉE (NOT RECOMMENDED). Les nouvelles implémentations PEUVENT (MAY) implémenter la décompression selon la Section 10 de la [RFC4944] mais NE DEVRAIENT PAS (SHOULD NOT) envoyer de paquets compressés selon la Section 10 de la [RFC4944].

Une implémentation conforme de la [RFC4944] telle que mise à jour par ce document DOIT (MUST) être capable de traiter correctement un paquet reçu qui utilise les dispositions de ce document. Une implémentation conforme PEUT (MAY) implémenter des types LOWPAN_NHC supplémentaires (Section 4) qui peuvent être enregistrés (Section 5) à l'avenir. La manière dont un compresseur apprend qu'un décompresseur a des capacités supplémentaires est hors de portée de ce document.

La Section 5.3 de la [RFC4944] définit également comment fragmenter des datagrammes IPv6 compressés qui ne tiennent pas dans une seule trame de liaison. La Section 5.3 de la [RFC4944] définit les valeurs datagram_size et datagram_offset de l'en-tête de fragment comme la taille et le décalage du datagramme IPv6 avant compression. En conséquence, toute la charge utile de fragment en dehors du premier fragment doit porter ses portions respectives du datagramme IPv6 avant compression. Ce document ne change pas cette exigence. Lors de l'utilisation du mécanisme de fragmentation décrit dans la Section 5.3 de la [RFC4944], tout en-tête qui ne peut pas tenir dans le premier fragment NE DOIT PAS (MUST NOT) être compressé.

Le format de compression d'en-tête défini dans ce document préempte la valeur de dispatch ESC définie dans la Section 5.1 de la [RFC4944]. Au lieu de cela, la valeur 01 000000 est réservée comme valeur de remplacement pour ESC, pour être finalement attribuée avec la première attribution d'octets d'extension.