Hello Joel: SCHC could be used to compress IP option headers and the residue be stored in a SCHC option, which a next header points at uncompressed transport (e.g., encrypted, uncompressible). Additionally, finding the SCHC context may require metadata that could also be found in a SCHC option. Over one hop in LPWAN that is all implicit but over IP it might not be.
SCHC is layered depending on which endpoint talks to which. E.g., you compress a tunnel with inner that is already SCHC-compressed, you do security, etc... So you could have SCHC options one after the other. We have not defined the option yet, LPWAN is discussing recharter to cover SCHC applied beyond LPWANs. But since we're at it, let's do both in one RFC. Note that we'll also need a value for IPv6-Compression-Protocol Types, see https://www.ietf.org/archive/id/draft-thubert-intarea-schc-over-ppp-03.html#name-iana-considerations. All the best, Pascal > -----Original Message----- > From: Int-area <int-area-boun...@ietf.org> On Behalf Of Joel Halpern > Sent: mercredi 7 septembre 2022 23:35 > To: Robert Moskowitz <rgm-i...@htt-consult.com>; Bob Hinden > <bob.hin...@gmail.com> > Cc: Internet Area <int-area@ietf.org> > Subject: Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz- > intarea-schc-ip-protocol-number > > My reading of 8200 is that an extension header MUST start with a one byte > "Next Header" field. SCHC does not. Therefore, it is a carried / upper > layer protocol, not an extension header. Much like IPv6 (in IPv6). Or > UDP (with carrying an application protocol or carrying some routing header > like GRE, LISP, ...) or ... > > Yours, > > Joel > > PS: I grant we are not fully consistent in this regard. ESP does not have > a next-header field. (AH does). But if we are going to pretend that > some headers are extensions headers and some are not, we should try to be > consistent with the description in 8200 (and 2460). > > On 9/7/2022 4:57 PM, Robert Moskowitz wrote: > > > > > > On 9/7/22 16:35, Carsten Bormann wrote: > >> On 7. Sep 2022, at 22:04, Bob Hinden <bob.hin...@gmail.com> wrote: > >>> To clarify my question, it only relates to if SCHC should be added > >>> to the IPv6 Extension Header Types registry. I continue to think > >>> that adding it to the IP Protocol Number registry is fine. > >> I believe the answer should be the same as for 142 (RFC 5858), which > >> is not in the list. > >> > >> I couldn’t find out quickly what an IPv6 Extension Header Type is(*), > >> so maybe that is an oversight for 142. > > > > From my limited understanding and which Protocols are listed as > > Extension Header Types and which not (other than 142), it is a > > Protocol that transports other Protocols. > > > > Though with that definition, I wonder how HIP got in the list. > > > > It is fun to open a can of worms! > > > >> > >> Grüße, Carsten > >> > >> (*) An IP protocol number, apparently. > >> But what specifically does it make an IPv6 Extension Header Type as > >> well? > >> The references given in the registry don’t seem to say. > >> > > > > _______________________________________________ > > 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 _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
