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;
Message-ID: <0548d1daa7e1eee9d8202481668bbe4975c9b33d.camel@redhat.com>
Subject: Re: [PATCH 1/4] net: if_arp: add ARPHRD_PUREIP type
From:   Dan Williams <dcbw@redhat.com>
To:     Rocco Yue <rocco.yue@mediatek.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        David Ahern <dsahern@gmail.com>
Cc:     "David S . Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Jonathan Corbet <corbet@lwn.net>,
        Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
        David Ahern <dsahern@kernel.org>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        Felix Fietkau <nbd@nbd.name>, John Crispin <john@phrozen.org>,
        Sean Wang <sean.wang@mediatek.com>,
        Mark Lee <Mark-MC.Lee@mediatek.com>, netdev@vger.kernel.org,
        linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        linux-mediatek@lists.infradead.org, bpf@vger.kernel.org,
        wsd_upstream@mediatek.com, chao.song@mediatek.com,
        kuohong.wang@mediatek.com
Date:   Thu, 24 Jun 2021 11:14:24 -0500
In-Reply-To: <20210624061310.12315-1-rocco.yue@mediatek.com>
References: <YNQYHfE09Dx5kWyg@kroah.com>
         <20210624061310.12315-1-rocco.yue@mediatek.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.2 (3.40.2-1.fc34) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Thu, 2021-06-24 at 14:13 +0800, Rocco Yue wrote:
> On Thu, 2021-06-24 at 07:29 +0200, Greg KH wrote:
> > 
> > Thanks for the explaination, why is this hardware somehow "special"
> > in
> > this way that this has never been needed before?
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Before kernel-4.18, RAWIP was the same as PUREIP, neither of them
> automatically generates an IPv6 link-local address, and the way to
> generate an IPv6 global address is the same.

This distinction seems confusing from a kernel standpoint if it only
changes how v6 IIDs are determined. Do we really need something that's
also reflected to userspace (in struct ifinfomsg -> ifi_type) if the
kernel is handling the behavior that's different? Why should userspace
care?

I'm also curious why this isn't an issue for the ipa/rmnet (Qualcomm)
modem drivers. There's probably a good reason, but would be good to
know what that is from Alex Elder or Loic or Bjorn...

Dan

> 
> After kernel-4.18 (include 4.18 version), the behavior of RAWIP had
> changed due to the following patch:
> @@  static int ipv6_generate_eui64(u8 *eui, struct net_device *dev)
> +       case ARPHRD_RAWIP:
> +               return addrconf_ifid_rawip(eui, dev);
>         }
>         return -1;
> }
> 
> the reason why the kernel doesn't need to generate the link-local
> address automatically is as follows:
> 
> In the 3GPP 29.061, here is some description as follows:
> "in order to avoid any conflict between the link-local address of
> MS and that of the GGSN, the Interface-Identifier used by the MS to
> build its link-local address shall be assigned by the GGSN. The GGSN
> ensures the uniqueness of this Interface-Identifier. Then MT shall
> then enforce the use of this Interface-Identifier by the TE"
> 
> In other words, in the cellular network, GGSN determines whether to
> reply to the Router Solicitation message of UE by identifying the
> low 64bits of UE interface's ipv6 link-local address.
> 
> When using a new kernel and RAWIP, kernel will generate an EUI64
> format ipv6 link-local address, and if the device uses this address
> to send RS, GGSN will not reply RA message.
> 
> Therefore, in that background, we came up with PUREIP to make kernel
> doesn't generate a ipv6 link-local address in any address generate
> mode.
> 
> Thanks,
> Rocco
>