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

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:pthubert@cisco.com] 
Sent: Saturday, March 19, 2016 2:40 AM
To: Samita Chakrabarti; Brian Haberman; 6lo@ietf.org
Cc: Jonathan Hui
Subject: RE: [6lo] 6lo Last Call: draft-ietf-6lo-dispatch-iana-registry

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

> -----Original Message-----
> From: Samita Chakrabarti [mailto:samita.chakrabarti@ericsson.com]
> Sent: samedi 19 mars 2016 02:21
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>; Brian Haberman 
> <brian@innovationslab.net>; 6lo@ietf.org
> Cc: Jonathan Hui <jonhui@nestlabs.com>
> Subject: RE: [6lo] 6lo Last Call: 
> draft-ietf-6lo-dispatch-iana-registry
> 
> 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:6lo-bounces@ietf.org] On Behalf Of Pascal Thubert
> (pthubert)
> Sent: Tuesday, March 08, 2016 7:52 AM
> To: Brian Haberman; 6lo@ietf.org
> Cc: Jonathan Hui
> Subject: Re: [6lo] 6lo Last Call: 
> draft-ietf-6lo-dispatch-iana-registry
> 
> 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.
> 
> [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.
> 
> 
> 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.
> 
> -
> [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
> 
> 
> > -----Original Message-----
> > From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Brian Haberman
> > Sent: mardi 1 mars 2016 16:24
> > To: 6lo@ietf.org
> > Cc: Jonathan Hui <jonhui@nestlabs.com>
> > Subject: [6lo] 6lo Last Call:
> >
> > 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
> 
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo