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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 13 Nov 2020 02:50:00 +0100
From:   Dmytro Shytyi <dmytro@...tyi.net>
To:     "Hideaki Yoshifuji" <hideaki.yoshifuji@...aclelinux.com>
Cc:     "kuba" <kuba@...nel.org>, "kuznet" <kuznet@....inr.ac.ru>,
        "yoshfuji" <yoshfuji@...ux-ipv6.org>,
        "liuhangbin" <liuhangbin@...il.com>, "davem" <davem@...emloft.net>,
        "netdev" <netdev@...r.kernel.org>,
        "linux-kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next V3] net: Variable SLAAC: SLAAC with prefixes of
 arbitrary length in PIO

Hello,

---- On Thu, 12 Nov 2020 17:55:08 +0100 Hideaki Yoshifuji <hideaki.yoshifuji@...aclelinux.com> wrote ----

 > Hi, 
 >  
 > 2020年11月13日(金) 0:46 Dmytro Shytyi <dmytro@...tyi.net>: 
 > > 
 > > Variable SLAAC: SLAAC with prefixes of arbitrary length in PIO (randomly 
 > > generated hostID or stable privacy + privacy extensions). 
 > > The main problem is that SLAAC RA or PD allocates a /64 by the Wireless 
 > > carrier 4G, 5G to a mobile hotspot, however segmentation of the /64 via 
 > > SLAAC is required so that downstream interfaces can be further subnetted. 
 > > Example: uCPE device (4G + WI-FI enabled) receives /64 via Wireless, and 
 > > assigns /72 to VNF-Firewall, /72 to WIFI, /72 to VNF-Router, /72 to 
 > > Load-Balancer and /72 to wired connected devices. 
 > > IETF document that defines problem statement: 
 > > draft-mishra-v6ops-variable-slaac-problem-stmt 
 > > IETF document that specifies variable slaac: 
 > > draft-mishra-6man-variable-slaac 
 > > 
 > > Signed-off-by: Dmytro Shytyi <dmytro@...tyi.net> 
 > > Reported-by: kernel test robot <lkp@...el.com> 
 > > --- 
 >  
 > > -       write_lock_bh(&idev->lock); 
 > > +       int ret; 
 > > +#if defined(CONFIG_ARCH_SUPPORTS_INT128) 
 > > +       __int128 host_id; 
 > > +       __int128 net_prfx; 
 > : 
 >  
 > No, this does not help anything. 
 > Please do not rely on __int128. 

[Dmytro] Understood. Thank you.

 > --yoshfuji 
 > 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ