Re: [Roll] I-D Action: draft-thubert-roll-flow-label-00.txt

Brian E Carpenter <> Tue, 08 May 2012 09:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC8E921F85AC for <>; Tue, 8 May 2012 02:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RXxs5Jk0A8FO for <>; Tue, 8 May 2012 02:52:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AF92D21F858E for <>; Tue, 8 May 2012 02:52:54 -0700 (PDT)
Received: by eabd1 with SMTP id d1so1285018eab.31 for <>; Tue, 08 May 2012 02:52:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=D3bi+yqp1x5zwx3aI+NEYaICGayjPWrmTe560THe2Gw=; b=ThzzaWARFEjMcI70yNiP+ZZDr8JMEadqOlM73XhZINBuSRHXdGu6Y3xzBNhisu+KjR Zh36Ye9H5W5jpBbQUuKA2z5hQecWBnkwob3DCCyLKdn81gnO4+RWHLCVFHs/agaPX0Bq w5rDp0fdBYONvDsA6ZaSV/qs3V7gINRKnI3cwuMxF9NZ8tbrtSRPOLvvmSIp7XPhICXj kDVFVZZlOuyyxPgqH8EYddTNG+GmEkT+juNx5PduuYXMdDjH2WcgJ0Be886GKyFlW02c Omg+3regmJ4qDV4RFPujMPCPW587JZyxwuAjqJL9MF4/Iibmr4Swf/tWvZzKtm/qjVtL 1idw==
Received: by with SMTP id 23mr3348493ebo.36.1336470773094; Tue, 08 May 2012 02:52:53 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id n52sm92893154eef.6.2012. (version=SSLv3 cipher=OTHER); Tue, 08 May 2012 02:52:52 -0700 (PDT)
Message-ID: <>
Date: Tue, 08 May 2012 10:52:48 +0100
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Roll] I-D Action: draft-thubert-roll-flow-label-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 May 2012 09:52:56 -0000

On 2012-05-07 13:59, Pascal Thubert (pthubert) wrote:
> Hi Brian:
>> IMHO there are problems with this proposal. One is that it doesn't,
>> as far as I can see, demonstrate that the overhead of rewriting the
>> flow label on exit from an RPL domain is significantly less than
>> the overhead of dealing with the RPL hop-by-hop option at the edge
>> of the domain.
> [Pascal] The overhead is mainly for packets coming from the outside
> into the RPL domain. Such packets need extra encapsulation that's
> detrimental for batteries and may cause a small packet to grow above
> the MAC Max Frame, leading to L2 or 6LoWPAN fragmentation.

If you can explain this in a few words in the text, it will be fine.

> Then, this phrase:
>> Sadly, the Option must be placed in a Hop-by-Hop option that must
>> be inserted or removed as the packet crosses the border of the RPL
>> domain.
> bothers me, because (and I have looked recently) there is nothing in
> the IPv6 specs that allows for an extension header being inserted (or
> removed) en route. The text continues
> [Pascal] I'll reword to indicate that the operation of inserting /
> removing the HbH header comes with 6in6. RFC 6553 says: " When the
> router is the source of the original packet and the destination is
> known to be within the same RPL Instance, the router SHOULD include
> the RPL Option directly within the original packet. Otherwise,
> routers MUST use IPv6-in-IPv6 tunneling [RFC2473] and place the RPL
> Option in the tunnel header.  Using IPv6-in-IPv6 tunneling ensures
> that the delivered datagram remains unmodified and that ICMPv6 errors
> generated by a RPL Option are sent back to the router that generated
> the RPL Option."

Yes, I had to read quite deeply into 6553 to understand this. I think
your draft will be read by people without detailed knowledge of RPL so
it needs to be explained.

>> ...This operation may involve an extra encapsulation that is
>> detrimental to the network operation, in particular with regards to
>> bandwidth and battery constraints.
> Why "may"? If the packet is inbound to RPL, RFC 6553 makes it clear
> that it must be encapsulated; if the packet is outbound, why would it
> be encapsulated at all? This case is covered in the RFC too:
> [Pascal] I wrote "may" from the fact that the packet may be issued
> and consumed within the RPL domain in which case the option is
> conserved all the way and there is no 6in6 encapsulation. But I agree
> the operation above does come with 6in6.


>> 3.  Datagrams destined to nodes outside the RPL Instance are
>> dropped if the outermost IPv6 header contains a RPL Option not
>> generated by the RPL router forwarding the datagram.
> Then, the draft says:
>> This document specifies how the Flow Label can be reused within the
>>  RPL domain as a replacement to the RPL option.  The use of the
>> Flow Label within a RPL domain is an instance of the stateful
>> scenarios decribed in [RFC6437]...
> In fact RFC 6437 carefully says very little about stateful scenarios;
> it does not describe them, but it does constrain them. Here is the
> entire section on this topic:
> [Pascal] what about the word "introduced", or "discussed"?


>> 4.  Flow State Establishment Requirements
>> A node that sets the flow label MAY also take part in a flow state 
>> establishment method that results in assigning specific treatments
>> to specific flows, possibly including signaling.  Any such method
>> MUST NOT disturb nodes taking part in the stateless scenario just 
>> described.  Thus, any node that sets flow label values according to
>> a stateful scheme MUST choose labels that conform to Section 3 of
>> this specification.  Further details are not discussed in this
>> document.
>> The problem is that section 3 intentionally does not consider flow
>> label values in which any of the bits have semantic significance,
>> and this was the consensus in the 6MAN WG after a great deal of
>> discussion. However, the  present proposal assigns semantics to
>> various bits in the flow label, destroying its desired property of
>> belonging to a statistically uniform distribution.
> [Pascal] That is true within the edge network that is the RPL domain.
> But outside the RPL domain the desired properties are conserved. The
> rationale for the statistically uniform distribution does not
> necessarily bring a lot of value within the LLN. On the other hand,
> the 6in6 encaps and HbH header are hugely detrimental to the
> operations and will result is shorter battery life and reduced
> applicability. I participated as a coeditor to the ISA100.11a
> standard that actually uses IPv6 in the 6LoWPAN HC form. I've seen
> how the adoption of IPv6 was at stake for a single additional octet
> in a header, and this actually led to changes at the IETF and the new
> 6LoWPAN HC. Indeed, unless you have a power source, every octet that
> you have to place it in every frame or packet in the LLN counts
> dearly.

I understand that, but there was a strong feeling in 6MAN that the flow
label should be an end-to-end field (even though that is unenforceable).
If you can make it clear that the flow label in your model refers only
to the label of the encapsulating packet, and that any flow label set by
the source host in the inner packet is not changed, it will be fine.
That's the same model as RFC 6438 (flow labels for ECMP/LAG tunnels).

>> The issue is clearly stated in RFC 6437:
>> Once set to a non-zero value, the Flow Label is expected to be 
>> delivered unchanged to the destination node(s).  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.
> [Pascal]  We have a compelling operational reason for sure, because
> the power consumption is the number one critical constraint that
> drives most of the physical design choices in a LLN where a battery
> life must often expressed in years.  I'm unclear, though, why RFC
> 6437 went as far as indicating that the compelling reason should be
> qualified as security. 

Because the firewall people had already made it very clear that whatever
we wrote in an RFC, firewalls in sensitive applications would treat the
flow label as a covert channel risk. Apart from that, as noted above,
the WG wanted to insist on the end to end property of the label.

> I take that as an indication of criticality as
> opposed to a tentative to predict future needs. It makes sense to me
> to add in the draft that "the source in the LLN SHOULD set the Flow
> label to zero and MUST NOT expect that the flow label will be
> conserved end to end if it knows by policy that the LLN will use this
> draft". Would that be sufficient to alleviate this concern?

If we are talking about the encapsulating packet, sure. Is there any
reason that the label in the raw packet would be changed?


> And yes, I will certainly keep you CCed, and CC you if other threads
> pop up on the subject in ROLL, if you do not mind;
> Pascal