netdev - Re: [PATCH net-next] ipv6: Flow label state ranges

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 03 May 2015 21:58:23 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	tom@...bertland.com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net-next] ipv6: Flow label state ranges

From: Tom Herbert <tom@...bertland.com>
Date: Wed, 29 Apr 2015 15:33:21 -0700

> This patch divides the IPv6 flow label space into two ranges:
> 0-7ffff is reserved for flow label manager, 80000-fffff will be
> used for creating auto flow labels (per RFC6438). This only affects how
> labels are set on transmit, it does not affect receive. This range split
> can be disbaled by systcl.
> 
> Background:
> 
> IPv6 flow labels have been an unmitigated disappointment thus far
> in the lifetime of IPv6. Support in HW devices to use them for ECMP
> is lacking, and OSes don't turn them on by default. If we had these
> we could get much better hashing in IPv6 networks without resorting
> to DPI, possibly eliminating some of the motivations to to define new
> encaps in UDP just for getting ECMP.
> 
> Unfortunately, the initial specfications of IPv6 did not clarify
> how they are to be used. There has always been a vague concept that
> these can be used for ECMP, flow hashing, etc. and we do now have a
> good standard how to this in RFC6438. The problem is that flow labels
> can be either stateful or stateless (as in RFC6438), and we are
> presented with the possibility that a stateless label may collide
> with a stateful one.  Attempts to split the flow label space were
> rejected in IETF. When we added support in Linux for RFC6438, we
> could not turn on flow labels by default due to this conflict.
> 
> This patch splits the flow label space and should give us
> a path to enabling auto flow labels by default for all IPv6 packets.
> This is an API change so we need to consider compatibility with
> existing deployment. The stateful range is chosen to be the lower
> values in hopes that most uses would have chosen small numbers.
> 
> Once we resolve the stateless/stateful issue, we can proceed to
> look at enabling RFC6438 flow labels by default (starting with
> scaled testing).
> 
> Signed-off-by: Tom Herbert <tom@...bertland.com>

Ok, applied, let's see what happens.

Thanks Tom.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html