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

Brian E Carpenter <> Fri, 01 August 2014 19:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 31E911B28B3; Fri, 1 Aug 2014 12:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dzWyXlpn-ouQ; Fri, 1 Aug 2014 12:58:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 22E901A0467; Fri, 1 Aug 2014 12:58:39 -0700 (PDT)
Received: by with SMTP id lj1so6345450pab.33 for <multiple recipients>; Fri, 01 Aug 2014 12:58:38 -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=65VqK3L8Io+gxTbGcPhMlmRHYmei9ukzebgwZ3yvwoI=; b=jquQukMkQbEMWA1wYLcREps6MPMwYgN8hMeyFkFYiK4jRKOoj6DCIPPomEo/6iva6J oQHip2j2ZjBIJ6l55QcRraJr8c5PDRFf4XIMscdXZO8nP5uKb2fOovNim3PTlwbN6bTA BijuqBgD15sbzePy8LYqAHKfSZJl5NFz9eT2rvNzHVxhbNi6zLfI3unbvyiUi9fEXVKN dmXMY3GzLJ7tUpBgNg2OQitfT1CK24nY52WLCanN1MCoXwqkEjcMFCEbMrIH0bUtz08Q hh4XkWoMCt49W/XFSwOQDIEmXcIFNuRBZREhWhaoxSPTSzTHYhR4n7ngsgzUe3nTEVff xrag==
X-Received: by with SMTP id xk9mr8745410pbc.123.1406923118839; Fri, 01 Aug 2014 12:58:38 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id xq3sm33503484pab.0.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Aug 2014 12:58:38 -0700 (PDT)
Message-ID: <>
Date: Sat, 02 Aug 2014 07:58:39 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Carsten Bormann <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: 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: Fri, 01 Aug 2014 19:58:41 -0000

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.