2. Spezifische Aktualisierungen zu RFC 4944

Dieses Dokument spezifiziert ein Header-Kompressionsformat, das dazu bestimmt ist, das in Abschnitt 10 von [RFC4944] definierte Format zu ersetzen. Die Implementierung von Abschnitt 10 von [RFC4944] wird nun NICHT EMPFOHLEN (NOT RECOMMENDED). Neue Implementierungen KÖNNEN (MAY) die Dekompression gemäß Abschnitt 10 von [RFC4944] implementieren, SOLLTEN ABER NICHT (SHOULD NOT) Pakete senden, die gemäß Abschnitt 10 von [RFC4944] komprimiert sind.

Eine konforme Implementierung von [RFC4944], wie durch dieses Dokument aktualisiert, MUSS (MUST) in der Lage sein, ein empfangenes Paket, das von den Bestimmungen dieses Dokuments Gebrauch macht, ordnungsgemäß zu verarbeiten. Eine konforme Implementierung KANN (MAY) zusätzliche LOWPAN_NHC-Typen (Abschnitt 4) implementieren, die in Zukunft registriert werden können (Abschnitt 5). Es liegt außerhalb des Geltungsbereichs dieses Dokuments, wie ein Kompressor erfährt, dass ein Dekompressor über zusätzliche Fähigkeiten verfügt.

Abschnitt 5.3 von [RFC4944] definiert auch, wie komprimierte IPv6-Datagramme fragmentiert werden, die nicht in einen einzelnen Link-Frame passen. Abschnitt 5.3 von [RFC4944] definiert die Werte datagram_size und datagram_offset des Fragment-Headers als die Größe und den Offset des IPv6-Datagramms vor der Kompression. Infolgedessen muss alle Fragment-Nutzlast außerhalb des ersten Fragments ihre jeweiligen Teile des IPv6-Datagramms vor der Kompression tragen. Dieses Dokument ändert diese Anforderung nicht. Bei Verwendung des in Abschnitt 5.3 von [RFC4944] beschriebenen Fragmentierungsmechanismus DARF jeder Header, der nicht in das erste Fragment passt, NICHT (MUST NOT) komprimiert werden.

Das in diesem Dokument definierte Header-Kompressionsformat verdrängt den in Abschnitt 5.1 von [RFC4944] definierten ESC-Dispatch-Wert. Stattdessen ist der Wert 01 000000 als Ersatzwert für ESC reserviert, der endgültig mit der ersten Zuweisung von Erweiterungsbytes zugewiesen wird.