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

[Greg KH]

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