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

[Bob Hinden]

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)  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"  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" 
>>  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  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
>> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Int-area mailing list
Int-area@ietf.org

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

[Eric Vyncke (evyncke)]

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"  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" 
 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  
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
>  >
>
>  

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

[Robert Moskowitz]

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" 
 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  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

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

[Eric Vyncke (evyncke)]

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" 
 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  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

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

[Carsten Bormann]

On 2022-09-08, at 18:08, Robert Moskowitz  wrote:
> 
> Thanks Tom!
> 
> Wow is that buried...  (IMHO)

Third hit for me under
https://www.google.com/search?q=IPv6-Compression-Protocol+Types+site%3Aiana.org

> The values seem to be all over the place.  Any insight as to why this is?

Hysterical raisins…
Header compression for IP started 42 years ago with RFC 1144 and has evolved a 
lot since then.  So did PPP.
(PPP also has these favorable and less favorable numbers, where what is 
favorable depends on what environment this will be used for.)

Grüße, Carsten



> 
> Bob
> 
> On 9/8/22 11:55, tom petch wrote:
>> From: Int-area  on behalf of Robert Moskowitz 
>> 
>> Sent: 08 September 2022 14:03
>> On 9/8/22 08:31, Pascal Thubert (pthubert) wrote:
>>> Hello Joel:
>>> 
>>> SCHC could be used to compress IP option headers and the residue be stored 
>>> in a SCHC option, which a next header points at uncompressed transport 
>>> (e.g., encrypted, uncompressible).
>>> Additionally, finding the SCHC context may require metadata that could also 
>>> be found in a SCHC option. Over one hop in LPWAN that is all implicit but 
>>> over IP it might not be.
>>> 
>>> SCHC is layered depending on which endpoint talks to which. E.g., you 
>>> compress a tunnel with inner that is already SCHC-compressed, you do 
>>> security, etc...
>>> So you could have SCHC options one after the other. We have not defined the 
>>> option yet, LPWAN is discussing recharter to cover SCHC applied beyond 
>>> LPWANs.
>>> 
>>> But since we're at it, let's do both in one RFC.
>>> Note that we'll also need a value for IPv6-Compression-Protocol Types, see 
>>> https://www.ietf.org/archive/id/draft-thubert-intarea-schc-over-ppp-03.html#name-iana-considerations.
>>> 
>> I cannot find this IANA registry.  Can someone please provide the URL.
>> 
>> Perhaps
>> https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-29
>> 
>> IP-Compression-Protocol Types in the Point-to-Point Protocol (PPP) Field 
>> Assignments  Group on the IANA website as set up by RFC1332.
>> 
>> Tom Petch
>> 
>> And this is why I have been instructed, and have adhered to, including
>> IANA URLs as informative references in my drafts.
>> 
>> Like in draft-moskowitz-intarea-schc-ip-protocol-number!
>> 
>> Bob
>> 
>> ___
>> 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

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

[Robert Moskowitz]

Thanks Tom!

Wow is that buried...  (IMHO)

The values seem to be all over the place.  Any insight as to why this is?

Bob

On 9/8/22 11:55, tom petch wrote:

From: Int-area  on behalf of Robert Moskowitz 

Sent: 08 September 2022 14:03
On 9/8/22 08:31, Pascal Thubert (pthubert) wrote:

Hello Joel:

SCHC could be used to compress IP option headers and the residue be stored in a 
SCHC option, which a next header points at uncompressed transport (e.g., 
encrypted, uncompressible).
Additionally, finding the SCHC context may require metadata that could also be 
found in a SCHC option. Over one hop in LPWAN that is all implicit but over IP 
it might not be.

SCHC is layered depending on which endpoint talks to which. E.g., you compress 
a tunnel with inner that is already SCHC-compressed, you do security, etc...
So you could have SCHC options one after the other. We have not defined the 
option yet, LPWAN is discussing recharter to cover SCHC applied beyond LPWANs.

But since we're at it, let's do both in one RFC.
Note that we'll also need a value for IPv6-Compression-Protocol Types, see 
https://www.ietf.org/archive/id/draft-thubert-intarea-schc-over-ppp-03.html#name-iana-considerations.


I cannot find this IANA registry.  Can someone please provide the URL.

Perhaps
https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-29

IP-Compression-Protocol Types in the Point-to-Point Protocol (PPP) Field 
Assignments  Group on the IANA website as set up by RFC1332.

Tom Petch

And this is why I have been instructed, and have adhered to, including
IANA URLs as informative references in my drafts.

Like in draft-moskowitz-intarea-schc-ip-protocol-number!

Bob

___
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

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

[tom petch]

From: Int-area  on behalf of Robert Moskowitz 

Sent: 08 September 2022 14:03
On 9/8/22 08:31, Pascal Thubert (pthubert) wrote:
> Hello Joel:
>
> SCHC could be used to compress IP option headers and the residue be stored in 
> a SCHC option, which a next header points at uncompressed transport (e.g., 
> encrypted, uncompressible).
> Additionally, finding the SCHC context may require metadata that could also 
> be found in a SCHC option. Over one hop in LPWAN that is all implicit but 
> over IP it might not be.
>
> SCHC is layered depending on which endpoint talks to which. E.g., you 
> compress a tunnel with inner that is already SCHC-compressed, you do 
> security, etc...
> So you could have SCHC options one after the other. We have not defined the 
> option yet, LPWAN is discussing recharter to cover SCHC applied beyond LPWANs.
>
> But since we're at it, let's do both in one RFC.
> Note that we'll also need a value for IPv6-Compression-Protocol Types, see 
> https://www.ietf.org/archive/id/draft-thubert-intarea-schc-over-ppp-03.html#name-iana-considerations.
>

I cannot find this IANA registry.  Can someone please provide the URL.

Perhaps
https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-29

IP-Compression-Protocol Types in the Point-to-Point Protocol (PPP) Field 
Assignments  Group on the IANA website as set up by RFC1332.

Tom Petch

And this is why I have been instructed, and have adhered to, including
IANA URLs as informative references in my drafts.

Like in draft-moskowitz-intarea-schc-ip-protocol-number!

Bob

___
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

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

[Robert Moskowitz]

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  On Behalf Of Joel Halpern
Sent: mercredi 7 septembre 2022 23:54
To: Robert Moskowitz 
Cc: Internet Area 
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  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


_

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

[Joel Halpern]

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  On Behalf Of Joel Halpern
Sent: mercredi 7 septembre 2022 23:54
To: Robert Moskowitz 
Cc: Internet Area 
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  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

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

[Robert Moskowitz]

On 9/8/22 08:31, Pascal Thubert (pthubert) wrote:

Hello Joel:

SCHC could be used to compress IP option headers and the residue be stored in a 
SCHC option, which a next header points at uncompressed transport (e.g., 
encrypted, uncompressible).
Additionally, finding the SCHC context may require metadata that could also be 
found in a SCHC option. Over one hop in LPWAN that is all implicit but over IP 
it might not be.

SCHC is layered depending on which endpoint talks to which. E.g., you compress 
a tunnel with inner that is already SCHC-compressed, you do security, etc...
So you could have SCHC options one after the other. We have not defined the 
option yet, LPWAN is discussing recharter to cover SCHC applied beyond LPWANs.

But since we're at it, let's do both in one RFC.
Note that we'll also need a value for IPv6-Compression-Protocol Types, see 
https://www.ietf.org/archive/id/draft-thubert-intarea-schc-over-ppp-03.html#name-iana-considerations.



I cannot find this IANA registry.  Can someone please provide the URL.

And this is why I have been instructed, and have adhered to, including 
IANA URLs as informative references in my drafts.


Like in draft-moskowitz-intarea-schc-ip-protocol-number!

Bob

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Pascal Thubert (pthubert)]

Hello Carsten

> > 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…
> 
> Header Compression is organized layer violation, so even trying to assign
> a layer to it is futile.

As always, I love the way you're stating things

> Header Compression is usually done hop-by-hop as a local optimization,
> invisible to the endpoints; there is no end-to-end semantics that would be
> typical for a Transport Layer protocol.

With the neat that depending on what the layer is the endpoints are different.
See for instance 
https://www.rfc-editor.org/rfc/rfc8824.html#name-oscore-compression
So there can definitely be SCHC in SCHC, with different endpoints and rules.

For the PPP draft that uses SCHC as a PPP compression method, the endpoints are 
those of the PPP session. The architecture question is how to best structure 
the SCHC nesting.  
In Figure 7 of RFC 8824 the (encrypted) inner SCHC is concatenated to the 
residue of the outer SCHC. This means that the SCHC context is fully implicit 
and that the bits after the residue have to be the inner SCHC. Making those 2 
different SCHC headers would allow to decide for each layer whether SCHC is 
used or not, and pass enough info to avoid implicit deduction that may be 
misleading or constraining.
As far as RFC 8824 is great for LPWANs, I believe we need some better 
architectural structure when going to IP at large.




> The discussion so far about whether SCHC (or ROHC) would be IPv6 Extension
> Header Types seems to be rather sophistic to me, with little practical
> relevance of choosing one or the other.  Is there any behavior that would
> change based on whether they are IPv6 Extension Header Types or not?
> 
Yes, it seems to be placing the cart before the horse. But then again this is 
layer 0 of a stack of things we wish to achieve. So reserving the value in both 
registries, that's the same cost anyway.

All the best.

Pascal

> Grüße, Carsten
> 
> ___
> 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

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

[Pascal Thubert (pthubert)]

Hello Joel:

SCHC could be used to compress IP option headers and the residue be stored in a 
SCHC option, which a next header points at uncompressed transport (e.g., 
encrypted, uncompressible).
Additionally, finding the SCHC context may require metadata that could also be 
found in a SCHC option. Over one hop in LPWAN that is all implicit but over IP 
it might not be.

SCHC is layered depending on which endpoint talks to which. E.g., you compress 
a tunnel with inner that is already SCHC-compressed, you do security, etc... 
So you could have SCHC options one after the other. We have not defined the 
option yet, LPWAN is discussing recharter to cover SCHC applied beyond LPWANs. 

But since we're at it, let's do both in one RFC.
Note that we'll also need a value for IPv6-Compression-Protocol Types, see 
https://www.ietf.org/archive/id/draft-thubert-intarea-schc-over-ppp-03.html#name-iana-considerations.

All the best,

Pascal




> -Original Message-
> From: Int-area  On Behalf Of Joel Halpern
> Sent: mercredi 7 septembre 2022 23:35
> To: Robert Moskowitz ; Bob Hinden
> 
> Cc: Internet Area 
> Subject: Re: [Int-area] Resubmit - requesting WG Adoption draft-moskowitz-
> intarea-schc-ip-protocol-number
> 
> 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  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

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

[Antoine FRESSANCOURT]

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  On Behalf Of Joel Halpern
Sent: mercredi 7 septembre 2022 23:54
To: Robert Moskowitz 
Cc: Internet Area 
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  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

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

[Bob Hinden]

Joel,

> On Sep 7, 2022, at 2:35 PM, 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 ...

That is my take as well.

Bob


> 
> 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  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



signature.asc
Description: Message signed with OpenPGP
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Robert Moskowitz]

On 9/7/22 19:08, Carsten Bormann wrote:

On 8. Sep 2022, at 00:05, Robert Moskowitz  wrote:

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…

Header Compression is organized layer violation, so even trying to assign a 
layer to it is futile.
Header Compression is usually done hop-by-hop as a local optimization, 
invisible to the endpoints; there is no end-to-end semantics that would be 
typical for a Transport Layer protocol.

The discussion so far about whether SCHC (or ROHC) would be IPv6 Extension 
Header Types seems to be rather sophistic to me, with little practical 
relevance of choosing one or the other.  Is there any behavior that would 
change based on whether they are IPv6 Extension Header Types or not?


And I guess in large measure, this is the core of it.  What processing 
uniqueness is there for Ext Headers?  Why bother identifying which 
Protocols are or are not such.


I guess I need to read 8200 to understand this?  As if this is something 
I really need to add to my workload?  :)


And although much of Header Compression is done hop-by-hop as you 
indicated, I am proposing E2E use cases.


But then CoAP compression within DTLS is E2E.


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Carsten Bormann]

On 8. Sep 2022, at 00:05, Robert Moskowitz  wrote:
> 
> 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…

Header Compression is organized layer violation, so even trying to assign a 
layer to it is futile.
Header Compression is usually done hop-by-hop as a local optimization, 
invisible to the endpoints; there is no end-to-end semantics that would be 
typical for a Transport Layer protocol.

The discussion so far about whether SCHC (or ROHC) would be IPv6 Extension 
Header Types seems to be rather sophistic to me, with little practical 
relevance of choosing one or the other.  Is there any behavior that would 
change based on whether they are IPv6 Extension Header Types or not?

Grüße, Carsten

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Joel Halpern]

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  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

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

[Robert Moskowitz]

Oh, and although HIP has NH as the first byte in its header, that is NOT 
for something within the HIP datagram.  Rather this was a design to 
allow a "Piggybacking" of something else after HIP within the IP 
datagram.  For example a HIP R2 packet can have a NH of ESP where the 
ESP is in transport mode carrying a TCP SYN to start the TCP exchange, 
thus saving one packet in the exchange.




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  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

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

[Robert Moskowitz]

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  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

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

[Joel Halpern]

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  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

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

[Robert Moskowitz]

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  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

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

[Joel Halpern]

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  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

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

[Robert Moskowitz]

Yes, adopt it then have the knockdown, drag out on WHAT is an Extention 
Header...


Fun had by all!

On 9/7/22 16:55, Bob Hinden wrote:

Bob,


On Sep 7, 2022, at 1:53 PM, Robert Moskowitz  wrote:



On 9/7/22 16:04, Bob Hinden wrote:

Bob,

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 understood this.  The question is vers -00 or -01 going foreward.

Given it’s a request for adoption call, -01 is fine.   All can be changed later 
once it is a w.g. document :-)

Bob



thanks for your support.

Bob M.



Bob



On Sep 7, 2022, at 12:46 PM, Robert Moskowitz  wrote:



On 9/7/22 15:15, Carsten Bormann wrote:

On 2022-09-07, at 18:36, Bob Hinden  wrote:

Is this an IPv6 extension header?Does SCHC include a next header field so 
it can point to a header that follows?

If you haven’t seen RFC 5856 to 5858: This is a miniseries of documents where 
we have done the analog thing for the ROHC Robust Header Compression scheme 
that is now being proposed for the SCHC Static Context Header Compression 
scheme.

SCHC did it the other direction, first defining SCHC and then some of us coming 
up with use cases for it being the actual IP protocol.


The actual allocation of an Internet Protocol Number to ROHC is in Section 6 of 
RFC 5858:  https://www.rfc-editor.org/rfc/rfc5858.html#section-6

IANA has allocated the value 142 to "ROHC" within the "Protocol
Numbers" registry [PROTOCOL].  This value will be used to indicate
that the next-level protocol header is a ROHC header.

Some forms of ROHC headers contain a next header field, but mostly that field 
is compressed away as it is redundant between packets in a flow.

Bob’s document is doing the equivalent to RFC 5858, now for SCHC.
Once there is a WG adoption call, I’ll express that I am very much in favor of 
this work going forward.
(As I have said before, I’d also like to see the equivalent IKE/IPsec support 
that RFC 5856 and RFC 5857 provide for SCHC as well.  But this can be done on 
different timescales.)

Diet-ESP is the starting point.  It has to be fully SCHCed.

DTLS is already compressed enough, but as I point out, given DTLS and SCHC, you 
rarely need the UDP header content.

Bob



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Robert Moskowitz]

On 9/7/22 16:35, Carsten Bormann wrote:

On 7. Sep 2022, at 22:04, Bob Hinden  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

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

[Bob Hinden]

Bob,

> On Sep 7, 2022, at 1:53 PM, Robert Moskowitz  wrote:
> 
> 
> 
> On 9/7/22 16:04, Bob Hinden wrote:
>> Bob,
>> 
>> 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 understood this.  The question is vers -00 or -01 going foreward.

Given it’s a request for adoption call, -01 is fine.   All can be changed later 
once it is a w.g. document :-)

Bob


> 
> thanks for your support.
> 
> Bob M.
> 
> 
>> 
>> Bob
>> 
>> 
>>> On Sep 7, 2022, at 12:46 PM, Robert Moskowitz  
>>> wrote:
>>> 
>>> 
>>> 
>>> On 9/7/22 15:15, Carsten Bormann wrote:
 On 2022-09-07, at 18:36, Bob Hinden  wrote:
> Is this an IPv6 extension header?Does SCHC include a next header 
> field so it can point to a header that follows?
 If you haven’t seen RFC 5856 to 5858: This is a miniseries of documents 
 where we have done the analog thing for the ROHC Robust Header Compression 
 scheme that is now being proposed for the SCHC Static Context Header 
 Compression scheme.
>>> SCHC did it the other direction, first defining SCHC and then some of us 
>>> coming up with use cases for it being the actual IP protocol.
>>> 
 The actual allocation of an Internet Protocol Number to ROHC is in Section 
 6 of RFC 5858:  https://www.rfc-editor.org/rfc/rfc5858.html#section-6
 
IANA has allocated the value 142 to "ROHC" within the "Protocol
Numbers" registry [PROTOCOL].  This value will be used to indicate
that the next-level protocol header is a ROHC header.
 
 Some forms of ROHC headers contain a next header field, but mostly that 
 field is compressed away as it is redundant between packets in a flow.
 
 Bob’s document is doing the equivalent to RFC 5858, now for SCHC.
 Once there is a WG adoption call, I’ll express that I am very much in 
 favor of this work going forward.
 (As I have said before, I’d also like to see the equivalent IKE/IPsec 
 support that RFC 5856 and RFC 5857 provide for SCHC as well.  But this can 
 be done on different timescales.)
>>> Diet-ESP is the starting point.  It has to be fully SCHCed.
>>> 
>>> DTLS is already compressed enough, but as I point out, given DTLS and SCHC, 
>>> you rarely need the UDP header content.
>>> 
>>> Bob
>>> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Robert Moskowitz]

On 9/7/22 16:04, Bob Hinden wrote:

Bob,

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 understood this.  The question is vers -00 or -01 going foreward.

thanks for your support.

Bob M.




Bob



On Sep 7, 2022, at 12:46 PM, Robert Moskowitz  wrote:



On 9/7/22 15:15, Carsten Bormann wrote:

On 2022-09-07, at 18:36, Bob Hinden  wrote:

Is this an IPv6 extension header?Does SCHC include a next header field so 
it can point to a header that follows?

If you haven’t seen RFC 5856 to 5858: This is a miniseries of documents where 
we have done the analog thing for the ROHC Robust Header Compression scheme 
that is now being proposed for the SCHC Static Context Header Compression 
scheme.

SCHC did it the other direction, first defining SCHC and then some of us coming 
up with use cases for it being the actual IP protocol.


The actual allocation of an Internet Protocol Number to ROHC is in Section 6 of 
RFC 5858:  https://www.rfc-editor.org/rfc/rfc5858.html#section-6

IANA has allocated the value 142 to "ROHC" within the "Protocol
Numbers" registry [PROTOCOL].  This value will be used to indicate
that the next-level protocol header is a ROHC header.

Some forms of ROHC headers contain a next header field, but mostly that field 
is compressed away as it is redundant between packets in a flow.

Bob’s document is doing the equivalent to RFC 5858, now for SCHC.
Once there is a WG adoption call, I’ll express that I am very much in favor of 
this work going forward.
(As I have said before, I’d also like to see the equivalent IKE/IPsec support 
that RFC 5856 and RFC 5857 provide for SCHC as well.  But this can be done on 
different timescales.)

Diet-ESP is the starting point.  It has to be fully SCHCed.

DTLS is already compressed enough, but as I point out, given DTLS and SCHC, you 
rarely need the UDP header content.

Bob



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Carsten Bormann]

On 7. Sep 2022, at 22:04, Bob Hinden  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.

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

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

[Bob Hinden]

Bob,

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.

Bob


> On Sep 7, 2022, at 12:46 PM, Robert Moskowitz  
> wrote:
> 
> 
> 
> On 9/7/22 15:15, Carsten Bormann wrote:
>> On 2022-09-07, at 18:36, Bob Hinden  wrote:
>>> Is this an IPv6 extension header?Does SCHC include a next header field 
>>> so it can point to a header that follows?
>> If you haven’t seen RFC 5856 to 5858: This is a miniseries of documents 
>> where we have done the analog thing for the ROHC Robust Header Compression 
>> scheme that is now being proposed for the SCHC Static Context Header 
>> Compression scheme.
> 
> SCHC did it the other direction, first defining SCHC and then some of us 
> coming up with use cases for it being the actual IP protocol.
> 
>> The actual allocation of an Internet Protocol Number to ROHC is in Section 6 
>> of RFC 5858:  https://www.rfc-editor.org/rfc/rfc5858.html#section-6
>> 
>>IANA has allocated the value 142 to "ROHC" within the "Protocol
>>Numbers" registry [PROTOCOL].  This value will be used to indicate
>>that the next-level protocol header is a ROHC header.
>> 
>> Some forms of ROHC headers contain a next header field, but mostly that 
>> field is compressed away as it is redundant between packets in a flow.
>> 
>> Bob’s document is doing the equivalent to RFC 5858, now for SCHC.
>> Once there is a WG adoption call, I’ll express that I am very much in favor 
>> of this work going forward.
>> (As I have said before, I’d also like to see the equivalent IKE/IPsec 
>> support that RFC 5856 and RFC 5857 provide for SCHC as well.  But this can 
>> be done on different timescales.)
> 
> Diet-ESP is the starting point.  It has to be fully SCHCed.
> 
> DTLS is already compressed enough, but as I point out, given DTLS and SCHC, 
> you rarely need the UDP header content.
> 
> Bob
> 



signature.asc
Description: Message signed with OpenPGP
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Carsten Bormann]

On 7. Sep 2022, at 21:46, Robert Moskowitz  wrote:
> 
> SCHC did it the other direction, first defining SCHC and then some of us 
> coming up with use cases for it being the actual IP protocol.

Well, ROHC had been in use for almost a decade (RFC 3095) before we finally 
found that we’d need an IP protocol number (RFC 5858, predominantly to better 
compress ESP, which obviously cannot be compressed from the outside), so I’d 
say we went through the same sequence.

Grüße, Carsten

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Robert Moskowitz]

On 9/7/22 15:15, Carsten Bormann wrote:

On 2022-09-07, at 18:36, Bob Hinden  wrote:

Is this an IPv6 extension header?Does SCHC include a next header field so 
it can point to a header that follows?

If you haven’t seen RFC 5856 to 5858: This is a miniseries of documents where 
we have done the analog thing for the ROHC Robust Header Compression scheme 
that is now being proposed for the SCHC Static Context Header Compression 
scheme.


SCHC did it the other direction, first defining SCHC and then some of us 
coming up with use cases for it being the actual IP protocol.



The actual allocation of an Internet Protocol Number to ROHC is in Section 6 of 
RFC 5858:  https://www.rfc-editor.org/rfc/rfc5858.html#section-6

IANA has allocated the value 142 to "ROHC" within the "Protocol
Numbers" registry [PROTOCOL].  This value will be used to indicate
that the next-level protocol header is a ROHC header.

Some forms of ROHC headers contain a next header field, but mostly that field 
is compressed away as it is redundant between packets in a flow.

Bob’s document is doing the equivalent to RFC 5858, now for SCHC.
Once there is a WG adoption call, I’ll express that I am very much in favor of 
this work going forward.
(As I have said before, I’d also like to see the equivalent IKE/IPsec support 
that RFC 5856 and RFC 5857 provide for SCHC as well.  But this can be done on 
different timescales.)


Diet-ESP is the starting point.  It has to be fully SCHCed.

DTLS is already compressed enough, but as I point out, given DTLS and 
SCHC, you rarely need the UDP header content.


Bob

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Carsten Bormann]

On 2022-09-07, at 18:36, Bob Hinden  wrote:
> 
> Is this an IPv6 extension header?Does SCHC include a next header field so 
> it can point to a header that follows?

If you haven’t seen RFC 5856 to 5858: This is a miniseries of documents where 
we have done the analog thing for the ROHC Robust Header Compression scheme 
that is now being proposed for the SCHC Static Context Header Compression 
scheme.

The actual allocation of an Internet Protocol Number to ROHC is in Section 6 of 
RFC 5858:  https://www.rfc-editor.org/rfc/rfc5858.html#section-6

   IANA has allocated the value 142 to "ROHC" within the "Protocol
   Numbers" registry [PROTOCOL].  This value will be used to indicate
   that the next-level protocol header is a ROHC header.

Some forms of ROHC headers contain a next header field, but mostly that field 
is compressed away as it is redundant between packets in a flow.

Bob’s document is doing the equivalent to RFC 5858, now for SCHC.
Once there is a WG adoption call, I’ll express that I am very much in favor of 
this work going forward.
(As I have said before, I’d also like to see the equivalent IKE/IPsec support 
that RFC 5856 and RFC 5857 provide for SCHC as well.  But this can be done on 
different timescales.)

Grüße, Carsten

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Robert Moskowitz]

On 9/7/22 12:56, Joel Halpern wrote:
From your description, it seems clear that the SCHC header is not an 
extension header.  It does not follow the rules for extension 
headers.  Instead, it is an upper layer / carried protocol, just like 
IP in IP, or UDP carrying all sorts of interesting network layer headers.


I should clarify, that the Next Header value is almost always there, but 
just not in the physically in the datagram.


It could even be UDP with a rule that squeezes it down to zero bytes on 
the wire.  Further, since this is the ONLY SCHC rule between the 2 
parties, the physical length of the SCHC rule is also zero.  So what you 
may actually see on the wire is SCHC as Protocol Number and the next 
byte is the CID of a DTLS header.


So how do you label this thing?

Bob M.



Yours,

Joel

On 9/7/2022 12:47 PM, Robert Moskowitz wrote:



On 9/7/22 12:36, Bob Hinden wrote:

Pascal,

On Sep 6, 2022, at 11:26 PM, Pascal Thubert (pthubert) 
 wrote:


Hello Bob M.

My support remains, and so does my earlier comment. I believe the 
IANA section should indicate that the IPv6 extension header type 
registry must be also updated, see the notes at the top of 
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml 

Is this an IPv6 extension header?    Does SCHC include a next header 
field so it can point to a header that follows?


I think it does (at least in some cases), but wanted to confirm 
this.   Might be good to add a few words in the draft that describes 
this.


Oh, boy

That is all compressed!  The SCHC rule may say to expand and put in 
the next header.


For example the content is ESP, which it self is compressed according 
to appropriate SCHC rules.


So no, there is probably never an explicit Next Header.

And yes, there is almost always, after expansion, a header to be 
processed.


Wierd

Bob M.




Bob



All the best;

Pascal

From: Int-area  On Behalf Of Robert 
Moskowitz

Sent: mercredi 7 septembre 2022 4:44
To: Internet Area 
Subject: [Int-area] Resubmit - requesting WG Adoption 
draft-moskowitz-intarea-schc-ip-protocol-number



As was discussed at the INTAREA meeting at IETF 114,

I request that a call for WG adoption of this draft.

I have made draft name change and edits per Bob Hinden.

As I said earlier, there is a lot of work which will cascade in 
other areas once this is one its way.


thanks

Bob




 Forwarded Message 
Subject:
New Version Notification for 
draft-moskowitz-intarea-schc-ip-protocol-number-00.txt

Date:
Tue, 06 Sep 2022 19:40:41 -0700
From:
internet-dra...@ietf.org
To:
Stuart W. Card , Adam Wiethuechter 
, Robert Moskowitz 
, Stuart Card 




A new version of I-D, 
draft-moskowitz-intarea-schc-ip-protocol-number-00.txt

has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-intarea-schc-ip-protocol-number
Revision: 00
Title: Internet Protocol Number for SCHC
Document date: 2022-09-06
Group: Individual Submission
Pages: 7
URL: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-moskowitz-intarea-schc-ip-protocol-number/
Html: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-intarea-schc-ip-protocol-number



Abstract:
This document requests an Internet Protocol Number assignment for
SCHC so that SCHC can be used for IP independent SCHC of other
transports such as UDP and ESP.



The IETF Secretariat


___
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

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

[Robert Moskowitz]

On 9/7/22 12:56, Joel Halpern wrote:
From your description, it seems clear that the SCHC header is not an 
extension header.  It does not follow the rules for extension 
headers.  Instead, it is an upper layer / carried protocol, just like 
IP in IP, or UDP carrying all sorts of interesting network layer headers.


Back to ver -00!

:)

I really don't know, and look to those like you for guidance.

An 'observer' of the packet will see that it is SCHC payload and not 
know what to do with it.  Almost as bad as ESP.


It takes a receiver that has the SCHC rule to then expand the packet.  
And this may be in steps.  For example if the first expansion is ESP and 
the rule further says this is DIET-ESP, so the ESP header first needs to 
be decompressed before it is handed to the ESP process.  And then the 
Next Header in ESP is SCHC, so again it gets routed to SCHC handling 
which expands again and maybe this pass inserts the UDP header...


Well you see.  I hope.

If those with knowledge about this say this is NOT an extension header, 
what do I do?  Is there a way to retract ver -01, or do I submit -02 
which is identical to -00.  Maybe add text like above so that there is 
better understanding by non-SCHC conversant readers?


thanks

Bob M.




Yours,

Joel

On 9/7/2022 12:47 PM, Robert Moskowitz wrote:



On 9/7/22 12:36, Bob Hinden wrote:

Pascal,

On Sep 6, 2022, at 11:26 PM, Pascal Thubert (pthubert) 
 wrote:


Hello Bob M.

My support remains, and so does my earlier comment. I believe the 
IANA section should indicate that the IPv6 extension header type 
registry must be also updated, see the notes at the top of 
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml 

Is this an IPv6 extension header?    Does SCHC include a next header 
field so it can point to a header that follows?


I think it does (at least in some cases), but wanted to confirm 
this.   Might be good to add a few words in the draft that describes 
this.


Oh, boy

That is all compressed!  The SCHC rule may say to expand and put in 
the next header.


For example the content is ESP, which it self is compressed according 
to appropriate SCHC rules.


So no, there is probably never an explicit Next Header.

And yes, there is almost always, after expansion, a header to be 
processed.


Wierd

Bob M.




Bob



All the best;

Pascal

From: Int-area  On Behalf Of Robert 
Moskowitz

Sent: mercredi 7 septembre 2022 4:44
To: Internet Area 
Subject: [Int-area] Resubmit - requesting WG Adoption 
draft-moskowitz-intarea-schc-ip-protocol-number



As was discussed at the INTAREA meeting at IETF 114,

I request that a call for WG adoption of this draft.

I have made draft name change and edits per Bob Hinden.

As I said earlier, there is a lot of work which will cascade in 
other areas once this is one its way.


thanks

Bob




 Forwarded Message 
Subject:
New Version Notification for 
draft-moskowitz-intarea-schc-ip-protocol-number-00.txt

Date:
Tue, 06 Sep 2022 19:40:41 -0700
From:
internet-dra...@ietf.org
To:
Stuart W. Card , Adam Wiethuechter 
, Robert Moskowitz 
, Stuart Card 




A new version of I-D, 
draft-moskowitz-intarea-schc-ip-protocol-number-00.txt

has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-intarea-schc-ip-protocol-number
Revision: 00
Title: Internet Protocol Number for SCHC
Document date: 2022-09-06
Group: Individual Submission
Pages: 7
URL: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-moskowitz-intarea-schc-ip-protocol-number/
Html: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-intarea-schc-ip-protocol-number



Abstract:
This document requests an Internet Protocol Number assignment for
SCHC so that SCHC can be used for IP independent SCHC of other
transports such as UDP and ESP.



The IETF Secretariat


___
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

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

[Joel Halpern]

From your description, it seems clear that the SCHC header is not an 
extension header.  It does not follow the rules for extension headers.  
Instead, it is an upper layer / carried protocol, just like IP in IP, or 
UDP carrying all sorts of interesting network layer headers.


Yours,

Joel

On 9/7/2022 12:47 PM, Robert Moskowitz wrote:



On 9/7/22 12:36, Bob Hinden wrote:

Pascal,

On Sep 6, 2022, at 11:26 PM, Pascal Thubert (pthubert) 
 wrote:


Hello Bob M.

My support remains, and so does my earlier comment. I believe the 
IANA section should indicate that the IPv6 extension header type 
registry must be also updated, see the notes at the top of 
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml 

Is this an IPv6 extension header?    Does SCHC include a next header 
field so it can point to a header that follows?


I think it does (at least in some cases), but wanted to confirm 
this.   Might be good to add a few words in the draft that describes 
this.


Oh, boy

That is all compressed!  The SCHC rule may say to expand and put in 
the next header.


For example the content is ESP, which it self is compressed according 
to appropriate SCHC rules.


So no, there is probably never an explicit Next Header.

And yes, there is almost always, after expansion, a header to be 
processed.


Wierd

Bob M.




Bob



All the best;

Pascal

From: Int-area  On Behalf Of Robert 
Moskowitz

Sent: mercredi 7 septembre 2022 4:44
To: Internet Area 
Subject: [Int-area] Resubmit - requesting WG Adoption 
draft-moskowitz-intarea-schc-ip-protocol-number



As was discussed at the INTAREA meeting at IETF 114,

I request that a call for WG adoption of this draft.

I have made draft name change and edits per Bob Hinden.

As I said earlier, there is a lot of work which will cascade in 
other areas once this is one its way.


thanks

Bob




 Forwarded Message 
Subject:
New Version Notification for 
draft-moskowitz-intarea-schc-ip-protocol-number-00.txt

Date:
Tue, 06 Sep 2022 19:40:41 -0700
From:
internet-dra...@ietf.org
To:
Stuart W. Card , Adam Wiethuechter 
, Robert Moskowitz 
, Stuart Card 




A new version of I-D, 
draft-moskowitz-intarea-schc-ip-protocol-number-00.txt

has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-intarea-schc-ip-protocol-number
Revision: 00
Title: Internet Protocol Number for SCHC
Document date: 2022-09-06
Group: Individual Submission
Pages: 7
URL: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-moskowitz-intarea-schc-ip-protocol-number/
Html: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-intarea-schc-ip-protocol-number



Abstract:
This document requests an Internet Protocol Number assignment for
SCHC so that SCHC can be used for IP independent SCHC of other
transports such as UDP and ESP.



The IETF Secretariat


___
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

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

[Robert Moskowitz]

On 9/7/22 12:36, Bob Hinden wrote:

Pascal,


On Sep 6, 2022, at 11:26 PM, Pascal Thubert (pthubert) 
 wrote:

Hello Bob M.

My support remains, and so does my earlier comment. I believe the IANA section 
should indicate that the IPv6 extension header type registry must be also 
updated, see the notes at the top of 
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

Is this an IPv6 extension header?Does SCHC include a next header field so 
it can point to a header that follows?

I think it does (at least in some cases), but wanted to confirm this.   Might 
be good to add a few words in the draft that describes this.


Oh, boy

That is all compressed!  The SCHC rule may say to expand and put in the 
next header.


For example the content is ESP, which it self is compressed according to 
appropriate SCHC rules.


So no, there is probably never an explicit Next Header.

And yes, there is almost always, after expansion, a header to be processed.

Wierd

Bob M.




Bob



All the best;

Pascal

From: Int-area  On Behalf Of Robert Moskowitz
Sent: mercredi 7 septembre 2022 4:44
To: Internet Area 
Subject: [Int-area] Resubmit - requesting WG Adoption 
draft-moskowitz-intarea-schc-ip-protocol-number


As was discussed at the INTAREA meeting at IETF 114,

I request that a call for WG adoption of this draft.

I have made draft name change and edits per Bob Hinden.

As I said earlier, there is a lot of work which will cascade in other areas 
once this is one its way.

thanks

Bob




 Forwarded Message 
Subject:
New Version Notification for 
draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
Date:
Tue, 06 Sep 2022 19:40:41 -0700
From:
internet-dra...@ietf.org
To:
Stuart W. Card , Adam Wiethuechter 
, Robert Moskowitz , Stuart 
Card 



A new version of I-D, draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-intarea-schc-ip-protocol-number
Revision: 00
Title: Internet Protocol Number for SCHC
Document date: 2022-09-06
Group: Individual Submission
Pages: 7
URL: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-moskowitz-intarea-schc-ip-protocol-number/
Html: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-intarea-schc-ip-protocol-number


Abstract:
This document requests an Internet Protocol Number assignment for
SCHC so that SCHC can be used for IP independent SCHC of other
transports such as UDP and ESP.



The IETF Secretariat


___
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

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

[Bob Hinden]

Pascal,

> On Sep 6, 2022, at 11:26 PM, Pascal Thubert (pthubert) 
>  wrote:
> 
> Hello Bob M.
> 
> My support remains, and so does my earlier comment. I believe the IANA 
> section should indicate that the IPv6 extension header type registry must be 
> also updated, see the notes at the top of 
> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

Is this an IPv6 extension header?Does SCHC include a next header field so 
it can point to a header that follows?

I think it does (at least in some cases), but wanted to confirm this.   Might 
be good to add a few words in the draft that describes this.

Bob


> 
> All the best;
> 
> Pascal
> 
> From: Int-area  On Behalf Of Robert Moskowitz
> Sent: mercredi 7 septembre 2022 4:44
> To: Internet Area 
> Subject: [Int-area] Resubmit - requesting WG Adoption 
> draft-moskowitz-intarea-schc-ip-protocol-number
> 
> 
> As was discussed at the INTAREA meeting at IETF 114,
> 
> I request that a call for WG adoption of this draft.
> 
> I have made draft name change and edits per Bob Hinden.
> 
> As I said earlier, there is a lot of work which will cascade in other areas 
> once this is one its way.
> 
> thanks
> 
> Bob
> 
> 
> 
> 
>  Forwarded Message 
> Subject:
> New Version Notification for 
> draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
> Date:
> Tue, 06 Sep 2022 19:40:41 -0700
> From:
> internet-dra...@ietf.org
> To:
> Stuart W. Card , Adam Wiethuechter 
> , Robert Moskowitz 
> , Stuart Card 
> 
> 
> 
> A new version of I-D, draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
> has been successfully submitted by Robert Moskowitz and posted to the
> IETF repository.
> 
> Name: draft-moskowitz-intarea-schc-ip-protocol-number
> Revision: 00
> Title: Internet Protocol Number for SCHC
> Document date: 2022-09-06
> Group: Individual Submission
> Pages: 7
> URL: 
> https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-moskowitz-intarea-schc-ip-protocol-number/
> Html: 
> https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.html
> Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-moskowitz-intarea-schc-ip-protocol-number
> 
> 
> Abstract:
> This document requests an Internet Protocol Number assignment for
> SCHC so that SCHC can be used for IP independent SCHC of other
> transports such as UDP and ESP.
> 
> 
> 
> The IETF Secretariat
> 
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area



signature.asc
Description: Message signed with OpenPGP
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Robert Moskowitz]

Ah, I figured it out for myself and did the additions. ver -01 sbumitted:




 Forwarded Message 
Subject: 	New Version Notification for 
draft-moskowitz-intarea-schc-ip-protocol-number-01.txt

Date:   Wed, 07 Sep 2022 07:12:26 -0700
From:   internet-dra...@ietf.org
To: 	Stuart W. Card , Adam Wiethuechter 
, Robert Moskowitz 
, Stuart Card 





A new version of I-D, draft-moskowitz-intarea-schc-ip-protocol-number-01.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-intarea-schc-ip-protocol-number
Revision: 01
Title: Internet Protocol Number for SCHC
Document date: 2022-09-07
Group: Individual Submission
Pages: 7
URL: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-moskowitz-intarea-schc-ip-protocol-number/
Html: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-01.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-intarea-schc-ip-protocol-number
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-moskowitz-intarea-schc-ip-protocol-number-01


Abstract:
This document requests an Internet Protocol Number assignment for
SCHC so that SCHC can be used for IP independent SCHC of other
transports such as UDP and ESP.



The IETF Secretariat




On 9/7/22 08:19, Robert Moskowitz wrote:



On 9/7/22 02:26, Pascal Thubert (pthubert) wrote:


Hello Bob M.

My support remains, and so does my earlier comment. I believe the 
IANA section should indicate that the IPv6 extension header type 
registry must be also updated, see the notes at the top of 
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml




hmm.  Following that note I go to:

https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml

So you are saying that I should also add SCHC to:

https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header

?

Please confirm before I add this.

Bob




All the best;

Pascal

*From:* Int-area  *On Behalf Of *Robert 
Moskowitz

*Sent:* mercredi 7 septembre 2022 4:44
*To:* Internet Area 
*Subject:* [Int-area] Resubmit - requesting WG Adoption 
draft-moskowitz-intarea-schc-ip-protocol-number



As was discussed at the INTAREA meeting at IETF 114,

I request that a call for WG adoption of this draft.

I have made draft name change and edits per Bob Hinden.

As I said earlier, there is a lot of work which will cascade in other 
areas once this is one its way.


thanks

Bob



 Forwarded Message 

*Subject: *



New Version Notification for 
draft-moskowitz-intarea-schc-ip-protocol-number-00.txt


*Date: *



Tue, 06 Sep 2022 19:40:41 -0700

*From: *



internet-dra...@ietf.org

*To: *



Stuart W. Card  
<mailto:stu.c...@axenterprize.com>, Adam Wiethuechter 
 
<mailto:adam.wiethuech...@axenterprize.com>, Robert Moskowitz 
 <mailto:r...@labs.htt-consult.com>, Stuart 
Card  <mailto:stu.c...@axenterprize.com>





A new version of I-D, 
draft-moskowitz-intarea-schc-ip-protocol-number-00.txt

has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-intarea-schc-ip-protocol-number
Revision: 00
Title: Internet Protocol Number for SCHC
Document date: 2022-09-06
Group: Individual Submission
Pages: 7
URL: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-moskowitz-intarea-schc-ip-protocol-number/
Html: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-intarea-schc-ip-protocol-number



Abstract:
This document requests an Internet Protocol Number assignment for
SCHC so that SCHC can be used for IP independent SCHC of other
transports such as UDP and ESP.



The IETF Secretariat




___
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

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

[Robert Moskowitz]

On 9/7/22 02:26, Pascal Thubert (pthubert) wrote:


Hello Bob M.

My support remains, and so does my earlier comment. I believe the IANA 
section should indicate that the IPv6 extension header type registry 
must be also updated, see the notes at the top of 
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml




hmm.  Following that note I go to:

https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml

So you are saying that I should also add SCHC to:

https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header

?

Please confirm before I add this.

Bob




All the best;

Pascal

*From:* Int-area  *On Behalf Of *Robert 
Moskowitz

*Sent:* mercredi 7 septembre 2022 4:44
*To:* Internet Area 
*Subject:* [Int-area] Resubmit - requesting WG Adoption 
draft-moskowitz-intarea-schc-ip-protocol-number



As was discussed at the INTAREA meeting at IETF 114,

I request that a call for WG adoption of this draft.

I have made draft name change and edits per Bob Hinden.

As I said earlier, there is a lot of work which will cascade in other 
areas once this is one its way.


thanks

Bob



 Forwarded Message 

*Subject: *



New Version Notification for 
draft-moskowitz-intarea-schc-ip-protocol-number-00.txt


*Date: *



Tue, 06 Sep 2022 19:40:41 -0700

*From: *



internet-dra...@ietf.org

*To: *



Stuart W. Card  
<mailto:stu.c...@axenterprize.com>, Adam Wiethuechter 
 
<mailto:adam.wiethuech...@axenterprize.com>, Robert Moskowitz 
 <mailto:r...@labs.htt-consult.com>, Stuart 
Card  <mailto:stu.c...@axenterprize.com>





A new version of I-D, 
draft-moskowitz-intarea-schc-ip-protocol-number-00.txt

has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-intarea-schc-ip-protocol-number
Revision: 00
Title: Internet Protocol Number for SCHC
Document date: 2022-09-06
Group: Individual Submission
Pages: 7
URL: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-moskowitz-intarea-schc-ip-protocol-number/
Html: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-intarea-schc-ip-protocol-number



Abstract:
This document requests an Internet Protocol Number assignment for
SCHC so that SCHC can be used for IP independent SCHC of other
transports such as UDP and ESP.



The IETF Secretariat

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Robert Moskowitz]

You and I disagree on drafts

Drafts are forever.  I have rsynced them all on my hard drive.

tools search function works off from draft name.  Very handy.  Of course 
on my own copies, I use locate, find, and grep.


and datatracker allows the author to link all drafts together through 
name changes.


But I hear you...

Bob

On 9/7/22 05:15, tom petch wrote:

From: Int-area  on behalf of Robert Moskowitz 

Sent: 07 September 2022 03:43

As was discussed at the INTAREA meeting at IETF 114,

I request that a call for WG adoption of this draft.

I have made draft name change and edits per Bob Hinden.


I am sorry you have made this change.  The draft name only has meaning for the 
life of the draft; it needs to be unique, it needs to guide readers as to its 
content, it does not have to be semantically and syntactically perfect.

The document title, on the other hand, lives for ever and so its value  matters 
- change the draft name just makes it harder for everyone to track what has and 
is happening.

Tom Petch


As I said earlier, there is a lot of work which will cascade in other areas 
once this is one its way.

thanks

Bob




 Forwarded Message 
Subject:New Version Notification for 
draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
Date:   Tue, 06 Sep 2022 19:40:41 -0700
From:   internet-dra...@ietf.org
To: Stuart W. Card , Adam Wiethuechter 
, Robert Moskowitz 
, Stuart Card 




A new version of I-D, draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-intarea-schc-ip-protocol-number
Revision: 00
Title: Internet Protocol Number for SCHC
Document date: 2022-09-06
Group: Individual Submission
Pages: 7
URL: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-moskowitz-intarea-schc-ip-protocol-number/
Html: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-intarea-schc-ip-protocol-number


Abstract:
This document requests an Internet Protocol Number assignment for
SCHC so that SCHC can be used for IP independent SCHC of other
transports such as UDP and ESP.



The IETF Secretariat




___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[tom petch]

From: Int-area  on behalf of Robert Moskowitz 

Sent: 07 September 2022 03:43

As was discussed at the INTAREA meeting at IETF 114,

I request that a call for WG adoption of this draft.

I have made draft name change and edits per Bob Hinden.


I am sorry you have made this change.  The draft name only has meaning for the 
life of the draft; it needs to be unique, it needs to guide readers as to its 
content, it does not have to be semantically and syntactically perfect.

The document title, on the other hand, lives for ever and so its value  matters 
- change the draft name just makes it harder for everyone to track what has and 
is happening.

Tom Petch


As I said earlier, there is a lot of work which will cascade in other areas 
once this is one its way.

thanks

Bob




 Forwarded Message 
Subject:New Version Notification for 
draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
Date:   Tue, 06 Sep 2022 19:40:41 -0700
From:   internet-dra...@ietf.org
To: Stuart W. Card 
, Adam 
Wiethuechter 
,
 Robert Moskowitz 
, Stuart Card 




A new version of I-D, draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-intarea-schc-ip-protocol-number
Revision: 00
Title: Internet Protocol Number for SCHC
Document date: 2022-09-06
Group: Individual Submission
Pages: 7
URL: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-moskowitz-intarea-schc-ip-protocol-number/
Html: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-intarea-schc-ip-protocol-number


Abstract:
This document requests an Internet Protocol Number assignment for
SCHC so that SCHC can be used for IP independent SCHC of other
transports such as UDP and ESP.



The IETF Secretariat



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Pascal Thubert (pthubert)]

Hello Bob M.

My support remains, and so does my earlier comment. I believe the IANA section 
should indicate that the IPv6 extension header type registry must be also 
updated, see the notes at the top of 
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

All the best;

Pascal

From: Int-area  On Behalf Of Robert Moskowitz
Sent: mercredi 7 septembre 2022 4:44
To: Internet Area 
Subject: [Int-area] Resubmit - requesting WG Adoption 
draft-moskowitz-intarea-schc-ip-protocol-number


As was discussed at the INTAREA meeting at IETF 114,

I request that a call for WG adoption of this draft.

I have made draft name change and edits per Bob Hinden.

As I said earlier, there is a lot of work which will cascade in other areas 
once this is one its way.

thanks

Bob



 Forwarded Message 
Subject:
New Version Notification for 
draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
Date:
Tue, 06 Sep 2022 19:40:41 -0700
From:
internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
To:
Stuart W. Card <mailto:stu.c...@axenterprize.com>, 
Adam Wiethuechter 
<mailto:adam.wiethuech...@axenterprize.com>,
 Robert Moskowitz 
<mailto:r...@labs.htt-consult.com>, Stuart Card 
<mailto:stu.c...@axenterprize.com>



A new version of I-D, draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-intarea-schc-ip-protocol-number
Revision: 00
Title: Internet Protocol Number for SCHC
Document date: 2022-09-06
Group: Individual Submission
Pages: 7
URL: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-moskowitz-intarea-schc-ip-protocol-number/
Html: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-intarea-schc-ip-protocol-number


Abstract:
This document requests an Internet Protocol Number assignment for
SCHC so that SCHC can be used for IP independent SCHC of other
transports such as UDP and ESP.



The IETF Secretariat

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Robert Moskowitz]

As was discussed at the INTAREA meeting at IETF 114,

I request that a call for WG adoption of this draft.

I have made draft name change and edits per Bob Hinden.

As I said earlier, there is a lot of work which will cascade in other 
areas once this is one its way.


thanks

Bob




 Forwarded Message 
Subject: 	New Version Notification for 
draft-moskowitz-intarea-schc-ip-protocol-number-00.txt

Date:   Tue, 06 Sep 2022 19:40:41 -0700
From:   internet-dra...@ietf.org
To: 	Stuart W. Card , Adam Wiethuechter 
, Robert Moskowitz 
, Stuart Card 





A new version of I-D, draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-intarea-schc-ip-protocol-number
Revision: 00
Title: Internet Protocol Number for SCHC
Document date: 2022-09-06
Group: Individual Submission
Pages: 7
URL: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-moskowitz-intarea-schc-ip-protocol-number/
Html: 
https://www.ietf.org/archive/id/draft-moskowitz-intarea-schc-ip-protocol-number-00.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-intarea-schc-ip-protocol-number



Abstract:
This document requests an Internet Protocol Number assignment for
SCHC so that SCHC can be used for IP independent SCHC of other
transports such as UDP and ESP.



The IETF Secretariat

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area