Bob, > On Sep 7, 2022, at 1:53 PM, Robert Moskowitz <rgm-i...@htt-consult.com> wrote: > > > > On 9/7/22 16:04, Bob Hinden wrote: >> Bob, >> >> 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 understood this. The question is vers -00 or -01 going foreward.
Given it’s a request for adoption call, -01 is fine. All can be changed later once it is a w.g. document :-) Bob > > thanks for your support. > > Bob M. > > >> >> Bob >> >> >>> On Sep 7, 2022, at 12:46 PM, Robert Moskowitz <rgm-i...@htt-consult.com> >>> wrote: >>> >>> >>> >>> On 9/7/22 15:15, Carsten Bormann wrote: >>>> On 2022-09-07, at 18:36, Bob Hinden <bob.hin...@gmail.com> wrote: >>>>> Is this an IPv6 extension header? Does SCHC include a next header >>>>> field so it can point to a header that follows? >>>> If you haven’t seen RFC 5856 to 5858: This is a miniseries of documents >>>> where we have done the analog thing for the ROHC Robust Header Compression >>>> scheme that is now being proposed for the SCHC Static Context Header >>>> Compression scheme. >>> SCHC did it the other direction, first defining SCHC and then some of us >>> coming up with use cases for it being the actual IP protocol. >>> >>>> The actual allocation of an Internet Protocol Number to ROHC is in Section >>>> 6 of RFC 5858: https://www.rfc-editor.org/rfc/rfc5858.html#section-6 >>>> >>>> IANA has allocated the value 142 to "ROHC" within the "Protocol >>>> Numbers" registry [PROTOCOL]. This value will be used to indicate >>>> that the next-level protocol header is a ROHC header. >>>> >>>> Some forms of ROHC headers contain a next header field, but mostly that >>>> field is compressed away as it is redundant between packets in a flow. >>>> >>>> Bob’s document is doing the equivalent to RFC 5858, now for SCHC. >>>> Once there is a WG adoption call, I’ll express that I am very much in >>>> favor of this work going forward. >>>> (As I have said before, I’d also like to see the equivalent IKE/IPsec >>>> support that RFC 5856 and RFC 5857 provide for SCHC as well. But this can >>>> be done on different timescales.) >>> Diet-ESP is the starting point. It has to be fully SCHCed. >>> >>> DTLS is already compressed enough, but as I point out, given DTLS and SCHC, >>> you rarely need the UDP header content. >>> >>> Bob >>> >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
