Internet-Draft SCHC ICMPv6 Compression October 2024
Barthel & Toutain Expires 24 April 2025 [Page]
Workgroup:
schc Working Group
Internet-Draft:
draft-ietf-schc-icmpv6-compression-00
Published:
Intended Status:
Informational
Expires:
Authors:
D. Barthel
L. Toutain
IMT Atlantique

Static Context Header Compression (SCHC) for the Internet Control Message Protocol (ICMPv6)

Abstract

This document describes how the ICMPv6 protocol can be integrated into the SCHC architecture. It extends the YANG Data Model described in [RFC9363] with new field IDs specific to ICMPv6 headers as defined in [RFC4443].

To enhance the compression of ICMPv6 error messages, the document also introduces two new Matching Operators and two new Compression Decompression Actions to manipulate the ICMPv6 payload.

Finally, for constrained networks such as LPWAN, it introduces a proxy behavior, where a SCHC Core end-point may anticipate the device reaction to incorrect messages.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 24 April 2025.

Table of Contents

1. Introduction

When applying SCHC compression to IPv6 networks, users expect to perform control operations such as ping to ensure that devices are still active. In the same way, ICMPv6 error messages can be helpful for the Device which may adapt its behavior when the Application becomes unreachable. The Application may also benefit from the ICMPv6 error message produced by the SCHC entity when the compression is not possible.

The compression described in this document is not limited to traffic over LPWANs, but can be applied to any kind of network. The ICMPv6 messages covered by this document are those defined in ICMPv6 protocol [RFC4443]. The compression described in this document does not cover other ICMPv6 messages, such as an extended format of the same messages [RFC4884] and other messages used by the Neighbor Discovery Protocol [RFC4861].

ICMPv6 defines a generic message format, which is used to inform the source of an IPv6 packets about errors during the packet delivery. It also specifies messages used by the ping command to test connectivity with a remote node.

[RFC4443] instantiates four such error messages:

[RFC4443] also defines two informational messages, the Echo Request (type=128) and Echo Reply messages (type = 129), which provide support for the ping application.

This document describes recommended compression of ICMPv6/IPv6 messages (including header fields and structured payload) and extends SCHC by specifying new Field Identifiers for ICMPv6 and two MO and two CDA to compress the ICMPv6 payload. This covers different scenarios:

2. Terminology

This draft re-uses the Terminology defined in [RFC8724] and the achitecture document.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Use cases

In the following sections, we will describe at Section 4 ICMPv6 message compression for all ICMPv6 messages specified in [RFC4443]. We will then extend this basic compression with a specific focus on the following cases:

4. ICMPv6 compression

This section defines ICMPv6 fields that can be compressed by SCHC. [RFC4443] defines several formats with respect to the type of the ICMPv6 message.

From them, several fields can be extracted (the field ID identifiers are specified in the augmentation of the YANG Data Model Section 9):

These fields are present in all the messages:

The other fields depends of the message type:

Since the fields present in an ICMP message differ from one type to another, it is not possible to use a single rule to compress all ICMP messages. The next section gives some examples of ICMP message compression rules.

4.1. Rule Examples

Table 1 gives an example of the Destination Unreachable message sent to a Device. The Type is 1 and can be elided, Code can be reduced to 3 bits with a Matching List. The Unused field does not appear in the rule, and payload is sent integrally. Since the payload size cannot be easily guessed, this field is marked as variable, which adds 4 bits if its length is less than 255 bytes and 12 bits otherwise.

To reduce the size of the SCHC message, the Payload can be elided with the not-sent CDA instead of the value-sent CDA, or the new CDA introduced Section 7.2 may be used to compress it using SCHC rules.

Table 1: Example of Destination Unreachable compression rule.
Field FL FP DI Value Matching Operator CDA Sent bits
IPv6 Headers description
ICMPv6 Type 8 1 Dw 1 equal not-sent
ICMPv6 Code 8 1 Dw [0,1,2,3,4,5,6] match-mapping mapping-sent 3
ICMPv6 Checksum 1 1 Dw ignore compute-*
ICMPv6 Payload var 1 Dw 0 ignore value-sent (data length*8) + 4 or +12

Table 2 shows an example of the Packet Too Big message compression Rule. In this Rule, the MTU field is present. If the maximum MTU is 1500 Bytes, the value is coded on 11 bits, therefore, the 21 left-most bit can be elided, with the MSB/LSB MO/CDA.

Table 2: Example of Packet Too Big compression rule.
Field FL FP DI Value Matching Operator CDA Sent bits
IPv6 Headers description
ICMPv6 Type 8 1 Dw 2 equal not-sent
ICMPv6 Code 8 1 Dw 0 equal not-sent 3
ICMPv6 Checksum 1 1 Dw ignore compute-*
ICMPv6 MTU 32 1 Dw MSB(21) LSB
ICMPv6 Payload var 1 Dw 0 ignore value-sent (data length*8) + 4 or +12

5. Device does a ping

A Device may send an Echo Request message to check the availability of the network and the host running the Application.

If a ping Echo Request is generated by a Device, then SCHC compression applies.

The format of an ICMPv6 Echo Request message is described in Figure 1, with Type=128 and Code=0.

       0                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Identifier          |        Sequence Number        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Data ...
      +-+-+-+-+-

Figure 1: ICMPv6 Echo Request message format

If we assume that one rule will be devoted to compressing Echo Request messages, then the Type and Code are known in the rule to be 128 and 0 and can therefore be elided with the not-sent CDA.

Checksum can be reconstructed with the compute-* CDA and therefore is not transmitted.

[RFC4443] states that the identifier and sequence number are meant to “help in matching Echo Responses to this Echo Request” and that they “may be zero”. Data are "zero or more bytes of arbitrary data”.

For constrained devices or networks, we recommend that the Identifier be zero, the Sequence Number be a counter on 3 bits, and the Data be zero bytes (absent). Therefore, Identifier is elided with the not-sent CDA, Sequence Number is transmitted on 3 bits with the LSB CDA and no Data is transmitted.

The data part is defined in the rule through the ICMPv6 Payload field. The payload can be sent as a residue with a value-sent. It is also possible to elide the data by setting them in the Target Value and use a not-sent CDA.

When the destination receives the Echo Request message, it will respond with an Echo Reply message. This message bears the same format as the Echo Request message but with Type = 129 (see Figure 1).

[RFC4443] states that the Identifier, Sequence Number, and Data fields of the Echo Reply message shall contain the same values as the invoking Echo Request message. Therefore, a rule shall be used similar to that used for compressing the Echo Request message.

5.1. Rule example

The following rule gives an example of a SCHC compression. The type can be elided if the direction is taken into account. Identifier is ignored and generated as 0 at decompression. This implies that only one single ping can be launched at any given time on a device. Finally, only the least significant 8 bits of the sequence number are sent on the LPWAN, allowing a serie of 255 consecutive pings.

Table 3: Example of compression rule for a ping from the device
Field FL FP DI Value Matching Operator CDA Sent bits
IPv6 Headers description
ICMPv6 Type 8 1 Up 128 equal not-sent
ICMPv6 Type 8 1 Dw 129 equal not-sent
ICMPv6 Code 8 1 Bi 0 equal not-sent
ICMPv6 Identifier 16 1 Bi 0 ignore not-sent
ICMPv6 Sequence 16 1 Bi 0 MSB(13) LSB 3
ICMPv6 Checksum 1 1 Dw ignore compute-*
ICMPv6 Payload var 1 Bi 0 ignore value-sent (data*8) + 4 or +12

The transmission cost of the Echo Request message is therefore the size of the Rule Id + 3 bits and the data size increased of the Payload residue size. The rule ID Length can be chosen to avoid adding padding.

6. Device is the source of an ICMPv6 error message

As stated in [RFC4443], a node should generate an ICMPv6 message in response to an IPv6 packet that is malformed or which cannot be processed due to some incorrect field value.

The general intent of this document is to spare both the Device and the LPWAN network this un-necessary traffic. The incorrect packets should be caught at the SCHC Core and the ICMPv6 notification should be sent back from there.

     Device       NGW     SCHC Core                    Internet Host

       |           |            |    Destination Port=XXX    |
       |           |            |<---------------------------|
       |           |            |                            |
       |           |            |--------------------------->|
       |           |            | ICMPv6 Port Unreachable    |
       |           |            |                            |
       |           |            |                            |


Figure 2: Example of ICMPv6 error message sent back to the Internet

Figure 2 shows an example of an IPv6 packet trying to reach a Device.

Let's assume that no rule matches the incoming packet (i.e. there is no co-compression rule)

Instead of sending the packet over the LPWAN and having this packet rejected by the Device, the SCHC Core issues an ICMPv6 error message “Destination Unreachable” (Type 1) with Code 1 (“Port Unreachable”) on behalf of the Device.

In that case the SCHC C/D MAY act as a router (i.e. it MUST have a routable IPv6 address to generate an ICMPv6 message). When compressing a packet containing an IPv6 header, no compression rules are found and:

7. Device is the destination of an ICMPv6 error message

In this situation, a Device has been configured to send information to a server on the Internet. If this server becomes no longer accessible, an ICMPv6 message will be generated back towards the Device by either an intermediate router or the destination. This information can be useful to the Device, for example, for reducing the reporting rate in case of periodic reporting of data.

Therefore, the ICMPv6 error message should reach the Device. The data inside this error message includes the packet at the origin of the error. It should be compressed by the SCHC Core, but in the reverse direction. New MOs and CDAs are introduced to perform this operation. The MO check is a rule that matches the Target Value in the forward or reverse direction and the CDA performs this compression.

     Device       NGW     SCHC Core                    Internet Server

       |           |            |                            |
       | SCHC compressed IPv6   |                            |
       |~~~~~~~~~~~|----------->|----------------------X     |
       |           |            |<---------------------      |
       |<~~~~~~~~~~|------------| ICMPv6 Host unreachable    |
       |SCHC compressed ICMPv6  | payload: IPv6 packet       |
       |payload: compressed IPv6|                            |
       |           |            |                            |


Figure 3: Example of ICMPv6 error message sent back to the Device

Figure 3 illustrates this behavior. The ICMPv6 error message is compressed as described in Section 7.3 and forwarded over the LPWAN to the Device.

The SCHC returning message contains the SCHC residue of the ICMPv6 message and MAY contain the compressed original message contained in the ICMP message. The compression can be done by the SCHC Core by reversing the direction as if this message was issued by the device.

7.1. Matching Operator rule match and reverse rule match.

If the Target Value contains a header, this matching operator returns True if a Rule exists in the current Set of Rule to compress it. The selection can either be done:

  • in the same direction of the End-Point, this can be used to compress a protocol encapsulated in the header.
  • in the reverse direction of the end point, as in an ICMPv6 error message.

7.2. Compression Decompression Actions to compress Target Values.

These CDAs compress-sent and rev-compress-sent compress the Target Value using rules defined in the current Set of Rules. This CDA MUST be used in conjunction with the Matching Operators defined in Section 7.1 according to the direction. The compression is using the same direction as the End-Point, the reverse compression uses the opposite direction.

7.3. Example of ICMPv6 error message compression.

The ICMPv6 error messages defined in [RFC4443] contain the fields shown in Figure 4.

       0                   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Value/Unused                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    As much of invoking packet                 |
      +                as possible without the ICMPv6 packet          +
      |                exceeding the minimum IPv6 MTU                 |

Figure 4: ICMPv6 Error Message format

[RFC4443] states that Type can take the values 1 to 4, and Code can be set to values between 0 and 6. Value is unused for the Destination Unreachable and Time Exceeded messages. It contains the MTU for the Packet Too Big message and a pointer to the byte causing the error for the Parameter Error message.

The payload is viewed as a field. An unsued field MUST not appear in the compressoin rules.

The source address of the message SHOULD be "ignore", since it can be initiated by any router on the path.

The following generic rule can therefore be used to compress all ICMPv6 error messages as defined today. More specific rules can also be defined to achieve better compression of some error messages.

The Type field can be associated with a matching list [1, 2, 3, 4] and is therefore compressed to 2 bits. Code can be reduced to 3 bits using the LSB CDA. Value can be sent on 11 bits using the LSB CDA, but if the Device is known to send smaller packets, then the size of this field can be further reduced.

The first rule example Table 4 just sends the ICMP type and code as residue to the device.

Table 4: Example of compression rule for a ICMP error to a device
Field FL FP DI Value Matching Operator CDA Sent bits
IPv6 Headers description
ICMPv6 Type 8 1 Dw 3 equal not-sent
ICMPv6 Code 8 [0, 1] Dw 0 equal not-sent 1
ICMPv6 Checksum 1 1 Dw ignore compute-*
ICMPv6 Payload var 1 Dw 0 ignore not-sent 0

The second rule example Table 5 also only sends the ICMP type and code as residue to the device, but introduces the new MO "rev-rule match". This MO will check if a rule matches the payload.

Table 5: Example of compression rule for a ICMP error to a device
Field FL FP DI Value Matching Operator CDA Sent bits
IPv6 Headers description
ICMPv6 Type 8 1 Dw 3 equal not-sent
ICMPv6 Code 8 1 Dw [0,1] match-mapping mapping-sent 1
ICMPv6 Checksum 1 1 Dw ignore compute-*
ICMPv6 Payload var 1 Dw 0 rev-rule-match not-sent

By [RFC4443], the rest of the ICMPv6 message must contain as much as possible of the IPv6 offending (invoking) packet that triggered this ICMPv6 error message. This information is used to try and identify the SCHC rule that was used to decompress the offending IPv6 packet. If the rule can be found, then the Rule Id is added at the end of the compressed ICMPv6 message. Otherwise, the compressed packet ends with the compressed Value field.

The third rule example Table 6 also sends the ICMP type, code, and the compresssed payload as residue. It can be noted that this field is identified as "variable" in the rule, which will introduce a size before the IPv6 compressed header of 4 or 12 bits.

Table 6: Example of compression rule for a ICMP error to a device
Field FL FP DI Value Matching Operator CDA Sent bits
IPv6 Headers description
ICMPv6 Type 8 1 Dw 3 equal not-sent
ICMPv6 Code 8 1 Dw [0,1] match-mapping mapping-sent 1
ICMPv6 Checksum 1 1 Dw ignore compute-*
ICMPv6 Payload var 1 Dw 0 rev-rule-match rev-compress-sent (compressed IPv6 header*8) + 4 or +12

8. YANG identities and tree

This YANG module extends Field ID identities to includes fields contained in ICMPv6 header. Note that the ICMPv6 payload is parsed to the specific field "fid-icmpv6-payload"

It also defines two new Mactching Operator identities:

The Field Value may be compressed by a rule. The result SHOULD be included in the SCHC message as a variable length residue. It contains the Rule ID used by the compression, the residue, the payload and some padding bits since the variable length in it is in bytes.

9. YANG Module

module ietf-schc-oam {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-schc-oam";
  prefix schc-oam;

  import ietf-schc {
      prefix schc;
  }

  organization
    "IETF IPv6 over Low Power Wide-Area Networks (lpwan) working group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/lpwan/about/>
     WG List:  <mailto:p-wan@ietf.org>
     Editor:   Laurent Toutain
       <mailto:laurent.toutain@imt-atlantique.fr>
     Editor:   Ana Minaburo
       <mailto:ana@minaburo.com>";
  description
     "
     Copyright (c) 2021 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Simplified BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
     for full legal notices.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.

     *************************************************************************

     This module extends the ietf-schc module to include the compound-ack
     behavior for Ack On Error as defined in RFC YYYY.
     It introduces a new leaf for Ack on Error defining the format of the
     SCHC Ack and add the possibility to send several bitmaps in a single
     answer.";

  revision 2024-05-19 {
    description
      "Initial version for RFC YYYY ";
    reference
      "RFC YYYY: OAM";
  }

  identity fid-icmpv6-base-type {
    base schc:fid-base-type;
    description
      "Field IP base type for ICMPv6 headers described in RFC 4443";
    reference
      "RFC 4443   Internet Control Message Protocol (ICMPv6)
                  for the Internet Protocol Version 6 (IPv6) Specification";
  }

// ICMPv6 Fields

  identity fid-icmpv6-type {
    base schc:fid-icmpv6-base-type;
    description
      "ICMPv6 code field present in all ICMPv6 messages.";
  }

  identity fid-icmpv6-code {
    base schc:fid-icmpv6-base-type;
    description
      "ICMPv6 code field present in all ICMPv6 messages.";
  }

  identity fid-icmpv6-checksum {
    base schc:fid-icmpv6-base-type;
    description
      "ICMPv6 checksum field present in all ICMPv6 messages.";
  }

    identity fid-icmpv6-mtu {
    base schc:fid-icmpv6-base-type;
    description
      "ICMPv6 MTU, present in Packet Too Big message.";
  }

  identity fid-icmpv6-pointer {
    base schc:fid-icmpv6-base-type;
    description
      "ICMPv6 Pointer, present in Parameter Problem message.";
  }

  identity fid-icmpv6-identifier {
    base schc:fid-icmpv6-base-type;
    description
      "ICMPv6 identifier field, present in Echo Request/Reply message.";
  }

  identity fid-icmpv6-sequence {
    base schc:fid-icmpv6-base-type;
    description
      "ICMPv6 sequence number field, present in Echo Request/Reply message.";
  }

  identity fid-icmpv6-payload {
    base schc:fid-icmpv6-base-type;
    description
      "ICMPv6 payload following ICMPv6 header.
      If payload is empty, this field exists with a length of 0.";
  }

// MO and CDA

  identity mo-rule-match {
    base schc:mo-base-type;
    description
        "Macthing operator return true, if the TV matches a rule
        keeping UP and DOWN direction." ;
  }

  identity mo-rev-rule-match {
    base schc:mo-base-type;
    description
        "Macthing operator return true, if the TV matches a rule
        reversing UP and DOWN direction." ;
  }


  identity cda-compress-sent {
    base schc:mo-base-type;
    description
        "Send a compressed version of TV keeping UP and
        DOWN direction." ;
  }

  identity  cda-rev-compress-sent {
    base schc:mo-base-type;
    description
        "Send a compressed version of TV reversing UP and
        DOWN direction." ;
  }
}
Figure 5: YANG module

10. Security considerations

flood the return path with ICMP error messages.

11. IANA Considerations

TODO

12. Contributors

The following people have been co-authors of precursor versions of this draft. Their contribution is deeply appreciated and acknowledged.

13. References

13.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4443]
Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, , <https://www.rfc-editor.org/info/rfc4443>.
[RFC4861]
Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, , <https://www.rfc-editor.org/info/rfc4861>.
[RFC4884]
Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, DOI 10.17487/RFC4884, , <https://www.rfc-editor.org/info/rfc4884>.
[RFC6291]
Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, DOI 10.17487/RFC6291, , <https://www.rfc-editor.org/info/rfc6291>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <https://www.rfc-editor.org/info/rfc8200>.
[RFC8724]
Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, , <https://www.rfc-editor.org/info/rfc8724>.
[RFC9363]
Minaburo, A. and L. Toutain, "A YANG Data Model for Static Context Header Compression (SCHC)", RFC 9363, DOI 10.17487/RFC9363, , <https://www.rfc-editor.org/info/rfc9363>.

13.2. Informative References

[RFC8376]
Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, , <https://www.rfc-editor.org/info/rfc8376>.

Authors' Addresses

Dominique Barthel
France
Laurent Toutain
IMT Atlantique
2 rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France