Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-intarea-schc-ip-protocol-number

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-bounces@ietf.org> On Behalf Of Joel Halpern
Sent: mercredi 7 septembre 2022 23:54
To: Robert Moskowitz <rgm-ietf@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.hinden@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