From mboxrd@z Thu Jan  1 00:00:00 1970
From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Subject: Re: [PATCH net-next] net: ipv6: Generate random IID for addresses on
 RAWIP devices
Date: Fri, 08 Jun 2018 18:34:37 -0600
Message-ID: <94773789691f384f93975f599ea01e5c@codeaurora.org>
References: <1528062874-19250-1-git-send-email-subashab@codeaurora.org>
 <CAPA1RqBmffQObdTWMxNSNMRTgM9gPjD4KGqk2+MTwdbR34Wkhw@mail.gmail.com>
 <CAKD1Yr0uFPS5poYVPJe_LqFh1EVmepWoeEXyhuubSAU_VMBFuQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Cc: YOSHIFUJI Hideaki <hideaki.yoshifuji@miraclelinux.com>,
        David Miller <davem@davemloft.net>, netdev@vger.kernel.org,
        YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
To: Lorenzo Colitti <lorenzo@google.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from smtp.codeaurora.org ([198.145.29.96]:42332 "EHLO
        smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752691AbeFIAei (ORCPT
        <rfc822;netdev@vger.kernel.org>); Fri, 8 Jun 2018 20:34:38 -0400
In-Reply-To: <CAKD1Yr0uFPS5poYVPJe_LqFh1EVmepWoeEXyhuubSAU_VMBFuQ@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

> Actually, I think this is fine. RFC 7136 clarified this, and says:
> 
> ======
>    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.
> ======
> 
> 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.

Hi Lorenzo

In v2 of this patchset, I used addrconf_ifid_ip6tnl() similar to
IP6 Tunnels / VTI6, so I didnt need that way of generating the IID.
addrconf_ifid_ip6tnl() also provides fixed IIDs during the lifetime of 
the
net device while IN6_ADDR_GEN_MODE_RANDOM generates different addresses.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project