Subject: [6lo] 6lo Last Call: draft-ietf-6lo-dispatch-iana-registry

From: Brian Haberman <[email-masked]>
Date: Tue, 1 Mar 2016 10:24:03 -0500

All,
     This message starts a 2-week working group last call on advancing:

     Title      : IANA Registry for 6lowpan ESC Dispatch Code points
     Authors    : Samita Chakrabarti
                  Gabriel Montenegro
                  Ralph Droms
                  James Woodyatt
     Filename   : draft-ietf-6lo-dispatch-iana-registry-01.txt
     Pages      : 8
     Date       : 2016-02-25

as a Proposed Standard. All substantive comments are to be posted to the
mailing list. Editorial comments should be sent to the document authors.
This last call will end on 2016-03-15.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Tue, 8 Mar 2016 08:21:20 -0500

Just a reminder on this last call. To date, I have seen zero feedback on
the suitability of this document for publication. Please review and
comment.  If no feedback is received, I will assume no one has an
interest in seeing the document published.

Regards,
Brian

On 3/1/16 10:24 AM, Brian Haberman wrote:
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 8 Mar 2016 15:52:29 +0000

Hello Brian:

Sorry for this delay, please find some comments below:

1) Sections 3 and 3.2 provide an example whereby the esc sequence is used after the IPHC+IP payload. One issue with that is that the packet length is elided by RFC6282 (section 3.2) and assumes the rest of the frame. If the ESC can be placed after an IPHC then we need to signal the size of the IP payload. An alternate approach would be that the order is enforced indicating that the escaped data is always before the IP header.

2) Section 3 says 'as long as it ... does noy induce fragmentation.' I'm unsure why 6LoWPAN fragmentation would be incompatible with the use of escape?

3) Section 3.1 mandates that unknown EEDs are dropped. This is a regression from IPv6 options which can signal whether they can be skipped, and 6LoRH. An alternate approach that is compatible with ITU-T specs could be to use the most (2? 3?) significant bits set to indicate skippable, in which case the other 7 (6?, 5?) bits could be a length in bytes, and then the next octet would be an EED. This would give us 127 (191?, 223?) non skippable EEDs and 254 skippable EEDs.

4) Section 3.4 does not update RFC4944 on NALP. Since NALP denotes a non-6LoWPAN behavior, it could be clarified that NALP is not expected inside a 6LoWPAN frame, meaning after a 6LoWPAN dispatch was found. After a transition phase, this would reopen the 00xxxxxx dispatch space inside a 6LoWPAN frame.

Cheers,

Pascal

> -----Original Message-----
> From: 6lo [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: mardi 1 mars 2016 16:24
> To: [email-masked]
> Cc: Jonathan Hui <[email-masked]>
> Subject: [6lo] 6lo Last Call: 	
> 
> All,

---

From: Samita Chakrabarti <[email-masked]>
Date: Sat, 19 Mar 2016 01:21:11 +0000

Hi Pascal,

Thanks so much for the detail review and the good catch on fragmentation and sequence after LOWPAN_IPHC.
Please see our response in-line and proposed updates.

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, March 08, 2016 7:52 AM
To: Brian Haberman; [email-masked]
Cc: Jonathan Hui
Subject: Re: [6lo] 6lo Last Call: draft-ietf-6lo-dispatch-iana-registry

Hello Brian:

[SC>] 

Good catch.  Though RFC8262 is not very clear that IPHC payload means the rest of the frame. But due to not being clear we could have implementations which can assume so. In order to mitigate this problem, we propose the updated text as following:

====
3.2.  ESC Extension Bytes Typical Sequence

When LOWPAN_IPHC is present, the ESC bytes SHOULD  appear before LOWPAN_IPHC dispatch type. But if the implementation requires ESC byte to be placed after LOWPAN_IPHC dispatch and payload, then the elided IPHC payload length MUST include the ESC bytes. It means  during de-capsulation of ESC bytes the LOWPAN_IPHC payload length  need to be adjusted [RFC 6282 section 3.2]
==========

2) Section 3 says 'as long as it ... does noy induce fragmentation.' I'm unsure why 6LoWPAN fragmentation would be incompatible with the use of escape?
[SC>]  That will be addressed by the above change.

3) Section 3.1 mandates that unknown EEDs are dropped. This is a regression from IPv6 options which can signal whether they can be skipped, and 6LoRH. An alternate approach that is compatible with ITU-T specs could be to use the most (2? 3?) significant bits set to indicate skippable, in which case the other 7 (6?, 5?) bits could be a length in bytes, and then the next octet would be an EED. This would give us 127 (191?, 223?) non skippable EEDs and 254 skippable EEDs.
[SC>] 
[SC>]  We don't agree that it is a regression from IPv6 options.  These are ESC bytes not IPv6 options.
The idea of separating this document vs the 6loh and 6lorh-paging document are that we want to keep the definition and usage of ESC bytes simple. If there is a need for skip-able ESC bytes sequence, then that can be introduced in some other document (ex. 6loRH ? ) where the application demands it.

So our conclusion is to keep it simple and drop unknown ESC bytes. 

-
[SC>]  We worked on a new text to clarify difference between ESC and NALP bytes as we see today.

===========
3.4 NALP and ESC bytes

According to RFC4944 [RFC4944] section 5.1, NALP dispatch bytes are reserved in order to identify  non-6lowpan payloads.
This is another approach of an escape method for a 6lowpan implementation and the handling NALP frame is clarified in [RFC4944].

This document clarifies that NALP dispatch codes only provides an
escape method for non-6LoWPAN payloads when they appear as the
initial byte of a LoWPAN encapsulation, and that the potential
meaning of their appearance in any other location is reserved for
future use.

Since ESC bytes are extended  6lowpan dispatch types, they are orthogonal to NALP bytes.

====

-Samita and co-authors

> as a Proposed Standard. All substantive comments are to be posted to 
> the mailing list. Editorial comments should be sent to the document authors.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 19 Mar 2016 09:40:26 +0000

Hello Samita:

I'm perfectly happy with this, but for point 1.

RFC 6282 has "The IPv6 Payload Length field MUST always be elided and inferred from lower layers using the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header." This denotes the assumption that the length of all that is not IP is in the frame known, and that IP and its payload is the rest of the frame. Current Implementations are expected to consider that the rest of the frame after the IPHC is the rest of the IP packet and it would be better that we stay backward compatible with that. Otherwise 6LoWPAN may end up injecting data at the end of the packets that the transport and security layers may or may not process correctly.

In any fashion, if we allowed esc after IPHC, then I'm unclear how an implementation will figure the end of the IPv6 payload. It is valid to have a byte in IP payload with the same value as esc so an implementation cannot just scan the data. Should it have to look into the transport?

Now I'm wondering if there is a need for this complexity? Do we have actual use cases where esc would be after the IP packet?

Take care,

Pascal

> From: Samita Chakrabarti [mailto:[email-masked]]
> Sent: samedi 19 mars 2016 02:21
> To: Pascal Thubert (pthubert) <[email-masked]>; Brian Haberman
> <[email-masked]>; [email-masked]
> Subject: RE: [6lo] 6lo Last Call: draft-ietf-6lo-dispatch-iana-registry
> 
> Hi Pascal,
> 
> 
> 1) Sections 3 and 3.2 provide an example whereby the esc sequence is used
> after the IPHC+IP payload. One issue with that is that the packet length is
> elided by RFC6282 (section 3.2) and assumes the rest of the frame. If the ESC
> can be placed after an IPHC then we need to signal the size of the IP
> payload. An alternate approach would be that the order is enforced
> indicating that the escaped data is always before the IP header.
> 
> [SC>]
> 
> Good catch.  Though RFC8262 is not very clear that IPHC payload means the
> rest of the frame. But due to not being clear we could have implementations
> which can assume so. In order to mitigate this problem, we propose the
> updated text as following:
> 
> ====
> When LOWPAN_IPHC is present, the ESC bytes SHOULD  appear before
> LOWPAN_IPHC dispatch type. But if the implementation requires ESC byte to
> be placed after LOWPAN_IPHC dispatch and payload, then the elided IPHC
> payload length MUST include the ESC bytes. It means  during de-capsulation
> of ESC bytes the LOWPAN_IPHC payload length  need to be adjusted [RFC
> 6282 section 3.2] ==========
> 
> 
> 2) Section 3 says 'as long as it ... does noy induce fragmentation.' I'm unsure
> why 6LoWPAN fragmentation would be incompatible with the use of escape?
> 3) Section 3.1 mandates that unknown EEDs are dropped. This is a regression
> from IPv6 options which can signal whether they can be skipped, and 6LoRH.
> An alternate approach that is compatible with ITU-T specs could be to use
> the most (2? 3?) significant bits set to indicate skippable, in which case the
> other 7 (6?, 5?) bits could be a length in bytes, and then the next octet
> would be an EED. This would give us 127 (191?, 223?) non skippable EEDs
> and 254 skippable EEDs.
> [SC>]
> The idea of separating this document vs the 6loh and 6lorh-paging
> document are that we want to keep the definition and usage of ESC bytes
> simple. If there is a need for skip-able ESC bytes sequence, then that can be
> introduced in some other document (ex. 6loRH ? ) where the application
> demands it.
> 
> 4) Section 3.4 does not update RFC4944 on NALP. Since NALP denotes a non-
> 6LoWPAN behavior, it could be clarified that NALP is not expected inside a
> 6LoWPAN frame, meaning after a 6LoWPAN dispatch was found. After a
> transition phase, this would reopen the 00xxxxxx dispatch space inside a
> 6LoWPAN frame.
> 
> -
> According to RFC4944 [RFC4944] section 5.1, NALP dispatch bytes are
> reserved in order to identify  non-6lowpan payloads.
> This is another approach of an escape method for a 6lowpan
> implementation and the handling NALP frame is clarified in [RFC4944].
> 
> This document clarifies that NALP dispatch codes only provides an escape
> method for non-6LoWPAN payloads when they appear as the initial byte of a
> LoWPAN encapsulation, and that the potential meaning of their appearance
> in any other location is reserved for future use.
>

---

From: Gabriel Montenegro <[email-masked]>
Date: Sun, 20 Mar 2016 00:07:10 +0000

+1 on Pascal's point, I also don't see the need for the complexity.

I'd rather we change SHOULD to MUST place ESC before IP packet. 

> Sent: Saturday, March 19, 2016 02:40
> To: Samita Chakrabarti <[email-masked]>; Brian Haberman
> RFC 6282 has "The IPv6 Payload Length field MUST always be elided and
> inferred from lower layers using the 6LoWPAN Fragmentation header or the
> IEEE 802.15.4 header." This denotes the assumption that the length of all that
> is not IP is in the frame known, and that IP and its payload is the rest of the
> frame. Current Implementations are expected to consider that the rest of the
> frame after the IPHC is the rest of the IP packet and it would be better that we
> stay backward compatible with that. Otherwise 6LoWPAN may end up
> injecting data at the end of the packets that the transport and security layers
> may or may not process correctly.
> 
> In any fashion, if we allowed esc after IPHC, then I'm unclear how an
> implementation will figure the end of the IPv6 payload. It is valid to have a byte
> in IP payload with the same value as esc so an implementation cannot just scan
> the data. Should it have to look into the transport?
> 
> Now I'm wondering if there is a need for this complexity? Do we have actual
> use cases where esc would be after the IP packet?
> 
> Take care,
> 
> Pascal
> 
> 
> > Thanks so much for the detail review and the good catch on
> > fragmentation and sequence after LOWPAN_IPHC.
> > 1) Sections 3 and 3.2 provide an example whereby the esc sequence is
> > used after the IPHC+IP payload. One issue with that is that the packet
> > length is elided by RFC6282 (section 3.2) and assumes the rest of the
> > frame. If the ESC can be placed after an IPHC then we need to signal
> > the size of the IP payload. An alternate approach would be that the
> > order is enforced indicating that the escaped data is always before the IP
> header.
> >
> > [SC>]
> >
> > Good catch.  Though RFC8262 is not very clear that IPHC payload means
> > the rest of the frame. But due to not being clear we could have
> > implementations which can assume so. In order to mitigate this
> > problem, we propose the updated text as following:
> >
> > ====
> > LOWPAN_IPHC dispatch type. But if the implementation requires ESC byte
> > to be placed after LOWPAN_IPHC dispatch and payload, then the elided
> > IPHC payload length MUST include the ESC bytes. It means  during
> > de-capsulation of ESC bytes the LOWPAN_IPHC payload length  need to be
> > adjusted [RFC
> > 2) Section 3 says 'as long as it ... does noy induce fragmentation.'
> > I'm unsure why 6LoWPAN fragmentation would be incompatible with the use
> of escape?
> > 3) Section 3.1 mandates that unknown EEDs are dropped. This is a
> > regression from IPv6 options which can signal whether they can be skipped,
> and 6LoRH.
> > An alternate approach that is compatible with ITU-T specs could be to
> > use the most (2? 3?) significant bits set to indicate skippable, in
> > which case the other 7 (6?, 5?) bits could be a length in bytes, and
> > then the next octet would be an EED. This would give us 127 (191?,
> > 223?) non skippable EEDs and 254 skippable EEDs.
> > [SC>]
> > document are that we want to keep the definition and usage of ESC
> > bytes simple. If there is a need for skip-able ESC bytes sequence,
> > then that can be introduced in some other document (ex. 6loRH ? )
> > where the application demands it.
> >
> > 4) Section 3.4 does not update RFC4944 on NALP. Since NALP denotes a
> > non- 6LoWPAN behavior, it could be clarified that NALP is not expected
> > inside a 6LoWPAN frame, meaning after a 6LoWPAN dispatch was found.
> > After a transition phase, this would reopen the 00xxxxxx dispatch
> > space inside a 6LoWPAN frame.
> >
> > -
> > escape method for non-6LoWPAN payloads when they appear as the initial
> > byte of a LoWPAN encapsulation, and that the potential meaning of
> > their appearance in any other location is reserved for future use.
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> >
> etf.org%2fmailman%2flistinfo%2f6lo&data=01%7c01%7cGabriel.Montenegro
> %4
> >
> 0microsoft.com%7c7710e598250247242ac808d34fdab0b8%7c72f988bf86f14
> 1af91
> >
> ab2d7cd011db47%7c1&sdata=TU%2fKAzUVEIvEyFurkHDW7hMqRK6wYl8q2x3
> cTmIsrdU
> > %3d
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.
> org%2fmailman%2flistinfo%2f6lo&data=01%7c01%7cGabriel.Montenegro%40
> microsoft.com%7c7710e598250247242ac808d34fdab0b8%7c72f988bf86f141
> af91ab2d7cd011db47%7c1&sdata=TU%2fKAzUVEIvEyFurkHDW7hMqRK6wYl8
> q2x3cTmIsrdU%3d

---

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 21 Mar 2016 18:49:33 +0000

Hi Pascal,

Point is taken.   So far, I don't see a pressing need for putting ESC byte behind LOWPAN-IPHC. 
I see Gabriel (w/co-author hat) also agreed to the idea you proposed.
As you also argued about keeping backward compatibility, let's change it to MUST and clean up the additional text about updating IPlen.

Thanks,
-Samita

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Saturday, March 19, 2016 2:40 AM
To: Samita Chakrabarti; Brian Haberman; [email-masked]
Cc: Jonathan Hui
Subject: RE: [6lo] 6lo Last Call: draft-ietf-6lo-dispatch-iana-registry

Hello Samita:

Take care,

Pascal

> order is enforced indicating that the escaped data is always before the IP header.
> 
> [SC>]
> 
> I'm unsure why 6LoWPAN fragmentation would be incompatible with the use of escape?
> regression from IPv6 options which can signal whether they can be skipped, and 6LoRH.

---

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 21 Mar 2016 18:56:47 +0000

Acknowledged. Will do the change.
-Samita

-----Original Message-----
From: Gabriel Montenegro [mailto:[email-masked]] 
Sent: Saturday, March 19, 2016 5:07 PM
To: Pascal Thubert (pthubert); Samita Chakrabarti; Brian Haberman; [email-masked]
Cc: Jonathan Hui
Subject: RE: [6lo] 6lo Last Call: draft-ietf-6lo-dispatch-iana-registry

> To: Samita Chakrabarti <[email-masked]>; Brian 
> Haberman <[email-masked]>; [email-masked]
> inferred from lower layers using the 6LoWPAN Fragmentation header or 
> the IEEE 802.15.4 header." This denotes the assumption that the length 
> of all that is not IP is in the frame known, and that IP and its 
> payload is the rest of the frame. Current Implementations are expected 
> to consider that the rest of the frame after the IPHC is the rest of 
> the IP packet and it would be better that we stay backward compatible 
> with that. Otherwise 6LoWPAN may end up injecting data at the end of 
> the packets that the transport and security layers may or may not process correctly.
> 
> implementation will figure the end of the IPv6 payload. It is valid to 
> have a byte in IP payload with the same value as esc so an 
> implementation cannot just scan the data. Should it have to look into the transport?
> 
> Now I'm wondering if there is a need for this complexity? Do we have 
> actual use cases where esc would be after the IP packet?
> 
> Take care,
> 
> Pascal
> 
> 
> > used after the IPHC+IP payload. One issue with that is that the 
> > packet length is elided by RFC6282 (section 3.2) and assumes the 
> > rest of the frame. If the ESC can be placed after an IPHC then we 
> > need to signal the size of the IP payload. An alternate approach 
> > would be that the order is enforced indicating that the escaped data 
> > is always before the IP
> header.
> >
> > [SC>]
> >
> > Good catch.  Though RFC8262 is not very clear that IPHC payload 
> > means the rest of the frame. But due to not being clear we could 
> > have implementations which can assume so. In order to mitigate this 
> > LOWPAN_IPHC dispatch type. But if the implementation requires ESC 
> > byte to be placed after LOWPAN_IPHC dispatch and payload, then the 
> > elided IPHC payload length MUST include the ESC bytes. It means  
> > during de-capsulation of ESC bytes the LOWPAN_IPHC payload length  
> > need to be adjusted [RFC
> > An alternate approach that is compatible with ITU-T specs could be 
> > to use the most (2? 3?) significant bits set to indicate skippable, 
> > in which case the other 7 (6?, 5?) bits could be a length in bytes, 
> > and then the next octet would be an EED. This would give us 127 
> > (191?,
> > non- 6LoWPAN behavior, it could be clarified that NALP is not 
> > expected inside a 6LoWPAN frame, meaning after a 6LoWPAN dispatch was found.
> > meaning of their appearance in any other location is reserved for future use.
> >
> > > as a Proposed Standard. All substantive comments are to be posted 
> > > to the mailing list. Editorial comments should be sent to the 
> > > document
> > authors.