[BUG] gre interface incorrectly generates link-local addresses

[BUG] gre interface incorrectly generates link-local addresses

[Aleksey Shumnik]

Dear Maintainers,

I found that GRE arbitrarily hangs IP addresses from other interfaces
described in /etc/network/interfaces above itself (from bottom to
top). Moreover, this error occurs on both ip4gre and ip6gre.

Example of mgre interface:

13: mgre1@NONE: <MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc noqueue
state UNKNOWN group default qlen 1000
    link/gre 0.0.0.0 brd 0.0.0.0
    inet 10.10.10.100/8 brd 10.255.255.255 scope global mgre1
       valid_lft forever preferred_lft forever
    inet6 fe80::a0a:a64/64 scope link
       valid_lft forever preferred_lft forever
    inet6 fe80::7f00:1/64 scope host
       valid_lft forever preferred_lft forever
    inet6 fe80::a0:6842/64 scope host
       valid_lft forever preferred_lft forever
    inet6 fe80::c0a8:1264/64 scope host
       valid_lft forever preferred_lft forever

It seems that after the corrections in the following commits
https://github.com/torvalds/linux/commit/e5dd729460ca8d2da02028dbf264b65be8cd4b5f
https://github.com/torvalds/linux/commit/30e2291f61f93f7132c060190f8360df52644ec1
https://github.com/torvalds/linux/commit/23ca0c2c93406bdb1150659e720bda1cec1fad04

in function add_v4_addrs() instead of stopping after this check:

if (addr.s6_addr32[3]) {
                add_addr(idev, &addr, plen, scope, IFAPROT_UNSPEC);
                addrconf_prefix_route(&addr, plen, 0, idev->dev, 0, pflags,
                                                                GFP_KERNEL);
                 return;
}

it goes further and in this cycle hangs addresses from all interfaces on the gre

for_each_netdev(net, dev) {
      struct in_device *in_dev = __in_dev_get_rtnl(dev);
      if (in_dev && (dev->flags & IFF_UP)) {
      struct in_ifaddr *ifa;
      int flag = scope;
      in_dev_for_each_ifa_rtnl(ifa, in_dev) {
            addr.s6_addr32[3] = ifa->ifa_local;
            if (ifa->ifa_scope == RT_SCOPE_LINK)
                     continue;
            if (ifa->ifa_scope >= RT_SCOPE_HOST) {
                     if (idev->dev->flags&IFF_POINTOPOINT)
                              continue;
                     flag |= IFA_HOST;
            }
            add_addr(idev, &addr, plen, flag,
                                    IFAPROT_UNSPEC);
            addrconf_prefix_route(&addr, plen, 0, idev->dev,
                                     0, pflags, GFP_KERNEL);
            }
}

Moreover, before switching to Debian 12 kernel version 6.1.15, I used
Debian 11 on 5.10.140, and there was no error described in the commit
https://github.com/torvalds/linux/commit/e5dd729460ca8d2da02028dbf264b65be8cd4b5f.
One link-local address was always generated on the gre interface,
regardless of whether the destination or the local address of the
tunnel was specified.

Which linux distribution did you use when you found an error with the
lack of link-local address generation on the gre interface?
After fixing the error, only one link-local address is generated?
I think this is a bug and most likely the problem is in generating
dev->dev_addr, since link-local is formed from it.

I suggest solving this problem or roll back the code changes made in
the comments above.

Re: [BUG] gre interface incorrectly generates link-local addresses

[Jakub Kicinski]

Adding Thomas as well.

On Fri, 24 Mar 2023 19:35:06 +0300 Aleksey Shumnik wrote:
> Dear Maintainers,
> 
> I found that GRE arbitrarily hangs IP addresses from other interfaces
> described in /etc/network/interfaces above itself (from bottom to
> top). Moreover, this error occurs on both ip4gre and ip6gre.
> 
> Example of mgre interface:
> 
> 13: mgre1@NONE: <MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc noqueue
> state UNKNOWN group default qlen 1000
>     link/gre 0.0.0.0 brd 0.0.0.0
>     inet 10.10.10.100/8 brd 10.255.255.255 scope global mgre1
>        valid_lft forever preferred_lft forever
>     inet6 fe80::a0a:a64/64 scope link
>        valid_lft forever preferred_lft forever
>     inet6 fe80::7f00:1/64 scope host
>        valid_lft forever preferred_lft forever
>     inet6 fe80::a0:6842/64 scope host
>        valid_lft forever preferred_lft forever
>     inet6 fe80::c0a8:1264/64 scope host
>        valid_lft forever preferred_lft forever
> 
> It seems that after the corrections in the following commits
> https://github.com/torvalds/linux/commit/e5dd729460ca8d2da02028dbf264b65be8cd4b5f
> https://github.com/torvalds/linux/commit/30e2291f61f93f7132c060190f8360df52644ec1
> https://github.com/torvalds/linux/commit/23ca0c2c93406bdb1150659e720bda1cec1fad04
> 
> in function add_v4_addrs() instead of stopping after this check:
> 
> if (addr.s6_addr32[3]) {
>                 add_addr(idev, &addr, plen, scope, IFAPROT_UNSPEC);
>                 addrconf_prefix_route(&addr, plen, 0, idev->dev, 0, pflags,
>                                                                 GFP_KERNEL);
>                  return;
> }
> 
> it goes further and in this cycle hangs addresses from all interfaces on the gre
> 
> for_each_netdev(net, dev) {
>       struct in_device *in_dev = __in_dev_get_rtnl(dev);
>       if (in_dev && (dev->flags & IFF_UP)) {
>       struct in_ifaddr *ifa;
>       int flag = scope;
>       in_dev_for_each_ifa_rtnl(ifa, in_dev) {
>             addr.s6_addr32[3] = ifa->ifa_local;
>             if (ifa->ifa_scope == RT_SCOPE_LINK)
>                      continue;
>             if (ifa->ifa_scope >= RT_SCOPE_HOST) {
>                      if (idev->dev->flags&IFF_POINTOPOINT)
>                               continue;
>                      flag |= IFA_HOST;
>             }
>             add_addr(idev, &addr, plen, flag,
>                                     IFAPROT_UNSPEC);
>             addrconf_prefix_route(&addr, plen, 0, idev->dev,
>                                      0, pflags, GFP_KERNEL);
>             }
> }
> 
> Moreover, before switching to Debian 12 kernel version 6.1.15, I used
> Debian 11 on 5.10.140, and there was no error described in the commit
> https://github.com/torvalds/linux/commit/e5dd729460ca8d2da02028dbf264b65be8cd4b5f.
> One link-local address was always generated on the gre interface,
> regardless of whether the destination or the local address of the
> tunnel was specified.
> 
> Which linux distribution did you use when you found an error with the
> lack of link-local address generation on the gre interface?
> After fixing the error, only one link-local address is generated?
> I think this is a bug and most likely the problem is in generating
> dev->dev_addr, since link-local is formed from it.
> 
> I suggest solving this problem or roll back the code changes made in
> the comments above.

Re: [BUG] gre interface incorrectly generates link-local addresses

[Aleksey Shumnik]

Dear maintainers,

I remind you that the problem is still relevant.
The problem is not only in generating the number of link-local
addresses in an amount equal to the number of addresses on all
interfaces defined in /etc/network/interfaces before the gre
interface.
Due to the new method of link-local address generation, the same
link-local address may be formed on several gre interfaces, which may
lead to errors in the operation of some network services

Would you please answer the following questions
> Which linux distribution did you use when you found an error with the
> lack of link-local address generation on the gre interface?
> After fixing the error, only one link-local address is generated?
Is this a bug or an expected behavior?

On Sat, Mar 25, 2023 at 1:34 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> Adding Thomas as well.
>
> On Fri, 24 Mar 2023 19:35:06 +0300 Aleksey Shumnik wrote:
> > Dear Maintainers,
> >
> > I found that GRE arbitrarily hangs IP addresses from other interfaces
> > described in /etc/network/interfaces above itself (from bottom to
> > top). Moreover, this error occurs on both ip4gre and ip6gre.
> >
> > Example of mgre interface:
> >
> > 13: mgre1@NONE: <MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc noqueue
> > state UNKNOWN group default qlen 1000
> >     link/gre 0.0.0.0 brd 0.0.0.0
> >     inet 10.10.10.100/8 brd 10.255.255.255 scope global mgre1
> >        valid_lft forever preferred_lft forever
> >     inet6 fe80::a0a:a64/64 scope link
> >        valid_lft forever preferred_lft forever
> >     inet6 fe80::7f00:1/64 scope host
> >        valid_lft forever preferred_lft forever
> >     inet6 fe80::a0:6842/64 scope host
> >        valid_lft forever preferred_lft forever
> >     inet6 fe80::c0a8:1264/64 scope host
> >        valid_lft forever preferred_lft forever
> >
> > It seems that after the corrections in the following commits
> > https://github.com/torvalds/linux/commit/e5dd729460ca8d2da02028dbf264b65be8cd4b5f
> > https://github.com/torvalds/linux/commit/30e2291f61f93f7132c060190f8360df52644ec1
> > https://github.com/torvalds/linux/commit/23ca0c2c93406bdb1150659e720bda1cec1fad04
> >
> > in function add_v4_addrs() instead of stopping after this check:
> >
> > if (addr.s6_addr32[3]) {
> >                 add_addr(idev, &addr, plen, scope, IFAPROT_UNSPEC);
> >                 addrconf_prefix_route(&addr, plen, 0, idev->dev, 0, pflags,
> >                                                                 GFP_KERNEL);
> >                  return;
> > }
> >
> > it goes further and in this cycle hangs addresses from all interfaces on the gre
> >
> > for_each_netdev(net, dev) {
> >       struct in_device *in_dev = __in_dev_get_rtnl(dev);
> >       if (in_dev && (dev->flags & IFF_UP)) {
> >       struct in_ifaddr *ifa;
> >       int flag = scope;
> >       in_dev_for_each_ifa_rtnl(ifa, in_dev) {
> >             addr.s6_addr32[3] = ifa->ifa_local;
> >             if (ifa->ifa_scope == RT_SCOPE_LINK)
> >                      continue;
> >             if (ifa->ifa_scope >= RT_SCOPE_HOST) {
> >                      if (idev->dev->flags&IFF_POINTOPOINT)
> >                               continue;
> >                      flag |= IFA_HOST;
> >             }
> >             add_addr(idev, &addr, plen, flag,
> >                                     IFAPROT_UNSPEC);
> >             addrconf_prefix_route(&addr, plen, 0, idev->dev,
> >                                      0, pflags, GFP_KERNEL);
> >             }
> > }
> >
> > Moreover, before switching to Debian 12 kernel version 6.1.15, I used
> > Debian 11 on 5.10.140, and there was no error described in the commit
> > https://github.com/torvalds/linux/commit/e5dd729460ca8d2da02028dbf264b65be8cd4b5f.
> > One link-local address was always generated on the gre interface,
> > regardless of whether the destination or the local address of the
> > tunnel was specified.
> >
> > Which linux distribution did you use when you found an error with the
> > lack of link-local address generation on the gre interface?
> > After fixing the error, only one link-local address is generated?
> > I think this is a bug and most likely the problem is in generating
> > dev->dev_addr, since link-local is formed from it.
> >
> > I suggest solving this problem or roll back the code changes made in
> > the comments above.
>

Re: [BUG] gre interface incorrectly generates link-local addresses

[Thomas Winter]

Hello Aleksey,

Sorry, I was on leave during March so only getting to this now. I will
have a proper look at this when I get back to work on Tuesday and try
to reproduce your issue.

My issue was on our routers using kernel 5.15.89 and we don't
use /etc/network/interfaces for configuration. The tunnel was created
with netlink messages like with the "ip link" command and an IPv6 link
local address is generated by
setting /proc/sys/net/ipv6/conf/tunnel0/addr_gen_mode but this broke
after commit e5dd729460ca. I did not see any hanging addresses like you
described.

Regards,
Thomas

On Thu, 2023-04-06 at 18:04 +0300, Aleksey Shumnik wrote:
> Dear maintainers,
> 
> I remind you that the problem is still relevant.
> The problem is not only in generating the number of link-local
> addresses in an amount equal to the number of addresses on all
> interfaces defined in /etc/network/interfaces before the gre
> interface.
> Due to the new method of link-local address generation, the same
> link-local address may be formed on several gre interfaces, which may
> lead to errors in the operation of some network services
> 
> Would you please answer the following questions
> > Which linux distribution did you use when you found an error with
> > the
> > lack of link-local address generation on the gre interface?
> > After fixing the error, only one link-local address is generated?
> Is this a bug or an expected behavior?
> 
> On Sat, Mar 25, 2023 at 1:34 AM Jakub Kicinski <kuba@kernel.org>
> wrote:
> > Adding Thomas as well.
> > 
> > On Fri, 24 Mar 2023 19:35:06 +0300 Aleksey Shumnik wrote:
> > > Dear Maintainers,
> > > 
> > > I found that GRE arbitrarily hangs IP addresses from other
> > > interfaces
> > > described in /etc/network/interfaces above itself (from bottom to
> > > top). Moreover, this error occurs on both ip4gre and ip6gre.
> > > 
> > > Example of mgre interface:
> > > 
> > > 13: mgre1@NONE: <MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc
> > > noqueue
> > > state UNKNOWN group default qlen 1000
> > >     link/gre 0.0.0.0 brd 0.0.0.0
> > >     inet 10.10.10.100/8 brd 10.255.255.255 scope global mgre1
> > >        valid_lft forever preferred_lft forever
> > >     inet6 fe80::a0a:a64/64 scope link
> > >        valid_lft forever preferred_lft forever
> > >     inet6 fe80::7f00:1/64 scope host
> > >        valid_lft forever preferred_lft forever
> > >     inet6 fe80::a0:6842/64 scope host
> > >        valid_lft forever preferred_lft forever
> > >     inet6 fe80::c0a8:1264/64 scope host
> > >        valid_lft forever preferred_lft forever
> > > 
> > > It seems that after the corrections in the following commits
> > > https://github.com/torvalds/linux/commit/e5dd729460ca8d2da02028dbf264b65be8cd4b5f
> > > https://github.com/torvalds/linux/commit/30e2291f61f93f7132c060190f8360df52644ec1
> > > https://github.com/torvalds/linux/commit/23ca0c2c93406bdb1150659e720bda1cec1fad04
> > > 
> > > in function add_v4_addrs() instead of stopping after this check:
> > > 
> > > if (addr.s6_addr32[3]) {
> > >                 add_addr(idev, &addr, plen, scope,
> > > IFAPROT_UNSPEC);
> > >                 addrconf_prefix_route(&addr, plen, 0, idev->dev,
> > > 0, pflags,
> > >                                                                 G
> > > FP_KERNEL);
> > >                  return;
> > > }
> > > 
> > > it goes further and in this cycle hangs addresses from all
> > > interfaces on the gre
> > > 
> > > for_each_netdev(net, dev) {
> > >       struct in_device *in_dev = __in_dev_get_rtnl(dev);
> > >       if (in_dev && (dev->flags & IFF_UP)) {
> > >       struct in_ifaddr *ifa;
> > >       int flag = scope;
> > >       in_dev_for_each_ifa_rtnl(ifa, in_dev) {
> > >             addr.s6_addr32[3] = ifa->ifa_local;
> > >             if (ifa->ifa_scope == RT_SCOPE_LINK)
> > >                      continue;
> > >             if (ifa->ifa_scope >= RT_SCOPE_HOST) {
> > >                      if (idev->dev->flags&IFF_POINTOPOINT)
> > >                               continue;
> > >                      flag |= IFA_HOST;
> > >             }
> > >             add_addr(idev, &addr, plen, flag,
> > >                                     IFAPROT_UNSPEC);
> > >             addrconf_prefix_route(&addr, plen, 0, idev->dev,
> > >                                      0, pflags, GFP_KERNEL);
> > >             }
> > > }
> > > 
> > > Moreover, before switching to Debian 12 kernel version 6.1.15, I
> > > used
> > > Debian 11 on 5.10.140, and there was no error described in the
> > > commit
> > > https://github.com/torvalds/linux/commit/e5dd729460ca8d2da02028dbf264b65be8cd4b5f.
> > > One link-local address was always generated on the gre interface,
> > > regardless of whether the destination or the local address of the
> > > tunnel was specified.
> > > 
> > > Which linux distribution did you use when you found an error with
> > > the
> > > lack of link-local address generation on the gre interface?
> > > After fixing the error, only one link-local address is generated?
> > > I think this is a bug and most likely the problem is in
> > > generating
> > > dev->dev_addr, since link-local is formed from it.
> > > 
> > > I suggest solving this problem or roll back the code changes made
> > > in
> > > the comments above.

Re: [BUG] gre interface incorrectly generates link-local addresses

[Thomas Winter]

Hello Aleksey and maintainers,

Commit e5dd729460ca made it so the link local address for tunnels is
based on the source address of the tunnel instead of the eui64
algorithm. But it also broke changing addr_gen_mode to create the link
local address which is what my patch 23ca0c2c9340 aimed to fix.

If the last 4 bytes of a source ipv6 address are zero or in your case
where the ipv4 source address is not present "link/gre 0.0.0.0" then it
generates ipv6 link local addresses based on ipv4 addresses of all
other interfaces.

> > The problem is not only in generating the number of link-local
> > addresses in an amount equal to the number of addresses on all
> > interfaces defined in /etc/network/interfaces before the gre
> > interface.
The simple fix for this to stop the for_each_netdev loop once one
address has been generated.

> > Due to the new method of link-local address generation, the same
> > link-local address may be formed on several gre interfaces, which
> > may
> > lead to errors in the operation of some network services
Can you explain this in more detail or list some example network
services where this is a problem?
My understanding is that referencing link local address should be used
with an ifindex/name because of the local scope but not all software
enforces this.

The other solution to this is to move back to eui64 generation as was
the case before the changes in e5dd729460ca for gre/sit tunnels.

Regards,
Thomas Winter


On Fri, 2023-04-07 at 10:58 +1200, Thomas Winter wrote:
> Hello Aleksey,
> 
> Sorry, I was on leave during March so only getting to this now. I
> will
> have a proper look at this when I get back to work on Tuesday and try
> to reproduce your issue.
> 
> My issue was on our routers using kernel 5.15.89 and we don't
> use /etc/network/interfaces for configuration. The tunnel was created
> with netlink messages like with the "ip link" command and an IPv6
> link
> local address is generated by
> setting /proc/sys/net/ipv6/conf/tunnel0/addr_gen_mode but this broke
> after commit e5dd729460ca. I did not see any hanging addresses like
> you
> described.
> 
> Regards,
> Thomas
> 
> On Thu, 2023-04-06 at 18:04 +0300, Aleksey Shumnik wrote:
> > Dear maintainers,
> > 
> > I remind you that the problem is still relevant.
> > The problem is not only in generating the number of link-local
> > addresses in an amount equal to the number of addresses on all
> > interfaces defined in /etc/network/interfaces before the gre
> > interface.
> > Due to the new method of link-local address generation, the same
> > link-local address may be formed on several gre interfaces, which
> > may
> > lead to errors in the operation of some network services
> > 
> > Would you please answer the following questions
> > > Which linux distribution did you use when you found an error with
> > > the
> > > lack of link-local address generation on the gre interface?
> > > After fixing the error, only one link-local address is generated?
> > Is this a bug or an expected behavior?
> > 
> > On Sat, Mar 25, 2023 at 1:34 AM Jakub Kicinski <kuba@kernel.org>
> > wrote:
> > > Adding Thomas as well.
> > > 
> > > On Fri, 24 Mar 2023 19:35:06 +0300 Aleksey Shumnik wrote:
> > > > Dear Maintainers,
> > > > 
> > > > I found that GRE arbitrarily hangs IP addresses from other
> > > > interfaces
> > > > described in /etc/network/interfaces above itself (from bottom
> > > > to
> > > > top). Moreover, this error occurs on both ip4gre and ip6gre.
> > > > 
> > > > Example of mgre interface:
> > > > 
> > > > 13: mgre1@NONE: <MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc
> > > > noqueue
> > > > state UNKNOWN group default qlen 1000
> > > >     link/gre 0.0.0.0 brd 0.0.0.0
> > > >     inet 10.10.10.100/8 brd 10.255.255.255 scope global mgre1
> > > >        valid_lft forever preferred_lft forever
> > > >     inet6 fe80::a0a:a64/64 scope link
> > > >        valid_lft forever preferred_lft forever
> > > >     inet6 fe80::7f00:1/64 scope host
> > > >        valid_lft forever preferred_lft forever
> > > >     inet6 fe80::a0:6842/64 scope host
> > > >        valid_lft forever preferred_lft forever
> > > >     inet6 fe80::c0a8:1264/64 scope host
> > > >        valid_lft forever preferred_lft forever
> > > > 
> > > > It seems that after the corrections in the following commits
> > > > https://github.com/torvalds/linux/commit/e5dd729460ca8d2da02028dbf264b65be8cd4b5f
> > > > https://github.com/torvalds/linux/commit/30e2291f61f93f7132c060190f8360df52644ec1
> > > > https://github.com/torvalds/linux/commit/23ca0c2c93406bdb1150659e720bda1cec1fad04
> > > > 
> > > > in function add_v4_addrs() instead of stopping after this
> > > > check:
> > > > 
> > > > if (addr.s6_addr32[3]) {
> > > >                 add_addr(idev, &addr, plen, scope,
> > > > IFAPROT_UNSPEC);
> > > >                 addrconf_prefix_route(&addr, plen, 0, idev-
> > > > >dev,
> > > > 0, pflags,
> > > >                                                                
> > > >  G
> > > > FP_KERNEL);
> > > >                  return;
> > > > }
> > > > 
> > > > it goes further and in this cycle hangs addresses from all
> > > > interfaces on the gre
> > > > 
> > > > for_each_netdev(net, dev) {
> > > >       struct in_device *in_dev = __in_dev_get_rtnl(dev);
> > > >       if (in_dev && (dev->flags & IFF_UP)) {
> > > >       struct in_ifaddr *ifa;
> > > >       int flag = scope;
> > > >       in_dev_for_each_ifa_rtnl(ifa, in_dev) {
> > > >             addr.s6_addr32[3] = ifa->ifa_local;
> > > >             if (ifa->ifa_scope == RT_SCOPE_LINK)
> > > >                      continue;
> > > >             if (ifa->ifa_scope >= RT_SCOPE_HOST) {
> > > >                      if (idev->dev->flags&IFF_POINTOPOINT)
> > > >                               continue;
> > > >                      flag |= IFA_HOST;
> > > >             }
> > > >             add_addr(idev, &addr, plen, flag,
> > > >                                     IFAPROT_UNSPEC);
> > > >             addrconf_prefix_route(&addr, plen, 0, idev->dev,
> > > >                                      0, pflags, GFP_KERNEL);
> > > >             }
> > > > }
> > > > 
> > > > Moreover, before switching to Debian 12 kernel version 6.1.15,
> > > > I
> > > > used
> > > > Debian 11 on 5.10.140, and there was no error described in the
> > > > commit
> > > > https://github.com/torvalds/linux/commit/e5dd729460ca8d2da02028dbf264b65be8cd4b5f.
> > > > One link-local address was always generated on the gre
> > > > interface,
> > > > regardless of whether the destination or the local address of
> > > > the
> > > > tunnel was specified.
> > > > 
> > > > Which linux distribution did you use when you found an error
> > > > with
> > > > the
> > > > lack of link-local address generation on the gre interface?
> > > > After fixing the error, only one link-local address is
> > > > generated?
> > > > I think this is a bug and most likely the problem is in
> > > > generating
> > > > dev->dev_addr, since link-local is formed from it.
> > > > 
> > > > I suggest solving this problem or roll back the code changes
> > > > made
> > > > in
> > > > the comments above.

Re: [BUG] gre interface incorrectly generates link-local addresses

[Антарио Просперо]

Hell
I want to bring up this topic again
Is it possible to use the addr_gen_mode parameter for GRE in the current version of addrconf?
There was an edit in the e5dd729460ca commit that dev->interface type should be equal to ARPHRD_ETHER, then addrconf_addr_gen will be called.
But doesn't this contradict the fact that before calling the addrconf_gre_config function, there is a check that dev->type should be equal to ARPHRD_IPGRE or ARPHRD_IP6GRE?

Re: [BUG] gre interface incorrectly generates link-local addresses

[Thomas Winter]

Hello,

On Fri, 2024-02-02 at 13:01 +0000, Антарио Просперо wrote:
> Hell
> I want to bring up this topic again
> Is it possible to use the addr_gen_mode parameter for GRE in the
> current version of addrconf?

Short answer, no.

> There was an edit in the e5dd729460ca commit that dev->interface type
> should be equal to ARPHRD_ETHER, then addrconf_addr_gen will be
> called.
> But doesn't this contradict the fact that before calling the
> addrconf_gre_config function, there is a check that dev->type should
> be equal to ARPHRD_IPGRE or ARPHRD_IP6GRE?

Commit e5dd729460ca broke the addrconf_addr_gen sysctl value generating
a link local address for GRE tunnels which our userspace was relying
on. My commits 30e2291f61f9 and 23ca0c2c9340 attempted to resolve this
by making addrconf_gre_config get called
by addrconf_sysctl_addr_gen_mode with the new
function addrconf_init_auto_addrs which will call addrconf_gre_config.

I tried to keep the new functionality from e5dd729460ca intact so
addrconf_addr_gen is still called only when dev->type == ARPHRD_ETHER
which means that the type of address generation
(eg IN6_ADDR_GEN_MODE_RANDOM or IN6_ADDR_GEN_MODE_EUI64) is not not
considered when the type is ARPHRD_IPGRE or ARPHRD_IP6GRE instead the
address will be generated based on another interface with add_v4_addrs.