idnits 2.17.1 draft-thubert-intarea-schc-over-ppp-00.txt: -(319): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5172, but the abstract doesn't seem to directly say this. It does mention RFC5172 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5172, updated by this document, for RFC5378 checks: 2007-05-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 July 2020) is 1388 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2516 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LPWAN P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Updates: 5172 (if approved) 1 July 2020 5 Intended status: Standards Track 6 Expires: 2 January 2021 8 SCHC over PPP 9 draft-thubert-intarea-schc-over-ppp-00 11 Abstract 13 This document extends RFC 5172 to signal the use of SCHC as the 14 compression method between a pair of nodes over PPP. Combined with 15 RFC 2516, this enables the use of SCHC over Ethernet and Wi-Fi. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 2 January 2021. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Extending RFC 5172 . . . . . . . . . . . . . . . . . . . . . 3 53 4. Profiling SCHC for high speed links . . . . . . . . . . . . . 3 54 4.1. Mapping the SCHC Architecture . . . . . . . . . . . . . . 4 55 4.2. SCHC Parameters . . . . . . . . . . . . . . . . . . . . . 4 56 4.2.1. Resulting Packet Format . . . . . . . . . . . . . . . 5 57 4.3. Security Considerations . . . . . . . . . . . . . . . . . 6 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 60 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 61 8. Informative References . . . . . . . . . . . . . . . . . . . 7 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 The Point-to-Point Protocol (PPP) [RFC5172] provides a standard 67 method of encapsulating network-layer protocol information over 68 point-to-point links. "A Method for Transmitting PPP Over Ethernet 69 (PPPoE)" [RFC2516] transports PPP over Ethernet between a pair of 70 nodes. It is compatible with a translating bridge to Wi-Fi, and 71 therefore enables PPP over Wi-Fi as well. 73 PPP also defines an extensible Link Control Protocol, and proposes a 74 family of Network Control Protocols (NCPs) for establishing and 75 configuring different network-layer protocols. "IP Version 6 over 76 PPP" [RFC5072] defines the IPv6 Control Protocol (IPV6CP) , which is 77 an NCP for a PPP link, and allows for the negotiation of desirable 78 parameters for an IPv6 interface over PPP. 80 "Negotiation for IPv6 Datagram Compression Using IPv6 Control 81 Protocol" [RFC5172] defines the IPv6 datagram compression option that 82 can be negotiated by a node on the link through the IPV6CP. The 83 "Static Context Header Compression (SCHC) and fragmentation for 84 LPWAN, application to UDP/IPv6" [SCHC] is a compression and 85 fragmentation technique that was defined after the publication of 86 [RFC5172]. In order to enable SCHC over PPP and therefore Ethernet 87 and Wi-Fi, [RFC5172] must be extended to signal SCHC as an additional 88 compression method for use over PPP. 90 2. BCP 14 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in BCP 95 14 [RFC2119][RFC8174] when, and only when, they appear in all 96 capitals, as shown here. 98 3. Extending RFC 5172 100 With this specification, a PPP session defines a vitual link where a 101 SCHC context is established with a particular set of Rules, which is 102 indicated at the set up of the PPP session as follows: 104 [RFC5172] defines an IPV6CP option called the IPv6-Compression- 105 Protocol Configuration option with a type of 2. The option contains 106 an IPv6-Compression-Protocol field value that indicates a compression 107 protocol and an optional data field as shown in Figure 1: 109 0 1 2 3 110 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 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Type | Length | IPv6-Compression-Protocol | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Data ... 115 +-+-+-+-+ 117 Figure 1: The IPv6-Compression-Protocol Configuration Option 119 This specification indicates a new IPv6-Compression-Protocol field 120 value for [SCHC] (see Section 5), and enables to transport a Uniform 121 Resource Identifier (URI) [RFC3986] of the set of rules in the 122 optional data. The default format for the set of rules is YANG using 123 the "Data Model for SCHC" [SCHC_DATA_MODEL] encoded in JSON as 124 specified in [RFC7951]. The size of the URL is computed based on the 125 Length of the option as Length-4. If the encoding is asymetrical, 126 the initiator of the session is considered downstream, playing the 127 role of the device in an LPWAN network. 129 4. Profiling SCHC for high speed links 131 Appendix D of [SCHC] specifies the profile information that 132 technology specifications such as this must provide. The following 133 section address this requirement. 135 4.1. Mapping the SCHC Architecture 137 This specification leverages SCHC between an end point that is an IP 138 Host and possibly a serial DTE (Data Terminal Equipment), and another 139 that is an IP Node (either another IP Host or a Router) and possibly 140 a serial DCE (Data Control Equipment), or a more modern physical or 141 emulated endpoint, e.g., Ethernet devices that echange IP packets 142 over PPPoE. 144 Both endpoints MUST support the function of SCHC Compressor/ 145 Decompressor (C/D) as shown in Figure 2. 147 +----------+ Wi-Fi / +----------+ .... 148 | IP | Ethernet | IP | .. ) 149 | Host +-----/------+ Router +----------( Internet ) 150 | SCHC C/D | Serial | SCHC C/D | ( ) 151 +----------+ +----------+ ... 152 <-- SCHC --> 153 over PPP 155 Figure 2: Typical Deployment 157 The assumption for this document is that the SCHC Fragmenter/ 158 Reassembler (F/R) is generally not needed, because the maximum 159 transmission unit (MTU) is expected to be large enough and SCHC only 160 reduces the frame size vs. native IP. 162 An example use case for SCHC over PPP over Ethernet (PPPoE) would be 163 to apply SCHC to streamline traffic by reducing the size of the 164 frames and maintain them to a constant size and constant rate, e.g., 165 to simplify the scheduling of [DetNet] packets over TSN or one of the 166 [RAW Technologies]. Scheduling on DetNet links introduces a form of 167 duty cycle, but that does not affect the SCHC operation, since 168 fragmentation is not provided. 170 A context may be generated for a particular upper layer application, 171 such as a control loop using an industrial automation protocol, to 172 protect the particular flow with a DetNet service. The context can 173 be asymetric, e.g., when connecting a master and a slave, a client 174 and a server, or a programmable logic controller with a sensor or an 175 actuator. 177 4.2. SCHC Parameters 179 Compared to typical LPWANs, most serial links and emulations such as 180 PPPoE are very fast and most of the constraints can be alleviated. 181 For this reason, the SCHC profile for PPP is defined as follows: 183 RuleID numbering scheme: Rules are of a fixed size of two bytes, 184 which allows for more than 65000 different Rules within one 185 session. Since this specification does not leverage the SCHC 186 fragmentation, a SCHC packet is always in the form: 188 |------- Compressed Header -------| 189 +---------------------------------+--------------------+ 190 | RuleID | Compression Residue | Payload | 191 +---------------------------------+--------------------+ 192 < 2bytes > 194 Figure 3: SCHC Packet 196 Maximum packet size: MAX_PACKET_SIZE is aligned to the PPP Link MTU. 198 Padding: The L2 word is one byte, so padding is up to the next byte 199 boundary. The padding bit is a 0. 201 4.2.1. Resulting Packet Format 203 In the case of PPPoE, the sequence of compression and encapsulation 204 is as follows: 206 A packet (e.g., an IPv6 packet) 207 | ^ (padding bits 208 v | dropped) 209 +------------------+ +--------------------+ 210 | SCHC Compression | | SCHC Decompression | 211 +------------------+ +--------------------+ 212 | ^ 213 | (No fragmentation) | 214 v | 215 +--------------------+ +--------------------+ 216 | PPP Session encaps | | PPP Session decaps | 217 +--------------------+ +--------------------+ 218 | ^ 219 | | 220 v | 221 +------------------+ +------------------+ 222 | PPPoE(oE) encaps | | PPPoE(oE) encaps | 223 +------------------+ +------------------+ 224 | ^ 225 | | 226 +-------------------------------------------+ 227 Sender Receiver 229 Figure 4: Stack Operation 231 In the case of PPPoE, a frame that transports an IPv6 packet 232 compressed with SCHC shows as follows: 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | | 238 + Source MAC Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination MAC Address + 241 | | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Ethernet Frame Type(0x8864) | Ver=1 | Type=1| Code=0 | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Session ID | Length | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 |PPP Protocol (IPv6CP) = 0x8057 | SCHC Rule | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 ... Compression ... 251 | Residue +-+-+-+ 252 | | Pad | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | | 255 | | 256 | Uncompressed | 257 ... Original ... 258 | Payload | 259 | | 260 | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 5: SCHC over PPP over Ethernet Format 265 4.3. Security Considerations 267 This draft enables to use the SCHC compression and fragmentation over 268 PPP and therefore Ethernet and Wi-Fi with PPPoE. It inherits the 269 possible threats against SCHC listed in the "Security considerations" 270 section of [SCHC]. 272 5. IANA Considerations 274 This document requests the allocation of a new value in the registry 275 "IPv6-Compression-Protocol Types" for "SCHC". A suggested value is 276 proposed in Table 1: 278 +=======+==========================================+===============+ 279 | Value | Description | Reference | 280 +=======+==========================================+===============+ 281 | 4 | Static Context Header Compression (SCHC) | This document | 282 +-------+------------------------------------------+---------------+ 284 Table 1: IP Header Compression Configuration Option Suboption Types 286 6. Acknowledgments 288 7. Normative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, 292 DOI 10.17487/RFC2119, March 1997, 293 . 295 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 296 and R. Wheeler, "A Method for Transmitting PPP Over 297 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, 298 February 1999, . 300 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 301 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 302 . 304 [RFC5172] Varada, S., Ed., "Negotiation for IPv6 Datagram 305 Compression Using IPv6 Control Protocol", RFC 5172, 306 DOI 10.17487/RFC5172, March 2008, 307 . 309 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 310 Resource Identifier (URI): Generic Syntax", STD 66, 311 RFC 3986, DOI 10.17487/RFC3986, January 2005, 312 . 314 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 315 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 316 May 2017, . 318 [SCHC] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 319 Zúñiga, "SCHC: Generic Framework for Static Context Header 320 Compression and Fragmentation", RFC 8724, 321 DOI 10.17487/RFC8724, April 2020, 322 . 324 8. Informative References 326 [SCHC_DATA_MODEL] 327 Minaburo, A. and L. Toutain, "Data Model for Static 328 Context Header Compression (SCHC)", Work in Progress, 329 Internet-Draft, draft-ietf-lpwan-schc-yang-data-model-02, 330 28 February 2020, . 333 [RAW Technologies] 334 Thubert, P., Cavalcanti, D., Vilajosana, X., Schmitt, C., 335 and J. Farkas, "Reliable and Available Wireless 336 Technologies", Work in Progress, Internet-Draft, draft- 337 thubert-raw-technologies-05, 18 May 2020, 338 . 341 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 342 RFC 7951, DOI 10.17487/RFC7951, August 2016, 343 . 345 [DetNet] Finn, N., Thubert, P., Varga, B., and J. Farkas, 346 "Deterministic Networking Architecture", RFC 8655, 347 DOI 10.17487/RFC8655, October 2019, 348 . 350 Author's Address 352 Pascal Thubert (editor) 353 Cisco Systems, Inc 354 Building D 355 45 Allee des Ormes - BP1200 356 06254 Mougins - Sophia Antipolis 357 France 359 Phone: +33 497 23 26 34 360 Email: pthubert@cisco.com