VOICI

2.1. Key problem solved by VOICI

                              Endpoint
                  +---------------------------------+
                  |                                 |
      Session A   |                                 |   Session B
                  | +------------+   +------------+ |
                  | | Instance A |   | Instance B | |
                  | +------------+   +------------+ |
                  |        ^               ^        |
                  |        |               |        |
                  |        +-------+-------+        |
                  |                |    how to      |
                  |                | discriminate?  |
                  |                |                |
                  +----------------|----------------+
                                   |
                                   |
                                   |
+----------------------------+----------------+
| Lower Layer headers        | SCHC Data Unit |
| no content discriminating  | e.g. Rule ID + |
|       Sessions A&B         |   residue      |
+----------------------------+----------------+

Figure 1 illustrates the fundamental problem addressed by VOICI. When an Endpoint hosts multiple SCHC Instances -- each serving a different Domain, tenant, or application -- their compressed Data Units must share a single link. The lower layer headers (Ethernet, IPv6, etc.) carry no information to distinguish which Instance a Data Unit belongs to, because the compression residue elides those distinguishing fields. Without an explicit discriminator, the receiver cannot route the incoming Data Unit to the correct handler. VOICI solves this by prepending a compact header that carries a Session ID, bridging the gap between the compression layer and the link layer.¶

The requirements below are organized into two groups. Requirements 1-3 were first identified by the SCHC architecture [SCHC-ARCH] for the specific case of SCHC-compressed Data Units. Requirements 4-5 were added when the scope was broadened to encompass other compression mechanisms and uncompressed payloads.¶

2.2. Requirements driven by SCHC

1. Session identification: A mechanism to distinguish Sessions and route Data Units to the correct processing handler (for example, a SCHC Instance). The identifier (Session ID) is locally significant to the link.¶

2. Original EtherType/port recovery (optional): A mechanism to carry the original EtherType or UDP port number when the carrier uses the SCHC EtherType or SCHC UDP port. This is needed when the payload is decompressed so that the receiver can restore the original framing layer after decompression.¶

3. Integrity protection (optional): A mechanism to detect corruption of the Data Unit, including the Session ID and the compressed residue.¶

2.3. Requirements driven by multi-mechanism and uncompressed payloads

1. Content identification: A mechanism to identify how the Data Unit is encoded when the link carries Data Units from multiple mechanisms (for example, SCHC, uncompressed). This allows the receiver to dispatch the Data Unit to the correct decompressor without inspecting its contents.¶

2. Layer independence: The encapsulation MUST operate over any link layer that carries compressed traffic, whether identified by an Ethertype, IP Protocol Number, or UDP port [SCHC-PROTO-NUMS].¶

3.1. MPLS

MPLS labels provide efficient multiplexing and are widely deployed in operator networks. However:¶

• MPLS adds 4 bytes per label, which may be excessive for highly constrained deployments.¶

• MPLS is not available on all link types relevant to SCHC (LPWAN, PPP, low-speed serial links).¶

• MPLS provides no integrity protection.¶

3.2. UDP Encapsulation

UDP is commonly used for Internet traversal and NAT traversal. The UDP source port can carry a Session ID:¶

• The UDP header is 8 bytes.¶

• Features a 16 bits Checksum.¶

• Using the UDP source port as Session ID is fragile in the presence of NAT (port remapping) and port exhaustion (65535 limit shared with other applications).¶

• UDP is only available above IP.¶

3.3. IP Protocol Number and SCHC Ethertype

The SCHC IP Protocol Number and Ethertype [SCHC-PROTO-NUMS] identify SCHC traffic at the respective layers but do not provide:¶

• Session multiplexing (one protocol number or Ethertype per link, not per Session).¶

• Integrity protection.¶

They are necessary to identify SCHC traffic but insufficient for multiplexing.¶

3.4. QUIC

QUIC [RFC9000] is a multiplexed, UDP-based transport that provides stream multiplexing, reliability, flow control, and mandatory encryption via TLS 1.3. While QUIC satisfies multiplexing and integrity requirements, it is generally infeasible for SCHC target deployments:¶

• QUIC operates exclusively over UDP, requiring a full IP stack.¶

• The mandatory TLS 1.3 handshake and AEAD encryption require cryptographic hardware or sufficient memory that constrained endpoints may not possess.¶

• The minimum AEAD ciphertext size (16 bytes for AES-128-GCM) combined with the TLS record and QUIC headers results in a per-packet overhead over 32 bytes.¶

3.5. Summary

VOICI fills the gap by providing multiplexing, integrity, content mechanism identification, and original EtherType/port recovery with minimal overhead. The comparison is summarized in Table 1.¶

3.6. Encoding Within SCHC Data Unit

Encoding session or version information inside the SCHC rules or rule results would couple transport-layer concerns (multiplexing, version negotiation) to compression-layer concerns (what to compress, how to parse the residue). A separate encapsulation keeps the SCHC Data Unit focused on compression results and allows the transport header to be added or removed without modifying the compression strategy or the Context/Rules.¶

Furthermore, when multiple compression mechanisms share the same link, an inner-field approach would require every mechanism to reserve space for the same routing metadata, reducing compression efficiency. VOICI places this metadata in a single, mechanism-agnostic header.¶

5.1. Fields

• V (1 bit): VOICI header format version. V=0 for this draft. V=1 for future VOICI revisions.¶

• O (1 bit): Original EtherType/Port present. When set, the Original EtherType/Port field is present, carrying the EtherType, IP Next Header, or UDP port number that was replaced by the VOICI EtherType, VOICI IP Protocol Number, or VOICI UDP port. The field is interpreted as an EtherType when VOICI is carried over a link-layer transport (for example, IEEE 802 Ethertype), as a Next Header if carried over IP, and as a UDP port when VOICI is carried in a UDP payload. This restoration is an VOICI responsibility; the Content Mechanism does not need to manage framing recovery and dispatching to original handler.¶

• I (1 bit): Integrity flag. When set, a CRC-16 field is present and covers the Session ID through the end of the Protocol Data Unit. When clear, no integrity check is carried.¶

• CI (2 bits): Content Identifier. Identifies the mechanism used for the Protocol Data Unit. VOICI profiles register new CI values as needed.¶

  The initial CI assignments are:¶

Profiles that register a new CI value MUST specify the mechanism and its parameters.¶

• SSS (3 bits): Session ID prefix (for Unprocessed/Raw and SCHC) or Extended CI value (for Extended CI). The SSS field uses an inline/extended encoding:¶

  • SSS in 0..6: The value is inlined in the first byte.¶

    • For Unprocessed/Raw or SCHC: SID = SSS. Header is 1 byte (unless O=1 or I=1).¶

    • For Extended CI: Ext_CI = SSS + 3. A Session ID follows as a LEB128 integer.¶

  • SSS = 7: A LEB128 variable-length integer follows.¶

    • For Unprocessed/Raw or SCHC: read LEB128 value; SID = LEB128_val + 7.¶

    • For Extended CI: read LEB128 value; Ext_CI = LEB128_val + 10. If SSS was inline (0-6), the Session ID follows immediately after the first byte. If SSS was 7, the Session ID follows immediately after the LEB128 integer.¶

  This gives 7 inline values in the 1-byte form, with continuous extension to 16-bit values via LEB128.¶

• Session ID (variable length): Identifies the logical session that owns this Protocol Data Unit. When a mechanism is registered with VOICI, the mechanism profile assigns Session IDs and registers them with the VOICI instance. The receiver VOICI uses the Session ID to dispatch the Protocol Data Unit to the correct handler -- for SCHC, the handler is an SCHC Instance; for Unprocessed/Raw, the handler is the raw dispatch path. The Session ID space (0-65535) is local to the link over which VOICI is carried and to the Content Mechanism.¶

  For CI values 00, 01 (Unprocessed/Raw and SCHC), the Session ID is derived from the SSS field as described in the parsing order (SID = SSS for inline values, SID = LEB128_val + 7 for extended values). For Extended CI, the Session ID follows the Extended CI value as a LEB128 integer.¶

  The LEB128 encoding follows [DWARF]: - If the value is less than 128, a single byte is used (MSB = 0). - If the value is 128 or greater, two bytes are used (first byte MSB = 1). - No values larger than 16 bits (65535) are supported.¶

  The receiver reads the Session ID by inspecting the most significant bit of each LEB128 byte: if the MSB is 1, the next byte is part of the value; if 0, the byte is the last.¶

• CRC (16 bits, optional): Present when I=1. CRC-16/CCITT-FALSE over the flag byte (V-O-I-CI-SSS), the Extended CI value bytes (if CI=3), the Session ID, the Original EtherType/Port field (if O=1), and the entire Protocol Data Unit.¶

• Original EtherType/Port (1-2 bytes, optional): Present when O=1. Carries the EtherType or UDP port number that was replaced by the VOICI carrier. The field is interpreted as an EtherType when VOICI is carried over a link-layer transport (for example, IEEE 802 Ethertype) and as a UDP port when VOICI is carried in a UDP payload.¶

5.2. Minimal Header

When no optional fields are needed (V=0, O=0, I=0) and the SSS field encodes an inline value (0-6), the VOICI header reduces to a single byte:¶

 0 1 2 3 4 5 6 7   bit
+-+-+-+---+-----+
|V|O|I|CI |S S S| (inline value, 1 byte)
+-+-+-+---+-----+

5.3. Header Size Summary

VOICI header sizes for various configurations (Unprocessed/Raw and SCHC):¶

Extended CI (CI=3) adds the Extended CI value and a LEB128 Session ID; the minimum is 2 bytes (flag byte + 1-byte Session ID, SSS inline), growing to 6 bytes (SSS=7 with 2-byte LEB128 Ext_CI + 2-byte LEB128 SID).¶

5.4. Header Field Reference

6.1. Transmit Path (Egress)

On the sender side, VOICI operates as an encapsulator. A Data Unit is passed to the VOICI module by an upper-layer handler together with metadata that determines the header fields. The inputs are:¶

• the Data Unit (payload), which may be compressed (for example, an SCHC residue), unprocessed, or encoded by another mechanism;¶

• a Session ID, identifying the logical session that owns the Data Unit;¶

• a Content Identifier, indicating the mechanism that encoded the Data Unit;¶

• an Original Framing value (EtherType, IP Next Header, or UDP port) when the carrier framing has been replaced by the VOICI carrier and the receiver must restore it;¶

• an Integrity flag indicating whether a CRC is required.¶

The VOICI module constructs the header as follows:¶

1. V field: Set to 0 (current version).¶

2. O field: Set to 1 if an Original Framing value is provided and must be carried to the receiver for restoration; otherwise set to 0.¶

3. I field: Set to 1 if integrity protection is required; otherwise set to 0.¶

4. CI field: Set to the Content Identifier associated with the Data Unit. For Unprocessed/Raw traffic, CI=0. For SCHC-compressed traffic, CI=1. For mechanisms registered under Extended CI, CI=3 (see below).¶

5. SSS field and Session ID:¶

   • For CI=0 (Unprocessed/Raw) or CI=1 (SCHC):¶

     • If Session ID is in the range 0-6: set SSS to the Session ID value (inline encoding). No additional Session ID bytes are emitted.¶

     • If Session ID is 7 or greater: set SSS to 7. Encode Session ID - 7 as a LEB128 integer following the first byte.¶

   • For CI=3 (Extended CI):¶

     • The SSS field encodes the Extended CI value rather than the Session ID. If the Extended CI value is in the range 3-9: set SSS to Extended CI - 3 (inline). Otherwise: set SSS to 7 and encode Extended CI - 10 as a LEB128 integer following the first byte.¶

     • After the Extended CI value (inline or LEB128), encode the Session ID as a LEB128 integer.¶

6. CRC field (if I=1): Compute CRC-16/CCITT-FALSE over the following bytes in wire order: the base header byte (V-O-I-CI-SSS), any Extended CI LEB128 bytes, the Session ID bytes, the Original EtherType/Port value (if O=1), and the entire Data Unit payload. The CRC field itself is NOT included in the computation. Append the 2-byte CRC field.¶

7. Original EtherType/Port field (if O=1): Append the Original Framing value. For Ethernet or UDP carriers, the field is 2 bytes (EtherType or UDP port). For IPv6, the field is 1 byte (Next Header value).¶

8. Prepend the complete VOICI header to the Data Unit to form the VOICI-encapsulated frame.¶

9. Carrier framing: Replace the outgoing frame's carrier identifier (EtherType, IP Protocol Number, or UDP port) with the VOICI carrier value defined in [SCHC-PROTO-NUMS].¶

10. Submit the encapsulated frame to lower layers for transmission.¶

6.2. Receive Path (Ingress)

On the receiver side, VOICI operates as a dispatcher. Frames arriving with the VOICI Ethertype, IP Protocol Number, or UDP port ([SCHC-PROTO-NUMS]) are handed to the VOICI module. Processing is as follows:¶

1. Parse the base header: Read the first byte; extract V, O, I, CI, and SSS.¶

2. Version check: If V indicates a version other than 0, the header format is unsupported. The frame MUST be discarded.¶

3. Reserved CI check: If CI=2 (Reserved), the Data Unit MUST be discarded.¶

4. Decode SSS:¶

   • For CI=0 (Unprocessed/Raw) or CI=1 (SCHC):¶

     • If SSS is 0-6: Session ID equals SSS.¶

     • If SSS is 7: read a LEB128 integer from the following byte(s); Session ID equals LEB128_val + 7.¶

   • For CI=3 (Extended CI):¶

     • If SSS is 0-6: Extended CI equals SSS + 3.¶

     • If SSS is 7: read a LEB128 integer; Extended CI equals LEB128_val + 10.¶

     • Read the Session ID as a LEB128 integer from the bytes following the Extended CI value (or following the first byte, if SSS was 0-6).¶

5. Read CRC field (if I=1): Read the 2-byte CRC value.¶

6. Read Original EtherType/Port field (if O=1): Read the Original EtherType/Port field. The field is 2 bytes for Ethernet/UDP carriers, 1 byte for IPv6 Next Header.¶

7. CRC verification (if I=1): Compute the expected CRC over all preceding bytes (base header byte, Extended CI bytes if CI=3, Session ID bytes, Original EtherType/Port if O=1), and the Data Unit payload. Note that the CRC field appears before the Original EtherType/Port field on the wire but covers it; the receiver reads both fields before verifying. If the computed CRC does not match the received CRC, the frame MUST be discarded.¶

8. Dispatch: Pass the Data Unit payload to the processing handler identified by the CI value and Session ID. For CI=1 (SCHC), the handler is the SCHC Instance corresponding to that Session ID. For CI=0 (Unprocessed/Raw), the handler is the raw dispatch path.¶

9. Handler processing: The handler processes the Data Unit (decompression, pass-through, etc.) and returns the result to VOICI.¶

10. Restore original framing (if O=1): Write the Original EtherType/Port value read in step 6 into the carrier framing of the outgoing frame (EtherType, IP Next Header, or UDP port as appropriate).¶

11. Egress to upper layers: Pass the reconstituted frame to the appropriate upper-layer handler. If O=1, the upper-layer handler is the one identified by the reconstructed carrier header.¶

6.3. Error Handling

If the receiver cannot identify a handler for a given (CI, Session ID) pair -- for example, the Session ID is not associated with any configured handler, or the CI value is not supported -- the frame MUST be discarded.¶

7.1. P2P Deployments

Session IDs MAY be negotiated between peers during Session establishment, or assigned by the Domain Manager during provisioning. Session ID 0 is a valid Session ID (no reserved values).¶

7.2. Star Topologies

The Network Gateway assigns Session IDs and communicates them to Devices during provisioning. The Gateway maintains the Session ID to handler mapping.¶

7.3. Mesh and Other Topologies

Session IDs MAY be assigned by a Network or Domain Manager, or negotiated between peers.¶

7.4. Relay Remapping

A relay or gateway translating between links MAY remap Session IDs. The Session ID space is local to each link segment; there is no requirement for global uniqueness.¶

8.1. Registration of New Mechanisms

Profiles that register a new CI value MUST specify the mechanism and its parameters. Implementations that encounter a CI value they do not recognize MUST drop the Data Unit.¶

9.1. CRC Scope

The CRC covers the VOICI header and the Data Unit payload, excluding the CRC field itself. Specifically, the CRC is computed over the base header byte (V-O-I-CI-SSS), the Extended CI LEB128 bytes (if CI=3 and SSS=7), the Session ID, the Original EtherType/Port field (if O=1), and the entire Data Unit payload.¶

9.2. CRC Algorithm

CRC-16/CCITT-FALSE (polynomial 0x1021, initial value 0xFFFF, no reflection, no final XOR) is used. This is the same algorithm used in many constrained network protocols (for example, Bluetooth, CAN bus).¶

9.3. Relationship to ULP Checksums

Some compression strategies elide Upper Layer Protocol (ULP) checksums (for example, UDP checksum) to reduce residue size. On links where the underlying transport does not guarantee Data Unit integrity, this makes the VOICI CRC the sole integrity mechanism. Profiles MUST specify whether ULP checksum elision is permitted and, if so, whether the VOICI CRC is mandatory to compensate.¶

9.4. Limitations

The CRC provides integrity (corruption detection) but NOT authentication. An attacker can compute a valid CRC for a forged Data Unit. Authentication must be provided by the underlying transport or a higher-layer security mechanism.¶

10.1. Over Ethertype

The SCHC Ethertype identifies VOICI-encapsulated traffic. When O=1, the Original EtherType/Port field carries the replaced EtherType value.¶

10.2. Over IP Protocol Number

The SCHC IP Protocol Number identifies VOICI-encapsulated traffic. The VOICI header follows the IPv6 header (or the IPv6 extension containing the protocol number). When O=1, the Original EtherType/Port field carries the replaced IPv6 Next Header value.¶

10.3. Over UDP

The SCHC UDP port identifies VOICI-encapsulated traffic carried in the UDP payload. The UDP header provides its own checksum, which may make the VOICI CRC redundant. When O=1, the Original EtherType/Port field carries the replaced UDP destination port number.¶

11.1. Session Hijacking

If Session IDs are predictable, an attacker could inject Protocol Data Units with a forged Session ID to redirect traffic to a different handler. Session IDs SHOULD be randomly generated or derived from a secure key exchange. In star topologies where the Domain Manager assigns Session IDs, the assigned values SHOULD be cryptographically random rather than sequential or otherwise predictable.¶

11.2. Integrity Limitations

The CRC provides corruption detection but not authentication. An attacker with link access can forge Protocol Data Units with valid CRCs. Authentication must be provided by the underlying transport (for example, IPsec, TLS) or a higher-layer mechanism (for example, OSCORE).¶

11.3. Flag Bit Manipulation

When the I flag is set, the CRC covers the flag byte, making flag bit flipping detectable at the cost of a CRC failure. When I=0, flipping the O flag (0 to 1) would cause the receiver to consume payload bytes as an Original EtherType/Port field. Higher-layer authentication is recommended for adversarial environments.¶

11.4. CI Manipulation

When the I flag is set, the CRC covers the CI field, making manipulation detectable. When I=0, an attacker can flip the CI field to dispatch the Protocol Data Unit to a wrong handler, causing decompression errors or potential information leakage if the wrong decompressor produces interpretable output.¶

11.5. Denial of Service

An attacker could inject Protocol Data Units with invalid Session IDs, causing the receiver to waste resources on lookup failures. Implementations SHOULD rate-limit Session ID lookup failures.¶

11.6. Replay Attacks

VOICI carries no sequence number or timestamp. An attacker with link access could replay previously captured Protocol Data Units. For SCHC's primary use cases (sensor telemetry, periodic reporting), replayed Protocol Data Units carry stale data that is not harmful. Deployments requiring replay protection SHOULD use a higher-layer mechanism (for example, OSCORE, DTLS) or the underlying transport.¶

12.1. Content Identifier Registry

This document requests the creation of a "Content Identifier (CI)" registry. The initial entries are:¶

New CI values are assigned per [RFC8126] "Specification Required" policy.¶

12.2. Session ID Space

The Session ID space is locally significant to the link and Content Mechanism. No IANA assignment is required.¶

12.3. Future Extensions

The VOICI header allows for future extensions. New flags or fields would be introduced through a subsequent revision of this document, with IANA registry updates. Existing implementations that encounter unrecognized flag combinations MUST treat the unrecognized flags as zero and process the header according to their supported flags. For the CI field, implementations that encounter a CI value they do not recognize MUST drop the Protocol Data Unit.¶

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, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[SCHC]

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, April 2020, <https://www.rfc-editor.org/rfc/rfc8724>.

13.2. Informative References

[DWARF]

Dwarf Standards Committee, "DWARF Debugging Information Format", Web https://dwarfstd.org/documentation/, <https://dwarfstd.org/documentation/>.

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.

[SCHC-ARCH]

Pelov, A., Thubert, P., Minaburo, A., Lampin, Q., and M. Dumay, "Static Context Header Compression (SCHC) Architecture", Work in Progress, Internet-Draft, draft-ietf-schc-architecture-06, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-schc-architecture-06>.

[SCHC-PROTO-NUMS]

Moskowitz, R., Thubert, P., Gomez, C., Minaburo, A., and M. Blanchet, "Protocol Numbers for SCHC", Work in Progress, Internet-Draft, draft-ietf-schc-protocol-numbers-06, 23 December 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-schc-protocol-numbers-06>.