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

[Robert Moskowitz <[e-mail]>]

With 20-20 hindsight and that ship long since sailed, we missed an 
opportunity years back to create "foo over UDP" by selecting a specific 
UDP port pair where the 1st byte after the UDP header was the 
IPv4Protocol/IPv6NextHeader field.

Might have made things simpler and enable more interesting things.

But that ship sailed long ago.

And since I have not been told what programmatic and/or operational item 
occurs for IP Extension Headers, I have no problem with dropping 
defining SCHC as an Internet Protocol Number as also a IP Extension 
Header type.

I just don't see any value in doing it.

Bob

On 9/8/22 09:48, Joel Halpern wrote:
> There are multiple "protocols" that are essentially tunnel headers 
> that use UDP.   Many of them have extension points in those headers. 
> And almost all of them can carry IP packets which can themselves 
> ccntain IP extension headers.
>
> My view is that the registry for extension headers is not about 
> whether the function of what is carried extends IP (many things not 
> listed there effectively extend the IP header information) but whether 
> the field beign defined is structurally an IP extension header.  Thus, 
> I have no problem with SCHC supporting the various use cases Pascal 
> describes without claiming that SCHC is an extension header.  
> Structurally, it isn't an extension header.
>
> Yours,
>
> Joel
>
> On 9/8/2022 3:38 AM, Antoine FRESSANCOURT wrote:
>> 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 <[e-mail]> On Behalf Of Joel Halpern
>> Sent: mercredi 7 septembre 2022 23:54
>> To: Robert Moskowitz <[e-mail]>
>> Cc: Internet Area <[e-mail]>
>> 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 <[e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/int-area
>> _______________________________________________
>> Int-area mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/int-area
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area