Hello Carsten > > But it is architecturally wrong to call what ROHC or SCHC as carrying an > upper layer protocol. They carry what is in our architecture a Transport > Layer protocol, acting in many ways as part of the IP layer itself… > > Header Compression is organized layer violation, so even trying to assign > a layer to it is futile.
As always, I love the way you're stating things > Header Compression is usually done hop-by-hop as a local optimization, > invisible to the endpoints; there is no end-to-end semantics that would be > typical for a Transport Layer protocol. With the neat that depending on what the layer is the endpoints are different. See for instance https://www.rfc-editor.org/rfc/rfc8824.html#name-oscore-compression So there can definitely be SCHC in SCHC, with different endpoints and rules. For the PPP draft that uses SCHC as a PPP compression method, the endpoints are those of the PPP session. The architecture question is how to best structure the SCHC nesting. In Figure 7 of RFC 8824 the (encrypted) inner SCHC is concatenated to the residue of the outer SCHC. This means that the SCHC context is fully implicit and that the bits after the residue have to be the inner SCHC. Making those 2 different SCHC headers would allow to decide for each layer whether SCHC is used or not, and pass enough info to avoid implicit deduction that may be misleading or constraining. As far as RFC 8824 is great for LPWANs, I believe we need some better architectural structure when going to IP at large. > The discussion so far about whether SCHC (or ROHC) would be IPv6 Extension > Header Types seems to be rather sophistic to me, with little practical > relevance of choosing one or the other. Is there any behavior that would > change based on whether they are IPv6 Extension Header Types or not? > Yes, it seems to be placing the cart before the horse. But then again this is layer 0 of a stack of things we wish to achieve. So reserving the value in both registries, that's the same cost anyway. All the best. Pascal > Grüße, Carsten > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
