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;
Date:   Thu, 14 Oct 2021 23:36:27 +0200
From:   Dmytro Shytyi <dmytro@shytyi.net>
To:     "Erik Kline" <ek@google.com>
Cc:     "Jakub Kicinski" <kuba@kernel.org>,
        "yoshfuji" <yoshfuji@linux-ipv6.org>,
        "kuznet" <kuznet@ms2.inr.ac.ru>,
        "liuhangbin" <liuhangbin@gmail.com>, "davem" <davem@davemloft.net>,
        "netdev" <netdev@vger.kernel.org>,
        "linux-kernel" <linux-kernel@vger.kernel.org>,
        "Jscherpelz" <jscherpelz@google.com>
Message-ID: <17c80bc2aba.fa4204331209995.6054034489659150411@shytyi.net>
In-Reply-To: <CAAedzxrXyfi4L9pGVLJhQFeajOmjOUJz10s3ohMnApsTi3OjiA@mail.gmail.com>
References: <175b3433a4c.aea7c06513321.4158329434310691736@shytyi.net>
 <202011110944.7zNVZmvB-lkp@intel.com> <175bd218cf4.103c639bc117278.4209371191555514829@shytyi.net>
 <175bf515624.c67e02e8130655.7824060160954233592@shytyi.net>
 <175c31c6260.10eef97f6180313.755036504412557273@shytyi.net>
 <20201117124348.132862b1@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
 <175e0b9826b.c3bb0aae425910.5834444036489233360@shytyi.net>
 <20201119104413.75ca9888@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
 <175e1fdb250.1207dca53446410.2492811916841931466@shytyi.net>
 <175e4f98e19.bcccf9b7450965.5991300381666674110@shytyi.net>
 <176458a838e.100a4c464143350.2864106687411861504@shytyi.net>
 <1766d928cc0.11201bffa212800.5586289102777886128@shytyi.net>
 <17c7be50990.d8ff97ac1139678.6280958386678329804@shytyi.net> <17c7bf4fe17.10fe56af01139851.4883748910080031944@shytyi.net> <CAAedzxrXyfi4L9pGVLJhQFeajOmjOUJz10s3ohMnApsTi3OjiA@mail.gmail.com>
Subject: Re: [PATCH net-next V10] net: Variable SLAAC: SLAAC with prefixes
 of arbitrary length in PIO
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Importance: Medium
User-Agent: Zoho Mail
Precedence: bulk

 > > This patch solves "Race to the bottom"  problem  in  VSLAAC. 
 >  
 > How exactly does this "solve" the fundamental problem? 
 > 

VSLAAC is replaced by the SLAAC starting from /64 
 
if (pinfo->prefix_len == 64) {
64_bit_addr_gen
} else if (pinfo->prefix_len > 0 && pinfo->prefix_len < 64 &&
              in6_dev->cnf.variable_slaac) {
variable_bit_addr_gen
 } else {
             net_dbg_ratelimited("IPv6: Prefix with unexpected length %d\n",
                                            pinfo->prefix_len);
 }

I meant to say that this is no longer an issue in VSLAAC particular context, considering /128 bits the "bottom".
In this version of the patch, we are not reaching the /128 bit "bottom".

Best regards,
Dmytro SHYTYI.