| Internet-Draft | SCHCoPPP | July 2020 |
| Thubert | Expires 2 January 2021 | [Page] |
This document extends RFC 5172 to signal the use of SCHC as the compression method between a pair of nodes over PPP. Combined with RFC 2516, this enables the use of SCHC over Ethernet and Wi-Fi.¶
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 2 January 2021.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
The Point-to-Point Protocol (PPP) [RFC5172] provides a standard method of encapsulating network-layer protocol information over point-to-point links. "A Method for Transmitting PPP Over Ethernet (PPPoE)" [RFC2516] transports PPP over Ethernet between a pair of nodes. It is compatible with a translating bridge to Wi-Fi, and therefore enables PPP over Wi-Fi as well.¶
PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. "IP Version 6 over PPP" [RFC5072] defines the IPv6 Control Protocol (IPV6CP) , which is an NCP for a PPP link, and allows for the negotiation of desirable parameters for an IPv6 interface over PPP.¶
"Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol" [RFC5172] defines the IPv6 datagram compression option that can be negotiated by a node on the link through the IPV6CP. The "Static Context Header Compression (SCHC) and fragmentation for LPWAN, application to UDP/IPv6" [SCHC] is a compression and fragmentation technique that was defined after the publication of [RFC5172]. In order to enable SCHC over PPP and therefore Ethernet and Wi-Fi, [RFC5172] must be extended to signal SCHC as an additional compression method for use over PPP.¶
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.¶
With this specification, a PPP session defines a vitual link where a SCHC context is established with a particular set of Rules, which is indicated at the set up of the PPP session as follows:¶
[RFC5172] defines an IPV6CP option called the IPv6-Compression-Protocol Configuration option with a type of 2. The option contains an IPv6-Compression-Protocol field value that indicates a compression protocol and an optional data field as shown in Figure 1:¶
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 | Length | IPv6-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
This specification indicates a new IPv6-Compression-Protocol field value for [SCHC] (see Section 5), and enables to transport a Uniform Resource Identifier (URI) [RFC3986] of the set of rules in the optional data. The default format for the set of rules is YANG using the "Data Model for SCHC" [SCHC_DATA_MODEL] encoded in JSON as specified in [RFC7951]. The size of the URL is computed based on the Length of the option as Length-4. If the encoding is asymetrical, the initiator of the session is considered downstream, playing the role of the device in an LPWAN network.¶
Appendix D of [SCHC] specifies the profile information that technology specifications such as this must provide. The following section address this requirement.¶
This specification leverages SCHC between an end point that is an IP Host and possibly a serial DTE (Data Terminal Equipment), and another that is an IP Node (either another IP Host or a Router) and possibly a serial DCE (Data Control Equipment), or a more modern physical or emulated endpoint, e.g., Ethernet devices that echange IP packets over PPPoE.¶
Both endpoints MUST support the function of SCHC Compressor/Decompressor (C/D) as shown in Figure 2.¶
+----------+ Wi-Fi / +----------+ ....
| IP | Ethernet | IP | .. )
| Host +-----/------+ Router +----------( Internet )
| SCHC C/D | Serial | SCHC C/D | ( )
+----------+ +----------+ ...
<-- SCHC -->
over PPP
The assumption for this document is that the SCHC Fragmenter/Reassembler (F/R) is generally not needed, because the maximum transmission unit (MTU) is expected to be large enough and SCHC only reduces the frame size vs. native IP.¶
An example use case for SCHC over PPP over Ethernet (PPPoE) would be to apply SCHC to streamline traffic by reducing the size of the frames and maintain them to a constant size and constant rate, e.g., to simplify the scheduling of [DetNet] packets over TSN or one of the [RAW Technologies]. Scheduling on DetNet links introduces a form of duty cycle, but that does not affect the SCHC operation, since fragmentation is not provided.¶
A context may be generated for a particular upper layer application, such as a control loop using an industrial automation protocol, to protect the particular flow with a DetNet service. The context can be asymetric, e.g., when connecting a master and a slave, a client and a server, or a programmable logic controller with a sensor or an actuator.¶
Compared to typical LPWANs, most serial links and emulations such as PPPoE are very fast and most of the constraints can be alleviated. For this reason, the SCHC profile for PPP is defined as follows:¶
Since this specification does not leverage the SCHC fragmentation, a SCHC packet is always in the form:¶
|------- Compressed Header -------|
+---------------------------------+--------------------+
| RuleID | Compression Residue | Payload |
+---------------------------------+--------------------+
< 2bytes >
In the case of PPPoE, the sequence of compression and encapsulation is as follows:¶
A packet (e.g., an IPv6 packet)
| ^ (padding bits
v | dropped)
+------------------+ +--------------------+
| SCHC Compression | | SCHC Decompression |
+------------------+ +--------------------+
| ^
| (No fragmentation) |
v |
+--------------------+ +--------------------+
| PPP Session encaps | | PPP Session decaps |
+--------------------+ +--------------------+
| ^
| |
v |
+------------------+ +------------------+
| PPPoE(oE) encaps | | PPPoE(oE) encaps |
+------------------+ +------------------+
| ^
| |
+-------------------------------------------+
Sender Receiver
In the case of PPPoE, a frame that transports an IPv6 packet compressed with SCHC shows as follows:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Source MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination MAC Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Frame Type(0x8864) | Ver=1 | Type=1| Code=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PPP Protocol (IPv6CP) = 0x8057 | SCHC Rule | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... Compression ... | Residue +-+-+-+ | | Pad | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Uncompressed | ... Original ... | Payload | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This draft enables to use the SCHC compression and fragmentation over PPP and therefore Ethernet and Wi-Fi with PPPoE. It inherits the possible threats against SCHC listed in the "Security considerations" section of [SCHC].¶
This document requests the allocation of a new value in the registry "IPv6-Compression-Protocol Types" for "SCHC". A suggested value is proposed in Table 1:¶
| Value | Description | Reference |
|---|---|---|
| 4 | Static Context Header Compression (SCHC) | This document |