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

[Philip Levis <[e-mail]>]

On Oct 31, 2012, at 3:43 AM, Pascal Thubert (pthubert) wrote:

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

I don't understand -- simply because fields are used end-to-end and "useless" to the network doesn't mean it shouldn't belong in the IPv6 header. For example, the protocol field in IPv4 (or next header in IPv6 denoting a transport header). Or the offset/MF in IPv4. 

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

Pascal, I think the issue is really simple. IMHO, any reasonable interpretation of RFC6537 is that a flow label generated outside a RPL instance MUST be delivered unchanged to a node inside a RPL instance. Full stop. Applications and other protocols using IPv6 and reading RFC6537 might make this assumption: suddenly they might break working when they hit a RPL network.

I mean, please explain, in a single sentence, how the proposed use does not violate this statement:

"A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons as described in Section 6.1."

Basically, if 6man is willing to change the flow label specification such that nodes need to assume it might be changed along a route, then this seems like a reasonable use of the flow label. But to go against a prior specification (in a way that can break interoperability) for an as-of-yet-unsubstantiated optimization effort seems like poor engineering to me.

Phil