Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH net-next] ipv6: use prandom_u32() for ID generation
From:   patchwork-bot+netdevbpf@kernel.org
Message-Id: <162252480507.23898.17168292577434341829.git-patchwork-notify@kernel.org>
Date:   Tue, 01 Jun 2021 05:20:05 +0000
References: <20210529110746.6796-1-w@1wt.eu>
In-Reply-To: <20210529110746.6796-1-w@1wt.eu>
To:     Willy Tarreau <w@1wt.eu>
Cc:     netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        davem@davemloft.net, kuba@kernel.org, kuznet@ms2.inr.ac.ru,
        yoshfuji@linux-ipv6.org, aksecurity@gmail.com, edumazet@google.com
Precedence: bulk

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Sat, 29 May 2021 13:07:46 +0200 you wrote:
> This is a complement to commit aa6dd211e4b1 ("inet: use bigger hash
> table for IP ID generation"), but focusing on some specific aspects
> of IPv6.
> 
> Contary to IPv4, IPv6 only uses packet IDs with fragments, and with a
> minimum MTU of 1280, it's much less easy to force a remote peer to
> produce many fragments to explore its ID sequence. In addition packet
> IDs are 32-bit in IPv6, which further complicates their analysis. On
> the other hand, it is often easier to choose among plenty of possible
> source addresses and partially work around the bigger hash table the
> commit above permits, which leaves IPv6 partially exposed to some
> possibilities of remote analysis at the risk of weakening some
> protocols like DNS if some IDs can be predicted with a good enough
> probability.
> 
> [...]

Here is the summary with links:
  - [net-next] ipv6: use prandom_u32() for ID generation
    https://git.kernel.org/netdev/net-next/c/62f20e068ccc

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html