From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lorenzo Colitti <lorenzo@google.com>
Subject: Re: [PATCH net-next] net: ipv6: Generate random IID for addresses on
 RAWIP devices
Date: Fri, 8 Jun 2018 11:52:01 +0900
Message-ID: <CAKD1Yr0uFPS5poYVPJe_LqFh1EVmepWoeEXyhuubSAU_VMBFuQ@mail.gmail.com>
References: <1528062874-19250-1-git-send-email-subashab@codeaurora.org> <CAPA1RqBmffQObdTWMxNSNMRTgM9gPjD4KGqk2+MTwdbR34Wkhw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>,
        David Miller <davem@davemloft.net>, netdev@vger.kernel.org,
        YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
To: YOSHIFUJI Hideaki <hideaki.yoshifuji@miraclelinux.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-wm0-f65.google.com ([74.125.82.65]:54965 "EHLO
        mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752415AbeFHCwR (ORCPT
        <rfc822;netdev@vger.kernel.org>); Thu, 7 Jun 2018 22:52:17 -0400
Received: by mail-wm0-f65.google.com with SMTP id o13-v6so657569wmf.4
        for <netdev@vger.kernel.org>; Thu, 07 Jun 2018 19:52:16 -0700 (PDT)
In-Reply-To: <CAPA1RqBmffQObdTWMxNSNMRTgM9gPjD4KGqk2+MTwdbR34Wkhw@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Mon, Jun 4, 2018 at 8:51 AM =E5=90=89=E8=97=A4=E8=8B=B1=E6=98=8E <hideak=
i.yoshifuji@miraclelinux.com> wrote:
>
> > +       if (ipv6_get_lladdr(dev, &lladdr, IFA_F_TENTATIVE))
> > +               get_random_bytes(eui, 8);
>
> Please be aware of I/G bit and G/L bit.


Actually, I think this is fine. RFC 7136 clarified this, and says:

=3D=3D=3D=3D=3D=3D
   Thus, we can conclude that the value of the "u" bit in IIDs has no
   particular meaning.  In the case of an IID created from a MAC address
   according to RFC 4291, its value is determined by the MAC address,
   but that is all.
[...]
   Specifications of other forms of 64-bit IIDs MUST specify how all 64
   bits are set, but a generic semantic meaning for the "u" and "g" bits
   MUST NOT be defined.  However, the method of generating IIDs for
   specific link types MAY define some local significance for certain
   bits.

   In all cases, the bits in an IID have no generic semantics; in other
   words, they have opaque values.  In fact, the whole IID value MUST be
   viewed as an opaque bit string by third parties, except possibly in
   the local context.
=3D=3D=3D=3D=3D=3D

That said - we already have a way to form all-random IIDs:
IN6_ADDR_GEN_MODE_RANDOM. Can't you just ensure that links of type
ARPHRD_RAWIP always use IN6_ADDR_GEN_MODE_RANDOM? That might lead to
less special-casing.