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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 26 Oct 2012 12:19:33 +0000

Hi Michael

At the time I wondered what sort of communication to the other side of the core was being envisioned in this thread.
If the end host wanted to use that flow label as a backchannel (or covert channel or an IPv6 version of the D-channel or whatever) 20 bits of data at a time, now, that would be a hack.
In any fashion, the flow label cannot be used to transport valuable information because it cannot be verified on the receiving side. Still, with the proposal, the root gets to see it, so for what that is worth it may use it.

The flow label is currently defined for the end host to interact with the core. Once the core is traversed, the value of the flow label is consumed. Thus it can be reset and reused.
Resetting the flow label for incoming packets at the root is a safe thing to do, there is no envisioned need to preserve the original flow label, and thus no envisioned need for IPinIP.

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: jeudi 25 octobre 2012 17:05
To: Philip Levis
Cc: Pascal Thubert (pthubert); [email-masked]
Subject: Re: [Roll] using the flow label instead of hop by hop

Philip Levis <[email-masked]> wrote:

    PL> What if an end-host outside the RPL instance wants to use a flow
    PL> label for its own purposes? It might think that a flow denotes a
    PL> stream of associated packets to a node within a RPL instance, not
    PL> the OF that instance happens to use.  

I presume that this end-host is interacting with the LLN in some way (or the question is irrelevant) When the packets arrive at the gateway, a 6in6 header is added.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 26 Oct 2012 14:56:22 +0200

On Oct 26, 2012, at 14:19, "Pascal Thubert (pthubert)" <[email-masked]> wrote:

> In any fashion, the flow label cannot be used to transport valuable information because it cannot be verified on the receiving side. 

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

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.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 31 Oct 2012 10:43:17 +0000

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

---

From: Philip Levis <[email-masked]>
Date: Wed, 31 Oct 2012 09:22:37 -0700

> [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 di…

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. 

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

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