Re: [PATCH net-next] ipv6: don't generate link-local addr in random or privacy mode

On Wed, 2021-11-17 at 13:09 +0800, Lorenzo Colitti wrote:

On Tue, Nov 16, 2021 at 3:15 PM Rocco Yue [off-list ref]
wrote:

quoted

In the 3GPP TS 29.061, here is a description as follows:
"In order to avoid any conflict between the link-local address
of the 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.
[...]
1) IN6_ADDR_GEN_MODE_STABLE_PRIVACY_NO_LLA, this mode is suitable
for cellular networks that support RFC7217. In this mode, the
kernel doesn't generate a link-local address for the cellular
NIC, and generates an ipv6 stable privacy global address after
receiving the RA message.

It sounds like this would violate RFC 4291 section 2.1 which says
"All
interfaces are required to have at least one Link-Local unicast
address. It is also not what 3GPP requires. 3GPP *does* require a
link-local address. It just requires that that the bottom 64 bits of
that link-local address be assigned by the network, not randomly.

Hi Lorenzo,

Thanks for your reply. :-)

Disabling the kernel's automatic link-local address generation
doesn't mean that it violates RFC 4291, because an appropriate
link-local addr can be added to the cellulal NIC through ioctl.

In fact, the current kernel has similar precedents. For example,
when device type is ARPHRD_NONE, and its addr_gen_mode is NONE,
the kernel will never generate a link-local addr for such interface.

Given that the kernel already supports tokenized interface addresses,
a better option here would be to add new addrgen modes where the
link-local address is formed from the interface token (idev->token),
and the other addresses are formed randomly or via RFC7217. These
modes could be called IN6_ADDR_GEN_MODE_RANDOM_LL_TOKEN and
IN6_ADDR_GEN_MODE_STABLE_PRIVACY_LL_TOKEN. When setting up the
interface, userspace could set disable_ipv6 to 1, then set the
interface token and the address generation mode via RTM_SETLINK, then
set disable_ipv6 to 0 to start autoconf. The kernel would then form
the link-local address via the token (which comes from the network),
and then set the global addresses either randomly or via RFC 7217.

The method you mentioned can also solve the current problem, but it
seems to introduce more logic: 
  (1) set the cellular interface addr_gen_mode to RANDOM_LL_TOKEN or PRIVACY_LL_TOKEN;
  (2) set the cellular interface up;
  (3) disable ipv6 first;
  (4) set token addr through netlink;
  (5) autoconf through the kernel;
  (6) kernel trigger send RS message;

For the current patch, it is simpler, the configure process as follows:
  (1) set the cellular NIC addr_gen_mode to RANDOM_NO_LLA or PRIVACY_NO_LLA;
  (2) set the cellular interface up;
  (3) configure the link-local addr for the NIC by ioctl;
  (4) kernel trigger send RS message;

I wonder to hear what you and David think.

Thanks,

Rocco