Re: [Roll] using the flow label instead of hop by hop

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Carsten,
 
[Carsten] Most of our current protocols are indeed designed to ignore v6 specific IP header fields.
[Carsten] But just to give a very accessible example: A v6 specific version of ESP (RFC4303) could use the label to transmit the SPI.

[Pascal] Which  I'd suggest exemplifies what must not be done.  The SPI is an end-to-end information that is useless to the network. Thus is does not belong to the IPv6 header. I hope we are not discussing this are we?

--

[Carsten] I'm not saying this because I want to rule out the use of the label for forwarding fabric purposes; it's just that with more focus on IPv6, hosts may find good uses for the label.  But using the label from RPL-cognizant nodes, e.g for router-sourced packets or for the outer header of the RPL tunnel, should be fine (if there is a way to detect that this has happened).  Overwriting the label when a previously formulated IPv6 packet enters the RPL instance is bad for the same reasons adding the RFC 6553 RPL hop-by-hop option or the RFC 6554 routing header in the middle of the path would be bad.

[Pascal] The IP in IP encaps in the HbH case is actually required because of the ICMP errors. If no error relates to the flow label then there is no need to save it. And so far there is no standard that I know of that would depend on the flow label in the ICMP error. For the standard use, the flow label is consumed once it has passed the core. Considering the footprint constraints in the IPv6 header, allowing to reuse the FL for network business after the packet passed the core is actually a good idea. 

[Pascal] Now, if in some future we do need so save the flow label in order to echo it back to the source in an ICMP error, then we can carve a little room for 20 bits in the 6LoWPAN compression. But so far that need was not identified and/or cost-justified. So, no, I do not see that we need IP in IP when we use the flow label for the RPL information.

--

Cheers,

Pascal