Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03

Ole Troan <> Mon, 04 August 2014 09:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D91D21B298A; Mon, 4 Aug 2014 02:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pkfDDUwHcbEt; Mon, 4 Aug 2014 02:51:02 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E5B501B298C; Mon, 4 Aug 2014 02:51:00 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmEGAKJW31OtJssW/2dsb2JhbABbhDaCeNB2BAIBgS53hAMBAQQBI1YFCwsYAgImAgIhNgYTiC4DCQitZI9sDYcAF4Esi3OBViQzB4J5NoEcAQSZf5A+hiiDTzsvAYEE
X-IronPort-AV: E=Sophos;i="5.01,797,1400025600"; d="scan'208";a="132591672"
Received: from (HELO ([]) by with ESMTP; 04 Aug 2014 09:50:59 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s749ovhq019970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2014 09:50:58 GMT
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\))
From: Ole Troan <>
In-Reply-To: <>
Date: Mon, 04 Aug 2014 11:50:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Brian E Carpenter <>
X-Mailer: Apple Mail (2.1971.5)
X-Mailman-Approved-At: Mon, 04 Aug 2014 02:52:09 -0700
Cc: 6man WG <>, roll <>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Aug 2014 09:51:04 -0000

> On 01 Aug 2014, at 21:58 , Brian E Carpenter <> wrote:
> On 01/08/2014 23:23, Carsten Bormann wrote:
> ...
>> The other story is that we are retracting RFC 6437 and turning the flow label into the “field you may trample on in your lower layers if you have a good reason”.  Cynically, one could say this is proper payback for designing this field without a compelling purpose and no protocol evolution story attached to it.  So the evolution just eats it.  Teachable moment.
> RFC 6437 co-author hat on (but only speaking for myself, of course):
> My opinion is that the draft doesn't retract RFC 6437. As I already said,
> 6437 attempts to recognise the reality that middleboxes can mess with the
> flow label, and to set conditions for that messing such that remote systems
> can still use it for load balancing. Since it's unprotected by checksum or
> crypto, there is a strict limit to how much it can be trusted anyway. As
> the RFC says:
>   There is no way to verify whether a flow label has been modified en
>   route or whether it belongs to a uniform distribution.  Therefore, no
>   Internet-wide mechanism can depend mathematically on unmodified and
>   uniformly distributed flow labels; they have a "best effort" quality.
>   Implementers should be aware that the flow label is an unprotected
>   field that could have been accidentally or intentionally changed en
>   route (see Section 6).
> It is true that the RFC also says
>   A forwarding node
>   MUST either leave a non-zero flow label value unchanged or change it
>   only for compelling operational security reasons...
> There is a case for arguing that flow-label-for-rpl should carry the
> legend "Updates: 6437 (if approved)" because it adds another exception
> to this sentence. There is also a case for arguing that flow-label-for-rpl
> is a stateful mechanism, out of scope for RFC 6437 according to
> Section 4 of that RFC.
> Either way, I don't see a problem.

I see the principles in these two documents as mutually exclusive:
RFC6437: middleboxes can mess with the flow label
-flow-label-for-rpl: networks uses flow label field as an immutable protocol field

you can't both use the flow label as an immutable protocol field and have middleboxes rewriting it.