Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753043AbcKAPfP (ORCPT <rfc822;w@1wt.eu>);
        Tue, 1 Nov 2016 11:35:15 -0400
Received: from shards.monkeyblade.net ([184.105.139.130]:46328 "EHLO
        shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750857AbcKAPfM (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 1 Nov 2016 11:35:12 -0400
Date: Tue, 01 Nov 2016 11:35:05 -0400 (EDT)
Message-Id: <20161101.113505.1429989348222226550.davem@davemloft.net>
To: jkbs@redhat.com
Cc: tom@herbertland.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, kuznet@ms2.inr.ac.ru, jmorris@namei.org,
        yoshfuji@linux-ipv6.org, kaber@trash.net
Subject: Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for
 forwarded ICMP errors from offending packet
From: David Miller <davem@davemloft.net>
In-Reply-To: <87bmxznsgg.fsf@redhat.com>
References: <20161031.151534.329043104568805244.davem@davemloft.net>
        <87bmxznsgg.fsf@redhat.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Tue, 01 Nov 2016 07:35:34 -0700 (PDT)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1769
Lines: 40

From: Jakub Sitnicki <jkbs@redhat.com>
Date: Tue, 01 Nov 2016 16:13:51 +0100

> On Mon, Oct 31, 2016 at 07:15 PM GMT, David Miller wrote:
>> From: Jakub Sitnicki <jkbs@redhat.com>
>> Date: Sun, 30 Oct 2016 14:03:11 +0100
>>
>>> 2) ensure the flow labels used in both directions are the same (either
>>>    reflected by one side, or fixed, e.g. not used and set to 0), so that
>>>    the 4-tuple we hash over when forwarding, <src addr, dst addr, flow
>>>    label, next hdr>, is the same both ways, modulo the order of
>>>    addresses.
>>
>> Even Linux, by default, does not do reflection.
>>
>> See the flowlabel_consistency sysctl, which we set by default to '1'.
> 
> Yes, unfortunately, if Linux-based hosts are used as sending/receiving
> IPv6, ICMP error forwarding will not work out of the box. Users will be
> burdened with adjusting the runtime network stack config, as you point
> out, or otherwise instructing the apps to set the flow label,
> e.g. traceroute6 -I <flow label> ...

I'm pretty sure that sysctl default was choosen intentionally, and we
actively are _encouraging_ the world to not depend upon reflection in
any way, shape, or form.

And it's kind of pointless to suggest a facility that can't work with
Linux endpoints out of the box.

This was the point I'm trying to make.

If the intentions of that sysctl default does pan out, the idea is for
the world to move towards arbitrary flow label settings, even perhaps
changing over time.  The intention is to make this more, not less,
common.  And the idea is to give maximum flexibility for endpoints to
set these flow labels, in order to increase entropy wherever possible.

I have a really hard time accepting a "fix" that depends upon behavior
that the Linux ipv6 stack doesn't even have.