linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rocco Yue <rocco.yue@mediatek.com>
To: Dan Williams <dcbw@redhat.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	"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>, Rocco Yue <rocco.yue@mediatek.com>
Subject: Re: [PATCH 1/4] net: if_arp: add ARPHRD_PUREIP type
Date: Fri, 25 Jun 2021 14:04:11 +0800	[thread overview]
Message-ID: <20210625060411.23853-1-rocco.yue@mediatek.com> (raw)
In-Reply-To: <0548d1daa7e1eee9d8202481668bbe4975c9b33d.camel@redhat.com>

On Thu, 2021-06-24 at 11:14 -0500, Dan Williams wrote:
On Thu, 2021-06-24 at 14:13 +0800, Rocco Yue wrote:
>> On Thu, 2021-06-24 at 07:29 +0200, Greg KH wrote:
>> 
>> 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

Hi Dan,

Thanks for your comment,

In the cellular network, v6 IID is important, If the device use the
link-local address formed by the incorrect IID to send RS message to
the network, based on 3GPP, GGSN will not reply solicited RA message.
It will lead to the device can get ipv6 address prefix and ipv6 route.

Maybe the table below is a little bit clearer

three device type: ARPHRD_RAWIP , ARPHRD_PUREIP, ARPHRD_NONE
three mode: IN6_ADDR_GEN_MODE_EUI64 , IN6_ADDR_GEN_MODE_NONE, IN6_ADDR_GEN_MODE_STABLE_PRIVACY

ipv6 link-local address generate behavior in the kernel:
+---------+-------------------+---------------------+----------------+
|         | MODE_EUI64        | MODE_STABLE_PRIVACY | MODE_NONE      |
+---------+-------------------+---------------------+----------------+
| RAWIP   | fe80::(eui64-id)  | fe80::(privacy-id)  | no address gen |
+---------+-------------------+---------------------+----------------+
| PUREIP  | no address gen    | no address gen      | no address gen |
+---------+-------------------+---------------------+----------------+
| NONE    | fe80::(random-id) | fe80::(privacy-id)  | no address gen |
+---------+-------------------+---------------------+----------------+

ipv6 global address generate behavior in the kernel:
+---------+-------------------+---------------------+-------------------+
|         | MODE_EUI64        | MODE_STABLE_PRIVACY | MODE_NONE         |   
+---------+-------------------+---------------------+-------------------+
| RAWIP   | prefix+(eui64-id) | prefix+(privacy-id) | prefix+(eui64-id) |
+---------+-------------------+---------------------+-------------------+
| PUREIP  | prefix+(GGSN-id)  | prefix+(privacy-id) | prefix+(GGSN-id)  |
+---------+-------------------+---------------------+-------------------+
| NONE    | prefix+(random-id)| prefix+(privacy-id) | prefix+(random-id)|
+---------+-------------------+---------------------+-------------------+

> also reflected to userspace (in struct ifinfomsg -> ifi_type) if the
> kernel is handling the behavior that's different? Why should userspace
> care?
> 

In my opinion, userspace program cares about it because the kernel behaves
differently for different device types.
userspace can get the device type of the interface through ioctl, such as
the following code weblink:
https://cs.android.com/android/platform/superproject/+/master:system/netd/server/OffloadUtils.cpp;drc=master;l=41?q=ARPHRD_RAWIP&ss=android%2Fplatform%2Fsuperproject&start=11

> 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

MediaTek and Qualcomm has different hardware or modem design.
For the MediaTek platform, device send the RS message that generated by
the kernel to the GGSN.

Thanks,
Rocco

      reply	other threads:[~2021-06-25  6:19 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-23 11:34 [PATCH 1/4] net: if_arp: add ARPHRD_PUREIP type Rocco Yue
2021-06-23 11:34 ` [PATCH 2/4] net: ipv6: don't generate link local address on PUREIP device Rocco Yue
2021-06-23 11:34 ` [PATCH 3/4] net: dev_is_mac_header_xmit() return false for ARPHRD_PUREIP Rocco Yue
2021-06-23 11:34 ` [PATCH 4/4] drivers: net: mediatek: initial implementation of ccmni Rocco Yue
2021-06-23 17:25   ` Greg KH
2021-06-23 17:31   ` Greg KH
2021-06-24 11:53     ` [PATCH 1/4] net: if_arp: add ARPHRD_PUREIP type Rocco Yue
2021-06-24 12:23       ` Greg KH
2021-06-24 15:55         ` [PATCH 4/4] drivers: net: mediatek: initial implementation of ccmni Rocco Yue
2021-06-24 16:51           ` Greg KH
2021-06-28  7:18             ` Rocco Yue
2021-06-28  9:30               ` Greg KH
2021-06-23 17:19 ` [PATCH 1/4] net: if_arp: add ARPHRD_PUREIP type Greg KH
2021-06-24  3:33   ` Rocco Yue
2021-06-24  5:15     ` David Ahern
2021-06-24  5:31       ` Rocco Yue
2021-06-24  5:29     ` Greg KH
2021-06-24  6:13       ` Rocco Yue
2021-06-24  9:04         ` Greg KH
2021-06-24 12:24           ` Rocco Yue
2021-06-24 13:06             ` Greg KH
2021-06-25  6:01               ` Rocco Yue
2021-06-24 16:14         ` Dan Williams
2021-06-25  6:04           ` Rocco Yue [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210625060411.23853-1-rocco.yue@mediatek.com \
    --to=rocco.yue@mediatek.com \
    --cc=Mark-MC.Lee@mediatek.com \
    --cc=bpf@vger.kernel.org \
    --cc=chao.song@mediatek.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=dcbw@redhat.com \
    --cc=dsahern@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=john@phrozen.org \
    --cc=kuba@kernel.org \
    --cc=kuohong.wang@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=sean.wang@mediatek.com \
    --cc=wsd_upstream@mediatek.com \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).