Eric, Also without any hats, but seems to me there is enough interest in the draft to start an adoption call now. So I think the adoption call can proceed and these (and other changes) could me made after adoption.
Bob > On Sep 10, 2022, at 12:06 AM, Eric Vyncke (evyncke) <[email protected]> wrote: > > Bob, > > My hat-less reply would be indeed to avoid: > - SCHC over IP being an IPv6 extension header > - citing a use case limited to drones (the broader the better) > - comparing to ESP-diet [1] > > Then, asking the WG chairs to launch the adoption call. > > Regards > > -éric > > [1] with my AD hat, thank you for pointing me to ESP-diet because I was not > aware of this other attempt of ipsecme WG to work as the IP layer WG ! > > On 09/09/2022, 18:41, "Robert Moskowitz" <[email protected]> wrote: > > Do you recommend I submit a -02 ver which is just the -00 (without > Extension Header)? That the wg would then adopt > > Or wg just adopts -00 and I submit that as wg ver? > > Bob > > > On 9/9/22 11:34, Eric Vyncke (evyncke) wrote: >> Without any hat, this proposal does not look like an extension header (i.e., >> it does not extend the semantic of the IP packet, it 'just' compress it) and >> looks more like a tunnel/transport header to me. >> >> All in all, it requires an IP protocol number >> >> -éric >> >> On 08/09/2022, 00:25, "Int-area on behalf of Joel Halpern" >> <[email protected] on behalf of [email protected]> wrote: >> >> As far as I can tell, SCHC has the same conceptual structure as almost >> all of our tunnel protocols. Which we do not call extension headers. >> Sure, they are not really upper layer protocols. But (although not >> described the way John Day does) we understand that "upper" can be >> recursion at the same layer. >> >> If we declare SCHC to be an extension header, I do not know how we >> answer the question the next time someone asks us "is this use an upper >> layer header or an extension header?" As long as we provide an ability >> to answer that question, I can live with either alternative. >> >> Yours, >> >> Joel >> >> On 9/7/2022 6:05 PM, Robert Moskowitz wrote: >>> It might be that the datagram can be interrogated for the Next Header >>> and that MIGHT mean an update to 8200. >>> >>> AH, you can find the NH. ESP not, as it is in the encrypted part. >>> >>> 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... >>> >>> Fun. >>> >>> On 9/7/22 17:35, Joel Halpern wrote: >>>> 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 <[email protected]> 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 >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/int-area >>> >> >> _______________________________________________ >> Int-area mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/int-area >> > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
