diff mbox series

[1/4] net: if_arp: add ARPHRD_PUREIP type

Message ID 20210623113452.5671-1-rocco.yue@mediatek.com (mailing list archive)
State Changes Requested
Delegated to: Netdev Maintainers
Headers show
Series [1/4] net: if_arp: add ARPHRD_PUREIP type | expand

Checks

Context Check Description
netdev/cover_letter warning Series does not have a cover letter
netdev/fixes_present success Link
netdev/patch_count success Link
netdev/tree_selection success Guessed tree name to be net-next
netdev/subject_prefix success Link
netdev/cc_maintainers warning 8 maintainers not CCed: yhs@fb.com kpsingh@kernel.org daniel@iogearbox.net andrii@kernel.org kafai@fb.com ast@kernel.org john.fastabend@gmail.com songliubraving@fb.com
netdev/source_inline success Was 0 now: 0
netdev/verify_signedoff success Link
netdev/module_param success Was 0 now: 0
netdev/build_32bit success Errors and warnings before: 2503 this patch: 2503
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/verify_fixes success Link
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 7 lines checked
netdev/build_allmodconfig_warn success Errors and warnings before: 2582 this patch: 2582
netdev/header_inline success Link

Commit Message

Rocco Yue June 23, 2021, 11:34 a.m. UTC
This patch add the definition of ARPHRD_PUREIP which can for
example be used by mobile ccmni device as device type.
ARPHRD_PUREIP means that this device doesn't need kernel to
generate ipv6 link-local address in any addr_gen_mode.

Signed-off-by: Rocco Yue <rocco.yue@mediatek.com>
---
 include/uapi/linux/if_arp.h | 1 +
 1 file changed, 1 insertion(+)

Comments

Greg KH June 23, 2021, 5:19 p.m. UTC | #1
On Wed, Jun 23, 2021 at 07:34:49PM +0800, Rocco Yue wrote:
> This patch add the definition of ARPHRD_PUREIP which can for
> example be used by mobile ccmni device as device type.
> ARPHRD_PUREIP means that this device doesn't need kernel to
> generate ipv6 link-local address in any addr_gen_mode.
> 
> Signed-off-by: Rocco Yue <rocco.yue@mediatek.com>
> ---
>  include/uapi/linux/if_arp.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/uapi/linux/if_arp.h b/include/uapi/linux/if_arp.h
> index c3cc5a9e5eaf..4463c9e9e8b4 100644
> --- a/include/uapi/linux/if_arp.h
> +++ b/include/uapi/linux/if_arp.h
> @@ -61,6 +61,7 @@
>  #define ARPHRD_DDCMP    517		/* Digital's DDCMP protocol     */
>  #define ARPHRD_RAWHDLC	518		/* Raw HDLC			*/
>  #define ARPHRD_RAWIP    519		/* Raw IP                       */
> +#define ARPHRD_PUREIP	520		/* Pure IP			*/

In looking at the patches, what differs "PUREIP" from "RAWIP"?  It seems
to be the same to me.  If they are different, where is that documented?

thanks,

greg k-h
Rocco Yue June 24, 2021, 3:33 a.m. UTC | #2
On Wed, 2021-06-23 at 19:19 +0200, Greg KH wrote:
On Wed, Jun 23, 2021 at 07:34:49PM +0800, Rocco Yue wrote:
>> This patch add the definition of ARPHRD_PUREIP which can for
>> example be used by mobile ccmni device as device type.
>> ARPHRD_PUREIP means that this device doesn't need kernel to
>> generate ipv6 link-local address in any addr_gen_mode.
>> 
>> Signed-off-by: Rocco Yue <rocco.yue@mediatek.com>
>> ---
>>  include/uapi/linux/if_arp.h | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/include/uapi/linux/if_arp.h b/include/uapi/linux/if_arp.h
>> index c3cc5a9e5eaf..4463c9e9e8b4 100644
>> --- a/include/uapi/linux/if_arp.h
>> +++ b/include/uapi/linux/if_arp.h
>> @@ -61,6 +61,7 @@
>>  #define ARPHRD_DDCMP    517		/* Digital's DDCMP protocol     */
>>  #define ARPHRD_RAWHDLC	518		/* Raw HDLC			*/
>>  #define ARPHRD_RAWIP    519		/* Raw IP                       */
>> +#define ARPHRD_PUREIP	520		/* Pure IP			*/
> 
> In looking at the patches, what differs "PUREIP" from "RAWIP"?  It seems

Thanks for your review.

The difference between RAWIP and PUREIP is that they generate IPv6
link-local address and IPv6 global address in different ways.

RAWIP:
~~~~~~
In the ipv6_generate_eui64() function, using RAWIP will always return 0,
which will cause the kernel to automatically generate an IPv6 link-local
address in EUI64 format and an IPv6 global address in EUI64 format.

PUREIP:
~~~~~~~
After this patch set, when using PUREIP, kernel doesn't generate IPv6
link-local address regardless of which IN6_ADDR_GEN_MODE is used.

@@  static void addrconf_dev_config(struct net_device *dev)
+       if (dev->type == ARPHRD_PUREIP)
+               return;

And after recving RA message, kernel iterates over the link-local address
that exists for the interface and uses the low 64bits of the link-local
address to generate the IPv6 global address.
The general process is as follows:
ndisc_router_discovery() -> addrconf_prefix_rcv() -> ipv6_generate_eui64() -> ipv6_inherit_eui64()

> to be the same to me.  If they are different, where is that documented?
> 
> thanks,
> 
> greg k-h

I tried to find corresponding documents about other device types, but I
am sorry I didn't find it. If it is needed, I am willing to provide.

Thanks,
Rocco
David Ahern June 24, 2021, 5:15 a.m. UTC | #3
On 6/23/21 9:33 PM, Rocco Yue wrote:
> 
> The difference between RAWIP and PUREIP is that they generate IPv6
> link-local address and IPv6 global address in different ways.
> 
> RAWIP:
> ~~~~~~
> In the ipv6_generate_eui64() function, using RAWIP will always return 0,
> which will cause the kernel to automatically generate an IPv6 link-local
> address in EUI64 format and an IPv6 global address in EUI64 format.
> 
> PUREIP:
> ~~~~~~~
> After this patch set, when using PUREIP, kernel doesn't generate IPv6
> link-local address regardless of which IN6_ADDR_GEN_MODE is used.
> 
> @@  static void addrconf_dev_config(struct net_device *dev)
> +       if (dev->type == ARPHRD_PUREIP)
> +               return;
> 
> And after recving RA message, kernel iterates over the link-local address
> that exists for the interface and uses the low 64bits of the link-local
> address to generate the IPv6 global address.
> The general process is as follows:
> ndisc_router_discovery() -> addrconf_prefix_rcv() -> ipv6_generate_eui64() -> ipv6_inherit_eui64()
> 

please add that to the commit message.
Greg KH June 24, 2021, 5:29 a.m. UTC | #4
On Thu, Jun 24, 2021 at 11:33:53AM +0800, Rocco Yue wrote:
> On Wed, 2021-06-23 at 19:19 +0200, Greg KH wrote:
> On Wed, Jun 23, 2021 at 07:34:49PM +0800, Rocco Yue wrote:
> >> This patch add the definition of ARPHRD_PUREIP which can for
> >> example be used by mobile ccmni device as device type.
> >> ARPHRD_PUREIP means that this device doesn't need kernel to
> >> generate ipv6 link-local address in any addr_gen_mode.
> >> 
> >> Signed-off-by: Rocco Yue <rocco.yue@mediatek.com>
> >> ---
> >>  include/uapi/linux/if_arp.h | 1 +
> >>  1 file changed, 1 insertion(+)
> >> 
> >> diff --git a/include/uapi/linux/if_arp.h b/include/uapi/linux/if_arp.h
> >> index c3cc5a9e5eaf..4463c9e9e8b4 100644
> >> --- a/include/uapi/linux/if_arp.h
> >> +++ b/include/uapi/linux/if_arp.h
> >> @@ -61,6 +61,7 @@
> >>  #define ARPHRD_DDCMP    517		/* Digital's DDCMP protocol     */
> >>  #define ARPHRD_RAWHDLC	518		/* Raw HDLC			*/
> >>  #define ARPHRD_RAWIP    519		/* Raw IP                       */
> >> +#define ARPHRD_PUREIP	520		/* Pure IP			*/
> > 
> > In looking at the patches, what differs "PUREIP" from "RAWIP"?  It seems
> 
> Thanks for your review.
> 
> The difference between RAWIP and PUREIP is that they generate IPv6
> link-local address and IPv6 global address in different ways.
> 
> RAWIP:
> ~~~~~~
> In the ipv6_generate_eui64() function, using RAWIP will always return 0,
> which will cause the kernel to automatically generate an IPv6 link-local
> address in EUI64 format and an IPv6 global address in EUI64 format.
> 
> PUREIP:
> ~~~~~~~
> After this patch set, when using PUREIP, kernel doesn't generate IPv6
> link-local address regardless of which IN6_ADDR_GEN_MODE is used.
> 
> @@  static void addrconf_dev_config(struct net_device *dev)
> +       if (dev->type == ARPHRD_PUREIP)
> +               return;
> 
> And after recving RA message, kernel iterates over the link-local address
> that exists for the interface and uses the low 64bits of the link-local
> address to generate the IPv6 global address.
> The general process is as follows:
> ndisc_router_discovery() -> addrconf_prefix_rcv() -> ipv6_generate_eui64() -> ipv6_inherit_eui64()

Thanks for the explaination, why is this hardware somehow "special" in
this way that this has never been needed before?

thanks,

greg k-h
Rocco Yue June 24, 2021, 5:31 a.m. UTC | #5
On Wed, 2021-06-23 at 23:15 -0600, David Ahern wrote:
On 6/23/21 9:33 PM, Rocco Yue wrote:
>> 
>> The difference between RAWIP and PUREIP is that they generate IPv6
>> link-local address and IPv6 global address in different ways.
>> 
>> RAWIP:
>> ~~~~~~
>> In the ipv6_generate_eui64() function, using RAWIP will always return 0,
>> which will cause the kernel to automatically generate an IPv6 link-local
>> address in EUI64 format and an IPv6 global address in EUI64 format.
>> 
>> PUREIP:
>> ~~~~~~~
>> After this patch set, when using PUREIP, kernel doesn't generate IPv6
>> link-local address regardless of which IN6_ADDR_GEN_MODE is used.
>> 
>> @@  static void addrconf_dev_config(struct net_device *dev)
>> +       if (dev->type == ARPHRD_PUREIP)
>> +               return;
>> 
>> And after recving RA message, kernel iterates over the link-local address
>> that exists for the interface and uses the low 64bits of the link-local
>> address to generate the IPv6 global address.
>> The general process is as follows:
>> ndisc_router_discovery() -> addrconf_prefix_rcv() ->
>> ipv6_generate_eui64() -> ipv6_inherit_eui64()
>> 
> 
> please add that to the commit message.

Thanks for your reminding, will do.

Thanks,
Rocco
Rocco Yue June 24, 2021, 6:13 a.m. UTC | #6
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.

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
Greg KH June 24, 2021, 9:04 a.m. UTC | #7
On Thu, Jun 24, 2021 at 02:13:10PM +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.
> 
> 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 for the better description.  That should go into the changelog
text somewhere so that others know what is going on here with this new
option.

And are these user-visable flags documented in a man page or something
else somewhere?  If not, how does userspace know about them?

thanks,

greg k-h
Rocco Yue June 24, 2021, 12:24 p.m. UTC | #8
On Thu, 2021-06-24 at 11:04 +0200, Greg KH wrote:
On Thu, Jun 24, 2021 at 02:13:10PM +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.
>> 
>> 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 for the better description.  That should go into the changelog
> text somewhere so that others know what is going on here with this new
> option.
>

Does changelog mean adding these details to the commit message ?
I am willing do it.

> And are these user-visable flags documented in a man page or something
> else somewhere?  If not, how does userspace know about them?
> 

There are mappings of these device types value in the libc:
"/bionic/libc/kernel/uapi/linux/if_arp.h".
userspace can get it from here.

But I also failed to find a man page or a description of these
device types.

Thanks,
Rocco
Greg KH June 24, 2021, 1:06 p.m. UTC | #9
On Thu, Jun 24, 2021 at 08:24:35PM +0800, Rocco Yue wrote:
> On Thu, 2021-06-24 at 11:04 +0200, Greg KH wrote:
> On Thu, Jun 24, 2021 at 02:13:10PM +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.
> >> 
> >> 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 for the better description.  That should go into the changelog
> > text somewhere so that others know what is going on here with this new
> > option.
> >
> 
> Does changelog mean adding these details to the commit message ?

Yes please.

> > And are these user-visable flags documented in a man page or something
> > else somewhere?  If not, how does userspace know about them?
> > 
> 
> There are mappings of these device types value in the libc:
> "/bionic/libc/kernel/uapi/linux/if_arp.h".
> userspace can get it from here.

Yes, they will show up in a libc definition, but where is it documented
in text form what the flag does?

thanks,

greg k-h
Dan Williams June 24, 2021, 4:14 p.m. UTC | #10
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
>
Rocco Yue June 25, 2021, 6:01 a.m. UTC | #11
> Does changelog mean adding these details to the commit message ?
> 
> Yes please.
> 

will do.

> > > And are these user-visable flags documented in a man page or something
> > > else somewhere?  If not, how does userspace know about them?
> > > 
> > 
> > There are mappings of these device types value in the libc:
> > "/bionic/libc/kernel/uapi/linux/if_arp.h".
> > userspace can get it from here.
> 
> Yes, they will show up in a libc definition, but where is it documented
> in text form what the flag does?

Judging from the changes of ARPHRD_xxx submitted before, I am sorry
I could not find the corresponding doucuments to describe their 
respective behaviors in details. Perhaps the best way to understand
their behaviors is to read the code directly.

Thanks,
Rocco
Rocco Yue June 25, 2021, 6:04 a.m. UTC | #12
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
diff mbox series

Patch

diff --git a/include/uapi/linux/if_arp.h b/include/uapi/linux/if_arp.h
index c3cc5a9e5eaf..4463c9e9e8b4 100644
--- a/include/uapi/linux/if_arp.h
+++ b/include/uapi/linux/if_arp.h
@@ -61,6 +61,7 @@ 
 #define ARPHRD_DDCMP    517		/* Digital's DDCMP protocol     */
 #define ARPHRD_RAWHDLC	518		/* Raw HDLC			*/
 #define ARPHRD_RAWIP    519		/* Raw IP                       */
+#define ARPHRD_PUREIP	520		/* Pure IP			*/
 
 #define ARPHRD_TUNNEL	768		/* IPIP tunnel			*/
 #define ARPHRD_TUNNEL6	769		/* IP6IP6 tunnel       		*/