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 <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
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
