Hello, Out of curiosity, as I am far less experienced than most people in this discussion, what do you have in mind when you mention " UDP-carrying headers-with-next-header as extension headers" ?
Thanks a lot for your clarifications, Antoine Fressancourt -----Original Message----- From: Int-area <int-area-boun...@ietf.org> On Behalf Of Joel Halpern Sent: mercredi 7 septembre 2022 23:54 To: Robert Moskowitz <rgm-i...@htt-consult.com> Cc: Internet Area <int-area@ietf.org> Subject: Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number 8200 implies that the first bye of the extension header is the next header field. explicitly and visibly. So that one can walk the next header chain. I would like us to articulate a clear meaning of when something is an extension header. I have tried to lay one such out. (Recognizing that there are a few historical exceptions). If we want instead to redefine IP-in-IP and UDP-carrying headers-with-next-header as extension headers I wouldn't like it, but I could live with it. Or we can say it si completely random I suppose. Although I have trouble seeing how that is a good answer. Yours, Joel PS: In case anyone is unclear, I am not criticizing Robert M. (or Bob H.). He is trying to do the right thing. And yes, we should give him a code point for this use. On 9/7/2022 5:49 PM, Robert Moskowitz wrote: > ESP, RFC 4303 most DEFINITELY DOES have a Next Header Field. > > It is just at the end of the datagram, before the ICV. > > > 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 <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
