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

[Rocco Yue <rocco.yue@mediatek.com>]

On Wed, 2021-11-17 at 13:09 +0800, Lorenzo Colitti wrote:
> On Tue, Nov 16, 2021 at 3:15 PM Rocco Yue <rocco.yue@mediatek.com>
> wrote:
>> 
>> 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


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek